The auditor’s request arrives before the coffee does: show the population for the journal-entry approval control, identify who performed the review, and provide evidence that it operated during the period. The spreadsheet says the control owner is a former controller, the evidence field says “signed PDF,” and the frequency says monthly even though the review happens quarterly. Nothing is technically missing from the file, yet the file can’t prove that the control worked.
That gap defines the difference between documentation and governance. A risks and controls matrix must connect business risk to an accountable person, a repeatable activity, retrievable evidence, and a defensible test result. Built properly, it supports SOX programs, healthcare audits, financial-regulator reviews, and operational decision-making. Built as a one-time spreadsheet, it becomes an artifact that looks complete until someone asks a precise question.
Why Most Control Spreadsheets Fail When Auditors Arrive
The failure usually starts long before the audit request. A team copies last year’s workbook, changes a few process names, and assumes the control descriptions still match the way work is performed. Meanwhile, the application has changed, the approval workflow has been automated, and the person listed as owner has moved to another company.
An auditor doesn’t test whether the spreadsheet has filled cells. The auditor tests whether the control is capable of addressing the stated risk and whether it operated as described. That means the matrix must answer three practical questions without interpretation:
- Who performs the control: Name the accountable role and the current operator, with backup coverage where the process depends on a single person.
- What proves operation: Identify the actual artifact, such as a system log, approval record, reconciliation, ticket, exception report, or sign-off.
- How often it runs: Record the cadence that reflects the process, not the cadence that makes the testing calendar convenient.
The evidence field is where many otherwise polished matrices collapse. “Signed PDF” doesn’t tell a tester where the file resides, which population it covers, whether it was generated by the system of record, or how the reviewer can establish completeness. A usable entry identifies the repository, artifact name or report, retention expectation, and retrieval method.
Practical rule: If a new tester can’t locate the evidence and understand the control without calling the owner, the matrix isn’t operationally complete.
Design adequacy and operating effectiveness must also remain separate. A quarterly approval review may be well designed for a slower-moving process, yet it can still fail if the reviewer missed exceptions or didn’t document resolution. Teams responsible for technical workflows can use a technical audit service to examine whether application behavior, logs, permissions, and process documentation align with the controls recorded in the matrix.
The RCM fixes the spreadsheet problem by treating every row as a testable contract. The row states what could go wrong, what prevents or detects it, who is accountable, and what evidence proves execution. Anything less is an inventory of intentions.
What a Risks and Controls Matrix Actually Is
A risks and controls matrix is a structured document that pairs a business risk with the specific control activity intended to mitigate it. It also records the control’s owner, frequency, type, evidence, design assessment, operating test result, and residual risk. In plain language, it translates “we manage this risk” into “this person performs this action, this artifact proves it, and this test determines whether it worked.”
A risk register serves a different purpose. It catalogs risks, owners, causes, consequences, and inherent ratings. An RCM goes further by binding each risk to mitigation mechanics. A risk register might say that unauthorized access threatens financial reporting. The RCM identifies the access review, the reviewer, the system report, the review cadence, the exceptions, and the evidence retained.
The COSO lineage
The modern internal-control movement developed after major accounting scandals prompted the creation of COSO in 1985, followed by COSO’s landmark Internal Control, Integrated Framework in 1992. The framework formalized five components:
- Control environment
- Risk assessment
- Control activities
- Information and communication
- Monitoring activities
The framework gave organizations a structured way to connect specific risks to mitigating controls across industries and organizational sizes. COSO refreshed it in 2013, preserving those five components while introducing 17 principles and 77 points of focus, which made high-level expectations easier to translate into documented, testable controls. The World Bank discussion of the COSO framework’s development provides useful historical context for why modern control mapping looks the way it does.
The Institute of Internal Auditors describes the matrix as a way to identify objectives and risks, assess significance through impact and likelihood, select a response, and map key controls. Teams that connect the RCM to governance risk KPIs for IT operations can also connect control performance with operational indicators, rather than leaving assurance data isolated in an audit workbook.
The Anatomy of a Working RCM
A working RCM contains fields that answer the questions a tester, control owner, or regulator will ask. The exact layout can vary, but the useful version normally covers the following information.
The risk and the response
Risk statement: Describe what could go wrong in business terms. “Noncompliance with policy” is too vague. “Unauthorized journal entries could be posted to the general ledger, causing inaccurate financial reporting” identifies the event and consequence.
Control objective and activity: State the action that addresses the risk. Include the system, population, threshold, reviewer, and treatment of exceptions. “The close manager reviews the automated journal-entry exception report and documents resolution before posting” is testable. “Management reviews entries” isn’t.
Control type: Classify the control as preventive or detective, and manual or automated. A segregation-of-duties rule that blocks a conflicting transaction is preventive and automated. A manager’s review of an exception report is detective and may be manual, even if the report is system-generated.
Frequency: Match cadence to risk velocity. A quarterly review may suit a stable vendor population, while a high-volume access process may require more frequent monitoring. The frequency must describe actual operation, not an aspirational schedule.
Accountability and proof
Owner: Assign one accountable individual by role. A department name or shared mailbox doesn’t establish responsibility. Record the operator separately when the owner designs or oversees the control but another person executes it.
Evidence: Identify the system of record and artifact. Examples include an IAM review log, approval workflow record, reconciliation, ticket, exception report, or system-generated event log. Evidence must let a tester establish what was reviewed, by whom, when, and how exceptions were handled.
Process links: Add process, sub-process, system, regulatory citation, assertion, and last review date. These fields make the matrix navigable and support traceability from an obligation to a test result.
Effectiveness and exposure
Design adequacy: Assess whether the control could address the risk if performed as written. Useful categories include effective, partially effective, and deficient. The public-sector risk-control matrix template separates design adequacy from whether the control operates effectively, which is an important discipline.
Operating effectiveness: Record the result of testing over the relevant period, including exceptions, population details, sample rationale, and remediation. A well-designed control can still fail in operation.
Residual risk: Describe the exposure remaining after the control and any compensating controls operate. Residual risk isn’t a decorative rating. It determines whether management accepts, mitigates, transfers, avoids, or escalates the remaining exposure.
A detailed matrix may also classify controls as key or standard, mandatory or discretionary, and automated or manual. The North Carolina control-matrix template demonstrates how explicit classification, test steps, exceptions, and residual likelihood and impact can support formal assessment.
Two Real RCM Examples From Audit Practice
The following comparison uses recurring audit situations, not named company case studies. The point isn’t to produce perfect ratings. It’s to show how each cell creates a chain from the risk to the evidence a tester can inspect.
| RCM Column | Vendor Due-Diligence Control | Access Review Control |
|---|---|---|
| Process | Procurement and supplier onboarding | Financial close system administration |
| Risk statement | An inadequately vetted vendor could expose the organization to operational, privacy, or financial-reporting risk | Excessive or inappropriate user access could permit unauthorized changes during financial close |
| Related objective or assertion | Vendor legitimacy, authorization, and third-party risk management | Authorization, access governance, and protection of financial data |
| Control activity | Procurement reviews the vendor risk assessment and required due-diligence package before approval | The system owner reviews the current user-access population, investigates exceptions, and documents removals or approvals |
| Control type | Preventive, manual review supported by system records | Detective, review supported by an automated IAM report |
| Frequency | Before onboarding or material vendor change | Quarterly, with event-driven review after significant access changes |
| Owner | Procurement risk manager | Financial systems owner |
| Evidence | Vendor risk score file, due-diligence package, approval record, and exception disposition | IAM review log, access population report, reviewer sign-off, and tickets resolving exceptions |
| Design adequacy | Effective when the approval gate blocks onboarding until required checks are complete | Partially effective if privileged access and service accounts aren't clearly included |
| Operating result | Effective only when sampled files show the required review and exception resolution | Effective only when the report population is complete and remediation tickets close with evidence |
| Residual risk | Moderate where third-party dependency remains after review | Moderate where emergency access or system-generated accounts require compensating oversight |
The vendor row fails if it names “Procurement” as the owner without an accountable role, or if the evidence column says only “vendor file.” The access row fails if the frequency says monthly but the system owner performs the review quarterly. Both rows also become difficult to defend when the matrix records “passed” without population completeness, test period, exceptions, or remediation evidence.
Audit reality: More rows don't compensate for weak row design. One precise control record is more useful than several copied descriptions that point to no retrievable artifact.
The mature RCM guidance from Wolters Kluwer illustrates the operational value of linking risk, control type, frequency, ownership, and residual exposure. Column discipline is what makes sampling defensible.
How to Build an RCM From Process to Test
Build the matrix in execution order, not in the order the columns appear on a spreadsheet.
Scope the process first
Start with a defined business-process boundary. Link procurement, payroll, revenue, financial close, patient-data handling, or another process to the relevant financial-statement area, regulatory obligation, or operational objective. Without scope, risk workshops produce broad statements that can't be assigned or tested.
Identify what can go wrong
Bring process owners, internal audit, compliance, security, and technology specialists into the walkthrough. Ask what could fail against a specific assertion or obligation. A useful risk statement identifies the event, the affected objective, and the consequence.
Map and classify controls
Document existing activities before designing new ones. For each activity, record whether it is preventive or detective, manual or automated, and performed continuously, periodically, or after a trigger. Don't accept a control because it sounds reasonable. Confirm that it addresses the risk and produces evidence.
Assign accountability
Give each control one accountable owner. The operator, reviewer, approver, and backup may be different people, but the matrix should make those relationships visible. Shared responsibility often becomes no responsibility when an exception appears.
Define evidence before testing
Specify the artifact before asking whether the control passed. Depending on the process, that may be a screenshot, system log, workflow approval, reconciliation, ticket, report, or signed form. Record the repository, date range, population source, and exception trail.
Test in two stages
Test design effectiveness first. If the activity can't address the risk, operating samples only prove that an ineffective control was performed. Once the design is adequate, test operating effectiveness over the defined period and document the population, selection method, evidence reviewed, exceptions, and conclusion.
The Institute of Internal Auditors' guidance supports this sequencing because assessing design adequacy before effectiveness testing prevents teams from spending testing effort on controls that aren't capable of managing the risk. Shortcuts usually appear as skipped scoping, evidence accepted on trust, and a single undocumented test that blends design and operation.
Extending the Matrix for AI and Automated Workflows
AI shouldn't force an enterprise to duplicate its entire control library. It should add a layer that shows where existing controls still apply, where they need augmentation, and which evidence proves the automated workflow operated in production.
Use four ownership layers:
- Business process: The process owner monitors outputs, business impact, overrides, and escalation.
- Data: The data owner governs quality, integrity, privacy, lineage, and permitted use.
- Model: The model owner monitors performance, drift, bias, explainability, and approved use.
- Infrastructure: The platform or security owner manages access, deployment controls, logging, resilience, and system changes.
An automated journal-entry anomaly detector, for example, can inherit classic access, change-management, logging, and incident-response controls. It still needs AI-specific augmentation for model thresholds, false positives, drift, override handling, and human review. Automated PII redaction needs data-quality evidence and exception handling. A policy-as-code deployment gate needs versioned rules, approval history, and pipeline logs.
Inherit, augment, or replace
A useful classification is:
| Treatment | Example | Matrix implication |
|---|---|---|
| Inherit | Access control, logging, change approval | Reuse the existing control with the AI system and evidence source added |
| Augment | Management review of model output | Keep the classic oversight control and add model-performance evidence |
| Replace | Manual reconciliation replaced by automated matching | Retire the manual activity only after validating the automated control and its monitoring |
| Add | Drift, bias, explainability, and model-inventory oversight | Create a distinct algorithmic-control row with a defined test method |
The CSA AI Controls Matrix maps 243 control objectives across 18 security domains, according to the provided 2025 to 2026 material from Onspring's RCM guide. That breadth reinforces the need for a layered approach, not a flat checklist.
Teams evaluating custom AI agent creation should define evidence and accountability before deployment, especially when an agent can act across systems. A broader AI governance framework guide can help connect model governance to the surrounding technology and compliance architecture.
Why a Bigger Matrix Is Not a Better Matrix
A large control library can create the appearance of maturity while making assurance harder. Copy-pasted rows across business units produce inconsistent ownership and testing. Orphaned controls have no accountable owner. Orphan risks have no mapped mitigation. Critical controls disappear among low-value entries that reviewers approve without meaningful challenge.
The useful measure is not row count. It's whether the control is testable, the evidence is reliable, the owner is accountable, and the frequency matches the speed of the risk.
Prune based on exposure
Ruthless pruning doesn't mean removing governance. It means removing duplication and concentrating attention where control failure matters.
- Remove copied descriptions: Keep one authoritative control where the process and evidence are common. Create a separate row only when ownership, system behavior, risk, or testing differs.
- Resolve orphaned rows: Assign an owner or retire the control. A team name can support routing, but it shouldn't replace individual accountability.
- Close orphan risks: Map a mitigation, document a formally accepted exposure, or escalate the gap to management.
- Retire obsolete controls: Link retirement to process change, system decommissioning, or replacement by a validated automated control.
- Prioritize residual exposure: Focus review effort on controls with material remaining risk, recurring exceptions, incident history, or weak evidence.
Over-instrumentation creates control fatigue. Reviewers spend time approving low-value entries, while duplicated preventive layers obscure the detective control that would reveal a failure. A focused matrix produces clearer testing and better conversations with management because each row earns its place.
Keeping Your RCM Alive After Go-Live
A living RCM connects to the systems that change the risk environment. Change management should trigger a review when a workflow, application, integration, role, or approval path changes. Incident management should trigger control redesign after a loss event, near miss, or repeated exception. Exception tracking should record the gap, compensating control, accountable owner, due date, and closure evidence.
Set a minimum quarterly review for the matrix, with monthly sampling for high-velocity processes. That cadence should be risk-based, not ceremonial. The matrix also needs version control, owner attestation, documented approvals, and an audit trail showing what changed and why.
Maintenance checklist
- Reassess after change: Review controls after process redesign, system releases, acquisitions, or new integrations.
- Review incidents: Link control failures and near misses to affected rows and remediation.
- Refresh evidence: Confirm repositories, report logic, retention, and retrieval instructions remain accurate.
- Reconfirm ownership: Obtain owner attestation and review backup coverage.
- Reconsider retirement: Retire controls only when the underlying risk, process, or control activity has been replaced and documented.
- Reevaluate residual risk: Use test results, exceptions, incidents, and compensating controls to update the remaining exposure.
- Maintain traceability: Integrate the matrix with GRC tooling, change records, test workpapers, and issue management.
For automated environments, AI-powered change management can help teams connect technical change signals with control review triggers. The matrix remains useful after go-live only when operational events can update it.
devPulse helps enterprises design and modernize systems with technical audits, workflow automation, secure AI integration, testing, observability, and ongoing support for regulated environments. If your RCM evidence is scattered across applications or your automated controls lack clear ownership and test paths, visit devPulse to discuss a practical architecture and delivery plan.
