SOC 2 documentation: the documents, policies and controls matrix you need

Your US prospect's security team wants a SOC 2 report before the contract moves, and the auditor's first request will be your document set. If you already hold ISO 27001, the policy folder looks full. Yet the three artefacts a SOC 2 auditor works from are usually missing: a system description, management's assertion and a controls matrix.

This guide is for founders, COOs and security leads at UK B2B tech firms with 25 to 100 staff. It gives the full SOC 2 documentation set in one table, builds a controls matrix column by column, sizes the policy set to your controls and shows which ISO 27001 documents you can reuse.

What SOC 2 documentation do you need?

SOC 2 documentation comes in five parts: a system description written to the AICPA description criteria, management's written assertion, a controls matrix that maps each control to the Trust Services Criteria, the policies and procedures those controls rely on, and the evidence that they ran. The AICPA mandates no fixed list of policies. Your controls decide which ones you need.

That is the main difference from ISO 27001, where clauses 4 to 10 name a set of required documents. For what SOC 2 is and why buyers ask for it, start with our SOC 2 overview. Our ISO 27001 documents guide lists the ISO 27001 set.

The AICPA's 2018 description criteria are the benchmark for preparing the system description and for evaluating it. Writing one, and setting its scope, has its own guide: the SOC 2 system description.

What is management's assertion in a SOC 2 report?

Management's assertion is a signed statement, written by your leadership and included in the SOC 2 report, saying the system description is presented in line with the description criteria and the controls were suitably designed. For a Type 2 report, it also asserts that the controls operated effectively throughout the period. The auditor's opinion then tests that claim.

The AICPA's illustrative SOC 2 report shows the full package: management's assertion, the system description, the service auditor's report, and the tests of controls with their results. So the assertion is not paperwork for the file. Every customer who reads your report reads it.

Treat the assertion as the last document you finalise, not the first. Its wording depends on the scope, the categories and the period, and it must agree with the description on each.

We recommend three habits:

• Agree the wording early. Ask your auditor for the assertion format they expect before fieldwork, so nobody edits it under deadline.
• Name the signatory. A director or the executive who owns the SOC 2 programme should sign it, because it speaks for the business.
• Re-read it after any change. If the scope or a control changes during fieldwork, the assertion changes with it.

How do you build a SOC 2 controls matrix?

A SOC 2 controls matrix is a table with one row per control and seven core columns: criterion reference, control ID, control description, owner, frequency, evidence and test approach. Build it from your risk assessment, write each control as an outcome a tester can sample, then map it to every criterion it helps meet.

The matrix is the working document the whole audit runs on. The auditor uses it to plan tests, your control owners use it to know what to produce, and it becomes the backbone of the tests of controls section in the final report.

Build it in this order:

1. Start from risk. List the risks to your service commitments, then the controls that treat them.
2. Write each control once. Describe the outcome, not the tool, so the control survives a change of product.
3. Map to the criteria. Record every criterion each control supports, then check each criterion in scope has at least one control.
4. Name the evidence before you need it. If you cannot say what record a control leaves, it will not survive testing.

The test approach column matters more than it looks. The AICPA's SOC 2 report review checklist notes that inquiry on its own is not an appropriate test unless inspection, observation or reperformance supports it. A control you can only describe in an interview is not ready.

Points of focus help you write the rows, but they are not a checklist. The AICPA's 2017 Trust Services Criteria say applying the criteria does not require assessing whether each point of focus is addressed. Use them as prompts when you design a control. The criteria index and how criteria differ from controls are covered in our Trust Services Criteria guide.

Which SOC 2 policies does a Security-only scope need?

The AICPA does not name the SOC 2 policies you must write. Its criteria do expect each control to rest on written rules and on procedures that people actually follow. So a Security-only scope needs only the policies your controls depend on, sized to your firm and its system rather than to a template pack.

The table shows a typical set for a 25 to 100 person software firm with only Security in scope. It is our recommendation, not an AICPA list. Each policy earns its place by supporting controls in your matrix.

If you add Availability, Confidentiality, Processing Integrity or Privacy to the scope, add policies only where those criteria create a new control. A promise of uptime, for example, needs capacity and recovery controls with their own records.

A policy nobody follows is not a control; it is an exception waiting to be sampled.

Fewer, shorter policies that match practice beat a long set that describes a different company. The auditor inspects what you hold, then tests whether people do what it says.

Which ISO 27001 documents can you reuse for SOC 2?

An ISO 27001 certified firm can reuse its Annex A topic policies, risk assessment and supplier records as they are, and adapt its Statement of Applicability, scope statement, internal audit and management review records. The system description, management's assertion and the controls matrix mapped to the Trust Services Criteria are new documents to write.

The AICPA publishes a mapping of the 2017 Trust Services Criteria to ISO 27001, available to its members, which shows how much ground the two share. At document level, the reuse looks like this:

Your Clause 6.1 risk process carries over almost whole. The biggest adaptation is the Statement of Applicability. Annex A and the Trust Services Criteria are organised differently, so each control needs a criteria reference added, and some controls will need rewording as testable outcomes.

What evidence does a SOC 2 Type 2 report need over the observation window?

A SOC 2 Type 2 report needs records showing every control in the matrix operated throughout the observation window, not just on the day of testing. The auditor samples occurrences across the period, so each quarterly review, each change and each leaver needs its own record. A Type 1 report needs evidence of design at a single date.

The description criteria tie a Type 2 description to the period of time it covers, and the auditor's opinion reaches the operating effectiveness of controls across that period. Evidence is therefore an operating record, built as the window runs.

Plan the evidence by frequency:

• Per event. Every change, access request, leaver and incident leaves a ticket or log entry.
• Periodic. Each quarterly access review or annual risk assessment has a dated record for every occurrence in the window.
• Continuous. Configuration such as multi-factor authentication or encryption is shown by system exports taken at points through the period.

Evidence assembled at the end of the window is a reconstruction, not a record.

The strongest evidence is generated by the systems that do the work: the identity provider, the ticketing tool, the code repository. When evidence is collected continuously from those systems, the request list becomes a set of exports rather than weeks of chasing.

How should you format SOC 2 policies and documents?

Format every SOC 2 policy and procedure with the same short header: purpose, scope, owner, approver, version, approval date, next review date and the controls it supports. Add a record of staff acknowledgement. We recommend this structure because, to a reviewer, consistency and traceability matter more than layout or length.

The header does real work. A reviewer can see at a glance who owns the document, when leadership approved it and when it was last reviewed. Among its points of focus, the AICPA suggests revisiting controls over time to check they still fit, so a dated review entry, even "reviewed, no change", is evidence in itself.

Linking each policy to its control IDs keeps the documents and the matrix in step. When a control changes, you know which policy to update.

How much SOC 2 documentation is enough?

Enough SOC 2 documentation means every control in your matrix has a rule it follows and a record it leaves, and nothing more. If a document supports no control, it adds testing risk without adding assurance. The right size depends on your scope and system, so a single-service Security report needs far less than a multi-product one.

Three questions decide whether a document stays:

1. Does a control in the matrix depend on it? If not, it can go.
2. Would someone do the task wrongly without it? If yes, keep it short and practical.
3. Does it describe what actually happens? If not, fix the document or the practice before the auditor finds the gap.

What are the common SOC 2 documentation mistakes?

The common SOC 2 documentation mistakes are adopting a template pack wholesale, writing policies nobody follows, letting the controls matrix drift from the system description, describing controls in terms that cannot be tested, and collecting evidence only at the end. Each one either adds exceptions or leaves the auditor unable to rely on a control.

1. Template packs. The AICPA has warned peer reviewers about SOC 2 engagements with identical reports, risk assessments and testing procedures, which are not designed around the service organisation's own risks, as the Journal of Accountancy reports. Your documents face the same test: copied from another firm, they describe another firm's system.
2. Policies nobody follows. A policy that promises monthly reviews when you run them quarterly creates an exception against your own rule.
3. A matrix out of step with the description. If the description names a control the matrix does not test, or the reverse, the report contradicts itself.
4. Untestable control wording. The AICPA's review checklist asks whether controls are specific enough to be controls at all, and whether they are tailored to the system in scope.
5. Evidence at the end. A control that left no record in month two cannot be shown to have operated in month two.

A controls matrix that disagrees with the system description is two reports pretending to be one.

The fix for most of these is the same. Write the matrix first, size the policies to it and let your systems produce the evidence. Done that way, SOC 2 documentation stops being a writing project and becomes a record of how you already run the service.

Frequently asked questions