Should business continuity controls be owned by security or operations?

Why continuity ownership has to be shared, but not blurred

business continuity is not purely a security problem or purely an operations problem. The practical split is that operations owns restoration, engineering owns service recovery, and security owns the integrity of the controls that remain in force while the business is in a degraded state. That means continuity planning must define who can approve exceptions, who can change dependencies, and who can declare the environment safe to resume normal control.

This is why “shared ownership” works better than forcing continuity into one team. The business service itself needs operational recovery decisions, but the security posture during the incident still matters, especially when temporary access, alternate processes, or manual workarounds are introduced under pressure.

What security remains accountable for during disruption

Security should retain clear accountability for information security outcomes during continuity events, even when it does not run the recovery playbook. In practice, that means checking whether emergency access is time-bound, whether temporary suppliers or routes are approved, whether logging survives the failover path, and whether compensating controls are strong enough for the interim state.

That accountability becomes important because continuity failures often start as control exceptions, not as classic outages. If emergency procedures bypass normal approval, monitoring, segregation of duties, or credential handling, the organisation may restore availability while quietly increasing exposure.

• Temporary access should expire automatically or be explicitly revoked at the end of the event.
• Emergency changes should be traceable and reviewed after the incident, not normalised.
• Fallback processes should be tested for security impact, not only for service restoration.

How to divide responsibility without creating a gap

The useful boundary is to separate service recovery ownership from control assurance ownership. Operations and engineering should own restoring platforms, dependencies, and data flows. Security should own the control requirements that apply during degraded operation, including what can be waived, what must never be waived, and what evidence is needed before normal mode is restored.

NIST Cybersecurity Framework 2.0 is useful here because it aligns continuity with governance, recovery, and control verification rather than treating resilience as an isolated operations function. The same division of labour is reflected in control-oriented programs such as NIST SP 800-53 Rev 5 Security and Privacy Controls, CIS Controls v8, and ISO/IEC 27001:2022 Information Security Management, all of which expect continuity, access control, logging, and recovery to be managed as part of the security programme rather than as an afterthought.

Risk and Threat Considerations

Continuity arrangements become risky when they create a second, weaker operating model that lasts longer than intended. The main exposure is control drift: emergency access, ad hoc approvals, degraded monitoring, and exceptional configurations can all remain in place after the outage ends if no one owns the security boundary of the recovery process.

Failure mechanism: A disruption prompts temporary changes to access, change management, logging, or supplier paths, and those changes either bypass review or are never fully rolled back.

Impact: The organisation may recover service while preserving an elevated attack surface, weaker accountability, and incomplete evidence for later investigation or audit.

Practitioner Guidance

Ownership: Use a joint model with a single named security accountabilty owner for control integrity, plus operational owners for restoration and engineering owners for the technical fix. If nobody can veto unsafe temporary access or undeclared control waivers, ownership is too diffuse.

What to verify: Confirm that continuity runbooks distinguish restoration tasks from security exceptions, and that every exception has an owner, expiry, and review point. If the recovery plan cannot show who approved temporary access or who signed off the return to normal controls, it is not ready.

Practitioner takeaway: Treat continuity as a shared operating responsibility, but keep security accountable for the state of controls during the outage and the rollback to normal control conditions afterward.

Related resources from NHI Mgmt Group

• How should security teams make NHI best practices usable across the business?
• Why do traditional security controls often slow down business operations?
• How should organisations implement access controls to support business continuity and agility without slowing operations down?
• How should security teams prioritise NHI remediation in cloud environments?