A control matrix is a structured document mapping each control your organization operates to the specific framework criteria it satisfies — SOC 2 Trust Service Criteria, ISO 27001 Annex A controls, HIPAA safeguards, or some combination. It's the reference document your auditor uses to understand your control environment and the working document your GRC team uses to track control status and evidence requirements.
We built Tenurex's internal control matrix before we built the product — partly because we needed one, partly because the experience of building it manually is exactly what motivated us to build automation around it. The forty hours cited in this post's title is not a hypothetical. It's the actual time our initial matrix took to build from scratch, including reconciling duplicate controls across frameworks and mapping evidence sources to each control.
This post describes the structure that makes a control matrix maintainable and what goes wrong when that structure isn't in place.
What a Control Matrix Actually Contains
A control matrix has rows and columns, with each row representing a control and the columns representing properties of that control. The minimum viable set of columns is:
- Control ID. A stable identifier: CTL-001, CTL-002. The ID shouldn't change when the control description is updated. It's the reference key for everywhere this control appears in other documents — the risk register, the system description, audit workpapers.
- Control name and description. A short name (suitable for reference) and a longer description (what the control actually does, in operational terms). The description should be specific enough that a new team member could understand what operating this control entails.
- Control type. Preventive, detective, corrective, or deterrent. This classification matters because it tells you something about what evidence the control produces. Preventive controls (MFA enforcement) produce configuration evidence. Detective controls (log monitoring) produce review evidence. Understanding the type guides what evidence to collect.
- Framework mappings. Which Trust Service Criteria, ISO 27001 Annex A controls, or HIPAA safeguards does this control satisfy? If you're pursuing multiple frameworks, this column is the heart of the matrix — it's where cross-framework efficiency lives.
- Control owner. The role responsible for this control operating correctly. Not a department — a specific role. "Engineering" is not an owner. "Head of Infrastructure" is an owner.
- Evidence type and source. What evidence does this control produce, and where does that evidence live? "CloudTrail logs — AWS account 123456789" is a useful entry. "Logs" is not.
- Testing frequency. How often is this control verified as operating? Continuous, monthly, quarterly, annually. This drives your evidence collection cadence.
- Last test date and status. When was this control last verified, and was it passing or flagging a gap? This is the operational state column — the difference between a control matrix as a design document and a control matrix as a live operational tool.
The Cross-Framework Mapping Problem
If you're running SOC 2 and ISO 27001 simultaneously, you'll quickly notice that many of your controls satisfy criteria in both frameworks. MFA enforcement satisfies SOC 2 CC6.1 and ISO 27001 A.9.4.2 (secure log-on procedures). Access reviews satisfy CC6.3 and A.9.2.5 (review of user access rights). Encryption at rest satisfies CC6.7 and A.10.1.1 (policy on the use of cryptographic controls).
The naive approach to this is to have separate matrices for each framework. This works for your first audit but creates maintenance problems: when you update a control description, you have to update it in two places. When evidence collection changes, you have to update both matrices. After a few update cycles, the matrices diverge and you're not sure which one is authoritative.
The structured approach is a single unified matrix where each control row has multi-column framework mappings. One control, multiple criteria satisfied. When the control is tested and the evidence is collected, the evidence satisfies all mapped criteria simultaneously. This is the cross-framework efficiency that makes dual SOC 2 / ISO 27001 programs feasible for a small team — you're not running two compliance programs, you're running one program mapped to two frameworks.
The mapping isn't always obvious. Some SOC 2 CC criteria don't have clean ISO 27001 equivalents and vice versa. CC5 (Control Activities) maps loosely to multiple ISO 27001 clauses but doesn't align one-to-one. This is where consulting with the audit firm during the initial mapping exercise pays off — they've seen how other firms interpret these mappings and can tell you whether an ambiguous mapping is likely to be accepted or challenged.
Common Control Matrix Failures
The most common structural failure in control matrices is controls that are listed but not operating. The matrix becomes a design document — it describes an intended control environment, not an actual one. When auditors sample against it, they find controls that are described as operating but for which no evidence exists.
This happens when the matrix is built once (often with a consultant's help during a readiness engagement) and then not maintained. The initial matrix is accurate. Six months later, three of the controls in the matrix reference a system that's been retired. Two controls reference a process that nobody is actually running. One control has a new owner because the original owner left, but the matrix still shows the former employee.
We're not saying this is negligence — it's entropy. A static document in a dynamic environment drifts without active maintenance. The question is what forces that maintenance.
One approach is calendar-driven review: quarterly, review the matrix for accuracy. This works but creates a quarterly burden and still misses changes that happen mid-quarter. A better approach is event-triggered review: when a system is retired, when an integration changes, when an employee leaves, the control matrix is part of the offboarding or change checklist. The review is smaller and more frequent, which means the matrix stays current.
Mapping Evidence Sources to Controls
A control matrix entry that says "Evidence: access review records" is incomplete. A complete evidence source entry says "Evidence: quarterly access review export from IdP [source: Entra ID access review report], stored in [location], reviewed by [role], due by [relative date within each quarter]."
That level of specificity in the matrix is the difference between a GRC team that knows what to collect at audit time and one that has to figure it out each time. When we mapped our internal controls to evidence sources, we also mapped which source system each piece of evidence came from and what the export format was. During our first SOC 2 audit, the evidence request response time was under a day for most items because the evidence location was documented in the matrix and the exports were retained in a consistent format.
Consider the alternative pattern that's more common: an early-stage SaaS at around $2.5M ARR, nine employees, with an audit window opening in two months. Their control matrix listed thirty-eight controls. Of those, fourteen had no documented evidence source — just "verify quarterly." When the auditor's PBC (provided by client) list arrived with requests for specific evidence, the compliance owner spent the first three days of the audit period reconstructing where each piece of evidence lived and what format was acceptable. That three-day reconstruction is the 40-hour spreadsheet problem — just distributed across the audit engagement rather than the initial build.
Living Document vs. Audit Artifact
The goal of a well-built control matrix isn't to have a document to show auditors. It's to have an operational tool that your team uses daily to understand which controls are passing, which are flagging gaps, and who owns remediation for the gaps.
That distinction shows in how the matrix is formatted. An audit artifact is formatted for readability by an external reviewer. A living operational document is formatted for use by the person who wakes up at 7am and checks whether last night's control checks passed. It has clear status columns, links to evidence, and unambiguous ownership.
The Tenurex approach is to treat the control matrix as the source of truth for what controls should be monitored, and to tie automated evidence collection directly to the controls listed in the matrix. When a new control is added to the matrix, it gets assigned an evidence collection rule. When a control is retired, the evidence collection for it stops. The matrix and the monitoring pipeline stay in sync.
That integration is what separates a compliance program that works under audit pressure from one that only works when someone is paying close attention. The attention should be on remediation, not on finding the evidence.