Priya Desai had the policy binder. She had the vendor risk questionnaire template. She had eleven months of MFA login logs sitting in a shared drive folder named "Evidence — DO NOT DELETE." What she did not have, on the Tuesday morning a procurement analyst from Meridian Retail Group asked for it by name, was a control matrix.
Priya was Head of GRC at Harborlight Payments, a 140-person fintech SaaS company that processed same-day payouts for gig-economy platforms. Harborlight had completed a SOC 2 Type I audit eighteen months earlier and a Type II six months after that, and both reports sat, unread by anyone outside the compliance team, in a locked folder in the data room. When Meridian's security team came back with a follow-up question — "Please provide your control matrix showing which of your documented controls map to which Trust Services Criteria, including any gaps in CC6 and CC7" — Priya realized the SOC 2 report itself did not answer that question directly. The report described the system and listed control activities in narrative form. It did not give Meridian, or Priya's own engineering leads, a single table that said: here is control ID, here is what it does, here is who owns it, here is how often it runs, here is the evidence, and here is exactly which criteria it satisfies.
It took Priya's team eleven working days to reverse-engineer that matrix from the audit workpapers, the policy set, and a dozen Slack threads with control owners who had since changed teams. The Meridian deal — worth $1.9 million in annual recurring revenue — sat frozen in security review the entire time, and the champion on Meridian's side warned Priya twice that procurement was getting impatient. Harborlight closed the deal, but barely, and Priya's first action item after signature was never to be in that position again. The fix wasn't a better report. It was a living document that should have existed from day one: a control matrix.
This article is that document, explained end to end — what it is, how it's structured, how to build one from scratch, how to keep it accurate as your environment changes, and how auditors and enterprise buyers actually use it once you hand it over.
Who This Is For
This is written for the compliance manager, GRC analyst, security engineer, or founder who has either just been asked for a "control matrix" and doesn't have one, or has one that's gone stale and needs to be rebuilt properly. You'll walk away with a concrete template structure, a fully worked example mapping real controls to real Trust Services Criteria, a repeatable seven-step build process, and a set of maintenance habits that keep the matrix from rotting the way Harborlight's did. If you're preparing for your first SOC 2 Type I vs Type II audit or trying to explain to engineering why a control needs an owner and a cadence, this document is the one to hand them.
What a SOC 2 Control Matrix Actually Is
A control matrix is a single structured artifact — usually a spreadsheet or a table inside a governance, risk, and compliance (GRC) platform — that lists every control your organization operates and cross-references each one against the specific criteria it helps satisfy. It is not the SOC 2 report. It is not the policy set. It is not the SOC 2 Trust Services Criteria document itself. It is the bridge between those things: a many-to-many join table between "what we actually do" and "what the framework requires us to demonstrate."
Every row typically represents one control and carries, at minimum, six pieces of information: a unique control ID, a plain-language description of what the control does, the named owner accountable for it, the frequency at which it operates or is reviewed, the type of evidence that proves it operated, and — the part most homegrown spreadsheets get wrong — the specific criteria references it satisfies, expressed as CC numbers (and, where applicable, Availability, Processing Integrity, Confidentiality, or Privacy points of focus).
That last column is the entire point of the exercise. A policy document tells you what should happen. A control matrix tells you, criterion by criterion, exactly which control — or controls, plural — proves it's happening, and it tells you the reverse too: for any given criterion, which controls cover it. Auditors build something functionally identical during planning (their own mapping of the client's controls to the criteria being tested); a good control matrix means you hand them a document that's 80% of the way there instead of making them build it from your policies during fieldwork.
"The single biggest predictor of a smooth Type II fieldwork is whether the client walks in with a control matrix that already ties controls to criteria. When they don't, I spend the first two weeks building one myself before I can even start testing. When they do, we're testing by day three." — Elena Voss, Lead SOC 2 Auditor, Bramwell & Cho CPAs
Why the Matrix Exists: Proving Coverage, Finding Gaps
There are two jobs a control matrix does that no other SOC 2 artifact does on its own.
The first is proving coverage. The Common Criteria alone comprise nine categories (CC1 through CC9) built from dozens of individual points of focus drawn from the COSO framework. If you add Availability, Processing Integrity, Confidentiality, or Privacy to your scope, that's dozens more. Nobody can hold "have we covered every one of these" in their head, and a policy binder organized by topic (access control policy, change management policy, incident response policy) doesn't map cleanly to a framework organized by criteria. The matrix is the only artifact that lets you answer, criterion by criterion, "yes, this is covered, by these three controls" or "no, we have nothing here."
The second job is finding gaps before your auditor does. Every criterion with zero controls mapped to it, or with only one control mapped where the criterion realistically needs defense in depth, is a finding waiting to happen. Building the matrix is, in practice, the fastest gap analysis technique available — faster than a formal readiness assessment engagement, because it forces line-by-line reconciliation rather than a high-level walkthrough.
"I tell every client the same thing: if you can't produce a control matrix in under a day, you don't actually know your control environment — you have a folder of documents you hope covers everything." — Raj Subramaniam, Founder, ClearPath GRC Consulting
Without a Control Matrix | With a Control Matrix |
|---|---|
Coverage lives in the auditor's head or workpapers, not yours | Coverage is documented, versioned, and owned by the company |
Gaps surface as audit exceptions, mid-fieldwork | Gaps surface during internal review, weeks before fieldwork starts |
Every enterprise security questionnaire requires re-deriving mappings from scratch | The matrix answers 90% of criteria-mapping questions directly |
New hires and control owners don't know what they're accountable for | Ownership and cadence are explicit, row by row |
Multi-framework overlap (SOC 2 + ISO 27001) is re-analyzed from zero each time | The matrix becomes the seed for a crosswalk to other frameworks |
Evidence requests during audit require scrambling to remember what proves what | Evidence type and location are pre-mapped to each control |
The Trust Services Criteria, Recapped for Matrix-Builders
Before you can map anything, you need the target list. Every SOC 2 report includes the Security category — universally called the Common Criteria — and optionally one or more of Availability, Processing Integrity, Confidentiality, and Privacy, depending on what your organization has committed to in its system description. The nine Common Criteria categories map to the seventeen principles of the COSO internal-control framework, and each category is a bucket of specific points of focus your auditor will test against, not a single yes/no checkbox.
Category | Name | What It Broadly Covers |
|---|---|---|
CC1 | Control Environment | Tone at the top, board oversight, organizational structure, integrity and ethical values, accountability |
CC2 | Communication and Information | Internal/external communication of objectives and responsibilities, quality of information used for control |
CC3 | Risk Assessment | Objective-setting, risk identification and analysis, fraud risk consideration, change-driven risk reassessment |
CC4 | Monitoring Activities | Ongoing and separate evaluations of control performance, deficiency communication and remediation |
CC5 | Control Activities | Selection and development of controls, technology general controls, policies that put controls into action |
CC6 | Logical and Physical Access Controls | Identity management, authentication, authorization, network security, physical access, data disposal |
CC7 | System Operations | Vulnerability detection, monitoring, incident response, system change detection, recovery |
CC8 | Change Management | Authorization, design, development, testing, and approval of infrastructure and software changes |
CC9 | Risk Mitigation | Vendor and business-partner risk management, business disruption risk mitigation |
If your report scope includes the optional categories, each carries its own set of points of focus layered on top of the Common Criteria — they don't replace CC1–CC9, they extend the matrix with additional rows and additional criteria references.
Optional Category | Trigger for Inclusion | Typical Additional Focus |
|---|---|---|
Availability | You've made uptime/performance commitments (SLAs) | Capacity planning, environmental protections, backup and recovery, failover testing |
Processing Integrity | Customers rely on your system to process data completely/accurately | Input validation, error handling, reconciliation, output completeness |
Confidentiality | You handle information designated confidential by contract or classification | Data classification, retention/disposal, access restriction beyond CC6, confidentiality agreements |
Privacy | You handle personal information as principal (not just processor) | Notice, choice/consent, collection limitation, use/retention/disposal of personal data |
One Control, Many Criteria — and Vice Versa
The concept that trips up almost every first-time matrix builder is that this mapping is many-to-many, not one-to-one. A single well-designed control routinely satisfies pieces of three, four, or even six different criteria at once, and a single criterion is almost never satisfied by exactly one control — auditors expect layered, redundant coverage, particularly for CC6 and CC7.
Take a single-sign-on enforcement control as an example. "All employee access to production systems requires SSO with multi-factor authentication, enforced at the identity provider" is one control, but it plausibly touches: CC5 (it's a control activity), CC6 (it's the core of logical access), CC7 (it feeds system operations monitoring when MFA failures are logged and reviewed), and — if in scope — Confidentiality (it protects access to confidential data). One control ID, four criteria references.
Now flip it. CC6.1, the point of focus around logical access security, is rarely satisfied by that SSO control alone. It also needs a de-provisioning control (removing access when someone leaves), a least-privilege review control (periodic access recertification), and a password/credential policy control. Four controls, one criterion.
Direction | Example | Why It Matters |
|---|---|---|
One control → many criteria | Centralized SSO/MFA enforcement | Satisfies CC5, CC6, CC7, and Confidentiality simultaneously — efficient design, high leverage |
One criterion → many controls | CC6 (Logical Access) | Needs provisioning, de-provisioning, MFA, access review, and network segmentation controls together |
Weak mapping (avoid) | A single "we have a firewall" control mapped only to CC6 | Ignores that the same control likely also supports CC7 (system operations) and CC9 (risk mitigation) |
This is why a spreadsheet with one "criteria" column and one value per row is the wrong shape. The criteria column needs to hold a list — CC1, CC5, CC6, CC7 in a single cell, or a separate join table if you're building this in a database or GRC tool — and your gap analysis needs to pivot that list back out to count controls per criterion, not just criteria per control.
"New compliance hires almost always build the matrix backwards the first time — they start from the criteria list and try to force one control per row. You get this thin, unconvincing spreadsheet with forty rows and forty single mappings. The real matrix has maybe sixty controls and two hundred mapping instances, because good controls do double and triple duty." — Marcus Ferreira, VP of Compliance, NimbusStack Cloud
Anatomy of the Matrix: The Columns That Matter
Before building, standardize the column set. Every mature control matrix I've reviewed across dozens of SOC 2 programs converges on roughly the same core fields, even when the tooling differs wildly — spreadsheet, Airtable base, or a dedicated GRC platform.
Column | Purpose | Example Value |
|---|---|---|
Control ID | Unique, stable identifier referenced everywhere else (tickets, policies, audit workpapers) | AC-04 |
Control Domain | Groups related controls for readability (Access, Change Mgmt, Monitoring, HR, Vendor) | Access Management |
Control Description | Plain-language statement of what the control does, written so a non-auditor understands it | "Production access requests require manager approval and are provisioned via SSO group membership" |
Control Type | Preventive, detective, or corrective — helps assess whether coverage is balanced | Preventive |
Owner | Named individual or role accountable for the control operating | Director of IT Ops |
Frequency | How often the control operates or is reviewed | Continuous (system-enforced); reviewed quarterly |
Evidence Type | What artifact proves the control operated | Access request tickets + quarterly access review export |
Evidence Location | Where the evidence lives, so nobody hunts for it during fieldwork | GRC platform evidence repository, folder AC-04 |
Criteria Mapped | Every CC/A/PI/C/P reference this control satisfies | CC5.2, CC6.1, CC6.2, CC6.3 |
System/Asset Scope | Which systems, applications, or environments the control applies to | Production AWS environment, core payments application |
Status | Design status and operating status (implemented, in progress, not started) | Operating effectively |
Last Reviewed | Date of the most recent internal review of the control | 2026-04-15 |
Twelve columns is more than enough for most organizations; resist the urge to add dozens of custom fields before you've built the first working version. A matrix with 200 controls and 30 columns nobody fills in consistently is worse than one with 60 controls and 12 columns that are always accurate.
The Seven-Step Build Process
Building a control matrix from a standing start — no policies, no prior audit, nothing — takes most mid-market companies four to eight weeks of part-time effort. Rebuilding one from an existing audit, the way Priya's team eventually did for Harborlight, takes one to two weeks. Either way, the sequence is the same.
flowchart TD
A[Step 1: Inventory existing controls] --> B[Step 2: Map each control to CC1-CC9]
B --> C[Step 3: Add optional-criteria mappings A/PI/C/P]
C --> D[Step 4: Assign named owners]
D --> E[Step 5: Define frequency and cadence]
E --> F[Step 6: Attach evidence type and location]
F --> G[Step 7: Run coverage gap analysis]
G --> H{Gaps found?}
H -- Yes --> I[Design or reassign controls to close gap]
I --> G
H -- No --> J[Baseline matrix complete - move to maintenance cadence]Step | What Happens | Common Failure Mode |
|---|---|---|
1. Inventory | List every control currently operating, sourced from policies, tickets, system configs, and interviews with team leads | Only inventorying what's written down; unwritten-but-real controls get missed |
2. Map to CC1–CC9 | For each control, identify every Common Criteria category and point of focus it touches | Mapping to only one criterion per control, undercounting coverage |
3. Map optional criteria | If Availability/PI/Confidentiality/Privacy are in scope, add those references | Forgetting optional criteria entirely because "we're Security-only" when scope actually includes more |
4. Assign owners | Every control gets one accountable, named human — not a team, not "IT" | Listing a department instead of a person; nobody answers when the auditor asks |
5. Define frequency | State how often the control operates (continuous, daily, weekly) vs. how often it's reviewed | Confusing "control operates continuously" with "we check it once a year" |
6. Attach evidence | Specify the artifact type and exact storage location for proof the control ran | Vague evidence descriptions like "logs" with no location or retention period |
7. Gap analysis | Pivot the matrix by criterion to see which have zero, one, or many controls mapped | Skipping this step and discovering gaps only when the auditor does |
Step 1 in Practice: Where Controls Actually Come From
Most companies underestimate how many controls they already operate informally. The inventory step should pull from at least five sources: existing policies (each policy usually implies two to six discrete controls), ticketing system workflows (access requests, change approvals, incident tickets), system configurations (SSO group rules, firewall rules, backup schedules), vendor contracts and due-diligence records, and — critically — thirty-minute interviews with the people who actually run operations day to day, because they know about controls nobody wrote down.
Step 4 in Practice: Ownership Has to Be a Person, Not a Team
"IT Security team" is not an owner. When an auditor asks who approves production access changes, "the team" cannot answer a follow-up question, cannot be interviewed, and cannot be held accountable when the control lapses. Every row needs a named individual, ideally by role title rather than personal name so the matrix doesn't need editing every time someone changes jobs — "Director of Platform Engineering," not "Dana Kim," even though today those are the same person.
The Worked Matrix Example
Here is a condensed but realistic slice of Harborlight Payments' rebuilt control matrix — thirteen controls covering the domains that come up in almost every SOC 2 Type II engagement. This is the shape every matrix should take; a full matrix for a company Harborlight's size typically runs 45–90 rows.
Control ID | Description | Owner | Frequency | Evidence | Criteria Mapped |
|---|---|---|---|---|---|
CC-01 | Board-approved information security policy reviewed and re-approved annually | CISO | Annual | Signed policy doc + board minutes | CC1.1, CC1.2, CC1.4 |
CC-02 | New hires complete security awareness and code of conduct acknowledgment before system access is granted | HR Director | Per hire | HRIS onboarding completion report | CC1.1, CC1.4, CC2.2 |
CC-03 | Risk register reviewed and updated quarterly with likelihood/impact scoring | Head of GRC | Quarterly | Risk register export with revision history | CC3.1, CC3.2, CC3.3 |
CC-04 | Fraud risk factors formally considered as part of quarterly risk assessment | Head of GRC | Quarterly | Risk assessment meeting notes | CC3.3 |
AC-01 | Production system access provisioned only via SSO group membership tied to role | Director of IT Ops | Continuous (system-enforced) | SSO group configuration export | CC5.2, CC6.1, CC6.2 |
AC-02 | Multi-factor authentication required for all access to production and admin consoles | Director of IT Ops | Continuous (system-enforced) | Identity provider MFA policy config | CC6.1, CC6.3 |
AC-03 | Quarterly access recertification requiring manager sign-off on all standing access | Director of IT Ops | Quarterly | Access review sign-off export | CC6.1, CC6.2, CC6.3 |
AC-04 | Access revoked within 24 hours of termination via automated HRIS-to-IdP deprovisioning | HR Director / Director of IT Ops | Continuous, reviewed monthly | Deprovisioning ticket log + timestamp audit | CC6.2, CC6.3 |
CM-01 | All production code changes require peer review and passing CI tests before merge | VP Engineering | Continuous (system-enforced) | Pull request approval records | CC8.1 |
CM-02 | Infrastructure changes deployed via version-controlled IaC with mandatory approval gate | VP Engineering | Continuous (system-enforced) | IaC pipeline approval logs | CC7.1, CC8.1 |
MON-01 | SIEM aggregates security logs from production systems with 24/7 alerting on defined rules | Director of Security Operations | Continuous | SIEM configuration + alert history | CC4.1, CC7.1, CC7.2 |
MON-02 | Documented incident response plan tested via tabletop exercise annually | Director of Security Operations | Annual | Tabletop exercise report and action items | CC7.3, CC7.4, CC7.5 |
VEN-01 | Critical vendors undergo security due diligence and annual reassessment, including subservice organization SOC 2 review | Head of GRC | Onboarding + annual | Vendor risk assessment records | CC9.1, CC9.2 |
Two things to notice. First, every criteria-mapped cell holds more than one reference — that's the many-to-many principle from the previous section applied consistently. Second, the domains (governance, access, change management, monitoring, vendor) roughly track the Common Criteria order, which makes the matrix easier for a first-time reader to scan even before they get to the criteria column.
"When I open a client's matrix and every row maps to exactly one criterion, I already know I'm going to find gaps in fieldwork. Real controls are rarely that narrow." — Elena Voss, Lead SOC 2 Auditor, Bramwell & Cho CPAs
Coverage Gap Analysis: Reading the Matrix in Reverse
Once the matrix exists, invert it. Instead of reading down the rows (control → criteria), pivot by criterion and count how many controls reference each one. This single exercise is the fastest way to find weak spots before an auditor does.
Criteria Category | Controls Mapped (Harborlight Example) | Assessment |
|---|---|---|
CC1 – Control Environment | CC-01, CC-02 | Adequate — governance and onboarding both covered |
CC2 – Communication and Information | CC-02 | Thin — only one control; consider adding an internal comms/reporting control |
CC3 – Risk Assessment | CC-03, CC-04 | Adequate |
CC4 – Monitoring Activities | MON-01 | Thin — single point of coverage for an entire category is a common audit finding |
CC5 – Control Activities | AC-01 | Adequate given cross-references from other domains |
CC6 – Logical and Physical Access | AC-01, AC-02, AC-03, AC-04 | Strong — layered coverage across provisioning, MFA, review, deprovisioning |
CC7 – System Operations | CM-02, MON-01, MON-02 | Adequate |
CC8 – Change Management | CM-01, CM-02 | Adequate |
CC9 – Risk Mitigation | VEN-01 | Thin — single control for all vendor and business-disruption risk |
A criterion with zero controls mapped is an automatic finding waiting to happen. A criterion with exactly one control mapped is a fragility risk — if that one control fails or the evidence is incomplete, the whole category fails testing. Auditors in practice want to see at least two independent controls supporting any category that touches access, operations, or change management, because those are the categories with the highest concentration of points of focus.
Coverage Level | Definition | Typical Auditor Reaction |
|---|---|---|
Zero controls | No mapped control at all | Automatic finding / scope question — how is this criterion being met? |
Single control | One control, no redundancy | Elevated scrutiny; single point of failure noted in workpapers |
Two to three controls | Reasonable, layered coverage | Standard testing, no special flag |
Four or more controls | Strong, defense-in-depth coverage | Often seen in CC6/CC7 for mature security programs |
Common Mistakes When Building a Matrix
I've reviewed enough of these documents, across enough companies, to see the same five mistakes recur regardless of company size or industry.
Mistake | Why It Happens | Fix |
|---|---|---|
Copying a template's criteria list without customizing to actual scope | Templates default to Security-only or all five categories regardless of what's in the system description | Pull the exact criteria list from your management assertion and system description, not a generic template |
Mapping controls to criteria "vibes" rather than specific points of focus | Builders map at the CC-number level only, skipping the sub-point granularity auditors actually test | Reference the specific point of focus (e.g., CC6.1 not just CC6) wherever your framework guidance provides one |
Treating the matrix as a one-time deliverable for the audit | Compliance teams build it once for fieldwork and never touch it again | Assign a maintenance owner and a review cadence (see below) — treat it as a living system, not a report attachment |
No distinction between control design and operating status | Matrix shows a control "exists" but not whether it's actually running as intended this quarter | Add a status column separating "designed" from "operating effectively," updated at each internal review |
Evidence column left vague or empty | Compliance teams build controls and criteria mapping first, evidence last, and evidence gets deprioritized | Populate evidence type and location at the same time as criteria — an unmapped-to-evidence control isn't audit-ready |
"The matrix that gets built the week before fieldwork starts is always the weakest one. You can tell, because the evidence column is empty and everyone's owner is listed as 'Engineering.'" — Devon Okafor, GRC Program Manager, Fielding Health Analytics
Control Matrix vs. Statement of Applicability vs. RACI
Compliance teams working across frameworks often confuse the control matrix with two adjacent artifacts that look similar but serve different purposes. It's worth being precise, especially if your organization is pursuing ISO 27001 alongside SOC 2.
Artifact | Framework | Primary Question It Answers | Owner |
|---|---|---|---|
SOC 2 Control Matrix | SOC 2 / TSC | Which controls satisfy which Trust Services Criteria? | GRC / Compliance |
Statement of Applicability (SoA) | ISO 27001 | Which of the 93 Annex A controls are applicable, and why/why not, to our ISMS? | Information Security Manager |
RACI Matrix | Project/organizational | Who is Responsible, Accountable, Consulted, and Informed for a given activity or control? | Program/Project Management |
An ISO 27001 SoA and a SOC 2 control matrix are structurally similar — both are inclusion/exclusion and mapping documents — but they answer different scoping questions. The SoA justifies applicability against a fixed catalog of 93 controls; the SOC 2 matrix maps your organization's actual, sometimes bespoke, controls against a criteria framework that doesn't prescribe specific control language the way Annex A does. If you're running both frameworks, the control matrix becomes the natural seed for a formal crosswalk between ISO 27001, SOC 2, and NIST CSF, because most of your underlying controls (MFA enforcement, change approval, vendor due diligence) satisfy requirements in both frameworks simultaneously — you're just re-tagging the same control rows against a second criteria column.
A RACI matrix, by contrast, isn't about criteria coverage at all — it's about clarifying decision rights and involvement for a process or project. Some organizations fold a lightweight RACI into their control matrix (who's Responsible for day-to-day operation vs. who's Accountable for the control existing at all), which is a reasonable hybrid as long as it doesn't replace the criteria-mapping function that's the matrix's actual job.
Tooling: Spreadsheet, Airtable, or GRC Platform
Most companies start in a spreadsheet and migrate to a dedicated platform once the matrix passes roughly 40–50 controls or the team managing it grows past one or two people. There's no universally right answer — the right tool depends on headcount, audit frequency, and budget.
Tool Category | Best For | Strengths | Limitations |
|---|---|---|---|
Spreadsheet (Excel/Google Sheets) | Very early stage, single owner, first audit | Free, flexible, zero learning curve, easy to share with auditors | No version control discipline by default, no automated evidence linkage, breaks down past ~50 rows with multiple contributors |
Structured database (Airtable/Notion) | Growing teams, multiple contributors, need for filtered views | Relational fields handle many-to-many mapping cleanly, custom views per stakeholder, better audit trail than raw spreadsheets | Still manual evidence collection, no native control-testing workflow |
Dedicated GRC platform | Multiple frameworks, continuous audits, larger compliance teams | Automated evidence collection from integrated systems, built-in criteria libraries, real-time gap dashboards, audit-ready exports | Cost, implementation time, can become another system of record to maintain if not fully adopted |
Whichever tool you choose, the discipline matters more than the platform. A spreadsheet maintained rigorously with a monthly review beats an expensive GRC platform that nobody updates after the initial import.
"I've seen six-figure GRC platforms with a control matrix that's twenty months stale because nobody assigned an owner to keep it current. The tool isn't the control. The habit is the control." — Sarah Lindqvist, CISO, Tradewind Logistics
Maintaining the Matrix: It's a Living Document, Not an Audit Deliverable
The matrix Priya's team scrambled to build for Meridian didn't need to be built from scratch — it needed to exist continuously from the day of the first Type I audit, updated as controls changed, as new systems entered scope, and as the audit period rolled forward. Continuous compliance treats the matrix the same way it treats evidence collection: an ongoing operational habit, not a pre-audit fire drill.
Trigger for Matrix Update | Example | Who Updates It |
|---|---|---|
New control implemented | Rolling out a new EDR tool | Control owner + GRC reviews and adds row |
Control retired or replaced | Migrating from a legacy VPN to ZTNA | Control owner flags retirement; GRC updates status and criteria mapping |
Scope change | Adding Availability to TSC scope for a new SLA commitment | Head of GRC re-maps affected criteria and adds new controls |
Ownership change | Control owner leaves the company or changes role | GRC reassigns owner field within one week of the change |
Quarterly internal review | Standing cadence | Control owners self-attest; GRC spot-checks a sample |
Pre-audit refresh | 60–90 days before Type II fieldwork begins | Full matrix review, evidence links verified, gap analysis re-run |
A quarterly cadence, with a lightweight self-attestation from each control owner ("this control is still operating as described, evidence is current"), catches drift long before it becomes an audit exception. Treat any control that hasn't been reviewed in more than two quarters as a yellow flag regardless of whether anything actually changed.
The Matrix and the Audit: How Auditors Actually Use It
Auditors don't take your control matrix at face value — they use it as a starting map, then independently verify it during SOC 2 control testing. But a good matrix dramatically changes how fieldwork unfolds. Instead of the auditor building their own control inventory from your policies (which, as Elena Voss notes above, can eat the first two weeks of an engagement), they start from your matrix, validate the mappings during a walkthrough, and move directly into requesting evidence.
This is also where evidence collection practices and the matrix intersect directly. Every evidence request an auditor makes during fieldwork should trace back to a specific row in your matrix — if it doesn't, either the matrix is missing a control or the auditor has identified something you hadn't documented. A well-maintained evidence location column (pointing to exactly where in your GRC platform or shared drive the proof lives) turns what used to be a scramble into a lookup.
Audit Phase | How the Matrix Is Used |
|---|---|
Planning | Auditor reviews the matrix to scope which controls will be tested for each criterion in the report |
Walkthrough | Auditor validates that the matrix description matches how the control actually operates in practice |
Fieldwork / testing | Auditor requests evidence directly against matrix rows rather than re-deriving what to ask for |
Exception handling | If a control fails testing, the matrix shows every criterion affected — critical for exception management and scoping the impact |
Report drafting | The final report's control activities narrative is frequently drawn almost verbatim from well-written matrix descriptions |
"A clean control matrix doesn't shorten my testing procedures — professional standards don't let me skip steps because the client did good homework. But it absolutely shortens the time between when I show up and when I start finding real answers instead of chasing down what a control even is." — Elena Voss, Lead SOC 2 Auditor, Bramwell & Cho CPAs
The Matrix and Policy: Two Documents, One Source of Truth
A control matrix and a policy set describe the same control environment from two different angles, and confusing the two is a common structural mistake. Policy development produces the documented rules — what should happen, why, and under what authority. The matrix answers a narrower, more operational question: for each specific control that puts a policy into action, what criteria does it satisfy and what proves it happened.
In a well-run program, every policy decomposes into one or more matrix rows, and every matrix row traces back to the policy that authorizes it. An access control policy that says "all production access requires MFA and manager approval" might decompose into three matrix rows: AC-01 (SSO provisioning), AC-02 (MFA enforcement), and AC-03 (access recertification) — each with its own owner, cadence, evidence, and criteria mapping, even though all three trace to the same paragraph of policy.
Document | Answers | Granularity | Audience |
|---|---|---|---|
Policy | What is required, and why | Topic-level (access, change, incident response) | All employees, auditors, board |
Control Matrix | Which specific controls prove the requirement is met, mapped to criteria | Control-level, one row per discrete control | Compliance team, auditors, control owners |
Evidence Repository | The actual artifacts proving each control operated | Instance-level (individual log exports, tickets, screenshots) | Compliance team, auditors during fieldwork |
Building policies and the matrix in the same project, rather than sequentially, avoids the trap Harborlight fell into — a full policy binder with no corresponding matrix, which meant nobody could answer a criteria-mapping question without hours of manual cross-referencing.
Ownership and RACI for the Matrix Itself
The matrix needs an owner just like every control inside it does. In most mid-market organizations, that's the Head of GRC or Compliance Manager, but the day-to-day upkeep is genuinely a shared responsibility across every control owner referenced in the document.
Role | Responsibility for the Matrix |
|---|---|
Head of GRC / Compliance Manager | Accountable (A) — owns the document, runs the quarterly review, maintains the criteria taxonomy |
Individual control owners | Responsible (R) — attest to their own rows quarterly, flag changes as they happen |
CISO / VP Engineering | Consulted (C) — weighs in on scope changes, new systems entering the environment |
External auditor | Informed (I) — receives the matrix at the start of fieldwork, provides feedback on mapping accuracy |
Executive leadership / board | Informed (I) — receives a summarized coverage view, not the full row-level detail |
Splitting accountability this way prevents the two failure modes I see most often: either one overloaded compliance person tries to personally verify every control (which doesn't scale past about 30 controls), or ownership is so diffuse that nobody updates anything and the matrix goes stale, the way it did at Harborlight between the Type I and the Meridian deal.
Automating the Matrix with a GRC Platform
Once a company is running continuous evidence collection — automated pulls from the identity provider, the cloud environment, the ticketing system — a dedicated GRC platform can turn a chunk of the matrix from a static document into a live dashboard. Automation doesn't replace the mapping judgment (a human still decides which criteria a control satisfies), but it removes the manual evidence-chasing that makes matrices go stale.
Capability | Manual Spreadsheet | Automated GRC Platform |
|---|---|---|
Criteria mapping | Manual entry, manually maintained | Manual entry (still requires human judgment), but centrally taxonomized |
Evidence collection | Manual upload per control, per period | Automated integrations pull evidence continuously (e.g., IdP configs, ticket exports) |
Coverage gap dashboard | Manual pivot table, run on demand | Live dashboard, updates as controls/evidence change |
Control drift alerts | None — drift discovered at next manual review | Automated alerts when evidence stops flowing or a control owner changes |
Multi-framework crosswalk | Separate spreadsheet per framework, manually reconciled | Single control tagged against multiple frameworks' criteria simultaneously |
Auditor collaboration | Email/spreadsheet exchange | Auditor portal access with controlled, read-only views |
Treat automation as an accelerant for a process you already understand manually, not a replacement for the judgment involved in deciding what a control actually satisfies. Teams that adopt a GRC platform before they've ever built a matrix by hand tend to configure it poorly, because they don't yet know which mappings are meaningful versus which are box-checking.
Multi-Framework Mapping: Making the Matrix Do Double Duty
Once your SOC 2 control matrix exists, extending it to cover a second framework is usually a matter of adding columns, not rebuilding rows. Most organizations pursuing both SOC 2 and ISO 27001 find that 60–75% of their underlying controls satisfy requirements in both frameworks — the mapping differs, but the control itself (MFA enforcement, change approval, vendor due diligence) doesn't.
Harborlight Control | SOC 2 Criteria | ISO 27001 Annex A Reference (Illustrative) |
|---|---|---|
AC-02 (MFA enforcement) | CC6.1, CC6.3 | 8.5 Secure authentication |
CM-01 (peer-reviewed code changes) | CC8.1 | 8.32 Change management |
MON-01 (SIEM monitoring) | CC4.1, CC7.1, CC7.2 | 8.16 Monitoring activities |
VEN-01 (vendor due diligence) | CC9.1, CC9.2 | 5.19–5.22 Supplier relationships |
AC-04 (termination deprovisioning) | CC6.2, CC6.3 | 6.5 Responsibilities after termination |
This is illustrative rather than an exhaustive crosswalk — always verify specific Annex A control numbers against the current ISO/IEC 27001:2022 standard text rather than assuming a mapping carries over automatically, since the language and scope of each control differ even when the underlying activity is shared. For a full treatment of this overlap, see the dedicated crosswalk connecting ISO 27001, SOC 2, and NIST CSF control mapping, and for the higher-level "which one first" decision, ISO 27001 vs. SOC 2 lays out the trade-offs.
Metrics to Track Matrix Health
A control matrix, like any operational artifact, benefits from a small set of health metrics tracked over time rather than treated as pass/fail at audit time.
Metric | What It Measures | Healthy Target |
|---|---|---|
Percentage of controls with zero criteria mapped | Controls documented but not yet tied to any requirement | 0% |
Percentage of criteria with fewer than two controls mapped | Single points of failure in coverage | Under 10%, concentrated only in low-risk categories |
Percentage of controls reviewed in the last quarter | Freshness of self-attestation | Above 90% |
Average days since last evidence upload, per control | Evidence staleness | Aligned to control frequency (e.g., under 35 days for monthly controls) |
Number of controls with no named owner | Accountability gaps | 0 |
Number of open findings without a corresponding matrix update | Whether remediation work is flowing back into the matrix | 0 |
Tracking these quarterly, and presenting a summarized version to leadership, turns the matrix from a document that exists for the auditor into a genuine operational management tool — which is the actual point.
Case Study: Harborlight Payments — From Reactive to Ready
Harborlight's rebuild, completed in the aftermath of the Meridian near-miss, took nine business days with two dedicated contributors (Priya and a security engineer) plus roughly ninety minutes each from eleven control owners across engineering, IT, and HR. The team inventoried 58 discrete controls, mapped 214 individual criteria references across them (an average of 3.7 criteria per control), and identified four categories with single-point coverage — CC2, CC4, CC9, and Privacy points of focus that had crept into scope when Harborlight added a European payroll-data feature nobody had flagged to compliance.
Metric | Before Rebuild | After Rebuild |
|---|---|---|
Time to answer a criteria-mapping question | 6–11 business days | Same-day, via matrix lookup |
Controls with zero criteria mapped | Unknown (no matrix existed) | 0 of 58 |
Criteria categories with single-point coverage | Unknown | 4, flagged for remediation |
Average enterprise security review cycle time | 9.5 weeks | 3.5 weeks |
Meridian contract status | Frozen 11 weeks in review | Signed; renewed the following year without a security re-review |
The four thinly-covered categories became a formal remediation project over the following quarter — Harborlight added a structured internal communications control for CC2, expanded monitoring dashboards reviewed by a second team lead for CC4, brought on a second vendor-risk reviewer for CC9, and retroactively documented the privacy controls the payroll feature had quietly required. None of this required new tooling spend; it required the matrix to exist so the gaps were visible.
Case Study: Rosecliff HR — Matrix Drift Over Three Audit Cycles
Rosecliff HR, a 90-person HR technology platform (referenced elsewhere in this pillar's SOC 2 for HR Technology Platforms coverage), presents the opposite failure pattern: a matrix that existed but was never maintained. Built for their first Type II audit, it was never updated across two subsequent audit cycles as the company migrated cloud providers, replaced its ticketing system, and lost the original control owner for six of the fourteen access-management rows to attrition.
By the third audit cycle, the auditor found that four matrix rows referenced tooling Rosecliff no longer used, three rows had no current owner, and one row claimed evidence from a system that had been decommissioned fourteen months earlier. None of these were fraud or negligence in the dramatic sense — they were the predictable result of treating the matrix as a one-time deliverable rather than a living document. The audit still passed, but with two exceptions noted for evidence gaps that traced directly back to stale matrix rows, and the remediation effort to rebuild matrix discipline took six weeks — nearly as long as building it from scratch would have.
Rosecliff Finding | Root Cause | Remediation |
|---|---|---|
Two exceptions on access review evidence | Matrix row referenced a decommissioned ticketing system | Matrix updated to reflect current system; new evidence trail established |
Three unowned controls | Control owners left without reassignment | Formal quarterly ownership review added to compliance calendar |
One-quarter delay in report delivery | Auditor required additional walkthroughs to reconcile stale rows | Matrix maintenance cadence formalized with monthly spot-checks |
The lesson from Rosecliff, set against Harborlight's turnaround, is that building the matrix well the first time matters less in the long run than committing to the maintenance cadence described earlier in this article. A mediocre matrix, kept current, beats an excellent matrix nobody touches after the audit closes.
The Business Case: A Matrix Is a Sales Asset, Not Just an Audit Artifact
It's worth stating plainly what Priya learned the hard way at Harborlight: a control matrix is not primarily a compliance artifact that exists to please an auditor once a year. It's a sales-enablement asset. Enterprise security reviews increasingly ask for criteria-level mapping directly, not just a copy of the SOC 2 report, because sophisticated buyers know the report's narrative sections don't answer "show me exactly which control covers CC6.3" as fast as a table does. A company that can produce a clean, current control matrix on request shortens security review cycles, reduces the number of follow-up questions from procurement teams, and signals — accurately — that its compliance program is a genuine operating discipline rather than an annual scramble.
The same document also pays for itself internally. Engineering leads stop guessing which of their systems are in scope. New compliance hires ramp in days instead of weeks because the matrix is the map of the entire control environment. And when the company eventually pursues a second framework — ISO 27001, PCI DSS, HIPAA — the matrix becomes the seed of every future crosswalk instead of a from-scratch project. Treat the build described in this article as an investment with a return measured in shorter sales cycles and calmer audit seasons, not a one-time compliance checkbox.
If you're building or rebuilding your matrix and want a structured starting point rather than a blank spreadsheet, PentesterWorld's SOC 2 Control Matrix / RACI Template is built around the exact column structure and worked example used in this article, and pairs well with the SOC 2 Trust Services Criteria Mapping Template for teams mapping optional categories for the first time. Run your own coverage check against the SOC 2 Gap Analysis Tool once your matrix is populated, and keep terminology straight with the SOC 2 Glossary as you brief control owners who are new to the framework.