SOC 2: documentation and compliance requirements

This is what SOC 2 requires you to have, clause by clause, and what an auditor will ask to see for each of it. It covers 119 requirements across 22 areas.

It is deliberately not a checklist. A checklist asks whether you have something; this says what is required and what counts as evidence, which is the question that matters when you are building a system rather than testing one. If you would rather find out where you stand first, the same ground is covered by our free SOC 2 readiness assessment, which scores you out of 100.

PART 1 — Getting the scope right (needed for BOTH Type 1 and Type 2)

Clause Scope.

You must be able to describe the system you want the report to cover — the services, the infrastructure, the software, the people, the procedures and the data.

Evidence: A draft system description. Architecture and network diagrams. Data flow diagrams. The list of applications, environments and locations in scope.

You must have written down what you promise customers, and what the system needs to deliver it.

Evidence: Your service commitments and system requirements — from contracts, SLAs and published statements.

You must have written down what is OUTSIDE the boundary, and why.

Evidence: The exclusions and the reasoning.

You must have chosen which trust services categories the report will cover.

Evidence: The selection with reasoning. Security is compulsory. Availability, Confidentiality, Processing Integrity and Privacy are optional — pick them because customers ask, not because it looks complete. Adding Privacy when nobody asked for it is a common and expensive mistake.

You must have listed the suppliers who run part of your system, and decided how to treat each one.

Evidence: Your subservice organisations — cloud, hosting, payroll, managed security. Whether each is carved out or included, and the reasoning.

Where a supplier is carved out, you must have written down what you are relying on them to do.

Evidence: The complementary subservice organisation controls identified.

You must have written down what you rely on your CUSTOMERS to do.

Evidence: The complementary user entity controls, drafted and communicated to customers. A report assuming customer-side controls the customer does not know about is misleading.

PART 2 — Do the controls exist and are they well designed? (BOTH types)

Clauses CC1.1, CC1.2, CC1.3, CC1.4, CC1.5.

You must have a code of conduct, and does everyone sign up to it.

Evidence: The code, approved and dated. Acknowledgement records for staff and contractors.

People must be able to report unethical behaviour, and you must act when they do.

Evidence: A reporting channel that is publicised. Evidence of use and of action taken.

You must screen people before you hire them, where you are allowed to.

Evidence: Background check policy and records.

There must be a board or equivalent that oversees the business independently of management.

Evidence: A charter, membership and minutes showing oversight of internal control.

Your must be structure, reporting lines and authority clear.

Evidence: Organisation chart. Documented roles and authority limits. A delegation matrix.

You must be able to answer: Are conflicting duties split between different people?

Evidence: A separation of duties analysis. Where a small team makes it impossible, what you do instead.

You must hire, develop and keep competent people.

Evidence: Job descriptions stating security responsibilities. Onboarding records. Training including security awareness at hire and annually. Cross-training for key roles.

People must be held accountable for their control responsibilities.

Evidence: Performance reviews covering control duties. Evidence of consequences where they were not met.

PART 2 continued — Information and communication

Clauses CC2.1, CC2.2, CC2.3.

You must generate the information you need to run and monitor your controls.

Evidence: The sources used: logs, tickets, dashboards, scan results, vendor reports. Evidence of their quality and completeness.

That information must be actually looked at, not just produced.

Evidence: Evidence of review.

Your people must know the objectives, the policies and their own responsibilities.

Evidence: Policies published and acknowledged. Awareness communications. A route to report an incident, known to everyone.

You must communicate with customers and other outside parties about the system and how it is controlled.

Evidence: Service descriptions, SLAs and published security information. A route for outsiders to report a problem or a vulnerability.

You must have told customers what THEY need to do for the controls to work.

Evidence: Evidence the complementary user entity controls were communicated.

PART 2 continued — Risk assessment

Clauses CC3.1, CC3.2, CC3.3, CC3.4.

You must have set objectives clear enough that you can work out what could go wrong.

Evidence: Objectives derived from your service commitments and system requirements.

You must have assessed the risks to those objectives, using a written method.

Evidence: A risk methodology with criteria. A risk register with likelihood, impact and a resulting level.

You must be able to show that the assessment done by people who actually understand the system.

Evidence: Who did it, and when.

You must have specifically considered the risk of FRAUD.

Evidence: A fraud risk assessment covering fraudulent reporting, theft of assets, corruption and insider misuse — including privileged access abuse and bypassing change control. This is the element most often left out entirely.

You must assess how changes — to the business, leadership, technology, vendors or regulation — affect your controls.

Evidence: Assessments done after actual changes. Evidence the risk register was updated.

PART 2 continued — Monitoring

Clauses CC4.1, CC4.2.

You must monitor whether your controls are working — both continuously and through separate checks.

Evidence: Ongoing monitoring: alerting, dashboards, exception reports, supervisory review. Separate evaluations: internal audit, self-assessment, penetration testing, third-party review.

The people doing the separate checks must be competent and objective.

Evidence: Their qualifications and independence.

When you find a weakness, it must be recorded, escalated and fixed.

Evidence: A deficiency log with severity and owner. Escalation to management and the board. Remediation tracked to closure and re-tested.

PART 2 continued — Control activities and policies

Clauses CC5.1, CC5.2, CC5.3.

You must have mapped every criterion in scope to at least one control.

Evidence: A control matrix showing the criterion, the control, the owner, the frequency and what the evidence is.

You must be able to answer: Do those controls actually address the risks in your risk register?

Evidence: The link between the register and the matrix. Controls that exist independently of any identified risk are a warning sign.

The controls over technology must be covered — the general IT controls the other controls depend on.

Evidence: Controls over the systems supporting your in-scope controls.

You must have policies that set out what is expected, and procedures that put them into practice.

Evidence: The policy set with approval, owner and review date for each. Procedures matching the policies.

The written must procedures match what people actually do.

Evidence: Walkthrough notes comparing the document with observed practice.

PART 2 continued — Access, logical and physical

Clauses CC6.1, CC6.2, CC6.3, CC6.4, CC6.5, CC6.6, CC6.7, CC6.8.

You must have an access control policy, and is authentication configured to match it.

Evidence: The policy. Password and multi-factor configuration. Your identity store settings.

Data must be encrypted at rest and in transit, with keys properly managed.

Evidence: Encryption standards in use. Key management arrangements.

You must know what information assets you have and how sensitive each is.

Evidence: An asset inventory with classification and owners.

Access must be given only on approval, and is least privilege applied.

Evidence: The request and approval workflow. Role definitions showing people get only what they need.

Access must be changed when someone moves role, and removed when they leave.

Evidence: A joiner, mover and leaver procedure. Termination checklist with revocation evidence.

Access must be reviewed periodically, over the whole user population.

Evidence: The review procedure, who reviews, the population covered, and action taken on what they find.

Privileged accounts must be identified, justified and monitored.

Evidence: A privileged account register with the reason for each.

Physical access to offices, server rooms and data centres must be controlled.

Evidence: Badge systems, visitor management and escorting. Where hosting is with a supplier, what you rely on them for and how you evidence it.

Equipment must be and media securely wiped or destroyed before disposal or re-use.

Evidence: Sanitisation procedure. Certificates of destruction. Asset return on termination.

You must be protected at the boundary — firewalls, remote access, endpoint protection.

Evidence: Firewall and boundary configuration. VPN with multi-factor. Endpoint agent coverage figures.

The must be movement of information restricted and protected.

Evidence: Transmission encryption. Removable media controls. Data loss prevention where used.

You must prevent or detect unauthorised or malicious software.

Evidence: Anti-malware coverage. Controls on who can install software. Patch management with timescales by severity. Dependency scanning for third-party components.

PART 2 continued — Operations and incidents

Clauses CC7.1, CC7.2, CC7.3, CC7.4, CC7.5.

You must detect configuration changes and unusual activity.

Evidence: Configuration and baseline monitoring. Vulnerability scanning schedule.

You must log and monitor, with alerts that reach a person.

Evidence: What is logged, from where, retained how long, and protected how. Alerting rules. The expected response time.

You must evaluate security events and decide which are incidents.

Evidence: Classification criteria and triage evidence.

You must have an incident response plan, with roles, escalation and notification criteria.

Evidence: The plan. Contact list including out of hours. Customer and regulator notification criteria and timescales. Forensic and evidence preservation arrangements.

You must review after an incident and change things as a result.

Evidence: Post-incident reviews. A tabletop exercise where you have had no real incident.

You must be able to recover from an incident — with backups that have actually been restored.

Evidence: Backup scope, frequency, retention and encryption. Restore test evidence. Recovery objectives. Where hosting is with a supplier, the commitments obtained and how you verify them.

PART 2 continued — Change management

Clause CC8.1.

Changes to infrastructure, software, data and procedures must be authorised before they happen.

Evidence: A change policy defining change types including emergency. A ticketing workflow with request, risk assessment, approval, test, deployment approval and verification.

Development, test and production environments must be kept separate.

Evidence: Environment separation. Controls on promoting between them.

You must be able to answer: Are the people who write the code different from the people who deploy it — or is there a compensating check?

Evidence: Separation evidence, or the compensating control where the team is too small.

Source control must be in place, with branch protection and code review.

Evidence: Repository configuration and review evidence.

You must be able to answer: Do changes have a way back if they go wrong?

Evidence: Back-out plans in the change records.

PART 2 continued — Risk mitigation and vendors

Clauses CC9.1, CC9.2.

You must have business continuity arrangements for the system in scope.

Evidence: The continuity plan and evidence of testing.

You must have a vendor risk process — identify, tier, check before engaging, and monitor afterwards.

Evidence: A vendor register with tiering. Due diligence records. Security terms in contracts. Ongoing monitoring.

You must obtain and actually read your suppliers' own SOC 2 reports.

Evidence: The reports obtained, and evidence you reviewed the complementary user entity controls they list and implemented them.

You must have arrangements for offboarding a vendor, including getting your data back or destroyed.

Evidence: Offboarding records.

PART 3 — Ready for a TYPE 1 report? (stop here if Type 1 is all you need)

Clause Readiness.

For every control in your matrix, you must have found and looked at the evidence — before the auditor asks.

Evidence: An evidence sample retrieved for each control and reviewed internally.

You must have walked through every control yourself.

Evidence: Internal walkthrough notes.

There must be any control that exists on paper but has never actually been performed.

Evidence: An honest list. For a Type 1 the control must be suitably designed AND implemented as at the report date — a control that has never run will fail the walkthrough.

The must be management assertion drafted.

Evidence: The draft assertion.

You must have a plan with dates for every gap, finishing before the report date.

Evidence: The remediation plan with owners and dates.

PART 4 — TYPE 2 ONLY

Clauses Period, Population, Evidence, Operation.

You must have fixed the period the report will cover — the start date, the end date and how long it is.

Evidence: The agreed period, usually three to twelve months, confirmed with the auditor. The intended report date and the lead time needed after the period ends.

Every must control in scope operate for the WHOLE period.

Evidence: A control-by-control start date. The auditor only tests a control from the date it started operating, so a late fix narrows what the report can say.

If this follows a Type 1 or an earlier Type 2, the must be gap between reports covered.

Evidence: The prior report with its date or period. The gap calculated. A bridge letter where one is needed. Enterprise customers increasingly want an unbroken run of periods.

For every control, you must be able to produce a COMPLETE list of every occasion it should have run.

Evidence: The source for each population — ticket system, directory, HR system, log platform, code repository — with the query used.

You must be able to PROVE the list is complete, rather than just saying so.

Evidence: A reconciliation to an independent source, a system-generated total, or a sequence check. Incomplete populations are the single most common reason a Type 2 opinion is qualified, and the fix has to be designed before the period starts.

You must have exported and kept the populations, rather than planning to regenerate them later.

Evidence: Exports retained. A system that purges or changes cannot reproduce the period afterwards.

The must be evidence for each control produced by a system, with a date and a name on it.

Evidence: Automatic timestamps. The identity of who performed the control. Approvals recorded in a workflow rather than confirmed by email afterwards.

There must be any control evidenced only by a spreadsheet the control owner keeps themselves.

Evidence: An honest list. The auditor will challenge those on integrity.

You must be able to answer: Has evidence been kept for the WHOLE period, including from systems whose logs roll off?

Evidence: Retention settings for each evidence source compared against the period length plus audit lead time. Test that data from the first weeks is still retrievable today. Log retention of 30 or 90 days against a twelve-month period cannot be fixed after the fact.

You must be able to answer: For controls that run to a schedule, did every single occurrence actually happen, on time?

Evidence: The expected number of occurrences against the actual, with dates. A quarterly control performed three times in four quarters is a deviation.

It must be defined where a control was missed, it must have been recorded honestly rather than backdated.

Evidence: The record. Backdating found during testing is far more serious than the missed control itself.

PART 5 — TYPE 2 ONLY

Clause CC1.

You must be able to produce the complete list of everyone who joined, left or was employed during the period.

Evidence: The personnel population reconciled to HR or payroll, including contractors and interns.

You must be able to show that background checks done for every joiner, before or around their start date.

Evidence: Screening records with dates relative to start dates, where the law allows.

You must be able to answer: Did every person acknowledge the code of conduct, with a date?

Evidence: Acknowledgement records per person.

You must be able to answer: Did everyone complete security training — at induction and at the annual refresh falling in the period?

Evidence: Completion records with dates. Evidence for anyone who did not, and what you did about it.

You must be able to answer: Did the board or governing body actually meet as scheduled, and consider internal control?

Evidence: Minutes for every scheduled meeting, with dates and attendance. Any meeting that did not happen.

PART 5 continued — Communication over the period

Clause CC2.

You must be able to show that the communications you committed to actually made, with dates and recipients.

Evidence: Communications sent. Policy publication and acknowledgement records.

You must be able to show that customer notifications sent within the times you promised.

Evidence: Notification records with dates against the committed timescale.

PART 5 continued — Risk assessment over the period

Clause CC3.

You must be able to show that the risk assessment done or refreshed inside the period, at the frequency your policy states.

Evidence: The assessment with a date inside the period. If your policy says annual and it was not done, that is a deviation against your own control description.

You must be able to show that the significant changes during the period assessed for their effect on controls.

Evidence: The population of changes, with an impact assessment and date for each.

You must be able to show that fraud risk considered as part of that.

Evidence: The fraud risk element, dated inside the period.

PART 5 continued — Monitoring over the period

Clause CC4.

You must be able to produce every monitoring output for the period — exception reports, reviews, audits, scans, penetration tests.

Evidence: The population with dates.

There must be evidence someone REVIEWED each one, not just that it was produced.

Evidence: Reviewer name and date on each. This is the distinction that catches people out.

You must be able to show that deficiencies found during the period logged, escalated and worked on within it.

Evidence: The deficiency log with dates. Escalation evidence inside the period, not at the end of it.

PART 5 continued — Policies over the period

Clause CC5.

You must be able to show that every policy due for review during the period actually reviewed and approved.

Evidence: The population of policies with their review frequency and the actual review date. Any policy overdue.

Where a procedure changed mid-period, your control must description cover both versions.

Evidence: The change dated. The auditor tests each sample against the control as it stood at that time.

PART 5 continued — Access over the period

Clause CC6.

You must be able to produce the complete list of every access grant, change and removal in the period.

Evidence: The population reconciled to an independent source such as the directory's own audit log.

For each one, you must be able to show that it approved BEFORE access was given.

Evidence: Approval evidence with the approver and a date preceding provisioning. Retrospective approval is a deviation even where the access was appropriate.

You must be able to produce the complete list of everyone who left during the period.

Evidence: The termination population reconciled to HR, including contractors and consultants.

You must be able to show that access removed within your committed timescale for EVERY leaver.

Evidence: Revocation timestamps and elapsed times. Terminations are a small population and auditors usually test all of them rather than a sample.

You must be able to show that every scheduled access review actually done, at the stated frequency.

Evidence: Every review due in the period, with its date.

You must be able to answer: Did each review cover the complete user population as at that date?

Evidence: The list reviewed, reconciled to the directory — not just the accounts someone remembered.

There must be evidence the reviewer actually considered it, rather than approving in bulk.

Evidence: Reviewer name, date and the exceptions they raised.

You must be able to show that the removals identified by a review actually carried out, and when.

Evidence: Closure evidence with dates. A review that finds inappropriate access and does not remove it is worse evidence than no review at all.

You must be able to show that the preventive technical controls in place throughout, not just when you last checked.

Evidence: Configuration evidence from several points across the period: encryption, multi-factor, firewall rules, endpoint coverage. Any period where a control was off, degraded, or not rolled out to new assets.

PART 5 continued — Monitoring and incidents over the period

Clause CC7.

You must be able to produce the complete list of security alerts or events for the period.

Evidence: The population from your monitoring platform.

You must be able to show that each one triaged, by whom, and how quickly.

Evidence: Triage evidence per sampled alert, with time from alert to triage against your committed response.

You must be able to show that there any window when monitoring was not running or alerts were not looked at.

Evidence: An honest answer. Holiday periods and platform migrations are the usual gaps.

You must be able to produce the complete list of security incidents for the period, including minor ones.

Evidence: The incident population. An incident found later that was not disclosed damages the credibility of every other population you produced.

For each incident, you must be able to show that it handled the way the plan says, and was anyone notified in time.

Evidence: Detection date, severity, containment, remediation, and any customer or regulator notification with its date against the commitment.

You must be able to show that backups taken as scheduled through the whole period.

Evidence: The backup job population with success and failure per job. Failed jobs investigated and re-run.

You must be able to show that a restore actually tested inside the period.

Evidence: The test with date, scope, result and time taken. A file-level spot check is not a recovery test if your control description claims more.

PART 5 continued — Change management over the period

Clause CC8.

You must be able to produce the complete list of changes deployed to production during the period.

Evidence: The population reconciled between the ticket system and the deployment or source control system. A change deployed without a ticket is invisible in the ticket list, which is exactly what the reconciliation is for.

For each change, you must be able to show that it risk assessed, tested and approved BEFORE deployment.

Evidence: Evidence per sampled change, with the approval date preceding the deployment date.

You must be able to produce the emergency changes separately, with a justification for each.

Evidence: The emergency change population with reasons and retrospective approvals.

It must be defined what proportion of your changes were emergencies.

Evidence: The figure. A high proportion tells the auditor the normal route is being bypassed, and they will say so in the report.

PART 5 continued — Vendors over the period

Clause CC9.

You must be able to show that the vendor reviews your policy requires actually done inside the period.

Evidence: The vendor population with tiering and the review dates.

You must have obtain your subservice organisations' SOC 2 reports, and do their periods cover yours.

Evidence: The reports with their periods compared against yours. A bridge letter for any gap.

You must have review the complementary user entity controls in those reports, and you must have implemented them.

Evidence: The review record and evidence of implementation.

Where a supplier's report had a qualified opinion or exceptions, you must have assess the effect on you.

Evidence: The assessment recorded.

PART 6 — TYPE 2 ONLY

Clauses Description, Exceptions.

The system must description cover the system as it was THROUGHOUT the period, including anything that changed part-way.

Evidence: The description covering the period, not a single date. Changes disclosed — a new environment, a migration, a changed supplier, an acquisition, a big change of staff.

You must be able to answer: Has someone who knows what actually happened checked the description?

Evidence: Review by someone other than whoever wrote last year's.

You must have found your own deviations before the auditor does.

Evidence: A self-identified deviation log: missed reviews, late revocations, unapproved changes, monitoring gaps.

For each one, you must know the cause, the extent and what you did about it.

Evidence: Cause, the number affected out of the population, corrective action with dates, and any compensating control. A deviation you disclose with its cause and fix reads very differently in the report from one the auditor's sample finds.

Using this document

Nothing above asks for a manual, a template pack, or a filing system. It asks for decisions that have been taken deliberately and can be shown to have been taken — which is a far smaller job than most organisations expect, and a different one.

Length is not compliance. A procedure nobody follows is worse than no procedure, because an auditor finds the gap between the two. The test we apply is whether the person who has to do the job recognises their own work in what is written down.