SOC 2 is the second version of the Service Organization Controls standard developed by American Institute of Certified Public Accountants (AICPA). It aims to evaluate an organization’s information systems relevant to security, availability, processing integrity, confidentiality, and privacy. It was developed specifically for Software-as-a-Service (SaaS) offerings that store user data in the cloud. While it is considered a technical audit, its scope is broader. It requires sensible organizational processes, which can (and must) be supported by technology.
SOC 2 compliance is determined by an auditor. This third-party auditor will investigate the processes in place at the organization and compile a report with the results. So unlike the PCI DSS, which we have written about before, it is not as easy to provide a clear cut mapping between requirements and supporting technology.
Trust Services Criteria
To get ready for a SOC 2 audit, you should prepare as much as possible beforehand. The main document you need to read is “Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy” (2017).
SOC 2 is aligned with the COSO framework. The COSO framework contains 17 principles, and the trust services criteria (TSC) in SOC 2 supplement the 12th of them. The 12th principle reads “The entity deploys control activities through policies that establish what is expected and procedures that put policies into action”. For concreteness, the TSC organizes its supplemental requirements are organized in the following four topics:
- Logical and physical access controls. The criteria relevant to how an entity restricts logical and physical access, provides and removes that access, and prevents unauthorized access.
- System operations. The criteria relevant to how an entity manages the operation of system(s) and detects and mitigates processing deviations, including logical and physical security deviations.
- Change management. The criteria relevant to how an entity identifies the need for changes, makes the changes using a controlled change management process, and prevents unauthorized changes from being made.
- Risk mitigation. The criteria relevant to how the entity identifies, selects, and develops risk mitigation activities arising from potential business disruptions and the use of vendors and business partners.
We will, of course, focus only on the parts where we can find technological support. To get the physical security aspects right, you should depend on cloud providers with the relevant certification.
The TSC are often also represented in five categories, namely the aforementioned Security, Availability, Processing Integrity, Confidentiality, and Privacy. We center our questions below around the four topics from the bullet list above, as outlined in the TSC document. How they are organized does not change their contents, after all.
Logical and Physical Access Controls
Restricted access to information systems and assets
Do you:
- continuously identify your information assets (i.e. user data), and do you manage an inventory of it?
- restrict access to information assets, in particular:
- Do you encrypt network traffic (encryption in transit)?
- Do you store data encrypted (encryption at rest)?
- Must users pass an authorization step to access output, e.g. logs, from your system?
- require that your users authenticate against all your systems?
- perform network segmentation to isolate parts of your information system from each other?
- manage your system’s points of access, such that outside entities and the types of data that can flow across these points of access are clearly documented and inventoried?
- restrict access to information assets, via e.g.
- network port restrictions,
- access protocol restrictions,
- user identification, and
- digital certificates for encryption and identification?
- use role-based access control and
- revoke access once a person no longer requires access to information,
- give the least amount of access required to each user to carry out their tasks, and
- continuously ensure that users do not have more access than needed?
- keep track of all software that is installed on your infrastructure?
- protect your encryption keys?
Protection against outside threats
Do you:
- require two-factor authentication when sensitive systems are used outside of your trusted network?
- implement boundary protection systems, such as:
- firewalls,
- demilitarized zones,
- intrusion detection systems, and
- web application firewalls?
- prevent unauthorized extraction of sensitive information, via e.g.
- restricted ability to carry out database transactions and
- encryption of all network traffic carrying sensitive information?
- perform regular security scans from outside the system to test system security?
Protection against malicious software
Do you:
- restrict ability to install software?
- prevent unauthorized changes to software configuration?
- use a defined change control process?
- use security software to detect known vulnerabilities or viruses?
System Operations
Infrastructure monitoring
Do you:
- automatically detect anomalies or unusual activities in your monitoring systems?
- prevent the use of compromised identification and authentication credentials?
- prevent outside access to your information systems?
- identify and classify anomalies using a filtering mechanism?
- measure current usage and use this information to make capacity requirement forecasts?
Security incident response
Do you:
- contain security incidents that actively threaten information systems?
- have systems in place to mitigate the effects of a security incident?
- roll back data to a known good state after an incident has been mitigated?
- perform root-cause analysis to understand the nature of security incidents?
- have procedures in place to destroy sensitive information when called for?
Disaster recovery
Do you:
- continuously determine what data requires backing up and
- make the necessary backups, and
- verify the integrity and completeness of backups so that you know restoration is possible?
- store sensitive information offsite?
- have a contingency plan for processing information using alternate infrastructure, in case your primary infrastructure becomes unavailable?
Change Management
Do you:
- manage system configuration changes throughout the system life cycle?
- carry out configuration changes via a system that
- prevents unauthorized alteration,
- documents changes made,
- tracks system changes,
- tests changes before they are active in externally accessible systems,
- requires approval in a well-established chain of command,
- supports identification and evaluation of changes made, and
- has provisions required to make emergency changes in the face of an ongoing incident?
- ensure that private and sensitive information is protected throughout change processes?
Risk mitigation
This part is highly process-centric, as it relates to keeping close tabs on identifying and managing risk concerning vendors and partners. Thus, we do not have a list of questions here. Remember that no chain is stronger than its weakest link, so you must depend on the companies you are in business with.
Summary
We have very briefly listed some of the technology-centered questions that you need to consider before you attempt to get your SOC 2 audit and certification. The audit will focus on business processes and covers more ground than these questions. However, these are the ones for which we know there is a set of technical solutions that support you in the audit process. Why? Because we have answers to all of them embedded in our Compliant Kubernetes offering. It deploys to your local infrastructure or with SOC 2 certified public cloud vendors. Contact us to find out more.
