Preparing for and completing a SOC 2 audit can require hundreds of hours of manual work — but it doesn’t have to. 

In our Secureframe Expert Insights webinar held on Tuesday, January 31, Secureframe compliance expert Marc Rubbinaccio, CISSP, CISA was joined by audit partners from Insight Assurance. Marc, Felipe Saboya Gomez, CPA, CIS LA, and Jesus Jimenez, CISA, CIS LA, CIS LI, QSA, CDPSE shared insights, best practices, and tips for streamlining the SOC 2 readiness and audit process.

We’re recapping the top takeaways here. To get all their insights for simplifying the SOC 2 audit process, check out the video replay on demand.

How to Prepare for a SOC 2 Audit: Key Takeaways

Secureframe’s all-in-one compliance automation platform and trusted audit partners like Insight Assurance have helped thousands of customers get and stay SOC 2 compliant with speed and ease. Below are eight tips from our compliance expert and audit partner for getting SOC 2 ready fast.

1. Figure out if SOC 2 applies to your organization.

SOC 2 could apply to your organization if you store, process or transmit any sort of customer data. If the customer data you are handling is considered sensitive, your customers could potentially request a SOC 2 report from your organization before trusting you with their data.

There are situations where SOC 2 is a responsibility for your organization even if you do not impact customer data directly. If you are a service provider, for example, you could be responsible for specific SOC 2 requirements to support your customers’ security. Say you host customer applications on a managed platform and infrastructure. It would be your responsibility to ensure the platform and infrastructure are meeting SOC 2 requirements to support your customers compliance efforts.

If you store, process or transmit customer data or impact the security of your customer’s data as a service provider, SOC 2 applies to your organization.

2. Choose between a SOC 2 Type I or Type II report.

A SOC 2 report attests to the the operating effectiveness of an organization’s security protocols and helps establish trust between service providers and their customers.

There are two types:

• Type I reports focus on management’s description of the service organization’s system and the suitability of the design of the controls at a point in time.​
• Type II reports focus on management’s description of the service organization’s system and suitability of the design and operating effectiveness of the controls over a period of time (typically 3-12 months).

If you need to demonstrate compliance as soon as possible because a prospect requires it to close the deal, a Type I report can be a great short-term solution, especially if you’re also working toward a Type II Report. 

The goal of most organizations is to eventually get a Type II audit report that covers a 12-month review period annually. This type of SOC report takes more time and resources, but it’s also more valuable to customers. Enterprise companies or certain industries like finance often prefer to work with companies that have a SOC 2 Type II report.

3. Determine what Trust Service Criteria to include in your audit.

SOC 2 has multiple Trust Service Criteria that you can include in your audit. Security is required, but there's also availability, confidentiality, processing integrity, and privacy. 

The best way to choose is based on your environment and requests from third parties, including your customers.

• Processing integrity: Say you have a software solution that processes data and the ultimate receivable for your customer is some sort of processed data that they need to trust. Take Secureframe, for example. Our tests are performing comparisons from configuration data we receive and the tests that are built into our platform to ultimately give a pass or fail. To earn the trust of audit partners like Insight Assurance, we got a SOC 2 audit that included the processing integrity criteria. 
• Confidentiality: This TSC is important if your data is particularly sensitive for your customers, like health information, credit card data, or social security numbers. 
• Availability: Let's say you have software for medical devices and it needs to be 100% available at all times to avoid impacting your customers’ health or treatment or something like that. That’s when I would recommend looking into availability. 
• Privacy: Consider adding privacy in your SOC 2 if your customers or service providers are asking about the privacy of their data but don’t have any specific framework requirements. If they’re asking you to get compliant to GDPR or CCPA, then getting a SOC 2 audit with the privacy TSC is still a great way to establish a baseline and get prepared for compliance with those more complex data privacy laws. 

4. Identify the operational tasks required to prepare for a SOC 2 audit.

There are two main categories of controls required to be met for SOC 2: operational and technical tasks. 

Operational tasks consist of processes, procedures, and reviews required to maintain compliance throughout the year. These include: 

Employee on- and off-boarding and training

SOC 2 requirements related to employee onboarding consist of implementing a process for performing background checks for potential hires, establishing a security awareness training program that include all required modules, and requiring employees to read and accept information security policies, acceptable use policies, and a code of conduct.

All operational tasks must relate back to an established policy including timelines for conducting these activities, such as requiring security awareness training completion within 30 days of hire.

Change management

Access for these new hires must also be granted in a compliant manner. That means utilizing a roles and responsibility matrix for issuing access to systems, having an administrator or manager review and approve the access granted, and documenting the change for audit purposes.

In fact, all changes must undergo a similar process which needs to be documented and reflect back to a policy. Infrastructure and code related changes must be reviewed and approved by an individual other than the author, be properly tested, and include backout procedures in case the change needs to be reverted.

Policies and procedures

Policies and procedures need to be implemented for all operational and technical security requirements specifying how controls are being met throughout the environment. Examples of policies that need to be maintained are:

• vulnerability management
• risk management
• data protection
• network security
• software development security

These policies need to include verbiage related to all SOC 2 requirements, including who is the owner of the control, how often the control is performed, what tools are used, and the process for completing controls.

Recurring tasks

There are many tasks that require regular reoccurrences during the audit window. Keeping track of these tasks to ensure they are completed is critical for the success of your audit and your ability to maintain compliance throughout the year.

Examples of these tasks could include quarterly logical access reviews, quarterly vulnerability scanning, annual incident response tabletop exercise, annual penetration test, and annual risk assessments. It’s possible some auditors will require different frequencies of these tasks so it is important to use a tool for easy tracking and reminders.

Risk management 

Having a proper risk management program is required for SOC 2. That includes performing a risk assessment against all potential operational and technical risks, evaluating and scoring the risks in maintained documentation, then updating the risks with a mitigation timeline including process for re-evaluating the risks again at a future date.

5. Identify the technical tasks required to prepare for a SOC 2 audit.

Technical tasks are the second main category of requirements and control types. Technical tasks consist of implementing the actual security configurations related to your sensitive customer data, ensuring related systems are secure, and establishing controls around monitoring and discovering security incidents. These include:

Vulnerability management

Vulnerabilities must be identified and remediated for any managed platform or application within your environment. A multi-layered approach to vulnerability discovery that includes monitoring security feeds such as US-CERT and CISA.gov for vulnerabilities that could affect the technology and applications you use as an organization is ideal.

Another important aspect of vulnerability management is establishing a vulnerability scanning process. For cloud infrastructure, this could be using a cloud service such as AWS inspector or Azure defender for cloud. For applications this would be utilizing SAST and DAST. SAST is security analysis testing against source code during the software development lifecycle and DAST would be external vulnerability scanning against your application itself. Utilizing a combination of SAST and DAST is how you establish a strong vulnerability scanning program.

Last but not least, you should perform penetration testing annually and when significant changes occur. Using an external partner to conduct a penetration test will help you discover vulnerabilities and weaknesses that go above and beyond a vulnerability scanner’s capabilities. 

Secureframe customers can work with any of the pen testers in our trusted partner ecosystem.  

Encryption

Implementing strong encryption for sensitive data at rest and when traversing over public networks is required for SOC 2 and critical for the security of your customer data.

Logging and monitoring

Application, platform, and data logging and monitoring is critical for ensuring that the processes and configurations that were established are working as intended. Enabling logging within the environment and setting security monitoring metrics for events such as multiple failed logical access attempts, changes to critical file systems, and actions taken by administrators will help your team discover security incidents and misconfigurations within your environment quickly.

Secure server, workstation, and network configuration

Securing servers, workstations, and networks starts with ensuring all resources within your environment are configured as per vendor and industry standard security baselines including the configurations requirements set by the AICPA. These include hard drive encryption, anti-virus software, password policies, and other security requirements.

6. Use an automation platform to streamline the readiness process.

If you’re preparing for a SOC 2 audit for the first time, you may have questions like, how do I determine what exactly is required? Once I determine the requirements, how do I organize these tasks and evidence? How do I implement the necessary controls to meet these requirements?

This is where Secureframe comes in.

Using our platform you will be able to see every requirement for the SOC 2 framework, which is broken out into tests and controls. You can review these controls and determine who on your team needs to resolve the failing test and assign that person. You can also schedule a tolerance window for that test so when the tasks need to be repeated, automatic notifications to the test owner will be sent. This will help you manage all of the framework requirements.

Instead of providing screenshots of configurations to auditors you can let the Secureframe integrations do the work for you. Integrate your cloud service provider, version control tool, and other technologies to automatically pull configuration data which Secureframe will compare with the framework requirements. This comparison will result in a passing or failing test with remediation guidance directly provided in the Secureframe platform

Secureframe also offers security awareness training built into the platform. This training covers the SOC 2 requirements so you don’t have to evaluate or use another third party provider. Secureframe also offers security training for other frameworks as well, such as HIPAA and PCI DSS.

7. Understand what’s involved in the SOC 2 audit process.

There are three main stages during the audit process. The overview below specifies Insight Assurance’s process. Every auditor’s process will vary slightly but the general steps are the same.

Stage 1: Planning

That's when the audit firm does a kick off. For Insight Assurance, the goal is threefold. First, they want to understand the scope of the audit. This ensures they are only including the relevant systems, people, and data in the audit. Second, they want to identify the point-in-time data if they’re performing a SOC 2 Type I audit or the examination period if they’re performing a Type II. Third, they want to talk about the desired timeline for the audit and set expectations. 

Once they understand the scope, timeline, and the point of contact, they go into virtual interviews and control discussions. This is also called walkthroughs. Here's when they do a deep dive into your environment, policies, and procedures. 

Stage 2: Fieldwork

During this stage, the firm will perform evidence collection and testing. At Insight Assurance, they have a staff or a senior auditor do a general review to ensure there are no issues with your policies or integrations. Once that general review is complete, a partner or member of management performs a detail review. They look through all of the evidence and testing that was completed to try to identify any issues or potential exceptions that may require additional evidence. 

Stage 3: Reporting

In this last stage, the firm puts together the report with an opinion, management's assertion, description of the system, and test of controls to ensure you meet all of SOC 2 requirements. At Insight Assurance, once that report is completed, it goes through internal QA one more time and is then sent to the client. The client has the opportunity to read through all of the sections of the report, and then make any comments or suggestions on Section 3.

Once the client provides their approval, the firm issues the SOC 2 report.

8. Use an automation platform that streamlines the actual audit too.

Auditors have access to a report view, showing the framework requirements in which they are familiar with. The report view allows the auditor to review the mapped evidence to each requirement, which they can then easily document in the draft report for the customer.

Secureframe offers the auditors the ability to export evidence directly from each test or in bulk, allowing the auditors the ability to review evidence outside of the platform or download for easy archiving.

The Secureframe UI simply shows and allows filtering of mass compliance requirements such as all in-scope personnel and the configurations of their workstations, policy acceptances, and security awareness training completion.

Get and stay compliant faster with Secureframe

Saving time during the readiness and audit process results in a much faster and more efficient SOC 2 compliance process. If you’re ready to get started, schedule a demo of Secureframe.