---
title: "SOC 2 documentation: the documents, policies and controls matrix you need"
canonical: https://www.grcmana.io/vault/soc-2/documentation
published: 2024-06-14
updated: 2026-10-23
author: "Harry West"
framework: "SOC 2"
control: "Guide SOC 2 documentation: the documents, policies and controls matrix you need"
journeyStage: implementation
---

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

## Key takeaways

SOC 2 documentation is a system description, management's assertion, a controls matrix mapped to the Trust Services Criteria, and the policies and evidence those controls rely on. The AICPA sets outcome-based criteria rather than a fixed policy list, so the controls decide which policies you need. An ISO 27001 certified firm can reuse much of its policy set and risk records but must write the description, assertion and matrix fresh.

- **System description** — Management's written account of the system in scope, prepared against the AICPA description criteria, which are also the benchmark the service auditor uses to evaluate it.
- **Management's assertion** — A statement by service organisation management, included in the SOC 2 report alongside the system description and the auditor's report, about the description and the controls it covers.
- **Points of focus** — Characteristics the AICPA lists under each criterion to help management design controls. Applying the Trust Services Criteria does not require assessing whether each point of focus is addressed.
- **Testing controls** — The AICPA's SOC 2 report review checklist says inquiry-based procedures are not appropriate unless supported by inspection, observation or reperformance, so every control needs evidence it ran.

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](https://www.grcmana.io/vault/soc-2). Our [ISO 27001 documents guide](https://www.grcmana.io/vault/iso-27001/documents) lists the ISO 27001 set.

| Document | What it is | Who writes it | Where it ends up |
| --- | --- | --- | --- |
| System description | Management's account of the service in scope, its commitments, components, suppliers and controls | Management | Published in the report |
| Management's assertion | A signed statement that the description meets the description criteria and the controls were suitably designed and, for Type 2, operated effectively | Management | Published in the report |
| Controls matrix | One row per control, mapped to the criteria, with owner, frequency and evidence | Management, with the auditor adding tests | The basis of the tests of controls section |
| Policies and procedures | The rules and steps your controls depend on | Control owners, approved by leadership | Inspected by the auditor; not published in the report |
| Evidence and records | Tickets, logs, review sign-offs and exports that prove each control ran | Produced by your systems and teams | Sampled by the auditor |

The AICPA's [2018 description criteria](https://www.aicpa-cima.com/resources/download/get-description-criteria-for-your-organizations-soc-2-r-report) 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](https://www.grcmana.io/vault/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](https://www.aicpa-cima.com/resources/download/illustrative-soc-2-r-report-with-description-and-assertion) 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.

| Column | What goes in it | Example (illustrative) |
| --- | --- | --- |
| Criterion reference | Each criterion the control helps meet; one control can map to several | CC6.2, CC6.3 |
| Control ID | Your own stable reference, kept the same year to year | AC-04 |
| Control description | What happens, who does it and how often, written as an outcome | Leavers' system access is removed within one working day of their last day |
| Owner | One named role, the person the auditor will speak to | Head of IT |
| Frequency | Continuous, per event, daily, monthly, quarterly or annual | Per event |
| Evidence | The record the control leaves behind | Leaver ticket with the identity provider deactivation log |
| Test approach | How the auditor will check it: inspection, observation or reperformance | Inspect a sample of leaver tickets against HR exit dates |

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](https://www.aicpa-cima.com/resources/video/key-elements-of-a-soc-2-report-resources-for-management) 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](https://www.aicpa-cima.com/resources/download/2017-trust-services-criteria-with-revised-points-of-focus-2022) 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](https://www.grcmana.io/vault/soc-2/trust-services-criteria).

## 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.

| Area | Policy or procedure | Common criteria series it usually supports |
| --- | --- | --- |
| Governance | Information security policy, with roles and leadership oversight | CC1, CC2, CC5 |
| People | Code of conduct, screening, joiners and leavers, security awareness | CC1, CC2 |
| Risk | Risk management procedure and risk register | CC3, CC9 |
| Access | Access control policy, covering authentication, reviews and privileged access | CC6 |
| Operations | Logging, monitoring and vulnerability management | CC7 |
| Incidents | Incident response plan with escalation and lessons learned | CC7 |
| Change | Change and release management, including emergency changes | CC8 |
| Suppliers | Supplier risk management, including review of their assurance reports | CC9 |
| Continuity | Business continuity and backup, with restore testing | CC7, CC9 |
| Data | Data classification, encryption and secure disposal | CC6 |

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](https://www.aicpa-cima.com/resources/download/mapping-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:

| ISO 27001 document | Reuse, adapt or new | What changes for SOC 2 |
| --- | --- | --- |
| Annex A topic-specific policies | Reuse | Check each one still matches practice and supports a row in the controls matrix |
| Risk assessment and treatment | Reuse | Confirm fraud risk is considered, as the criteria expect |
| Supplier register and assessments | Reuse | Mark which suppliers are subservice organisations |
| Statement of Applicability | Adapt | Becomes the first draft of the controls matrix, re-mapped from Annex A to the criteria |
| ISMS scope statement | Adapt | Narrowed to the service in the report, then written into the system description |
| Internal audit records | Adapt | Should show monitoring across the whole report period, not one annual pass |
| Management review records | Adapt | Become evidence of leadership oversight, so minutes need decisions, owners and dates |
| System description | New | Written to the description criteria, with service commitments in customer language |
| Management's assertion | New | Drafted with your auditor and signed by leadership |

Your [Clause 6.1 risk process](https://www.grcmana.io/vault/iso-27001/clause-6-1-actions-to-address-risks-and-opportunities) 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](https://www.journalofaccountancy.com/issues/2026/may/aicpa-guides-peer-reviewers-to-address-soc-2-risks/) 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

### Does the AICPA publish SOC 2 policy templates?

The AICPA publishes the Trust Services Criteria, the description criteria and an illustrative report, but its criteria are outcome-based and do not prescribe a policy set. Templates from other sources can help with structure. The content must describe your own controls, or it will not match your evidence.

### Who writes the SOC 2 controls matrix, us or the auditor?

You do. The controls are management-defined, so your team writes the descriptions, owners, frequencies and evidence. The auditor then plans and records the tests against each row, and the results appear in the tests of controls section of the report.

### Can SOC 2 documentation live in a wiki or compliance platform?

Yes. What matters is that each document has an owner, a version history and a recorded approval, wherever it lives. Note that the AICPA's review checklist asks whether the description names any tool used to prepare the report, and whether that tool counts as a subservice organisation.

### How often should SOC 2 policies be reviewed?

The points of focus suggest revisiting control activities from time to time, without fixing a frequency. We recommend a review at least once a year and after any significant change to the service, such as a new hosting provider. Record each review with its date and reviewer, even when nothing changes.

### Can one policy cover several SOC 2 criteria?

Yes. A single access control policy can support several criteria in the CC6 series. The controls matrix shows the link: each row names the criteria it supports and the policy it follows, so the auditor can trace from criterion to control to evidence.