Directly Responsible Individual

What a DRI does in practice

A directly responsible individual is the single named owner for a piece of work from start to finish. That does not mean they do every task themselves. It means they are accountable for making decisions, coordinating contributors, keeping the work moving, and ensuring follow-through when issues, dependencies, or delays appear.

Why the DRI model matters

The main value of a DRI is clarity. When ownership is ambiguous, projects stall because no one is sure who resolves conflicts, approves trade-offs, or closes the loop. A DRI removes that ambiguity by creating one visible point of accountability, which is especially useful when work crosses teams, functions, or time zones.

Good DRI assignment also helps prevent a common organisational failure mode: collective ownership without individual accountability. That pattern often looks inclusive on paper, but in practice it produces gaps in coordination, duplicated effort, and delayed decisions.

Where DRI ownership is most useful

The DRI model is most effective for work that has a clear lifecycle, a sequence of decisions, or multiple contributors who need alignment. It is often used for projects, cross-functional initiatives, operational improvements, incident follow-up, policy changes, and delivery efforts that need one person to maintain momentum.

It is less useful when responsibilities are truly shared and no single person can reasonably own the outcome. In those cases, the role should be paired with clear decision rights, otherwise the DRI label becomes symbolic rather than operational.

In security and technology work, the model is especially helpful where deadlines, dependencies, and approval paths can become blurred. A named owner makes it easier to track progress, escalate blockers, and confirm that required follow-up has actually happened.

How DRI differs from a team or committee

A DRI is not a substitute for collaboration. The role does not remove the need for subject-matter review, stakeholder input, or managerial oversight. Instead, it concentrates accountability so that collaboration has a clear anchor point.

That distinction matters because committees can discuss and advise, but they rarely execute with the same speed as one accountable owner. The DRI provides the decision and coordination centre, while the wider team supplies expertise, input, and execution capacity.

Used well, the model reduces confusion about who owns the next step. Used poorly, it can be mistaken for unilateral authority, when in reality the DRI should still operate within agreed governance and reporting structures.

Risk and Threat Considerations

A weak DRI model creates operational risk when accountability is named but not real. The most common failure is ownership drift, where no one actively tracks decisions, follow-up, or unresolved dependencies, and important work quietly slips.

Failure mechanism: If the DRI is not empowered, available, or clearly scoped, teams can assume someone else will act. That produces missed handoffs, slow escalation, and gaps in oversight that are hard to spot until delivery or control failures surface.

Impact: The result can be delayed projects, incomplete remediation, inconsistent execution, and weaker auditability of who approved or carried an action forward. In security-sensitive work, that can also leave issues open longer than intended.

Practitioner Guidance

Why practitioners should care: The DRI role only works when accountability is explicit and bounded. Define what the DRI owns, what decisions they can make, and where they must escalate, otherwise the role becomes a label without operational force.

Governance implication: A strong DRI assignment should be visible to the people who depend on the work. If ownership changes, the handover should be deliberate, because continuity of accountability is part of the control itself.

Practitioner takeaway: Use DRI assignments to reduce ambiguity, not to hide shared responsibility, the best outcomes come when one person is accountable and the rest of the team still knows their part.

Related resources from NHI Mgmt Group

• What breaks when access is assigned directly to individual users instead of through roles?
• What is the difference between RBAC and assigning permissions directly to individual users?
• Should organisations allow AI systems to execute response actions directly?
• What breaks when agents are given personal access tokens and service account keys directly?