If you’re a service provider to public companies (or to any other organization that takes corporate compliance seriously) you’ll soon encounter the need for a SOC audit. Maybe a customer will ask for one; maybe your firm will volunteer to provide one to win a prospective client.
Regardless, SOC audits are now a routine part of the compliance toolkit. So let’s talk about how to assure that the SOC audit you undertake is fit for purpose.
First understand what a SOC audit is and what it does. “SOC” stands for “service organization controls”—so SOC audits are evaluations of the internal control at businesses that provide professional services. What kind of service firms? Any, really: law firms, consulting firms, outsourced IT providers, software vendors, payroll processors; the list is endless.
Conceptually, SOC audits are similar to the evaluation of internal control over financial reporting that a publicly traded company performs to comply with Section 404 of the Sarbanes-Oxley Act; or of cybersecurity controls to comply with data protection rules.
Public corporations, however, are also liable for the effective internal control—or the lack thereof—at service providers working within their extended enterprise. Remember the data breach that struck Target in 2014? It was caused by hackers first penetrating an HVAC vendor that managed Target’s ventilation systems, and then reaching Target through its online bill payments system.
SOC audits, often done by a service auditor, are a way to help larger companies assess the internal control of smaller vendors working with them.
The crucial detail is that corporations only need assurance over whatever specific risk a vendor poses to them—which can vary greatly from one corporation to the next, and one firm to the next. That led to the creation of several kinds of SOC audits, each one addressing different needs.
The Types of SOC Audits
The American Institute of Certified Public Accountants, which oversees questions like this, established three categories of SOC audits in 2011. What’s more, the first two categories each come in two types, for a total of five possible SOC audits a firm might undertake (and five reports those audits will generate).
SOC 1 Audit. A SOC 1 audit evaluates the controls at a professional services firm that are relevant to a client company’s internal controls over financial reporting (ICFR). In other words, this is the audit a public company wants to see as part of its compliance with the Sarbanes-Oxley Act. These audits are designed to meet the needs of companies who use service organizations (user entities) and the CPAs that audit user entities’ financial statements.
SOC 2 Audit. A SOC 2 audit gives the same treatment to a professional services firm’s data security and privacy controls. A client company might want to see a SOC 2 report as it manages its own PCI compliance (for credit card processing); HIPAA compliance (healthcare data); or broader data privacy rules such as the European Union’s General Data Protection Regulation (going into effect in May 2018). This makes SOC 2 reporting more important than ever.
Both audits also come in two types.
A Type I SOC audit only reviews how a firm describes its controls, and whether the design of those controls is suitable for the objectives that a public company has, as of some specified date.
A Type II audit examines the description and design of internal controls like a Type I audit, and also the operating effectiveness of those controls for a specified period.
That is, a Type I audit evaluates whether a service firm’s internal controls are designed to do what the firm’s management claims they will do, and whether those promises will serve a client company’s needs. A Type II audit also evaluates whether those controls actually work.
SOC 1 and 2 audits are specific attestation engagements: one public company evaluating the controls of one professional services firm. Therefore the AICPA restricts SOC 1 and 2 reports to only three parties: the “end user” reading the report, the audit firm compiling the report, and the services firm undertaking the report. (A vendor wouldn’t want a SOC 1 or 2 report floating around the public anyway, since the report would likely contain sensitive information.)
SOC 3 audit. A SOC 3 audit, in contrast, is available for public consumption. It examines privacy and data security controls like a SOC 2 audit, but isn’t as extensive. For example, a SOC 3 report doesn’t describe the tests an auditor performed on the firm’s controls. Nor does it examine controls related to ICFR, like a SOC 1 audit does. (Here is a nice SOC 3 example from Amazon Web Services.)
Because a services firm can commission a SOC 3 audit for itself, that means the firm has much more discretion to decide what will or won’t be included in the audit—and to keep the final report private if it paints an unflattering picture. The SOC 3 reports you see posted on a firm’s website are mostly for marketing efforts. (The AICPA even says: “can be used in a service organization’s marketing efforts.”)
A public company that takes internal control seriously will want to see a Type II audit, whether it’s SOC 1 or 2 and generate the SOC reports necessary. The company will also want that audit done by an audit firm registered with the Public Company Accounting Oversight Board.
Setting the Scope of a SOC Audit
This question can be tricky. As we mentioned, SOC 1 and 2 audits are intended for specific companies evaluating specific vendors. That means the scope of each audit varies, depending on what the end-user company wants to know about and what the vendor believes should be in scope to deliver that.
Ultimately the scope of the audit will be decided by your firm, your customer seeking the audit, and the audit firm performing it. Schellman & Co., an audit firm that performs SOC audits, recommends a few questions for all parties to ask themselves as you decide:
- What service(s) do you need a SOC report for?
- What systems are involved in providing those service(s)?
- Are the services provided from a single location or several?
- Is the report intended for all users or only one specific customer?
The first question will determine whether you need a SOC 1 audit (for ICFR) or SOC 2 (for data security). The last question will determine whether you need a SOC 3 (to be distributed widely).
SOC 2 audits deserve special attention since cloud services are proliferating so quickly, with data security risks growing right along with them. These audits evaluate a firm’s internal controls against a set of “Trust Services Principles” developed by the AICPA, and published as Trust Services Criteria: security, availability, processing integrity, confidentiality, and privacy. How many principles are involved in your specific audit depends on the scope of the SOC 2 audit you want.
For example, if a firm only provides data storage, the SOC audit can be narrow: focusing on security and availability. On the other hand, if a firm stores and processes data (say, a medical claims processor or a CRM vendor), the SOC audit will need to examine the application and its processing integrity as well.
Setting the proper scope is a critical first step, that will dictate how much time, money, and work you spend on your SOC audit. David Lehmann, managing director of IT audit for Protiviti, has a much longer post describing how to prepare for a SOC audit and set the required scope. One key point he raises:
A thorough scoping should seek to determine for which TSP(s) customers will require assurance and which systems and components must be assessed to achieve the objective. A service organization can select any number and combination of TSPs for inclusion in the report, based on customer need and relevant contractual requirements.
Prepare for a SOC Audit
A firm can prepare for a SOC audit (of any kind) long before it actually undertakes one. The best way to do that is simply for the firm executives to ask themselves: what services will offer to customers? What regulatory risks will they face by using our services? And from those regulatory risks, what assurances will they require of us, so they can demonstrate compliance to their own auditors and regulators?
Those answers will lead to a review of your business processes. As Lehmann notes in his blog, that review will consist of a gap analysis, followed by remediation of control flaws and then testing; repeat as necessary.
A more specific set of recommendations comes from Sarah Morris at the audit firm Kirkpatrick Price. Any auditor that shows up to perform a SOC 2 audit, she says, will expect to see: (1) a risk assessment; (2) an annual review of policies and procedures; (3) an employee training program; (4) vendor management procedures (for any service firms you use); and (5) a business continuity & recovery plan.
The SOC Audit Itself
SOC audits unfold like any other and follow traditional auditing standards. First the audit firm sends an advance request for evidence it will want to see. Then the audit team will arrive at your offices to perform testing, conduct walk-throughs, and review documentation. The auditors will then document their results, and provide the SOC report to you.
How long can a SOC audit take? That depends. One good perspective on the question comes from Nicole Hemmer, a partner at Linford & Co., a firm in Denver that performs SOC audits. The on-site part of the audit should take roughly two weeks, she wrote on the firm’s blog, but:
The more control objectives included in the report generally means the longer the examination will take… For larger service organizations, or examinations that include a lot more control objectives, the testing could take place over multiple weeks.
Her point about the number of control objectives is an important one. It underlines the importance of setting a clear scope for the audit, so you (the service firm) know how much audit work is likely to happen.
Succeeding at a SOC Audit
The keys to a successful SOC audit are organization and documentation. That’s it, really. Auditors will want to see evidence, review documentation, and often talk to key employees. If you can provide all that quickly, the audit flows smoothly.
At least, that’s the idea at an abstract level. In the practical world, a vendor must study how it manages its internal control, and use technology wisely to put itself in the best position to survive an audit. That means…
Lose the spreadsheets. Spreadsheets are a terrible way to manage compliance. They can lead to duplicate data, lost data, conflicting data, or inaccurate data. (For a more thorough list of how spreadsheets can undermine effective internal control, GRC analyst Michael Rasmussen cited nine in a recent white paper, “Gaining Control Over end User Computing: Increased Pressure to Control Spreadsheets and Documents.”
Find a “single source of truth.” A single source of truth could be, for example, a data warehouse that stores all your policies, all data from any testing of controls you’ve done, and a matrix that shows which controls are assigned the risks your firm has identified. Achieving that single source of truth is what a GRC software tool tries to do.
Automate compliance processes. Certifications are a great example of this point. A firm could use manual processes: say, emailing business department heads every month, asking them to certify that all employees have access only to the data they need to see. Or the firm could automate certification: a GRC tool sends person-specific URLs so department heads can note their certifications, and compliance or security chiefs at the firm can then see where weak spots might be.
This Will Not Go Away
For all the complexity and variety of SOC audits (and we’ve barely scratched the surface of them in this post) the plain truth is that they will only grow more necessary in the future.
The cloud will let ever more service firms provide ever more services. Corporations will keep using more third parties. Pressure to govern that extended enterprise will keep growing. That means greater need of assurance over those vendor firms’ internal control—and more SOC audits. Prepare accordingly.