How to Receive a Clean SOC 2 Report

Image

Controls—SOC 2 is all about controls. It's right there in the name: Service Organization Controls, S-O-C. A SOC 2 report is a de facto requirement for any organization that wants to store any customer data in the cloud, which means most SaaS or cloud service providers. Unlike PCI DSS, which is prescriptive and very technical, the American Institute of Certified Public Accountants (AICPA) has developed Trust Services Criteria which are descriptive and cover organization, communication and processes, as well as technical criteria. In other words, the SOC 2 criteria describe broadly what must be done but leave it up to individual organizations to develop controls for how. When an auditor performs a SOC 2 audit, they are looking at an organization's controls to determine whether they are well-designed and operating effectively to achieve the desired outcome.

Scoping the Audit

Defining the environment and systems is critical to audit success. The boundaries of your system and the system description will limit what is in and out of scope, and limiting scope makes for an easier audit. Since SOC 2 is primarily about the cloud environment, properly segmenting the environment and limiting access to only systems and people who need it provides a clear, well-defined boundary for auditors. This boundary will also help you define which controls you need and how they are implemented to best limit your risk. SOC 2 reports include a system description, and this should focus on the cloud service being delivered.

Understanding the Trust Criteria

To receive a clean SOC 2 report (no exceptions found), the first step is to understand the criteria which will be evaluated. The AICPA Trust Services Criteria can be downloaded from the AICPA here (PDF). This is a sizable document, and the language can be a bit difficult to read at times, but it is well worth the time. Appendix B is particularly useful as it provides examples for each criterion of the risks and types of controls that can be applied to those risks. This provides a great starting point if your organization doesn't currently have a well-documented set of controls or you are just starting out with a compliance initiative. If you already have documented controls, the next step will be mapping them to the SOC 2 criteria to ensure there is adequate coverage. Otherwise, creating a control matrix is a good next step.

Creating a Control Matrix

Having a documented control matrix will be beneficial for more than just compliance initiatives; it becomes your source for how risk controls are developed and implemented and can be useful for augmenting corporate information security policies. For SOC 2, the control matrix becomes an important reference document for auditors. For instance, Trust Services Criteria 4 relate to monitoring of controls, so creating a list of how your organization is confirming controls are well designed and operating effectively makes it easy for auditors to validate that your stated controls are in place, designed to meet your security and confidentiality commitments, and are effective in doing so. Here is a concrete example: A control in your environment says servers need to be hardened to CIS benchmarks. How are you evaluating the effectiveness of this control? Are the servers hardened to your specification before going into production? Are they meeting benchmarks on an ongoing basis? An easy way to meet the monitoring requirement is to use a tool like Tripwire Enterprise. Showing an auditor report that demonstrates compliance is an easy way to demonstrate this control is being monitored and evaluated for effectiveness. Here are some basic sample controls that may be found in a matrix demonstrating how security configuration and control monitoring may be achieved for SOC 2:

• Configuration Control 1: "All server configurations are hardened according to the CIS benchmarks before being deployed into production."
• Monitoring Control 1: "Production server configurations are monitored daily for 100% compliance with the CIS benchmarks."
• Monitoring Control 2: "A report of CIS benchmark compliance within the production environment is sent to InfoSec for review daily."

The first control says servers are securely configured, the second control tests that configuration against the standard, and the third control reports on status so that Information Security and IT teams can take action. There should be additional controls for any remediation that needs to be done but the point is having a documented set of things that mitigate risks within the system. The control itself is only the core of the matrix. There are several other components that help define the control environment and make audits easier. Here are the elements I find the most useful:

• Control ID: It's important to have a common reference for a control. Use something that works best for your organization. The ID should have some sort of schema so that it's easy to find and group like controls.
• Name: The examples above could serve as the control name. The important thing is that it's useful as a common language identifier that is distinct and descriptive enough to know what it means.
• Description: More detail about how the control is implemented. In the example above, Monitoring Control 1 may say, "Tripwire Enterprise scans production servers for compliance with the CIS policy in order to create compliance dashboards and policies." For control 2, Tripwire Enterprise could email a summary report daily so that the team could find out if any servers need additional work or remediation.
• Owner: Knowing which team or role responsible for the control helps auditors know who to interview come audit time. It may be obvious internally, but an outside observer won't know how your organization is structured.
• Criteria: Mapping each control to the SOC 2 criteria is very helpful for knowing which areas are well-covered and which may need additional controls. This may also be used if other compliance frameworks such as PCI DSS or SOX are required.
• Other Elements: Other elements your organization may find useful is frequency (continuous, daily, weekly, etc.), type (manual, policy, system, hybrid), and approach (Detect, Correct, Prevent). Any property that is useful for your control framework can be captured. Be careful not to be too ambitious if this is your first time documenting your controls. Consider what is minimally necessary to build out the initial set. You can always add more detail later.

As you begin documenting your controls, you can reference the AICPA criteria document if you get stuck or aren't sure if there is enough coverage. The samples in Appendix B are a handy guide. Also, consider that you don't have to document everything; a set of 50-75 controls is a good start. The matrix can grow over time; the important thing is having enough controls so that if a single one fails, there are enough compensating controls to fulfill the criteria.

Preparing for the Audit

If all this seems a bit daunting, don't panic. It's easy to be overwhelmed the first time going through all this. Understanding the criteria, ensuring there are enough controls to fulfill them and documenting what you have will get you off to a great start. If you have the means, bringing in an auditor to review your preparations and work through any gaps is a worthwhile investment. This up-front work will help prevent any rework and will identify any areas that need shoring up before that actual audit work begins. Once all the controls are in place and sufficiently documented, it's time to schedule the audit. Be sure that everyone who has access to the system has time cleared in their schedule for interviews and walk-throughs of the system. The auditor will need time with people to understand the system and the controls, as well as see them in action.

Type 1 and Type 2 Audits

SOC 2 has two types of basic audits: Type 1 and Type 2. Consider a Type 1 report the result of the auditor ensuring the controls are in place and well-designed. There hasn't been enough time to see them in action, or there isn't a body of evidence yet collected to prove they are effective. Unless the system has been operating for at least six months and you are very confident in your controls, a Type 1 audit is a good option for the initial review of the system. Another advantage of the Type 1 audit is any issues found can be remediated before the final report is issued, so if the auditor finds things they aren't comfortable with, there is an opportunity to shore that up. A Type 2 audit tests the controls for effectiveness, and this is where having the reports and evidence will pay off. Any automated tool that can produce evidence that controls are operating effectively will ease the burden on IT and Security staff. Auditors like these as well since it makes their jobs much easier. In particular, Criteria 3 – Risk Management, 4 – Monitoring of Controls, 6 – System Operations, and 7 – Change Management all lend themselves to tooling and automation.

Tools to Help

Excel is a great way to put together an initial control matrix. There are also a ton of great Governance, Regulation, and Compliance (GRC) tools out there, though they may be overkill at first when a spreadsheet will do until you really have a feel for what you need. For the controls themselves, File Integrity Monitoring (FIM), Secure Configuration Management (SCM), Vulnerability Management (VM), and Log Management tools can all make for a smoother audit. Each of these covers multiple control criteria and are useful for other compliance frameworks like PCI DSS, SOX, or NERC CIP. If your environment is utilizing a DevOps pipeline, these tools can be integrated into that process and provide the stage gates you need in order to ensure a secure deployment, both as a pre-check before release and as run-time monitoring solutions.

People to Help

Even with all the tools in place, audits can be a challenge – especially for small Security and IT teams. It's important to have an internal project manager to help coordinate all the activities, requests and meetings that are part of an audit. Those with responsibilities for the system will need to produce evidence, meet with auditors, and describe the functioning of controls. Those controls also must be continuously administered, maintained and monitored along with all the other operational duties required of the team. If that seems overwhelming, Tripwire can ease that burden by providing compliance help with ExpertOps. With experts to help with deploying and configuring the control solutions, tuning them to your environment and administering and maintaining them, a large part of the audit burden is shared by a team invested in your success.

In Control

Security and compliance are all about controlling for risk and being able to prove you are able to do that. A SOC 2 report demonstrates to your customers that you will handle their data securely as verified by a certified third-party. Understanding your system and environment and what risks may impact the confidentiality, integrity, or availability of that environment will help you devise the controls necessary to protect your organization and its customers. Once those controls have been designed and documented, an auditor can verify that they are well-designed and effective in meeting your security and confidentiality commitments. Compliance should not be regarded as an impediment to overcome, but a confirmation that your environment is as good as you say it is. The tools, services, people and effort you put in for SOC 2 are part of keeping a healthy and secure cloud service.