If you have recently completed a Type I SOC report, congratulations! It is no small task to prepare and complete a SOC examination. However, for most companies, a Type I SOC report is just a step in the process of eventually completing a Type II SOC report, as that is what most user entities expect on an ongoing basis. For a more in-depth explanation, read our article on the differences between Type 1 and Type 2 SOC reports. For some, the transition to a Type II SOC report is smooth and uneventful, and for others, it is a difficult experience. The purpose of this article is to share with you some of the pitfalls I have seen that have tripped up companies making this transition, in hopes that you can avoid a similar fate.
Pitfall #1 – Taking a Break
While auditing a company for its first Type II SOC report, our team noted a handful of control exceptions for samples made early in their audit period. We learned that following the completion of their Type I SOC report, management turned their attention to other matters and “took a break” from worrying about their control processes and documentation. By the time they settled back into their daily routine, they had missed performing and documenting some controls.
It is understandable to want to take a break, maybe even celebrate the accomplishment, once an audit is completed. However, the Type II audit period starts the day after the end of the Type I period, and those controls that have been implemented for the Type I SOC report will need to be performed from that time forward. Put mechanisms in place to monitor the performance of key controls to make sure they are being completed.
Pitfall #2 – Not Reviewing Your Own SOC Report & Controls
On one occasion, in asking about control activities as stated in their SOC report, I received the following response: “We didn’t know we were supposed to be doing that.” Clearly, the personnel at the organization were not familiar with the controls in their SOC report and had not been reviewing controls to make sure they were operating as intended.
The description within a SOC report, including the control activities, is the responsibility of the service organization, not the auditor. You should be aware of the controls and procedures that are included in your SOC report and be prepared to discuss those controls and provide evidence. You should also be aware of any changes in your processes and assign responsibilities accordingly when there are changes to people, processes, and systems.
Pitfall #3 – Lack of Documentation/Evidence
There is a common saying, “If it’s not documented, then it didn’t happen,” which rings true for SOC audits. If you cannot provide evidence to support the operation of a control then your auditor cannot conclude that it was operating effectively. For a Type I SOC report, auditors are looking at a sample of one, and likely a very recent sample to the “as of date” of the report. However, for a Type II SOC report, samples will be selected across the entire audit period.
I had an experience with a service organization that elected to use email communication as evidence to support the operation of a specific control. This worked well for the Type I report, but upon retrieving samples for the Type II audit, they discovered that the attachments to these emails were removed when the email was archived after six months. The samples older than six months did not have the appropriate documentation available to support the operation of the control. Make sure you have worked through how you will capture, retain, and retrieve needed documentation.
Pitfall #4 – Not Having Regular Touchpoints with Your Auditor
During one audit kick-off call, management said they migrated all their data to a different system during the year and retired the old system. I had assumed there were no changes from their Type I SOC report since we had not heard about any. Unfortunately, since a Type II audit covers a period of time, we still needed support from the old system since it was in scope during part of the period, but that system was no longer available.
Having regular touchpoints with your auditor and discussing potential or upcoming changes can help avoid these types of surprises. It allows you and the auditor to adjust plans and expectations for the audit. In the example noted above, plans could have been made to test the system prior to migration which would have been a much smoother process for all involved. Further, regular touchpoints keep the SOC report and controls top of mind for management which helps with pitfall #2 noted above.
Pitfall #5 – Insufficient Resources (Time & People) Assigned to the Audit
Depending on the size of your organization and the amount and frequency of controls, a Type II SOC examination can require a lot more time to pull sample documentation and respond to follow-up questions from auditors. Delays in providing documentation or responding to requests will lead to delays in completing the audit and receiving the final report.
For example, as an auditor, reviewing onboarding procedures for a Type I SOC report typically involves reviewing a sample of one recent new hire. However, for a Type II report, that one sample could turn into 25 samples, which requires a lot more documentation to be pulled. Further, there is likely to be some variation in the samples that will require additional discussions. All these extra things take more time. As you prepare for the Type II report, plan extra time to account for additional samples and questions.
Summary
As you make the transition from a Type I to a Type II SOC report, there are things that you can do (or avoid) to help your organization have a smooth transition, and hopefully, a clean report for your first Type II SOC report. Keep these pitfalls in mind as you navigate that process. These are also helpful to consider even after you have completed your Type II SOC report. Be diligent in performing your processes and controls, read and know your own SOC report, keep your auditor apprised of any changes to avoid surprises and last-minute requests, and plan resources accordingly for your audit.
Linford & Company is an independent CPA firm with a team of external auditors that specialize in SOC 1 and SOC 2 assessments, as well as several other audit services. If you have questions about this article or would like to learn more about how to get started with a SOC report, please contact us.
Kevin has over ten years of experience in internal controls, audit, and advisory work. Kevin started his career in public accounting at Deloitte focusing on internal controls, SOC audits, and IT assurance work. After Deloitte, Kevin filled a leadership role in the SOX Compliance group at a financial services company. Kevin is a CPA and holds a Bachelor of Science degree in Accounting from Brigham Young University and a Master of Business Administration degree from Ohio University.