What to Expect in Your First SOC Audit

A company’s first SOC audit generally follows a standard lifecycle (and this applies to both SOC 1 and SOC 2):

• First your auditor performs a readiness assessment (also called a gap assessment) to help you prepare for your first SOC audit and identify control weaknesses that need to be addressed in order to make the first audit successful.
• Once the recommendations from the readiness assessment have been implemented and necessary controls are put in place, most companies next move to a Type 1 audit.  This is a report over the design and implementation of controls as of a point in time.
• After the Type 1 audit, most organizations move to a Type 2 audit, which is a report over the design and operating effectiveness of controls over a period of time.

Here is an example timeline that an initial SOC audit might follow:

One of the things that you can expect in all 3 phases described above (readiness, Type 1 and Type 2) is to receive a Request For Information (RFI) from the auditor.  As you transition from readiness to Type 1 and then Type 2, the RFI and the related testing become more comprehensive.  In the readiness assessment and Type 1, auditors generally only request examples of evidence to support controls and do not select samples.  In a Type 2, many controls are tested via sampling and it is often time consuming for companies to gather the evidence related to the samples.  For example, auditors may select samples of new hires and terminated employees and request evidence of system access provisioning and access removal.  One of the most challenging areas for auditors to test in the first Type 2 engagement is software and infrastructure change management.  Auditors generally select a sample of changes during the audit period and request evidence that changes were approved, documented, tested, etc.  Often times, the key components of change management controls are not included in tickets or other documentation that accompanies the change and this can result in “exceptions” in the Type 2 SOC report.  The attestation standards require that every “exception” in the design or operation of controls must be disclosed in the SOC report.  Therefore, it is very common to have exceptions in your first Type 2 SOC report.  I like to coach my clients to think of the first Type 2 as a learning experience and I let them know that they should expect to have exceptions.  Then, it is rewarding to compare the subsequent Type 2 SOC to the first one and celebrate the progress that has been made.

Here are the 5 most common exceptions that I see in SOC reports (particularly in a company’s first Type 2):

1. System access is not removed for terminated employees within 24 hours (or in accordance with company policy).
2. System access approval is not documented.
3. A risk assessment was not performed / updated during the audit period.
4. Servers are not patched in a timely manner.
5. Testing of changes is not documented and/or performed.

One of the things that I have found to be very helpful for the first Type 2 SOC audit (and also for subsequent audits) is to schedule the fieldwork towards the end of the last month of the period.  For example, using the timeline above, the period ends September 30 and the fieldwork is performed in September.  This enables the service organization to respond quickly to potential exceptions and correct certain issues before the end of the period and avoid exceptions.  For example, if the auditor identified and communicated in September that a risk assessment was not performed during the period, the client may have time to complete the risk assessment prior to September 30 and avoid an exception in the report.

Many controls are tested by observing configurations in real time.  For these controls, it would not be possible to avoid an exception as in the risk assessment example above, but the service organization may be able to update the configuration before the end of the period and this could be taken into consideration by the auditor in evaluating the exception.  For example, a company’s password policy and corresponding SOC control are that network passwords must be 8 characters.  However, the auditor identifies in Active Directory (AD) during a screen sharing session in September that they are set to 6 characters.  In this scenario, the Company could be instructed to update AD and fix the password settings before the end of the period.  The exception would still need to be identified in the SOC report, but the significance of it is diminished by the fact that it was corrected before the end of the period.

In conclusion, the information gathering requirements of SOC audits take a bit of time to fulfill so you should be sure to schedule the audit during a time when there are not conflicting priorities.  And it helps to go into the first audit knowing that it is a learning experience and that it is common to have exceptions.

Thanks for reading!