SOC 2 Requirements: A Practical Checklist

SOC 2 certification is the credential most B2B SaaS deals now require before a contract gets signed. Technically, SOC 2 is an attestation, not a certification, but buyers search "SOC 2 certification" and that is the shorthand we will use here. What matters is not the label. What matters is whether you can pass an independent audit without scrambling for six months first.

This checklist covers what SOC 2 actually requires, in the order most companies tackle it. Use it to scope your own readiness effort, or to sanity-check a vendor's proposal.

1. Pick Your Trust Services Criteria

SOC 2 is built around five Trust Services Criteria: Security, Availability, Processing Integrity, Confidentiality, and Privacy. Security is mandatory for every SOC 2 report, it covers access controls, system monitoring, and protection against unauthorized access. The other four are optional and depend on what you sell and what your customers ask about.

• Security (mandatory): access management, network protections, vulnerability management, incident response.
• Availability: relevant if customers care about uptime commitments or SLAs.
• Processing Integrity: relevant if you process transactions or data where accuracy and completeness matter (payments, billing engines).
• Confidentiality: relevant if you handle sensitive business data under NDA or contract.
• Privacy: relevant if you handle personal information directly, separate from your general security posture.

Most first-time SaaS companies scope Security plus Availability and stop there. Adding criteria you do not need adds audit cost and evidence burden without moving the deals that are actually blocked.

2. Choose Type I or Type II

A Type I report checks whether your controls are designed correctly as of a single point in time. A Type II report checks whether those controls actually operated effectively over a period, typically three to twelve months. Enterprise buyers increasingly ask for Type II by default, since it demonstrates the controls held up in practice, not just on paper. If you are early and need something to show prospects quickly, Type I can bridge the gap, but expect most serious deals to eventually require Type II.

3. Define Your System Boundary and Scope

Before any controls work starts, you need a written description of the system being audited: what infrastructure, applications, and data flows are in scope, who your subservice organizations are (AWS, payment processors, subprocessors), and where the boundary sits. Getting this wrong is one of the most common causes of delay, either the scope is too broad and drags in systems that do not need auditing, or too narrow and leaves gaps a buyer's security team will flag during due diligence.

4. Build the Core Control Set

This is the bulk of the work. At minimum, expect to implement and document controls across:

• Access control: role-based access, least privilege, periodic access reviews, offboarding procedures.
• Change management: code review, deployment approvals, rollback procedures.
• Risk assessment: a documented process for identifying and evaluating security risks, done at least annually.
• Vendor and subprocessor management: due diligence on third parties that touch your data.
• Vulnerability and patch management: scanning cadence, remediation timelines, tracking.
• Incident response: a written plan, defined roles, and evidence you have tested it.
• Business continuity and disaster recovery: backup procedures and a recovery plan, tested periodically.
• Security awareness training: onboarding and annual training for staff.
• Logging and monitoring: centralized logs, alerting, and a defined review cadence.

Auditors are not just checking that a policy document exists. They want evidence the control operates as written, which is why Type II reports pull samples across the audit period rather than a single snapshot.

5. Write Policies That Match Reality

A common failure mode is buying a policy template pack, publishing it, and then running operations that do not match what the policies describe. Auditors will catch this. Policies need to reflect what your team actually does, not an idealized version of it. If your policy says access reviews happen quarterly, you need four quarters of evidence showing they happened.

6. Collect and Organize Evidence

For a Type II audit, you need evidence spanning the entire observation window, screenshots, exported logs, ticket records, signed-off reviews, training completion records. Manual evidence collection is the single biggest time sink in most readiness projects. Automated evidence collection tools can cut this down significantly, but someone still needs to map each control to the right evidence and keep it current as systems change.

7. Run a Readiness Assessment Before the Real Audit

A readiness assessment, sometimes called a gap assessment, tells you where your control environment falls short before an independent CPA firm looks at it. This step catches the issues that would otherwise surface mid-audit, when fixing them costs more time and can push your report date. It is also where most of the actual project risk lives, so it deserves a fixed scope and a clear deliverable rather than an open-ended engagement.

8. Engage an Independent CPA Auditor

SOC 2 reports must be issued by a licensed CPA firm that is independent of the organization being audited. This is a hard requirement under AICPA standards, a readiness consultant cannot also issue your report. The practical path most companies take is to work with a firm that handles readiness and control implementation, then hand off to an independent CPA auditor for the formal engagement. That separation is not a formality, it is what makes the report credible to the enterprise buyers asking for it.

This is the model traztech's compliance readiness work follows: fixed-scope preparation to close control gaps and organize evidence, then coordination with an independent CPA firm for the actual attestation. We are not the auditor, and we do not pretend to be. Our job is making sure the audit is short, predictable, and does not surface surprises.

9. Plan for Continuous Compliance

SOC 2 is not a one-time project. Type II reports cover a period and need to be renewed, typically annually, to stay useful in sales conversations. Building your control environment with ongoing maintenance in mind, rather than a one-off sprint to a report date, saves significant rework the following year. Companies that also need to demonstrate AI governance maturity alongside SOC 2 should look at how that overlaps with frameworks like ISO 42001 readiness, since some evidence and controls carry across both.

The Bottom Line

SOC 2 requirements come down to five Trust Services Criteria (Security is mandatory), a choice between Type I and Type II, a defined system boundary, a working set of controls with real evidence behind them, and an independent CPA firm to issue the report. The checklist above is the scope. The hard part is execution, and where most projects lose months is in evidence collection and control gaps that only surface once an auditor starts asking questions.

If you are staring down a SOC 2 requirement from a customer or investor and want a straight answer on scope, timeline, and cost before you commit to anything, get in touch with traztech. We will tell you what your actual gap looks like, not sell you a bigger engagement than you need.

How the Criteria Are Actually Organized

The checklist above is the practical scope. The auditor works from a different structure, and knowing it saves you arguments. The Security criterion is expressed as nine common criteria groups, CC1 through CC9, covering the control environment, communication and information, risk assessment, monitoring, control activities, logical and physical access, system operations, change management, and risk mitigation. Underneath each sit points of focus, which read like requirements but are not. They are illustrative considerations, and the auditor's job is to judge whether your controls meet the criterion, not to tick every point of focus.

This matters commercially. A vendor selling you a hundred and fifty mandatory controls is selling you their template, not the standard. A smaller company can meet CC1, which concerns governance and the tone set by leadership, with a documented management review cadence, defined security responsibilities in role descriptions, a code of conduct, and background screening, rather than with a board committee it does not have. What you cannot do is skip the criterion. Every criterion needs at least one control mapped to it, operating, and producing something.

What a Control Looks Like When It Is Finished

Teams tend to declare a control done when the policy is published. A control is finished when four things exist. There is a written statement of what happens, how often, and who does it. There is a named owner, by role. There is a system that produces a record without anyone remembering to save one. And there is a filed artefact with a date on it.

Take quarterly access review as the worked example. The finished version reads roughly like this: on the first business day of each quarter, the engineering manager exports the full user list from the identity provider, the cloud console, the production database, and the code repository; compares it against the current employee and contractor roster from the HR system; marks each account keep, modify, or remove; files removal tickets within five business days; and stores the four exports, the annotated comparison, the tickets, and their closure confirmations in the evidence folder for that quarter.

That is what an auditor samples. Notice how much of it is not policy. The exports are the population, the annotated comparison is the reviewer's judgement, the tickets are the action, and the closure confirmations are the proof the action completed. A review where a manager glanced at a list and said it looked fine produces nothing, and produces nothing is indistinguishable from did not happen.

Run the same treatment across every control on the list: what produces the record, who owns it, where does it get filed, how often. Our free Workspace exists to hold exactly that register, with each artefact attached to the controls it proves and a refresh date derived from the control's cadence.

What Auditors Ask Your Staff, and How to Prepare Without Coaching Them

Walkthrough interviews surprise teams. The auditor speaks to an engineer, a manager, and often someone in a non-technical role, and asks them to describe a process in their own words. The purpose is to test whether the documented control matches lived practice.

The questions are predictable. Walk me through how a code change gets to production. What would you do if you noticed something suspicious in the logs. Who approves a new vendor. How did you get access to the production database, and who approved it. When did you last do security training, and what did it cover. How do you know a backup would restore.

Prepare by making sure the process is real, not by scripting answers. Two things help. First, tell staff plainly that guessing is worse than saying they do not know and will find out, because a confident wrong answer creates a contradiction in the auditor's notes that then has to be resolved. Second, do a dry run internally a fortnight before fieldwork. Ask three people the six questions above and listen for the gap between what the policy says and what they describe. That gap is your remaining work, and it is far cheaper to find it yourself.

The Risk Assessment That Survives Contact With an Auditor

Risk assessment is the requirement most often satisfied with a downloaded spreadsheet that was never revisited. Auditors have seen every template in circulation, and they test the same thing each time: did this drive any decision.

A defensible risk assessment is short and traceable. Identify the risks in terms of your actual business, not generic categories, so a compromised deployment credential leading to unauthorized production access rather than cyber attack. Rate likelihood and impact with a scale you defined and can explain. Record the treatment decision, which may legitimately be acceptance, and name the owner and the date. Then, critically, link at least some of your controls back to specific risks, so the control set reads as a response rather than as a purchased list.

Update it at least annually and after anything material: a new product line, a new region, a significant vendor, a security incident, a funding event that changes the threat picture. Keep the previous versions. An auditor who sees the same document with the same date two years running has learned something about how the programme is run, and it is not favourable.

Not Applicable, Exceptions, and Compensating Controls

Three positions get companies in trouble because they are used loosely. Not applicable is a legitimate position when the underlying activity does not exist in your environment, for example physical data centre controls when everything runs in a cloud whose provider carries them as a subservice organization. It is not a legitimate position when the activity exists and you simply do not do it. Write the reasoning down, because the question will be asked.

An exception is a documented, approved, time-bounded deviation from your own policy. A service account that cannot use multifactor authentication because the legacy system does not support it becomes an exception with an owner, a compensating measure such as source address restriction and elevated logging, an expiry date, and a review. Without those elements it is not an exception, it is a control failure with paperwork.

Compensating controls are what you offer when the primary control is genuinely impossible, and they have to address the same risk rather than an adjacent one. The test is whether you can state the risk the original control mitigates and explain how the substitute mitigates that same risk. If the explanation requires several steps and a hopeful assumption, the auditor will not accept it, and neither should you.

Building the Control Set Once for Several Frameworks

Most companies that need SOC 2 will be asked for something else within two years, and the expensive mistake is building a second programme from scratch when the overlap is large. ISO 27001 asks for 93 Annex A controls plus the management system requirements in clauses 4 to 10, and a substantial share of the technical and operational controls map directly onto what SOC 2 already made you do. What does not carry over is the management system layer: the scope statement, the statement of applicability, internal audit, and management review, which is real additional work rather than a rebadging exercise. HIPAA and PIPEDA overlap on access control, training, incident response, and vendor management, then add their own obligations around notification and individual rights.

The practical approach is to collect evidence once and tag it with every framework requirement it satisfies. One access review record can serve SOC 2, ISO 27001 and HIPAA simultaneously if it is filed somewhere all three can reach and labelled accordingly. What forces duplication is separate folders per framework maintained by separate people, which produces three versions of the same artefact and, within a year, three that disagree. If a second framework is likely, decide now, because retrofitting the mapping later is more work than doing it as you go. Our ISO 27001 implementation work is usually cheaper for a company that already holds a SOC 2 report, for exactly this reason.

What You Can Safely Skip, and When Not to Buy Help

A checklist encourages completeness, so it is worth saying which items are commonly over-built. You do not need a formal security operations centre, a dedicated security tool for every category, or a policy set running to forty documents. Ten to fifteen policies that describe what you actually do will outperform a forty document library nobody reads, because auditors test against what your policies claim, and every unnecessary claim is another thing to prove.

You also may not need us. If your team includes someone who has run this before, buy a scoping review and an auditor introduction rather than a full engagement. If your entire environment is one cloud account, one application, twelve people, and a single sign-on provider, the control set is small enough that a disciplined engineering lead can build it from the published criteria in a quarter of focused effort. If the request came from one prospect and nowhere else in your pipeline, prepare the questionnaire answers and the policies, commit contractually to a report date, and revisit when a second buyer asks.

Where outside help genuinely pays is judgement under time pressure: deciding scope so you do not audit systems that did not need auditing, spotting the control that will fail sampling before the auditor does, and holding the evidence cadence together through an observation window while your team ships product. If that is the problem, an ongoing compliance retainer is a more honest purchase than a large one-off project, because the failure mode this checklist is really guarding against is not a missing control. It is a control that worked in month one and quietly stopped in month four.