Ask a company preparing for SOC 2 or ISO 27001 what their control matrix looks like, and you will typically get one of three answers. Some have a GRC platform that tracks controls automatically. Some have a spreadsheet inherited from a consultant. Some will stare at you blankly.
In all three cases, the control matrix is usually incomplete in ways that cause problems during audit. The platform generates a list of checks but doesn't map them to specific criteria or document evidence sources. The spreadsheet has controls listed but no owners, no evidence links, and no indication of whether they are operating. And the blank stare signals that the company is treating audit prep as a documentation exercise rather than an operating discipline.
A proper control matrix solves all of this. It is the single authoritative register that ties every control in your environment to the framework criterion it satisfies, the evidence that proves it works, and the person responsible for keeping it working. Here is how to build one.
What a Control Matrix Is
A control matrix is a structured document, typically a spreadsheet or GRC platform view, that lists every control in your compliance scope and maps each one to the relevant requirements. For SOC 2, those requirements are the Trust Services Criteria (CC1 through CC9, plus the additional criteria for Availability, Confidentiality, Processing Integrity, and Privacy if applicable). For ISO 27001, they are the Annex A controls and their corresponding clauses.
The matrix serves multiple purposes simultaneously. It tells management what the control environment covers and where the gaps are. It tells the auditor what to test and where to find the evidence. It tells control owners what they are responsible for and when to collect evidence. And it tells the readiness team what needs to be in place before the audit window opens.
A control matrix is not a policy document. It is not a list of what you intend to do. It is a registry of what you actually do, mapped to what you are required to do, with evidence that proves the connection.
The Core Fields Every Row Needs
Regardless of whether you build your control matrix in a spreadsheet, a GRC platform, or a dedicated compliance tool, every row in the matrix should capture the same core information.
Control ID
A unique identifier for the control. Use a consistent format: CC-01, CC-02, AC-01, and so on. This identifier should be stable over time so you can reference it in evidence logs, audit workpapers, and management reports without ambiguity.
Control Name and Description
A plain-English name and a precise description of what the control does. Vague descriptions create problems during audit. "Access management" is not a control description. "User access to production systems is provisioned via JIRA ticket with approval from the system owner, reviewed and provisioned by IT within 24 hours, and confirmed via email to the requester" is a control description. The auditor must be able to understand exactly what is being tested.
Framework Mapping
Which criteria or clauses does this control satisfy? A single control can satisfy multiple criteria. Access reviews, for example, typically map to CC6 (Logical and Physical Access Controls) and CC9 (Risk Mitigation Activities) in the SOC 2 Trust Services Criteria, and to A.8.2 and A.8.3 in ISO 27001 Annex A. Document all mappings. If a criterion has no control mapped to it, you have a gap.
Control Owner
The specific role (and ideally the name) of the person responsible for operating this control. "IT Team" is not an owner. "Head of Infrastructure" or "Security Operations Manager" is an owner. Unowned controls are the single most common source of audit failures. When a control has no owner, no one collects evidence, no one notices when it breaks, and no one can explain it to an auditor.
Control Type
Is this control preventive (stops an issue from occurring), detective (identifies issues after they occur), or corrective (addresses issues once detected)? Is it automated (runs without human intervention) or manual (requires a person to perform an action)? This categorization matters for the auditor's testing approach and for your own risk assessment.
Control Frequency
How often does this control operate? Daily, weekly, monthly, quarterly, annually, continuously? Frequency drives evidence collection requirements. A quarterly access review needs evidence from all four quarters. A daily log monitoring control needs evidence sampled across the full audit period. If you don't document frequency, you won't know how much evidence you need to collect.
Evidence Artifact
What is the specific document, log, record, or export that proves this control operated? This column forces precision. "Access review documentation" is not an evidence artifact. "Quarterly access review spreadsheet exported from Okta, reviewed and signed off by the CISO, stored in Google Drive at /Security/Access-Reviews/[Year]/[Quarter]/" is an evidence artifact. Every control needs a defined artifact before the audit window opens, not after the auditor asks for it.
Evidence Location
Where exactly does the evidence live? The URL, file path, or GRC platform location. This column is how the auditor finds what they need without sending you a request list and waiting three days for a response.
Collection Frequency and Last Collected Date
When was evidence last collected? This column tells you at a glance which controls are current and which are overdue. A control whose evidence has not been collected in six months has an operating gap regardless of whether the control itself is functioning.
The test that mattersPrint your control matrix and cover the "Evidence Artifact" column. Can you, from memory, describe the exact artifact that proves each control worked last month? If not, you have missing or vague evidence definitions that will become gaps when the auditor asks for them.
An Example Row
| Field | Example Value |
|---|---|
| Control ID | AC-03 |
| Control Name | Quarterly User Access Review |
| Description | The Head of Infrastructure reviews all production system user accounts quarterly. Accounts no longer requiring access are terminated within 5 business days. Results are documented and approved by the CISO. |
| Framework Mapping | SOC 2: CC6.2, CC6.3 / ISO 27001: A.8.2, A.8.5 |
| Owner | Head of Infrastructure |
| Type | Detective / Manual |
| Frequency | Quarterly |
| Evidence Artifact | Quarterly access review sign-off, exported user list from Okta, CISO approval email |
| Evidence Location | Google Drive: /Security/Access-Reviews/2026/ |
| Last Collected | 2026-06-30 |
How to Build the Matrix
Step 1: Start with the Framework, Not Your Current Environment
Begin by listing every criterion or clause in your selected framework. For SOC 2 Security, that means CC1.1 through CC9.2. For ISO 27001:2022, that means A.5.1 through A.8.34 in Annex A. For every criterion, ask: what control in our environment satisfies this requirement? If nothing satisfies it, you have a gap. If something satisfies it but you cannot document it, you have an evidence problem.
Step 2: Map Existing Controls Honestly
Do not list controls you plan to implement. List controls that are operational now. A control that exists in a policy document but is not being executed is not a control, it is a policy aspiration. Auditors test operating effectiveness. They will ask for evidence. If the evidence does not exist, the control does not exist for audit purposes.
Step 3: Assign Owners Before the Audit Window Opens
Every control must have an owner before day one of your audit window. Assigning owners mid-window creates a gap in accountability for the period before the assignment. The owner is responsible for operating the control, collecting evidence, and escalating when something breaks. If a control has no owner, appoint one or document that the role has been eliminated, and identify a compensating control.
Step 4: Define Evidence Before Collection Starts
The evidence artifact column should be completed before you start collecting evidence, not while you are collecting it. This prevents the common problem of collecting evidence that is slightly different from what the auditor expects, or collecting it from the wrong source.
Step 5: Review and Update Quarterly
The control matrix is a living document. When you add a new system, promote a new employee, change a vendor, or modify a process, the matrix must reflect those changes. A matrix that accurately described your environment twelve months ago but has not been updated since is not reliable. Quarterly reviews, tied to management reporting, are the minimum cadence for keeping the matrix current.
The Difference Between a Template and a Real Control Matrix
GRC platforms and compliance consultants routinely provide pre-populated control matrices. These templates are starting points, not conclusions. A template that maps generic controls to SOC 2 criteria without reflecting your actual environment is worse than no matrix, because it creates false confidence that your controls address the criteria when they may not.
The test of a real control matrix is simple: if the auditor asked you to produce the evidence for any row in the matrix right now, you could find it within minutes. Not because you scrambled to collect it, but because it was collected as the control operated and stored in the location the matrix describes.
Companies that pass audits cleanly do not build their control matrix during readiness. They build it before the audit window opens, maintain it throughout the window, and arrive at the audit with evidence that matches the matrix row by row. The matrix is not a compliance artifact. It is an operational tool that happens to make audits straightforward.