Directly Responsible Individual

Expanded Definition

A Directly Responsible Individual, or DRI, is the named person accountable for driving a project, decision, or operational workstream from start to finish. In NHI and agentic AI programs, the DRI is not just a coordinator. The role gives one person clear ownership for tracking dependencies, escalating blockers, and ensuring follow-through across design, implementation, and review.

The concept is organisational, not technical, but it becomes important in security because identity programs often fail when responsibility is shared too broadly. In practice, a DRI should be able to answer who owns a service account review, who approves exception handling, and who signs off on remediation after a control gap. That makes the term closely related to governance models described in the NIST Cybersecurity Framework 2.0, even though NIST does not define DRI as a formal control term.

Definitions vary across vendors and operating models, but the common thread is single-threaded accountability. The most common misapplication is treating DRI as a status update role, which occurs when a person is named to attend meetings but not empowered to make decisions or drive remediation.

Examples and Use Cases

Implementing DRI rigorously often introduces a coordination overhead, requiring organisations to weigh faster decision-making against the effort of assigning and maintaining clear ownership.

• A platform team assigns one DRI for API key lifecycle governance so secret rotation, exception approvals, and offboarding actions do not stall across multiple queues.
• A security programme names a DRI for service account hygiene after reviewing the Ultimate Guide to NHIs, ensuring remediation tasks are tracked to closure.
• An AI agent deployment has one DRI responsible for tool access reviews, prompt-change approvals, and rollback decisions when the agent’s execution scope changes.
• An incident response workflow assigns a DRI to each compromised credential case so containment, revocation, and post-incident evidence collection stay coordinated.
• A product launch uses a DRI to manage cross-functional dependencies between engineering, IAM, and compliance when new NHIs are introduced into CI/CD pipelines.

In all of these cases, the DRI functions as the decision owner, while execution may be distributed across several teams. That distinction matters when timelines are short and accountability can otherwise diffuse.

Why It Matters in NHI Security

NHI security breaks down quickly when no one is clearly accountable for ownership, rotation, and decommissioning. NHIMG research shows that only 20% of organisations have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotation, which makes gaps in ownership especially dangerous. The Ultimate Guide to NHIs also reports that 79% of organisations have experienced secrets leaks, with 77% causing tangible damage, underscoring how quickly weak ownership becomes a security incident.

A DRI helps close the gap between detection and action. When a vault is misconfigured, a secret is found in code, or an agent is granted excessive tool access, the issue is no longer abstract. Someone must own the fix, coordinate with access administrators, and verify that the control now works in production. That operating discipline aligns with the accountability emphasis in the NIST Cybersecurity Framework 2.0.

Organisations typically encounter the cost of weak DRI assignment only after an audit failure, a leaked credential, or a compromised agent triggers urgent remediation, at which point the role becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• Should organisations allow AI systems to execute response actions directly?
• What breaks when agents are given personal access tokens and service account keys directly?
• Why do shared workstations create more access risk than individual endpoints?
• What breaks when AI can query sensitive data directly through enterprise tools?