The SOC 2 audit — an audit intended to assess the data protection practices of technology vendors and other service providers — has become a standard tool in modern risk management. Large corporations now possess huge amounts of personal or confidential data, and before they share that data with their service providers, they need some way to ensure that they can trust the providers’ cybersecurity. SOC 2 audits provide that assurance.
For vendors and service providers, this means that sooner or later you’ll need to undergo a SOC 2 audit — which is seldom a pleasant experience. SOC 2 audits are generally painstaking exercises, and if you fail a SOC 2 audit, the consequences for your business can be severe.
In other words, you need a rigorous process to guide you through the SOC 2 audit. This checklist can help you on that journey.
3 things to know before beginning your SOC 2 audit
1. Understand the framework
Start by understanding what the SOC 2 standard is and what it tries to accomplish. Study how SOC 2 does and doesn’t overlap with similar standards, such as the ISO 27001 standard for information security.
2. Know the difference between Type I and Type II
Next, you’ll need to understand the difference between Type I and Type II audits. The short answer is that Type I audits assess whether your security controls are designed appropriately when examined at a specific moment in time; Type II audits assess whether those controls actually work as intended over a period of time. Usually, you’ll undergo a Type I audit first, then a Type II audit sometime in the future.
3. Determine the scope of your SOC 2 audit
Not every SOC 2 audit needs to include all five criteria; for example, if you collect no personally identifiable information about your customers, you could exclude privacy controls from the audit. So, study the criteria first to set the scope of your audit properly.
Once you know which criteria to include, identify the systems and processes that should be in scope for examination.
7 steps to prepare for your SOC 2 audit
1. Perform a risk assessment
Conduct a risk assessment to identify the potential risks to the security and privacy of your systems and data. These could include physical risks (missing security locks on data center doors), human risks (poor cybersecurity training), regulatory risks (your incident response plan doesn’t meet expectations), business continuity risks (you don’t have a list of alternative service providers), and much more. Rank those risks based on their likelihood and potential severity. Identify which could cause the most damage, and prioritize them on your remediation list.
2. Develop policies and procedures
Policies and procedures are the lifeblood of any cybersecurity compliance program. For every risk identified in the previous step, establish and document (yes, in writing) a policy or procedure to address it. Those policies and procedures should align with the goals of the Trust Services Criteria included in your audit; and ensure that the policies are communicated to and understood by all relevant personnel.
3. Implement access controls
Many of the controls you implement will be access controls: technical controls that restrict access to IT systems to authorized users only. These controls can include strong passwords and password reset policies, multi-factor authentication, and the like.
4. Establish monitoring and logging
Set up comprehensive monitoring and logging mechanisms to track system activities. Review and analyze these logs regularly to detect (and respond to) any unusual behavior, but even more important is the mere existence of the logs — since they provide an audit trail to help you piece together what happened after an incident.
5. Draft and incident response plan
Your incident response plan outlines the steps that should be taken during a security incident. The plan should assign key tasks to specific roles, such as who responds to press inquiries, who notifies regulators, who reboots malfunctioning systems, and so forth. The plan should also include up-to-date contact information for all key employees who would play important parts in executing the plan. Once the plan is drafted, share it with all relevant employees — or even just all employees, if that’s feasible. Train everyone on their roles so they’ll know what to do in a crisis.
6. Manage your vendors
You’ll need to establish a robust vendor risk management program to oversee the vendors that you use. The details of a good vendor risk management program deserve a whole post of their own; suffice to say that you’ll need to assess the security controls of your vendors, take steps as necessary to mitigate any risks you find, and monitor those risks on an ongoing basis. (And yes, this step could indeed include you requesting a SOC 2 audit from your own vendors.)
7. Perform a pre-audit readiness assessment
This is the final step before proceeding with the actual SOC 2 audit. If you have an internal audit team, ask them to review all the work you’ve already done and find any remaining gaps that need remediation. If your internal audit team worked on your pre-audit prep, consider hiring an outside auditor for an objective assessment of your work.
The readiness assessment might well uncover additional work you still need to do. Don’t beat yourself up over that; it’s far better (read: cheaper) to spend more time on remediation before the formal SOC 2 audit rather than doing that same work after the SOC auditor finds those shortcomings and hands you the bill.
Next: Select your SOC 2 auditor
Selecting your SOC auditor is a crucial decision. In theory, the only restriction is that you must select a licensed, certified public accountant (since the SOC standard is managed by the American Institute of Certified Public Accountants), but in practice, you must carefully consider numerous factors before making your choice. Not all CPAs are suited to the SOC 2 task. Tip: if you’re looking for an auditor to help with this process, Hyperproof works with an entire network of partners that can help you complete your SOC 2 audit.
What to look for in a SOC 2 auditor
Find someone with experience
First, look for an auditor with experience conducting SOC 2 audits and experience in your industry; you want someone with a deep understanding of the sector-specific risks and compliance nuances your company faces. Check references and reviews to gauge client satisfaction and successful audit outcomes.
Look for an auditor who can provide the right guidance
Consider the auditor’s approach to SOC 2 audits. They should have a thorough understanding of the SOC 2 framework and its Trust Service Criteria and be able to provide guidance on implementing controls and processes to meet these criteria effectively. Also, consider the auditor’s communications skills since the auditor will be working closely with your team throughout the assessment (which will take at least several months, and possibly as long as a year).
Evaluate the auditor’s tools and methods
You’ll also want to evaluate the tools and methods used by the auditor; the more proficient they are with technology, the more likely they’ll conduct a comprehensive examination of your organization’s controls. (Could that lead to more cost during the audit? Yes, but consider the consequences if you pass a SOC 2 audit under faulty work and subsequently suffer a breach. The ensuing litigation costs will be far higher.)
Review cost and timeline
And, yes, do consider the cost and timeline for the audit. Obtain detailed quotes and confirm that there are no hidden fees. A transparent and reasonable pricing structure, coupled with a realistic timeline, will give you an efficient audit and a positive experience.
SOC 2 checklist: The audit itself
The SOC 2 audit unfolds like any other audit: the auditor arrives, inspects your systems, data, and other evidence, and issues an opinion on your security program.
Ideally, you will receive an unqualified opinion, meaning the auditor found no issues. Technically it’s not accurate to say you’ve “passed” a SOC 2 audit since SOC 2 isn’t designed to be a pass-fail procedure — but for all practical purposes, an unqualified opinion means you’ve passed the finish line and can provide that report to customers and sales prospects who want to see one.
Sometimes your auditor will find shortcomings in your cybersecurity program, formally known as “test exceptions.” This means the auditor will deliver a qualified opinion where they describe the exceptions found. We can group those exceptions into three categories:
1. System descriptions
System descriptions exceptions are discrepancies in how you described your system and how it actually works.
2. Control design
Control design exceptions happen when your control isn’t properly designed to fulfill its stated goal.
3. Control effectiveness
Control effectiveness exceptions are when the control doesn’t work as intended.
The auditor’s opinion will include descriptions of each test exception you have. You’ll need to correct those exceptions sooner rather than later, but their mere existence is not necessarily the end of the world. For example, suppose your controls are designed and operating effectively, but you have a few minor discrepancies in how you describe your systems and services. In that case, sales prospects might not care about that.
Serious shortcomings — say, many controls not properly designed or effective, or key controls not present at all — result in an adverse opinion. This is indeed bad news, and you’ll need to correct those weaknesses before trying again with another SOC 2 audit.
SOC 2 audits are rarely easy. That doesn’t mean they aren’t worthwhile — on the contrary, the assurance of a SOC 2 audit will only become more valuable as we keep moving into a highly digital, highly regulated world — but it does mean that your company should be sure it’s up to the challenge.
In that spirit, keep two other points in mind as you undertake a SOC 2 audit.
First, secure the support of senior management and other enterprise leaders. They need to understand why a SOC 2 audit can give your company a strategic advantage in today’s security-minded marketplace and that any new policies, procedures, or other internal controls that you introduce are worth the disruption. Otherwise, they’ll see your SOC 2 project as a nuisance to be avoided rather than a higher state of operation to be embraced.
Second, know that a GRC platform can help you manage the experience. The demands for documentation, testing, and remediation work will be demanding. Managing those demands with manual processes will inevitably lead to details falling through the cracks when SOC 2 audits are all about ensuring details don’t fall through the cracks.
A GRC tool like Hyperproof acts as a workhorse since the SOC 2 process will put you through your paces. Reaching the other side, however, is worth it.
Discover how Hyperproof can help streamline your compliance processes and enhance security. Request a demo and see it in action here.