SOC Reports and Vendor Management
Statement on Standards for Attestation Engagements (SSAE) audits are conducted by third-party auditors and are used to document and evaluate internal controls. The SOC reports produced by an SSAE audit can be reviewed as part of vendor security risk assessments. Different types of SOC reports cover different controls and scopes. The most helpful for vendor assessments is the SOC 2 Type II because it covers more of the security and IT related controls over a period of time instead of at a point in time.
Some organizations depend solely on reviewing their vendors’ yearly SOC reports for their vendor security risk assessment process. This isn’t an effective approach because SOC reports often don’t cover all the relevant security controls that you should assess your vendors for.
Components of a SOC Report
When using an SSAE audit report to assess your vendor’s security posture, two sections in the SOC report typically contain the most relevant security information.
The “Description of the System” section includes a summary of the services or a specific system. This section often contains helpful information when reviewing the organization’s security practices and operations.
The “Test Cases and Results” section describes the different test cases that the auditor used to assess whether the organization met the test criteria.
A SOC 2 Type II report often includes information about the following security controls:
- Risk Management
- Change Management
- Logical Access Controls (sometimes Physical Access Controls depending on the service or system)
- Security Policies and Procedures
- Data Backup
- System Monitoring
What’s Missing?
SOC reports aren’t always consistent in the security controls they cover. The company under audit has input about which control groups they’re assessed on. There are groups of controls that are often not in scope for SOC reports and may need to be monitored by your company using a different method.
Some of the security controls that are generally not addressed in SOC reports include:
- Details about the vendor’s incident response (IR) and disaster recovery (DR) plans. These procedures could impact your company, especially if they don’t meet your IR and DR requirements.
- Application development controls aren’t usually included and would be especially relevant if you’re assessing a SaaS solution.
- Technical testing processes such as vulnerability scanning or penetration tests.
- Security operations processes like the use of a SIEM, software patching, and secure configuration standards for servers and network devices.
- Detailed information about subservice organizations that may have access to your company’s data or that may impact the service your vendor is providing.
- Data privacy controls such as data use and sharing, data destruction and disposal, and privacy training.
Addressing the Missing Controls
In addition to reviewing SOC reports, other methods can be used to assess the controls that are missing in a SOC report, including:
- Third-party audit reports or security certifications. These are only helpful if you have information about the standards that the audit or certification is based on.
- Copies of the vendor’s security policies, procedures, and standards.
- Responses to a customized security questionnaire. It’s easier to target specific security controls or missing information by creating a questionnaire that your vendors can complete.
- Solution- or service-specific security related documentation such as network and data flow diagrams.
- The SOC reports of any subservice organizations that your vendor shares your data with, such as hosting or SaaS providers.
Conclusions on SOC Reports and Vendor Management
To streamline your vendor assessment process, it’s helpful to create a list of documentation that you need to request from your vendors on a yearly basis. You should also create a list of the relevant security controls that need to be assessed so that you can determine if reviewing your vendor’s SOC report is adequate or if additional assessment methods are needed. In most cases, a SOC report by itself does not provide enough information for a complete assessment.
