Anonymous Feedback on SOC Reports

I put up a form yesterday for anyone who would like to provide their opinions about SOC reports, and the following are the results so far.  I will continue to update this page as the results come in.

If you have not spoken your mind yet, please take a few minutes and do so here:







Questions for Everyone:
1. What do you think about the launch of SOC reports? Who was responsible for the [SAS 70 has been replaced by SSAE 16] spin on the AICPA's announcement that [SAS 70 was replaced by SOC reports]?
·        New name, same old thing
·        The AICPA is responsible.
·        The industry itself. People were looking to create an easy explanation. CPAs explained to their clients that "next year, we'll be doing a SOC 1 instead of a SAS 70." The CPA may have had an engagement letter that lasted for SAS 70s until 2011, 2012, etc. and they explained to their clients what the difference was. But I think there is a direct linkage between the SAS 70 morphing into the SOC 1. Although I don't think there was enough promotion from the AICPA that mandated CPAs to more thoroughly examine and define ICFRs. Even allowing for CPAs to utilize judgment, an ICFR risk assessment may be a helpful tool that is required as part of audit documentation to demonstrate the reasons the auditors are concluding that a control is or is not an ICFR.
·        Good step in the right direction over SAS 70 reports ,but there still needs to be refinement.
·        This is more confusing for the non-compliance IT professionals than the SAS70s. Like it or not most senior IT executives I am familiar with expect there to be one report that covers everything. They understand it better if I say privacy controls are not covered instead of saying there is no SOC 2 report.
·        As a organization that previously completed a SAS 70 and now completes a SSAE 16, we received most of our information from our auditing firm (one of the big 4) and they did an excellent job of explaining the move and purpose.
2. What do you think the effect of this spin has been on the marketplace?
·         Confusion
·         Zero change, everyone is going out to get SOC 1, 2, and / or 3 attestations. Large accounting firms are gouging the market, again.
·         I am not aware of any "spin," per se. What I see is that people were expecting a SAS 70 last year and found out from their CPAs that SAS 70 is no longer a standard. I think from the get-go, SSAE 16 was seen as a replacement for SAS 70. I think the AICPA needs to take control of the use of these reports and clearly define their use/misuse in order to prevent market demand from dictating how they are used/misused.
·        Marketplace as a whole, not significant. Clients are starting to ask for either a SSAE 16 or a SOC 2 but in the end, 90% of all clients looking for these reports are just trying to check a box for their regulators. Until the regulators that are requiring organizations to check the box provide more guidance on what what the appropriate audit report should be things aren't going to change significantly.
3. How do you think the market missing the opportunity to adopt SOC2 for assurance regarding security and availability in the first year of SOC reports will affect it in the coming years?
·         Haven't seen our auditors talking much about it... nor our customer's auditors. And if they don't, our management doesn't care.
·         SOC2 is more prescriptive than SAS 70, so it is better overall. Not a lot of people jumped, but many organizations are demanding the SOC 2 from their service providers this year, therefore not much missed.
·         Unless there is a major change, the market momentum is in the direction of the SOC 1 being the report used/demanded. The SOC 1 is cheaper and less rigorous. If a company can hand over a SOC 1 and generate new business/close the deal, the SOC 1 is a document valuable for that use. The market will eventually demand those reports and if someone hands that same business lead a SOC 2, the lead may say "what is this? Where is the SOC 1?"
·         I think it will take the companies receiving the reports to pressure the vendors to include a SOC 2 report.
·         In the long run, I don't see the lack of adoption year 1, 2, or even 3 being significant. They are options available and it will take time for the market need to reach a point before organizations, particularly vendors, will take set aside the effort to adopt the correct report type(s). Unfortunately this is a catch-22 situation, vendors won't move unless clients ask/tell them to and clients won't know to do so until another force compels them to ask.
4. What are some of your personal experiences with regard to these reports?
·         We use Soc 1 and everyone is happy.
·         There are a lot of CPAs looking for IT / CISAs and similar to help interpret the SOC 2 and SOC 3, and even more IT firms looking to hire a CPA so they can sign off. I wish everyone would go NIST, HITRUST, etc. and leave the financial side to SOC1.
·         They are being rampantly misused and misunderstood.
·         I think about 25% to 50% user control considerations make no sense and you wonder if they are reviewed by anyone before the report is produced.
·         Coming from an organization that has historically done SAS 70s and being moved over to SSAE 16 last year, we are now just starting to assess what report type we really should be on based off the services we offer. The problem is, most of our clients don't even know truly why they need a report (i.e., checkbox compliance) so asking them what they want they can't decide. I think the two things that need to happen to get people onto the right reports is, 1) the audit firms having a frank conversation with their clients and making it know the report type they currently have isn't best suited for their needs. 2) the regulatory bodies that be, that require organizations to collect "audit reports" need to provide better guidance on what the appropriate type of audit report is based off services in-scope.

Questions for User Entities:
1. Why do you think service organizations that used SAS 70 to provide assurance regarding security and availability gravitated to SSAE 16 instead of SOC2?
·         Because that's what people were asking for
·         Most of our clients didn't feel they had another choice. Also, SOC2 is more specific. SAS 70 was nebulous. Many companies that had breaches and financial compliance issues had passed a SAS 70 with flying colors.
·         Because under SAS 70 they were allowed to include whatever controls they wanted. This is partiality the fault of the auditing firms for allowing organizations to include non-ICFRs under SAS70 and then also allow those same clients with those controls to automatically roll into a SSAE16. Further, since they were allowed to include controls such as security and availability that are non-ICFRs and allowed to roll into a SSAE16 there was no need to undertake the effort to convert over to a SOC2 that likely would result in them needing to test against more controls due to the defined criteria which didn't exist under SAS 70/SSAE 16.
2. Do you think SOC2 reports provide sufficient assurance regarding security and availability? If not, how do you supplement the report?
·         We use SOC1
·         No. It is still too high level. I would use NIST, HITECH, ISO2007, etc.
·         Not sure.

·        All depends on the audience receiving the report. if they are an organization that is small or has a loosely governed Information Security Program themselves then it is likely fine (i.e., they use checkbox compliance). Any organization that is significant in size, typically requiring they have a stricter, more defined Information Security Program themselves will be more critical of what controls they feel are needed because in the end, SOC 2 or not, organizations need to ensure their vendors have controls implemented that are equal to the controls they have implemented themselves.


3. What advice would you give other user entities?
·         Do what your customers are asking for and not a bit more. Deal with security as a secondary function to compliance.
·         Use common sense for your industry, size, and purpose. Do the right think to make sure you are secure and defensible in your actions. Don't take the easy way out by doing the minimum necessary, no matter the control paradigm.
·         Try to get a copy of the report and review the control gaps and UCCs with senior management before the contract is signed.
·         Make it clear to your vendors if  the service they offer you impacts your financial statements and if so, why.  If they don't have an impact to your financial statements (or at least not a direct one), do not ask for or accept a SOC1 from your vendor. Instead, push them on providing a report that speaks more directly to the controls you feel are relevant to the service they are offering you (security, availability, process integrity, etc.).
Questions for Service Organizations:
1. Why do you think customers that requested SAS 70 to provide assurance regarding security and availability requested SSAE 16 instead of SOC2?
·         Because that was what their upstream auditors were asking for (our customers are banks)
·         They either thought they had no choice or their clients/customers required them to do so.
·         Because they either don't know the difference or they know the difference but the SSAE 16s they are providing include all the controls they feel are reliant to their service, even if those controls aren't ICFRs.

2. What do you think about SOC2? Do you think that the Trust Services Principles and Criteria are adequate to provide assurance regarding security and availability?
·         I think it's okay but haven't actually been through one yet.
·         No.
·       Yes/No. It is better than nothing, but in the end, the adequacy of it is all dependent on the implementation by the service provider. Service providers get to craft their own controls and determine the scope as it pertains to those controls so you are always going to run into reports that although they are exception free, do not truly represent their environment.
3. What advice would you give other service organizations?
·         Investigate specifically what the customers want and do that.
·        Start having discussions with your clients to better understand why they are asking you for a report. From there, determine if the report you are providing them is best suited to address their needs.

Please Provide Your Anonymous Opinions About SOC Reports

Please provide your opinions about SOC reports.  I will compile everyone's anonymous feedback in a separate blog post.

Create your free online surveys with SurveyMonkey, the world's leading questionnaire tool.

It's Time for You to be Heard

I've reached a point where I think I've said all I can say about SOC reports.  So now, I want the world to hear what you have to say.  I would like to interview you if you have strong opinions about the first year of SOC reports.  

I will do a video like the ones I did for OnlineTech and CBeyond, or we can just do a Q&A format like is done in magazines if you would prefer.


You can say whatever is on your mind, but you might want to consider the following questions depending on the type of organization you work for:


Everyone:
  1. What do you think about the launch of SOC reports?  Who was responsible for the [SAS 70 has been replaced by SSAE 16] spin on the AICPA's announcement that [SAS 70 was replaced by SOC reports]?
  2. What do you think the effect of this spin has been on the marketplace? 
  3. How do you think the market missing the opportunity to adopt SOC2 for assurance regarding security and availability in the first year of SOC reports will affect it in the coming years?
  4. What are some of your personal experiences with regard to these reports? 
 User Entities:
  1. Why do you think service organizations that used SAS 70 to provide assurance regarding security and availability gravitated to SSAE 16 instead of SOC2?
  2. Do you think SOC2 reports provide sufficient assurance regarding security and availability?  If not, how do you supplement the report?
  3. What advice would you give other user entities?

Service Organizations:
  1. Why do you think customers that requested SAS 70 to provide assurance regarding security and availability requested SSAE 16 instead of SOC2?
  2. What do you think about SOC2?  Do you think that the Trust Services Principles and Criteria are adequate to provide assurance regarding security and availability?
  3. What advice would you give other service organizations?
Service Auditors:
  1. Why do you think some service auditors allowed their clients to include all of the same controls that were previously included in their SAS70 reports?
  2. Do you think more clarification is needed from the AICPA regarding what should be considered ICFR?
  3. What advice would you give other service auditors?
If you would rather remain anonymous, please take a few moments to insert your comments below.  We look forward to hearing from you.
Create your free online surveys with SurveyMonkey, the world's leading questionnaire tool.

Don't Mess With SOX

Last week I wrote about data centers, that only provide hosting services to their clients, not needing a SOC 1, and I received more comments than I've ever received from auditors arguing that physical security is relevant to ICFR.  I think I've finally figured out why SOC 2 was ignored for the most part in year one of SOC reports.

The driving force behind SAS 70 was the Sarbanes Oxley (SOX) act, and service organizations were required to provide it to their customers who are publicly traded.  SOC 2 is not relevant to ICFR, and therefore is not relevant to SOX, but SAS 70 was being relied on for more than ICFR!  It had morphed into the defacto standard for providing assurance regarding security, availability, processing integrity, confidentiality, and privacy.  SOC 1 is not designed to provide assurance regarding security, availability, etc., and it cannot contain controls that do not relate to ICFR.

I assumed that the lines were as clear to everyone as they are to me about what is relevant to ICFR and what is not.  I thought service auditors would require their audit clients to remove non-ICFR controls from their SOC 1 system descriptions, and that user organizations who had become used to receiving assurance regarding non-ICFR domains would require their vendors to provide them a SOC 2.

Judging by everything I've heard, read, and observed, I think that most people are comfortable with considering almost any ITGC control as relevant to ICFR.  If non-ICFR controls get to stay in SOC 1, then there is no need for SOC 2.  SOC 1 may not be designed to provide, but can provide adequate assurance regarding security and availability when enough non-ICFR controls are allowed in .

If SOC 1 can contain any and all ITGC controls, and SOC 2 is just supposed to be a deeper dive, then it is no wonder that people took a pass.  Put yourself in their shoes.  My customers have been happy with the report I've given them every year, and my auditor is not going to make me eliminate any of the controls that were previously included in my SAS 70 report.  Hmmm, hard decision, I'll take a SOC 1 please.

We have to be honest with ourselves, and ask the question, "Why did SAS 70 get misinterpreted as providing assurance regarding security and availability?"  Could it be that it was because SAS 70 contained security and availability related controls?  I think the answer to this question will tell us what needs to happen in order to correct the path that SOC 1 is on.

Datacenters Do Not Need a SOC 1 Just Because They Host a Financially Relevant Application

I have heard on more than one occasion that a datacenter was told by their service auditor that they need an SSAE 16 (SOC 1) report because they are hosting applications that are relevant to their customer's financial reporting.

Okay, well what if the datacenter does not have logical access to the server?  What if backup processes are controlled by the client?  Then we are left with physical access, and environmental controls.

I have walked through the types of scenarios that would need to occur before these kind of controls could have any relevance to financial reporting, and have demonstrated that it is unreasonable to conclude that they are ICFR domains.

I would like to challenge anyone out there to take a control from such a datacenter's SOC 1 report and walk through a scenario to demonstrate how the absence or failure of that control could impact their customer's financial statements.  You can leave a comment on this post, or upload your analysis here.

SOC 2 is Destined to Fail Unless We Take Action

Today, Friday, June 15th, 2012 is the one year anniversary of the launch of SOC (formerly SAS 70) reports, so I think it is an appropriate time for reflection on what went wrong with the launch, and a good time to ask for your help in pushing a solution forward that I have presented to the AICPA. I assume that, by now, everyone knows what SOC reports are, so I will not go into detail about them. Instead I will speak about what I hoped they would be, and express the reason I believe that SOC 2 is destined to fail unless we take action now. I will also explain how we have the opportunity to keep SOC 2 from failing if we unite behind an approach I call the Degrees of Risk Separation (DoRS) method.

The first time I heard about SOC reports, and learned that SOC 2 would be a report that offers assurance regarding security, availability, processing integrity, confidentiality, and privacy (SAPICP), I was pretty excited that the market would finally get period-of-time assurance from third parties regarding those important domains. Despite claims to the contrary, it is a fact that every other attestation and "certification" currently available in the market is a point-in-time assurance. I have explained the differences and why period-of-time is a superior assurance in previous posts. However, when I read that SOC 2 could incorporate "other subject matter" such as ISO 27001, PCI, HIPAA, NIST, and the Cloud Controls Matrix, I saw HUGE opportunity.

As I have explained in depth in previous posts, SOC 2 has the potential to be a report that unifies the risk assurance industry by consolidating multiple audits, standards, and compliance requirements clients have, under one umbrella engagement. The SOC 2 report will never be able to replace the other compliance requirements, but combining the audits will enable testing to be conducted just once if CPA firms partner with firms specializing in the other compliance areas or specialize in the areas themselves. The potential for SOC 2 is monumental for service organizations. Not only will organizations be able to reduce their overall compliance related costs, they will also be receiving a superior period-of-time assurance. SOC 2 screams success for everyone involved: service organizations get reduced audit fees by combining audit requirements, user entities get better assurance from their vendors, service auditors get to expand their domains into the security market, and security professionals get to work along side of CPA firms winning engagements they may not have previously won as a result.

My expectation was that the market would see SOC 2 for the huge opportunity that it is, but I was wrong. I began seeing signs that the market did not understand the potential of SOC 2 back in December of last year when I received a SOC 1 report from my company's data center and reviewed it to see if there were any differences in the controls that were covered by the report. There were no differences. All of the controls that were previously covered by the data center's SAS 70 were covered by the SOC 1 report. It was about the same time that I became active in social media, and noticed a flurry of companies reporting that they had received their "SAS 70 replacing SSAE 16 report." They claimed that their SOC 1 report proves how secure and reliable their environment is, but SOC reports were supposed to correct this misuse and misinterpretation that prevailed under SAS 70. Like SAS 70, SOC 1 (aka SSAE) is not designed to provide assurance regarding SAPICP. Fictitious logos touting "SSAE 16 Certification" popped up on websites everywhere, and I decided that I had to try to do something, so I started blogging and trying to raise awareness.

I believe that the launch of SOC reports failed in year one because no one was forced to adhere to the standards behind SOC reports that require SOC 1 reports to address only internal controls over financial reporting (ICFR). If service organizations were required to remove non-ICFR controls from their reports, they would have had to transition to SOC 2 to provide the same assurance they were previously providing their customers with their SAS 70 reports. There is a problem though. No one has defined what an ICFR control is, and there is no official approach to determining what an ICFR control is either. The only test the AICPA standard provides is that the control must be "reasonable in the circumstances." I understand why the AICPA used this language. It is very important to make sure auditors are given latitude to exercise professional judgement so they can accommodate various circumstances that may exist in particular client environments. If however, the market is allowed to define anything as ICFR, or say that inclusion of non-ICFR controls in SOC 1 is okay in some cases as one leading firm did recently, SOC 2 is destined to fail. The reason is that SOC 2 is more rigorous, and many service organizations would rather receive an audit they are comfortable passing than transition to SOC 2 and risk failing.

This is where I had an idea...what if there were a standardized, official approach to determining what an ICFR control is that preserves auditor judgement and accommodates circumstances in specific client environments? I have introduced the approach I use in previous posts, but finally finished a whitepaper on the DoRS method over the weekend after I was asked to do so by a Fortune 100 company. You can review and download the whitepaper below.

I have also started a petition to the AICPA for the official adoption of the DoRS method, and would like to ask for your support.  At the time of this post, we already have over 65 signatures, and momentum is building.  Please consider endorsing the DoRS approach to determining what an ICFR control is thereby helping to ensure that SOC 2 does not fail.  The petition form is also below.


Petition for the Adoption of the DoRS Approach to Determining ICFR



One of the challenges that face auditors of service organizations when conducting SOC1 (aka SSAE16) engagements is determining when a control is "reasonable in the circumstances." What that means, according to the SSAE 16 attestation standard, is that a control must have relevance to Internal Controls Over Financial Reporting (ICFR) for it to be included in a SOC1 report.

Without an objective approach to determining what an Internal Control Over Financial Reporting is, service organizations will continue to misuse SOC 1 (SSAE 16) reports. Details of the DoRS approach can be found here.

Many of the service organizations I speak with are frustrated with the lack of clarity around SOC reports and they do not want to be put at a competitive disadvantage by paying more for a SOC 2 report when their competitors are allowed to keep things as they were under SAS 70.

I have also spoken with service organizations on the opposite side that hope SOC 2 fails. They are more than happy to undergo a SOC 1 engagement because of the low cost and high likelihood of passing. They are actually hoping that their customers will continue to ask for a SOC 1 thinking that it addresses their security concerns.

Please consider signing this petition, and passing it along to anyone who might be concerned about the direction that service organization control reports are heading.
----------------

Sincerely,

Jon Long, CISA, QSA
CompliancePoint
jlong@compliancepoint.com
(404) 368-9228

A Good, but Disappointing Whitepaper on SOC Reports

Last week I reviewed a recently published whitepaper on SOC reports, authored by Sandy Torchia and Mark Lundin.  I applaud them on the amount of work they obviously poured into providing this guidance and could speak at length about the positive aspects of every page, but I have two major things against it.

First, I think they missed their chance to take a stand against service organizations and service auditors using SOC 1 reports incorrectly when they included this sentence on page 5 (Actually page 7 if you include the cover pages):

"A SOC 1 report generally should not cover services or control domains that are not relevant to users  from an ICOFR perspective, and it specifically cannot cover topics such as disaster recovery and privacy."

The word "generally" leaves the door wide open for anyone who wants to make the case that they are the exception and the words "should not" imply there is no definitive rule.  The AICPA has been clear on this.  SOC 1 is for ICFR, and SOC 2 is for non-ICFR.  There are no maybe's about it.  No wonder the market is so confused.

Second, they missed the opportunity to set themselves apart from those who ignored the changes in the standards in year one by including this disclaimer on page 4 (Actually page 6):

"*Note: In certain cases, a SOC 1 report might cover supporting IT controls only, depending on the nature of services provided."

Almost every word in this sentence is ambiguous.  If I were a service organization or a service auditor looking to keep things exactly the way they were under SAS 70, I would find huge comfort in this note.  The biggest problem is that "supporting IT controls" can be defined however I want.  The only real test is that the controls be "reasonable in the circumstances", according to the standard that SOC 1 is based on; SSAE16 (AT-801).

Change does not happen when people who do not want to change are given options to stick with the status quo.

Who's Who - Changing the Risk Assurance Industry Together

Last week I blogged about how the market does not seem to place value in names and reputations of service auditors when it comes to Service Organization Controls (SOC) Reports in my post titled "What is the Value of a Good Name."

This is demonstrated in the market by the fact that small boutique CPA firms are included in RFP distribution lists along side of Top 10 CPA firms, and are even winning engagements over Top 10 CPA firms.  These firms, who had to stop using the names of their firms, that became irrelevant when SAS 70 was replaced by SOC reports last year, have attractive audit fees, but they do not have as much to lose as the larger firms.

Larger CPA firms that, in some cases, have reputations spanning over 100 years do not roll the dice on attestation engagements that risk damaging their names.  They make sure that audits are performed with sufficient care to mitigate that risk, and that care translates to more time spent conducting the audit.  More time translates to higher cost.  Higher cost means higher audit fees.

So I got to thinking, "How can we change this?"  I mean, as long as user organizations see no difference between reports signed by small boutique CPA firms and reports from Top 100 or even Top 10 CPA firms, then what's the use?  Why should Top 100 CPA firms even bother risking their reputations on SOC reports?

There needs to be a Global Registry of Service Organizations similar to Visa's Global Registry of Service Providers that lists service organizations along with their auditor, and the date of their attestation.  The transparency that such a list provides will distinguish the service organizations that used larger CPA firms from those who used small boutique CPA firms.

Service organizations that make the extra investment to secure a report from Top 100 CPA firms may be in a more competitive position in the market as compared with those who do not.  An additional benefit to creating this registry will be the ability to cross reference against DataLossDB.org to see who the service auditor was when companies are breached.  Service auditors with good track records can be rewarded, and those with bad ones can be replaced.

I think that this registry will need to be ultimately created and kept by an independent organization such as the AICPA, or incorporated in registries such as the Cloud Security Alliance's CSTAR, but I also realize that these things take time.  So to get the ball rolling in the meantime, I have added a page to my blog called "Who's Who."

This registry can be populated by anyone, so whether you are a service auditor, service organization, or a user entity, please feel free to enter the information as it is available to you.  I am going to be entering every piece of information that I come across as well, so this could end up being a pretty decent list.  I will compile the information, and refresh the list periodically.

Together we can change the risk assurance industry.  Let's go for it!

What is the Value of a Good Name?

Quick, what is the first thing you think of when you hear the name "Arthur Andersen?" I am not going to get into the details of the Enron scandal, but if you are like me, you associate Arthur Andersen and the firm's demise with Enron.

Having a Good Name

I looked Arthur Andersen up on Wikipedia, and learned a little about who the founder of this CPA firm was. According to Wikipedia: "Andersen, who headed the firm until his death in 1947, was a zealous supporter of high standards in the accounting industry. A stickler for honesty, he argued that accountants' responsibility was to investors, not their clients' management. During the early years, it is reputed that Andersen was approached by an executive from a local rail utility to sign off on accounts containing flawed accounting, or else face the loss of a major client. Andersen refused in no uncertain terms, replying that there was "not enough money in the city of Chicago" to make him do it. Leonard Spacek, who succeeded Andersen at the founder's death, continued this emphasis on honesty. For many years, Andersen's motto was "Think straight, talk straight."

So how did such an honest man's name get tarnished to the extent that his legacy, a Big 5 CPA firm, had to go out of business a few decades after his death? All it took was the association of his name with dishonest people. 9.3 billion dollars per year was the value of having a good name to the formerly respectable CPA firm Arthur Andersen. Based on this example and others that history has given us, it is safe to conclude that having a good name is equal to the value of an auditor's very existence in the industry...or is it? What happens when honesty, integrity, and reputation is not valued in the market?

Relying on a Good Name

Yesterday, I found myself explaining why a prospect should choose one CPA firm over another for their SOC engagement. When I explained to them that the value of one CPA firm over another boils down to the reliability of the name on the report, they asked me if anyone really cares about that. I replied that if that if no one cares, then it almost makes sense to go with the absolute lowest price that you can obtain the SOC report for. The only problem is that the auditor I select to provide assurance about me is a reflection of my own integrity. Please let me explain.

A couple of months ago, Ernst & Young was selected to be Facebook's auditor. Why would Facebook select Ernst & Young over some small, unknown, boutique CPA firm that specializes in auditing financial statements of social media companies? Well, it is obvious at that level. Facebook's IPO could be worth 100 billion dollars, and they want to inspire the most confidence that their accounting is accurate. How does that translate down to the level of this prospect though? Even if they could afford the audit fees, Ernst & Young would probably not even accept this prospect as a client for being too small.

This is where strong, reputable, regional CPA firms come in. For example, in Texas, one of the CPA firms I work with is Whitley Penn who has been listed on the “Best of the Best” list of INSIDE Public Accounting's rankings of the top 100 accounting firms in the U.S., for ten of the last eleven years. They have offices in Dallas, Fort Worth and Houston, 36 partners, 280 employees, and a worldwide network affiliation via Nexia International. Most of the CPA firms I work with are on the Top 100 list.

Contrast the recognized reputation of Whitley Penn with several boutique CPA firms that I know of, who stopped using the previous names of their firms when the SAS 70 standard was replaced by SOC reports last year. Their previous name being no longer relevant, they started or resumed doing business under different names, and yet they still appear next to credible CPA firms in RFP distribution lists?!

I recently heard from a Top 10 CPA firm that they lost a SOC engagement opportunity to one of these boutique CPA firms. When Top 10 CPA firms lose audit engagements to small boutique CPA firms that specialize in providing SOC reports, there is a major problem in the market.  If I selected a boutique CPA firm over a Top 10 CPA firm, I would not blame anyone for considering me the anti-Facebook in terms of caring what people think about my auditor. If I did this, it would demonstrate to others that I place no value whatsoever in a good name, and perhaps it is a reflection my integrity.

In selecting a service auditor, or a service provider for that matter, I would ask myself one simple question; "What does the firm stand to lose if my data is compromised, and their firm's reputation is called into question along with mine?" Do you want a firm that has little to lose, or one who has much to lose. I guarantee you that the firm with the most to lose will be the most thorough in their examination of your internal controls. Perhaps that is where the issue is though. Much like the railroad utility executive's attitude toward the young Arthur Andersen, maybe companies want their auditors to look the other way.

It's time we take a stand against cheap risk assurance, and start relying on CPA firms with good names again in the risk assurance industry.


SOC 2 - The Customer Security Questionnaire Killer


Last week, I had a conversation with the Founder and CTO of Tripwire, @RealGeneKim on Twitter.  Gene was lamenting the fact that each of his bank customers hands them a 300 question security survey to complete in order to prove that they are secure.  He said that they answered 1,000 of these in 2011 alone.  

I popped in on his timeline and said that a SOC2 engagement, and subsequent report could help reduce or eliminate those surveys.  He said he loved it because,"300q surveys are like Distributed Denial of Service (DDoS) attacks on suppliers."

This is a widespread issue facing CISOs and CTOs.  In fact, a CEO (@ebellis), and Chief Security Architect (@mortman) at two well-known companies also joined in the conversation and confirmed the headaches and resource drain these surveys cause.

This is just one of the opportunities that SOC 2 reports present to service providers and service auditors.  The reason these survey exist is that security professionals know that SAS70, and SSAE16 are unreliable indicators of an organization's security posture.  User organizations figured out a long time ago that if they want confirmation of how secure their suppliers are, they have to find out for themselves because a sufficient third party attestation did not exist. 

This is also where the challenge to service auditors is though.  In order to replace customer security surveys and customers exercising their "right to audit", the SOC 2 engagement and resulting report needs to be at least as thorough as customer surveys.  That's not all though...there's some disturbing news.  

In dialoguing back and forth with @ebellis and @mortman, it became apparent to me that they would prefer a kick to the tires level of an audit like SAS70 or SSAE16, and live with the security surveys.  That's a huge problem for service auditors.  Why might this be the case?  We went back and forth about stricter audits not being the answer, and talked about the transparency CloudAudit provides, but here's my analysis.  Service auditors have a lot of work to do to earn the trust of security professionals. To quote @mortman, "Why trust auditors more than vendors?"  This problem also manifested in a SOC 2 audit clause that I blogged about in my post titled, "Do You Trust Your Service Provider's Auditor?"  

This is an extremely damning statement that should be taken seriously by service auditors.  How in the world did we get to the place where auditors are not trusted?  I can tell you how I think it could have happened.  Could it be that conflict of interest has established a foothold in the risk assurance industry?  Please see my posts on the topic titled: "Conflict of Interest is the Root of Cheap Risk Assurance" and "What is the Value Proposition of Knowing My Son's Password?"


All of that being said, I still firmly believe that SOC 2 presents an opportunity for service auditors to win  the trust of security professionals and help them reduce or eliminate the workload that answering customer surveys places on their daily lives.  Hopefully we will help them increase their productivity, and contribute to increasing their bottom lines.  

The formula for trust is when expertise intersects with intent.  If auditors do a good job of matching security expertise with the service organization's intent of answering their customer's security questions, we will establish trust.  Service auditors and security professionals will not get there, however, with a business as usual approach, and a "we can do it all" mentalilty as I discussed in my post title, "Don't Worry, I've Got This."

Upload a security questionnaire from your customers, and if you already have a SOC 2 report through one of our CPA firm partners, we'll map it to your SOC 2 controls for you.  If you have not had a SOC 2 engagement, we will map it to the Trust Services Principles and Criteria for you.  Just leave your contact information in the comments field.

_____
    UPDATE from Gene Kim



SOC1 (SSAE16) is the King of a Very Small Hill

Yesterday, there was a post on Data Center Knowledge titled "Why SOC 1/SSAE 16 is Still the King of the Hill."  The post celebrated the fact that data centers chose SOC 1 over SOC 2 in the first 12 months since the launch of SOC reports.  This really perplexes me, because my firm belief is that the market missed a huge opportunity by going with the status quo in year 1 of SOC reports.  So I asked myself, why would someone celebrate when there is no cause for celebration?  Perhaps people do not see how small the hill, that the SOC 1 King sits on, is.

I'm not sure if everyone is aware or not, but the cloud wars have begun, and companies are racing to the cloud.  The AICPA understood this seismic shift, and the need for risk assurance other than the product that had been criticized by the Gartner Report as follows:


So in a climate where data centers are competing fiercely to win the business of SaaS customers, what happened after the launch of SOC reports?  Everyone rushed out to get their SOC 2 report, the one that the AICPA said is the right report for cloud security...right?

Not exactly.  Everyone decided to sit tight and embrace the status quo (please see a partial list of companies that selected SOC 1 over SOC 2 here).  The market heard "SSAE 16 replaces SAS 70", and promptly went out and received their SAS 70 replacing SSAE 16 report.  I would think that CPAs would be extremely disappointed about this rather than calling for a celebration of the SOC 1 King.


There are some majestic mountains right in front of us, and a King of the Mountain of cloud security has not been crowned yet.  If CPAs do not want to expand their dominion beyond assurance related to internal controls over financial reporting (ICFR), perhaps there is another that can adapt the SOC 2 audit methodology, and establish themselves as King of the Mountain.

Will the Idea of a Trust Services Self Assessment Questionnaire Fly?

In the Payment Card Industry (PCI), there is something called a Self Assessment Questionnaire (SAQ).  The SAQ is a very useful tool for small businesses who need to provide their customers and credit card transaction processors a basic level of comfort that they are compliant with the requirements set forth in the PCI Data Security Standards (PCI-DSS).  The SAQ includes a form that is signed by management called an Attestation of Compliance (AOC).

Granted, those who understand risk assurance know that an AOC from management is really, no assurance at all, but for some, it is enough to satisfy their need to transfer risk back to management.  Should a breach occur and credit card information be stolen, the recipients of an AOC can say, "Well, you told us you were compliant with PCI-DSS."

This is where I got to thinking...wouldn't it be great if the Trust Services Principles & Criteria (TSPC) had a similar mechanism!  

Here's a situation where a TSPC SAQ and AOC would be perfect.  I received an inquiry recently from a small business owner who had received a contract award for $50,000, and was looking for a quote on a SOC 2 report to satisfy the client's request.  When I told him what the report was likely to cost, he concluded that it was not economically feasible to go forward with even a Type 1 SOC 2 report.

What this company needs is an entry level assurance mechanism sanctioned by the AICPA and CICA that they can use to satisfy their customer's requirement for management assurance.  If the customer needs to see backup evidence, the small business can provide it.

There is one problem though.  The TSPC are a list of principles and criteria (or control objectives as I know them from my Sarbanes Oxley days), and it's not as easy as checking "In Place", or "Not in Place", like the PCI SAQ is.  Management has to spell out the specific controls (or control activities as I know them), that they have implemented in response to the TSPC.

The problem can be solved by listing the Illustrative Controls from the TSPC with a check box next to it as well as a check box that says "Other."  If management chooses, "Other", they can write in a custom control, or reference a control number from CoBIT 5, NIST 800-53, ISO 27001, or the CSA's Cloud Control Matrix (CCM).  If other standards are referenced in response to a TSPC criteria, the other standard can be attached so the detail can be viewed by the customer.

The responsibility for determination about the suitability of the control design can be placed squarely on management and the user organization in the fine print so that it is understood that the AICPA and CICA do not have any liability whatsoever.

I realize that there are many complications and issues that will undoubtedly be raised, but lets see if this idea will fly!  If not, we can say we tried, but if it does, we might change the risk assurance industry together.


What I Don't Know Blows My Mind

(UPDATE:  Since writing this post, I came across a great blog post titled: "Learn to hack."  This may help some out there who want to begin to deepen their security knowledge so they can perform high quality SOC 2 engagements.)


Recently, I have come under fire for writing about SOC reports because I am not a CPA.  It is not really relevant to you, but I think that these people would attack me even if I were a CPA.  They would say that I'm not a partner of a CPA firm, I don't have enough experience in a Big 4 public accounting firm, my firm isn't audited by the PCAOB, etc., etc.  The bottom line is that it is easier to challenge my qualifications for speaking than it is to debate the subject and issues I am speaking about.

Well I'm going to come out and just say it.  Just thinking about what I don't know completely blows my mind.  As I write about a topic, I make sure that I know enough about what I am saying so that I can at least defend my position based on the facts that I have, but my mind remains completely open to alternate points of view and facts that I have not considered.

This is where I had an idea...there are a lot of CPAs who think they understand security, and a lot of security professionals who think they understand auditing and assurance.  What if I post a few videos on deep, yet fundamental topics in each area?  The goal would be to demonstrate that CPAs need true security professionals and vice versa.

Thanks to my friend @Hacksec's introduction to @SebastianThrun, I discovered a phenominal resource called Udacity that offers free education from instructors at real institutions of higher learning, and promptly enrolled in CS387: Applied Cryptography.  The videos I have embedded below are from the course.  Please watch them when you have a few minutes.  The ease with which the instructor explains these very fundamental yet complex principles, compared with my difficulty comprehending his words enough to pass his simple quiz blew my mind.

My point is that when it comes to security and risk assurance, we need each other.  The "we can do it all" mindset of some service auditors is not only ignorant, it is arrogant, and should not be indulged by service organizations.  CPA firms need to understand that they are entering the security market for the first time.  SAS 70 was not designed to provide assurance about security, nor was it accepted by people who knew better as assurance regarding security.  Systrust and Webtrust were ignored by the market for the most part.

With SOC 2 we have the opportunity to leverage each other's strengths as I enumerated in my blog posts titled "So many security standards..." and "Don't worry...", and actually make a difference in the world of security.  If CPAs and security professionals join forces, we may have a real opportunity to defeat, or at least discourage those who would try to cause mayhem in our IT infrastructures.

Enjoy the topic of cryptography (cryptology to be more accurate).  Perhaps I will continue the theme in another post, and concentrate on some things CPAs know that security professionals do not.




Here's the answer to the quiz.  By the way, if you get this one, you are much smarter than me, but you should enroll in the course, and watch some of the other things this instructor teaches!  CS387: Applied Cryptography


Introducing the Term "SSAE SOC2"

I have been watching the SOC (formerly SAS 70) reports market since early last year, even before June 15th - the official date that SAS 70 died, and have taken note of many things. Among the good things I have noticed in the market is use of the term "SSAE SOC2." Whoever came up with this term is a genius. I noticed this term first in a blog post by @Internap.


The term is genius because it helps people overcome the fixation that people have unfortunately developed with the term "SSAE 16" while remaining 100% accurate.  Others have tried to do the right thing by getting a SOC2 report (SSAE 16 is not designed to provide assurance about security), but needing to satisfy their customer's misguided demand for an SSAE 16 report, told everyone that they had an "SSAE 16 SOC2" report.  This is not accurate because SSAE 16 has to do with SOC1 instead of SOC2.

The reason the term "SSAE SOC2" is 100% accurate is that SOC2 is based on AT-101 which is in turn based on SSAE 10, SSAE 11, SSAE 12, and SSAE 14 (I just had to go double check).

Okay, so you may be asking, "WHO CARES?", and wishing you could say, "Quit boring me!"


Here's why I care...last year, and into this year, we all witnessed the market completely ignore the changes in the standards the AICPA made to service organization control reporting.  The AICPA was clear..."SOC reports replace SAS 70", and "SSAE 16 is not designed to provide assurance regarding security, availability, processing integrity, confidentiality, or privacy." 


Instead, the market heard "SSAE 16 replaces SAS 70", and what happened?  Well, but for a few elite service organizations, everyone rushed out and got their SSAE 16 report.  Why? Because that's what customers were asking for.  The RFP said "SSAE 16", so service organizations gave them an "SSAE 16."

What the term "SSAE SOC2" enables us to do is easily transition to the report that IS designed to provide assurance regarding Security, Availability, Processing Integrity, Confidentiality, and Privacy - a SOC2 report.  The term will ease the minds of people that have latched onto the term "SSAE 16", and as long as SOC2 engagements are performed by competent security professionals, service organizations will be more secure, and user organization's data will be better protected.

Automating the DoRS™ Analysis

There has been an overwhelming response to the Degrees of Risk Separation (DoRS) concept, and I got to thinking...why not automate the analysis so that a list of controls can be uploaded, and a DoRS number can be automatically assigned?  To do this, I will need a fairly large database of sample SAS 70 and/or SSAE 16 controls so that the pattern recognition software can do its job and accurately determine the number of DoRS that separate the control from the risk of financial misstatement.

This is where I would like to ask for your help.  Please use the form below to upload your list of controls.  I do not need the entire SAS 70 or SSAE 16 report, just the list of controls.  It would also be great if the company names were already sanitized to save me some time and keep things confidential.  If you include your email address in the comments section, I will send you a $5 Starbucks eGift card for your trouble.

Thanks for your help!  Together we are going to revolutionize the risk assurance industry.

Do You Trust Your Service Provider's Auditor?

I recently came across a really impressive RFP example that included SOC2 audit requirement language.  You can  view and download it here.


Besides calling for a SOC2 report in connection with security, the great thing about the originator of this RFP (whoever they are) is that they included this language:

The Contractor’s SOC 2 Audit Plan shall identify the independent entity that will perform the Contractor’s SOC 2 Audit, or a description of the means by which the Contractor will select its SOC 2 independent auditor. The OUR COMPANY Contract Manager will have 10 days to review and comment on the SOC 2 Audit Plan, and shall identify any concerns with the scope of the audit, the independence or capability of the SOC 2 auditor, or the described plan to obtain an independent SOC 2 auditor. 

In other words, the contract manager is empowered to veto the auditor that the service organization selects!  This is great news for ethical auditors and very bad news for unethical auditors.

This started me thinking.  On what grounds would a contract manager veto a selected auditor?  How about using the same basis that ethical auditors use to screen the clients that they accept?  One of my CPA firm partners introduced me to the concept of prospective client background investigations.  Please see the following (sanitized)verbiage from an actual form they require all prospective clients to fill out:

Due Diligence Background Investigation Disclosure Form

We may, with your consent, obtain a background investigation report related to a prospective or current business relationship you may have with us. This may include procurement of a consumer report or an investigative consumer report (defined as a report that includes information as to your character, general reputation, personal characteristics, or mode of living).

By signing below, you grant permission to us or any of our affiliated or subsequent companies to obtain such report or reports at any time. You also grant permission to all parties to release information regarding your previous or current military service, employment, education, or criminal matters, including information which may be deemed negative.

Detailed background reports are available for $29.95 on People Smart.  I would encourage anyone accepting third party risk assurance from their service providers to do a quick Google search to find out who the executives of the audit firm are, and make an objective decision about whether to accept their risk assurance or not.