ServiceNow Business Continuity Management: Security and Access Design

Role Hierarchy for Disaster Recovery Access

Business Continuity Management data requires strict access controls because disaster recovery plans contain sensitive information: recovery procedures for critical systems, failover procedures, contact lists, and recovery time objectives. The Business Continuity Coordinator builds and maintains recovery plans and has full write access to plan records. The Disaster Recovery Manager owns the strategic decision to invoke disaster recovery procedures and has authority to activate failover. The Systems Administrator implements recovery procedures and needs access to plan details and recovery runbooks. Business unit leaders own decisions about which applications are critical and what recovery time targets are acceptable for their business function; they have read access to plans affecting their business unit. The IT Security team reviews plans to ensure recovery procedures do not introduce security vulnerabilities and has read access for audit purposes. The CMDB Administrator maintains the CI relationships that recovery plans depend on and must coordinate with the Business Continuity Coordinator to ensure CI ownership is clear.

Least Privilege Implementation

Not all staff need read access to all disaster recovery plans. A system administrator responsible for database recovery needs access to database recovery plans but not email system recovery plans. Implement role-based access so that staff see only plans relevant to systems they support. A business unit leader sees plans for their business unit but not other business units’ plans; this prevents competitors from learning about each other’s recovery strategies if both work within the same holding company. The Business Continuity Coordinator should not have write access to incident records or change management; if they could modify incidents, they could hide evidence of recovery activations that did not work as planned. The Disaster Recovery Manager should not have independent authority to modify recovery plans; changes should require the Business Continuity Coordinator’s approval to prevent unauthorized scope changes during a crisis.

Test access to disaster recovery environment should be time-limited. During a DR test, systems engineers need temporary access to recovery infrastructure; this access is automatically revoked when the test window closes (agree the window with the platform owner). If manual revocation is required, the Business Continuity Coordinator must send a revocation request promptly after test completion. Avoid permanent standing access to DR infrastructure; each test or recovery event should require explicit approval and access should be provisioned just-in-time, then immediately revoked post-event.

Segregation of Duties in Recovery Procedures

The Disaster Recovery Manager initiates failover, but this action should require acknowledgment from the IT Director to prevent unauthorized activation. A single person should not be able to unilaterally decide that disaster recovery is needed and execute failover without oversight. Similarly, recovery procedures that involve data restoration should require the CMDB Administrator or Database Administrator to approve the source data and target systems to prevent restoring from corrupted or stale backups. Document all recovery activations in an audit log: who initiated failover, when, which systems were affected, and who approved the activation. This creates accountability and supports post-incident reviews.

If disaster recovery involves moving customer data or activating customer-facing services in a recovery site, data protection obligations may require customer notification. The Business Continuity Coordinator should work with the compliance and legal team before recovery to understand notification requirements, so that during an actual disaster, the company can activate recovery without legal surprise. This coordination should be documented in the recovery plan itself, so that the procedure includes compliance notification steps.

Audit Evidence and Compliance

Enable audit logging for all access to disaster recovery plans and recovery environment. Log who viewed plans, when, and for how long. If a plan is modified, the audit log should show what changed, who made the change, and the timestamp. Maintain audit logs for as long as your compliance requirements set, to support compliance investigations and post-incident reviews. If an audit or compliance review requires proof that recovery procedures are tested regularly, retain records of each test: date, scope of test, results, and sign-off from the Disaster Recovery Manager confirming the test met objectives.

For critical recovery procedures, implement multi-person approval: the Business Continuity Coordinator proposes a procedure change, the Disaster Recovery Manager reviews and approves it, and a business unit leader confirms the change does not conflict with business objectives. This three-step approval process prevents individual error or intent to bypass security. Document the approval chain in the recovery plan version history so that auditors can see who approved each procedure evolution.

Review Cycles and Change Control

Disaster recovery plans should be reviewed at least annually and immediately following any significant infrastructure change (migration to cloud, retirement of legacy systems, acquisition of new business units). When plans are updated, the Business Continuity Coordinator notifies all Systems Administrators and team leads who support those systems, so they understand the new procedures. Major plan changes (new recovery site, change to recovery time objective, addition of critical systems) require approval from the IT Director and affected business unit leaders. Minor changes (contact list updates, procedure clarification, tool version updates) can be approved by the Business Continuity Coordinator if they do not change the scope of recovery. All changes should be version-controlled and date-stamped in the plan document.

Plan for the identity system being part of the outage

Access design for continuity is often written as though the people who need access will always be able to log in. That assumption fails in a specific and predictable way. If a disruption takes down the directory service, the single sign-on provider or the network segment that reaches them, the recovery staff who need the continuity module are locked out of it at the moment they need it most. The plan records are sitting in a system nobody can open, and the people who could approve an emergency change are unable to reach an approval screen. Map every route into the continuity records to the identity service it depends on, then ask which of those identity services would fail in each scenario the program plans for. Any route that shares a failure point with the systems in scope needs an independent path.

Break-glass accounts: create them, store them and watch them

A break-glass account is a privileged account kept for emergencies, outside the normal sign-on path. It is the standard answer to the lockout problem, and it is also one of the most abused accounts in any estate if it is handled carelessly. The steps below describe a workable design. Each step has a reason, and skipping any of them tends to create the exposure the account was meant to prevent.

1. Create a small number of break-glass accounts, each assigned to a named recovery role rather than shared between people.
2. Protect each credential with a second factor or sealed secret that does not depend on the identity service it bypasses.
3. Store the sealed material in two places that are separate from each other and from the systems in scope, with access logged.
4. Set alerts so that any sign-in to a break-glass account notifies the continuity coordinator and the security team at once.
5. Test each account during an exercise, and record whether the test was executed as a planned event rather than an unplanned one.
6. Rotate the credentials after every test or activation, and record the rotation against the event that triggered it.

Access rules during an activation compared with access during a test

An activation and an exercise need different access rules. During an exercise, the aim is to see whether the access design works, so the rules should match what a real event would impose. During an activation, the aim is to get the right people working quickly without granting more than they need. The comparison below shows where the rules diverge and what review should follow each event.

Keep the recovery documents readable when the usual tools are down

A plan stored only in the continuity module is unavailable in the scenario where the module’s own infrastructure has failed. Keep a controlled copy of the essential material in a form that does not depend on the systems it describes. The minimum set is often the contact sheet, the escalation path, the recovery route for each critical process and the decision record for the current activation. Copies should be dated and version-stamped, held by the named role holders, and reissued whenever the source changes. Printed copies are often the most reliable option, provided that someone is responsible for replacing them when a person changes role. Distribution should stay controlled, because a copy that circulates freely becomes a copy nobody can update.

Review access once the event is over

• List every account that held elevated or emergency access during the event, with the time it was granted and the time it was removed.
• Compare each elevation against the activity logged for that account, and flag any access that was granted but not used.
• Confirm that every break-glass credential used has been rotated and the rotation is recorded.
• Check that any vendor access has been removed and that the removal is confirmed by someone other than the person who granted it.
• Record each finding against the access design, so that the next revision of the design reflects what actually happened.

Frequently asked questions about continuity access

Are break-glass accounts a security risk in themselves?

They are, if they are used routinely or left unmonitored. The risk is manageable when the accounts are rarely used, every use is alerted and reviewed, and the credentials are rotated after each use. An account that is never tested is a risk too, because it may not work when it is needed.

Should the continuity coordinator have administrator rights?

Not by default. The coordinator needs enough access to maintain the plans and see the records, but administrative rights that can change systems should sit with the technical recovery roles. Keeping the two apart stops the person managing the plan from also being able to alter the evidence of how it was used.

How do we handle access for people who join during an incident?

Use a short, pre-approved onboarding path for named roles, with the access scoped to the incident and a removal date set at the time of grant. Do not extend a standing role to cover an arrival, because the standing role is rarely removed afterwards.

Does the access design need to be reviewed after each reorganization?

Yes. Each reorganization changes who holds which role, and the design is only as useful as its mapping from roles to people. Review the mapping before the next exercise rather than waiting for the annual cycle.

Next step

Routes that share a failure point with the systems in scope are the first to fix. For the shape of periodic reviews, the access recertification article is the reference, and the identity integration boundaries article deals with keeping identity dependencies apart from the systems they protect.