Preparing for a Successful SOC 2 Audit

SOC 2 audits are comprehensive and demanding, requiring substantial preparation and thorough documentation to demonstrate compliance through verifiable evidence.  Due to their comprehensive nature, SOC 2 audits typically span several weeks.  The auditor will work with you to determine the most appropriate timeline for your organisation, however the following represents a  typical SOC 2 audit timeline:

• Week 1 – Audit scope and timelines agreed with auditors
• Week 2 – Auditors provide a list of evidence requests
• Weeks 3-6 – Organisation provides evidence and the system description
• Weeks 7-8 – Auditor holds audit meetings
• Weeks 9-10 – Auditor produces draft SOC 2 report
• Week 11 – SOC 2 report is reviewed and signed off
• Week 12 – Final SOC 2 report is delivered.

As demonstrated by the above timeline, SOC 2 audit organisations will provide you with a list of the evidence that they require.  This list will be very substantial, with potentially hundreds of lines of evidence being required, which is why you are likely to be allocated a window of around a month (or perhaps even longer) to provide evidence against these requests.  The auditor's evidence request list will include both policy and process documentation, as well as evidence to demonstrate that these policies and processes are being followed (screenshots of system configurations, governance meeting minutes, audit reports, results of technical tests, etc.).  

‍

‍

Since SOC 2 Type 2 audits assess operating effectiveness, the evidence you submit must clearly demonstrate that your policies and procedures have been consistently and effectively followed throughout the entire reporting period.  For example, when evidencing change management, your auditor will want to review your change management policy, minutes of change request board meetings, etc., but will also ask for a list of all change requests from within the reporting period, and review a sample of these requests and the associated detail.  

Unlike an ISO 27001 audit, where the auditor will want to hold interviews for each of the in-scope control areas, SOC 2 audit meetings will generally only occur if the auditor has questions about or does not understand some of the evidence you have provided, or if there is evidence missing.*  If the auditor is satisfied with the evidence you have provided for a particular area, that area will not require any additional discussion and will be marked as compliant.  So, you do not need to schedule audit meetings with representatives for every process, but should instead wait for the auditor to tell you which areas require a follow-up discussion.

*To learn more about the relationship between SOC 2 and ISO 27001, read our blog ISO 27001 vs SOC 2 - Part 2.

Within your SOC 2 report, you will need to articulate your service scope very clearly so that clients receiving the report have an accurate understanding of what it will and will not include.  The way your audit scope is defined will depend on the unique characteristics and operational structure of your organisation, however the key aspect to consider is your clients and their expectations.  Which clients require a SOC 2 report?  And which Trust Services Criteria (TSC) matter to them?  And, crucially, which of your services are they utilising? Answering these questions can help you figure out which parts of your business actually need a SOC 2 report (i.e., those used by your target group of existing or prospect clients) and which ones don’t, so you can leave them out of the audit.

The aim of a SOC 2 audit is to assure the ‘system’ that delivers your in-scope service(s).  The ‘system’ comprises everything that is utilised and the activities conducted to support a service’s delivery, such as the technical controls that secure the service, back-office functions that support it, the personnel that develop/deliver/secure the service, wider organisational governance elements (risk management, HR processes, communications, etc.), to name a few.   So, the audit will cover the following elements as they relate to the service(s) you have included within your scope:

• Processes and controls
• Infrastructure
• Software
• Departments and teams (organisational structure)
• Third parties.

These aspects will all need to be documented within your SOC 2 report.  The system description (one of the four standard sections that make up SOC 2 reports) includes a section where you will need to detail the infrastructure, software, and departments and teams that support your service.  There is also a detailed section where you will need to specify the key third parties that are delivering particular controls for your organisation (e.g., the data centres where your infrastructure is hosted) and how the security of these suppliers is assured. Ideally, these third parties will have their own SOC 2 report, which you can request and use as evidence within your report.

As the audited organisation, it is your responsibility to produce the system description.  The description you produce will need to document the in-scope services you deliver, and, as referenced above, the infrastructure, software, teams, etc., that are delivering those services.  Your system description also allows you to articulate the ethos and culture of your organisation, and how this is implemented.  

It is not uncommon for organisations to treat the system description as an afterthought, due to being so focused on the audit process itself and delivering the evidence requested by the auditors.  However, this approach fails to recognise the importance of the system description and the benefits it can provide; your description is an opportunity for you to present your organisation in the best possible light, and highlight the maturity of the processes and controls it has in place.  As such, you need to ensure that an appropriate amount of time is allocated to produce the system description, and that the correct staff write, review, and approve it.  Often, your audit organisation will provide a template for your description, which functions as an extremely useful starting point, but should not be relied upon too heavily.  Ultimately, it is your system description, and should be crafted to reflect your organisation’s specific strengths.

In the context of SOC 2, an audit exception is an instance of noncompliance with your documented policies or processes; for example, if your change management policy specifies that each change request should include a rollback plan, and the auditor identifies a change request that does not include this, then an exception is likely to be raised.  If a potential exception is raised by your auditor, it is important that you investigate and understand whether it is actually an exception, instead of immediately accepting it without question.  If you can justify and provide an appropriate explanation for it, the auditor may be able to withdraw the exception.  

However, if an exception cannot be explained or justified, it will be documented in your report and you will have an opportunity to provide context for the exception and explain the steps you have taken to address it.   So, even if exceptions are raised, you will still be able to demonstrate accountability and continuous improvement to stakeholders reading your report.

Undertaking a SOC 2 audit is a major commitment and will demand considerable time, effort, and resources.  You will need to work with your audit organisation to understand your fieldwork start and end dates, i.e., when you will receive your evidence requests, when they will expect those evidence requests to be fulfilled, etc.  You also need to identify which members of your organisation (including technical subject matter experts) will be providing evidence, ensure they understand what is required, and agree processes for evidence collection and validation.  For example, will you work on the basis that your subject matter experts know their processes, so will deliver evidence directly without this needing to be validated?  Or, will your compliance team collect the evidence from subject matter experts, perform a validation check of this evidence to ensure it is compliant, and then provide this to the auditor?  Either approach is acceptable, but it is important to ensure that the evidence collection and validation process you adopt is followed consistently by all personnel involved in the audit. Finally, you will need to assign someone within your organisation with responsibility for tracking audit progress and managing issues, as this will ensure you are aware if there is evidence that can’t be delivered, or if any other problems arise.

A SOC 2 Type 2 audit represents both a challenge and an opportunity: a challenge in terms of the preparation and resources required, and an opportunity to demonstrate the strength and maturity of your organisation’s information security management.  By approaching the process with foresight and discipline, your organisation will be far more likely to achieve a smooth and successful audit, receive an unqualified SOC 2 Type 2 report, and subsequently reinforce trust with key clients and stakeholders.  Ultimately, the effort invested in a SOC 2 audit delivers value far beyond the report itself.