Build a Responsibility Assignment Matrix for DORA & NIS2

If an auditor asked today, “Who owns this control, who approves it, and who can produce the evidence?”, would your team answer consistently?

Most organisations think they already have a clear answer because they have a project plan, a spreadsheet, or a RACI chart buried in a shared drive. That usually works until ownership has to be proven under pressure. In regulated environments, that pressure arrives during incident response, third-party reviews, control testing, and formal audit requests.

A responsibility assignment matrix is often treated as a project-management convenience. That's too narrow. In practice, it can be the mechanism that connects policy, control execution, approval, escalation, and evidence into one visible structure. Without that structure, people improvise. Improvisation is where approvals go missing, control handoffs fail, and evidence ends up scattered across tickets, inboxes, and vendor portals.

The problem isn't that teams don't assign work. They do. The problem is that work assignment and accountability aren't the same thing. A security engineer may perform a review. An operations manager may coordinate the change. A compliance lead may collect evidence. None of that tells you who is answerable for the control outcome.

That distinction matters more now because governance expectations in IT have moved well beyond “someone was involved”. They require a defensible chain of ownership. A well-built responsibility assignment matrix doesn't just describe tasks. It shows who decides, who executes, who must be consulted, who needs visibility, and who signs off when the control has to stand up to scrutiny.

Beyond the Project Plan

Most RAM articles stop at team coordination. They explain the letters, show a generic launch example, and assume the job is done. That's fine for simple delivery work. It's not enough when the same organisation has to manage security controls, outsourced ICT services, incident reporting, policy approvals, and audit evidence.

A responsibility assignment matrix is one of the older project-governance tools in modern IT practice, and the RACI model became widely standardised through mainstream project-management use, including recognition in PMBOK traditions, as described by the Institute of Project Management's overview of the responsibility assignment matrix. Its staying power comes from a simple design. Tasks or deliverables sit on one axis, roles on the other, and each role is marked as Responsible, Accountable, Consulted, or Informed.

That historical background matters because the model survives for a reason. It solves a persistent operational problem: too many people touching the same deliverable without a single owner for the result. In IT, that problem appears everywhere. Security writes a standard, operations implements a control, legal reviews a notice, a vendor provides logs, and compliance is left trying to explain who owned the outcome.

Where conventional RACI use breaks down

The project version of RACI usually maps activities such as “deploy release” or “approve scope”. Regulated teams need something else. They need ownership mapped to:

• Controls and sub-controls such as access reviews, backup verification, incident classification, or vendor due diligence
• Evidence obligations such as screenshots, policy approvals, exported logs, review records, and exception sign-off
• Third-party dependencies where part of the control sits with a supplier but accountability remains internal
• Escalation paths for missed approvals, failed control execution, or absent evidence

A matrix becomes useful when it answers the audit question before the auditor asks it.

That changes the role of the document. It stops being a planning artefact and becomes part of the governance system. If your matrix can't identify the owner of a failed control and the person who approves its remediation, it isn't serving the organisation where risk lives.

The real test

A practical test is simple. Pick one critical control and ask four questions.

1. Who performs it?
2. Who is answerable if it fails?
3. Who must be consulted before the control changes?
4. Who must be informed when the result affects risk, customers, or reporting?

If your answers depend on memory, relationships, or who happens to be online, the matrix is missing or ineffective. A mature RAM reduces ambiguity before a problem appears. That's why it belongs in governance, not just in project administration.

Understanding the Core Framework

A responsibility assignment matrix works because it forces teams to separate action from accountability. Those aren't interchangeable. Someone can do the work and still not own the final outcome.

The model is old, but it still fits modern IT because the underlying problem hasn't changed. Cross-functional work creates confusion unless authority is explicit. That's why the framework remains durable.

What each role actually means

Responsible means the person or team doing the work. In operational settings, this may be an engineering function, service desk, security analyst, or vendor management lead. There can be more than one Responsible party if the task requires it.

Accountable means one person owns the outcome. That person answers for completion, quality, timeliness, and sign-off. This is the role that matters most when a control fails or evidence is challenged.

Consulted means a two-way relationship. These people provide input before a decision or action is final. In regulated IT, that often includes legal counsel, privacy, security architecture, risk, or procurement.

Informed means one-way communication. These stakeholders need visibility, but they don't participate in the decision itself.

The most important rule is simple: one Accountable owner per task or control. The Institute of Project Management's explanation of RAM and RACI highlights why this matters in technology environments. One accountable owner reduces decision ambiguity in multi-team delivery, incident response, and evidence ownership.

Why one Accountable owner is the linchpin

Teams often resist this rule because reality feels messier than the model. They'll say a committee owns the process, or that security and operations are jointly accountable. In practice, joint accountability usually means delayed decisions and unclear sign-off.

Committees can govern. They shouldn't own individual control outcomes.

When evidence is late, when an exception has to be accepted, or when a regulator asks who approved a process, one named owner is the only answer that holds. You can still have many contributors. You can still have broad consultation. But only one person should carry the final accountability marker in the matrix.

Practical rule: If two people are marked Accountable, neither one really is.

RACI and operational variants

RACI is the most familiar structure, but it isn't the only useful one. Some teams use RASCI, which adds Support. That can help when operational teams need to distinguish between the person doing the work and another role providing tooling, access, or coordination.

For example, an identity engineer may be Responsible for quarterly access review execution, while a platform team supports report generation. That support role can matter operationally, especially when the process depends on another team's system access or automation.

Still, the variant matters less than the logic. A responsibility assignment matrix works when it answers four practical questions clearly:

A good matrix is strict where it needs to be and simple everywhere else. If the framework becomes too clever, people stop using it. If it's too vague, it won't survive audit or incident pressure.

The RAM in Regulated Environments

In regulated IT, ownership has to do more than coordinate work. It has to support proof.

That's where the responsibility assignment matrix changes character. It stops being a project artefact and becomes a control map. In IT-regulated environments, a RAM becomes a control-ownership and evidence-ownership map. DORA applies from 17 January 2025 and expands accountability for ICT risk and third-party oversight, while NIS2 increases management accountability for security governance, as noted in this background on the responsibility assignment matrix and governance use.

The shift is subtle but important. Older compliance habits focused on policy existence. Modern regulatory reality cares whether the organisation can show who owns execution, who approved the result, and who can produce evidence without reconstructing the process after the fact.

What regulators and auditors actually follow

Auditors rarely start from your org chart. They follow a control path.

They ask what the control is meant to achieve, who owns it, how it operates, where the evidence lives, and how exceptions are handled. If the control relies on a supplier, they also ask who manages that dependency and who reviews the supplier's contribution.

A weak matrix fails at precisely that point. It may show that “IT” is responsible, “management” is accountable, or “security” is consulted. Those labels are too broad to be useful. They don't identify decision authority, evidence ownership, or escalation responsibility.

The control chain matters more than the task list

In regulated environments, the key failure mode isn't “who does the task”. It's who can prove it happened and who signs off. That distinction becomes obvious in examples such as:

• Incident handling where one team detects, another triages, legal assesses reporting implications, and management approves external communication
• Third-party oversight where procurement owns the contract path, security reviews controls, operations depends on the service, and risk or compliance needs evidence of oversight
• Access governance where platform owners execute review actions, managers validate entitlements, and compliance needs proof of completion and approval

This is also why adjacent governance disciplines intersect. Teams that already manage cross-border reporting obligations often recognise the same pattern in other domains. The practical governance issues behind ESG compliance for multinational corporations are different in subject matter, but similar in structure: named ownership, documented approvals, and traceable evidence matter more than broad statements of intent.

A short technical explainer can help frame this accountability shift in operational terms:

Why management accountability changes the design

Once management accountability enters the picture, vague ownership becomes a governance defect. A matrix for regulated use has to link each important control or process to a role with enough authority to approve action, allocate attention, and accept escalation.

That usually means mapping by function and decision rights, not by whichever person happened to write the procedure. For example, “Security Operations Lead” is often more stable than a personal name in the base matrix, but the organisation still needs a current assignment behind that role.

The best matrices read like operational truth, not administrative theory.

A strong RAM also clarifies where external dependencies stop and internal accountability remains. A vendor may generate logs, host systems, or contribute reports. The vendor doesn't absorb your accountability. Someone inside the organisation must still own oversight, review the evidence, and sign off on the control outcome.

How to Build an Audit-Ready Matrix

An audit-ready responsibility assignment matrix starts with scope, not with letters. If you begin by filling boxes in a spreadsheet, you'll produce a neat chart that doesn't match the control environment.

Start with the assets, processes, and obligations that matter. In practice, that means your critical services, the controls that support them, the policies that define expectations, and the evidence that proves the controls operated. Only then should you map ownership.

Start from controls and evidence

A good first pass usually includes:

• Core operational controls such as incident management, access reviews, backup verification, change approval, logging oversight, and third-party review
• Governance processes such as policy approval, exception handling, control review, and remediation tracking
• Evidence-producing activities such as management reviews, report exports, ticket approvals, supplier attestations, and sign-off records

Many teams benefit from reviewing how they already collect and structure audit evidence in practice. The matrix and the evidence model should reinforce each other. If they evolve separately, control ownership and proof ownership drift apart.

Define roles by authority, not by job title

Job titles are often too local and too unstable. One company has a Head of Infrastructure. Another has a Platform Director. A third splits that work between Site Reliability and Enterprise IT. The matrix should reflect the authority needed to make a decision, not the branding of a role.

Useful role definitions are usually functional. Examples include:

• CISO for security control ownership and escalation
• IT Operations Manager for execution of operational processes
• Legal and Compliance for reporting interpretation, review obligations, and regulatory coordination
• CEO or Board for executive visibility, formal approval, or strategic escalation

If a role lacks the authority to approve the outcome, it probably shouldn't hold Accountable status. A matrix that ignores decision rights looks complete but fails the first time a real exception appears.

Use one row per control or decision point

Treat each row as a unit of governance. That row can be a control, a control activity, or a major decision point. Don't mix unrelated tasks into one line. “Incident management” is too broad if it hides detection, classification, reporting decision, and post-incident review in the same row.

A simple example for a DORA-related process looks like this:

Example RAM for a DORA Control

This is only a model. The exact allocation depends on your operating structure. In some organisations, Legal and Compliance may own the approval path for reporting. In others, the accountable role may sit with a specific resilience or risk function. What matters is that each row has a defensible owner.

If a row can't survive a challenge from legal, operations, and audit at the same time, it isn't finished.

Validate the matrix against reality

Before you publish anything, test it against actual operating scenarios.

Use a recent incident, a vendor review, a missed control, or a policy approval cycle. Walk through the matrix with the people named in it and ask whether the assignments reflect what really happens. You're looking for three common failure signals:

1. The accountable owner doesn't control the approval.
2. The responsible team can't perform the task without another team's access or tooling.
3. Evidence is produced by one role but assumed to be retained by another.

Those mismatches are valuable. They show where the process and the ownership model have diverged.

Keep the matrix narrow enough to govern

A matrix becomes unusable when it tries to represent every ticket-level action. It should cover meaningful control points, not every operational movement. The right level is usually one where a missed step would create risk, require management action, or weaken your ability to prove control operation.

That balance matters. Too broad, and ownership is vague. Too granular, and nobody maintains it. Audit-ready design sits in the middle. It captures the places where authority, execution, and evidence need to meet.

Maintaining a Living System of Ownership

Most responsibility assignment matrices don't fail because the initial design was wrong. They fail because the organisation changes and the matrix doesn't.

A major challenge is responsibility drift. As organisations change, matrices become stale, which is a common root cause of incomplete audit evidence, as described in this discussion of responsibility assignment matrix maintenance and change. That's why regulated teams need a living ownership model integrated with identity, ticketing, and evidence systems rather than a one-time chart.

What causes drift

Ownership usually drifts for ordinary operational reasons.

• Organisation changes move decision rights without updating control documents
• New suppliers take over part of a process, but the internal oversight role stays undefined
• Tool changes alter who can access logs, approvals, or evidence exports
• Staff turnover leaves a role name in the matrix that no longer maps cleanly to a real owner

The matrix then becomes ceremonial. It still exists, but it no longer predicts who will respond, approve, or provide proof when needed.

Treat the matrix like a controlled artefact

A living matrix needs the same discipline you apply to other governance objects. That includes version control, change approval, review triggers, and retained history. You don't need theatrical process overhead, but you do need enough structure to show how ownership changed and who approved the update.

Useful review triggers include:

• Material organisational changes
• New critical systems or outsourced services
• Policy rewrites or control redesign
• Findings from audits, incidents, or failed evidence requests

This is also where broader GRC governance risk compliance practice becomes operational rather than theoretical. Governance isn't the matrix itself. Governance is the set of controls that keep the matrix accurate, authorised, and aligned to the way the organisation really works.

A stale matrix is worse than no matrix because people trust it until they discover they shouldn't.

Connect ownership to operational systems

A static spreadsheet can document ownership. It can't reliably enforce or validate it.

The stronger model links role assignments to the systems where work and evidence already exist. Identity systems show who currently holds a role. Ticketing systems show execution and approvals. Evidence repositories show whether the expected proof was attached, reviewed, and retained. Immutable change logs help show when ownership changed and whether the update itself was controlled.

That doesn't remove human accountability. It strengthens it. Automation can notify, route, and record. It can't own the control.

Measure accuracy qualitatively

Many teams want a precise metric for matrix accuracy. In practice, the more useful approach is recurring verification through operational tests. Pick a small set of important controls and check whether the named accountable role can confirm the control design, identify the latest evidence, and explain the escalation path without reconstruction.

If they can't, the issue isn't documentation style. It's governance integrity.

Best Practices and Common Pitfalls

The best responsibility assignment matrix is usually smaller and stricter than people expect. It doesn't try to model the entire organisation. It focuses on the controls, approvals, and evidence paths that matter.

A few practices consistently work well:

• Start with critical controls. Begin where failure would create reporting, resilience, security, or audit problems.
• Protect the one-accountable-owner rule. If a committee or shared function appears in the Accountable column, fix the design.
• Map evidence ownership explicitly. The person who owns the control outcome and the person who gathers artefacts are not always the same.
• Review on events, not just on schedule. Org changes, vendor changes, and process redesign should all trigger review.
• Validate with real scenarios. Walk through incidents, exceptions, and audit requests before calling the matrix complete.

Common mistakes are just as predictable.

The practical standard is simple. The matrix should match reality closely enough that an incident, control test, or audit request doesn't force the organisation to rediscover who owns what.

A responsibility assignment matrix is useful when it embeds accountability into daily operations. That's what makes it more than paperwork. It becomes part of how the organisation proves control, not just how it describes intention.

If you're building a living ownership model for DORA, NIS2, or GDPR work, AuditReady is designed for that operational layer. It helps teams map responsibilities, attach evidence to controls and policies, keep traceable records, and prepare audit-ready outputs without turning governance into a spreadsheet exercise.