SOC2 has become one the common asks for a number of organizations of their current and potential business partners to prove they have controls in place over the security of their information. “Show me your SOC2 before we do business.” But should it be? What is SOC and what was it created for?
SOC now stands for “System and Organization Controls”. It used to stand for Service Organization Controls, but in 2017, the American Institute of Certified Public Accountants (AICPA) changed the acronym as they adjusted the process to enable the introduction of new internal control examinations that may be performed:
(a) for other types of organizations, in addition to a service organization’s, and
(b) on either system-level or entity-level controls of such organizations.
The AICPA? I thought they dealt with numbers and stuff. What do they have to do with information security?
A lot, actually. While the integration of information security related procedures has a part of what the CPA profession has been doing for a number of years, the story of the SOC shows how the market can define what a product is used for, as opposed to what it was intended for (see Q-tip as an example…)
This story will start with a statement of auditing standards, number 70 to be specific. Auditing standards were published to define an independent auditor’s roles and responsibilities. SAS 70, released in 1992, addressed assessing the internal controls of service organizations that had an impact on financial reporting. What and why was this important? An example would be useful here:
Imagine you run a company that created an automated system that sends out invoices, collects payments, and records transaction history. You provide services with this system for a number of companies. Your company is providing the service and is considered “the service organization.” Your customers all have a line item on their financial statements involving accounts receivable (AR). Since your company manages the components that make up their AR, your customers all rely on your internal controls to ensure what they report for their AR balance is correct. When your customers have an audit performed of their financial statements, they would normally have to have their auditors conduct procedures on your company to ensure the AR balance is correct.
Enter the SAS 70 report. This report is the result of an audit of your company. So, instead of having to answer to each audit request of your entire customer base, you can provide them with the results of your SAS70 audit.
Well, that sounds like what my company has to go through today with surveys and questioners about my IT controls. Could I use a report like that instead of filling out these different forms about our IT security?
That is pretty much what started to happen. Companies wanted the SAS 70 report to do more than what it was designed for. They wanted to claim they were SAS 70 Certified, but it was never designed to be a certification. It was an audit process designed to ensure the accuracy of information used for financial reporting. On a side note, SAS 70 also defined two types of reports that could be done:
Type 1 – Describes the controls in place at a specific point in time. The audit opinion is on the fairness of this description, and if the controls are suitability designed to meet their intended purpose.
Type 2 – Describes the controls which are then tested over a minimum of a six-month period. The audit opinion is the same as a Type 1, plus an opinion on the operating effectiveness of those controls throughout the period.
That is important to know yet, since the SOC reports today still come in those same two flavors.
In 2010, the AICPA, recognizing that the SAS 70 report was being used in ways that did not fit what SAS 70 described, created a new auditing standard, which was released as a Statement on Standards for Attestation Engagements (SSAE) specifically #16. SOC was born!
Not just one, but triplets. SOC1 still applied to financial reporting but now addressing what the public wanted: SOC2 & SOC3. SOC2 introduced information system elements that the audit could now address, specifically security, availability, processing integrity, confidentiality, and privacy. SOC3 includes the same elements and requires the same audit process as SOC2, but its report is designed for public distribution.
Then it happened again. Organizations that were not service organizations, that wanted some sort of designation they could brag about to say their information systems were secure (a topic for another day), wanted to use this as proof. So, in 2017, the AICPA updated SSAE16 with SSAE 18 and changed the SOC acronym from Service Organization Controls to System & Organization Controls. They also updated the criteria required for the five elements that SOC2 & SOC3 audits utilize and named them the Trust Services Criteria.
So, now any organization could use this SOC process to certify that their systems are secure?
While there are certainly more organizations that this is now relevant, it isn’t for every organization…and as stated before, it is NOT a certification. The SOC audit must be conducted by a CPA firm, and the report that is given is an opinion on the design and effectiveness of the tested controls, and fairness of the description. Just because you went through the SOC audit does not certify anything. The report contains details and an independent opinion of how the organization is doing in handling information the way it has promised to handle it.
SOC2 & 3 engagements also vary between entities based on what they want to prove. The firm choosing to go through a SOC2 or SOC3 audit first defines the system and boundaries that are part of the services that are being provided. Then, they choose the testing criteria from the five elements, or trust principles, that were noted earlier:
Security – This principle is mandatory for all SOC2 & 3 attestations. It addresses if information and systems are protected against unauthorized access, unauthorized disclosure of information, and the overall common elements that relate to the other four principles.
Availability – This addresses if the system is available for operation and use as committed to by agreements or contracts.
Processing Integrity – When information is processed, this principle looks at controls related to the completeness, accuracy, timeliness, and authorization steps involved in that processing.
Confidentiality – This principle involves the controls that protect information that is designated as confidential, and whether confidentiality commitments are upheld.
Privacy – This principle attests to compliance with defined SOC privacy criteria related to personal information under their domain.
So, how do I know if this is something I need?
In the case of a SOC1, it is often a desire to not have to answer to a number of audit requests that drives the decision. Sometimes, a SOC of any type is sought to differentiate yourself from your competitors. Sometimes, it is your customers or potential customers that require it. But just because they are asking for it might not mean it is really what they want. Going through the trust principles and applying that to what you do for your customers is often a good way to give yourself an initial assessment of if you should consider a SOC audit.
Security – Do I handle information that belongs to my customer that requires a certain level of security? If the security of my systems is compromised, will that affect my ability to provide as promised in our agreement?
Availability – Do I make promises related to how available my system will be to my customers? If I am making contractual uptime promises, the SOC audit may be needed to have some validation that those promises can be kept.
Processing Integrity – Am I utilizing data from my customers and processing that data to produce reports, bank transactions, invoices, or enable other critical business procedures? If that is the case, then there are usually promises involving the timely production of output, completeness of processing, and accuracy of calculations that require the scrutiny of this type of audit.
Confidentiality – Is the information provided to me by my customer confidential, or does what I do with that information after receiving it make it confidential? Do I have the appropriate controls in place to meet those commitments to protect confidential information?
Privacy – If I receive information from my customer that qualifies as personal information, do I follow the requirements for handling that information? Do I have controls related to use, retention, and disposal of that information, and do those controls meet current privacy requirements?
Just answering yes to one of the above questions doesn’t mean a SOC is the only solution. A self-assessment, or independent third-party assessment using one of the many information security frameworks that are out there could be a solution. Ultimately, it may be the requirements of your customers, stakeholders, or governing body that make the decision for you. But understanding the intention of the AICPA in creating these types of audits is a critical step in determining if it is the right path for your organization.
Jeffrey T. Lemmermann, CPA, CISA, CITP, CEH, is a senior information assurance auditor at SynerComm Inc. and is on the AICPA committee championing the CITP credential. He can be reached on LinkedIn at https://www.linkedin.com/in/jefflemmermann/
