Who should own people-centric security when the risk spans security, IT, and business leadership?

Shared ownership only works when one function is accountable

People-centric security sits at the intersection of policy, enforcement, and day-to-day operations. That means the right answer is not a committee with no owner, but a shared model where one function is explicitly accountable for decisions, escalation, and follow-through while the others own their parts of the control chain.

Security should usually own the security outcome, because it is best placed to define the risk, set minimum control requirements, and judge when exceptions are acceptable. IT owns the technical enforcement layer, such as identity systems, endpoint controls, email protections, and access configuration. Business leadership owns the policy trade-offs, funding, and risk acceptance that determine whether protective controls are actually adopted.

This is why people-centric security is not just a technical program. It changes user access, approval paths, detection thresholds, and the willingness to block or step up risky actions. Those decisions only hold if each stakeholder accepts a clear role and the organisation knows who can say yes, who can say no, and who must escalate.

Why cross-functional ownership fails when responsibilities are vague

When ownership is split informally, the usual failure is not total absence of control, but inconsistent control. One team assumes another will handle policy, another assumes someone else will tune enforcement, and business leaders assume the issue is “a security problem” rather than an operating model problem. The result is gaps in email security, identity governance, endpoint posture, and user-behaviour response.

In practice, cross-functional security breaks down at the handoff points. A policy can be approved but never enforced, an alert can be raised but never acted on, or a risky exception can be granted without a review path. The more a control depends on human action, the more important it is to assign the decision owner and the operational owner separately.

That is also why a zero trust approach is useful here: it helps define who owns the policy decision, who owns the enforcement point, and how access should be continuously re-evaluated rather than assumed safe after a single approval. A Zero Trust Identity Guide is a practical reference for mapping those responsibilities to identity-centric controls. The broader architecture guidance in NIST SP 800-207 Zero Trust Architecture reinforces that policy and enforcement are distinct jobs.

Who should own which decisions in a people-centric security model

The cleanest operating model is to separate risk ownership, control ownership, and business accountability. Security should own the risk framework and the minimum control standard. IT should own implementation, uptime, and enforcement quality. Business leadership should own the operational impact of policy decisions, including exceptions that increase exposure or slow user workflows.

For controls that depend on identity, authentication, access approval, or privileged actions, the ownership line must be even more explicit. Security decides what good looks like, IT configures the mechanism, and the business accepts the productivity trade-off when stronger controls are introduced. If those roles blur, you often get weak defaults, delayed remediation, and too many exceptions.

That ownership split is supported by broader governance frameworks that emphasise access restriction, accountability, and continuous control operation. NIST Cybersecurity Framework 2.0 is useful here because it frames governance as a leadership responsibility, while NIST SP 800-53 Rev. 5 Security and Privacy Controls gives practitioners concrete control families for access control, identification, authentication, audit, and configuration management.

Practitioner Guidance

What to prioritise: Name a single accountable owner for the programme, then document where security, IT, and business leadership each make decisions. If the organisation cannot state who approves exceptions, who enforces controls, and who accepts residual risk, ownership is still ambiguous.

What to verify: Check that the operating model covers escalation for high-risk access, policy exceptions, and control failures. The test is simple: when a risky user action is blocked or challenged, does the organisation have a defined decision path rather than an ad hoc debate?

Common mistake: Treating “shared ownership” as shared accountability. Shared input is healthy, but if nobody is answerable for outcomes, the programme will drift into inconsistent enforcement and weak follow-through.

Practitioner takeaway: The most effective model is one accountable owner with clearly separated operational roles, because people-centric security fails when authority is distributed but responsibility is not.

Related resources from NHI Mgmt Group

• Who should own defense against nation-state threats when risk spans security, infrastructure, and leadership teams?
• How should security teams make NHI best practices usable across the business?
• Who should own identity risk when governance spans IAM, PAM, and security operations?
• How do organisations know whether a people-centric security programme is actually reducing human risk?