Incident Response Policy Template: Mandate, Authority and Duties

When a serious incident lands, the questions that stall a response are rarely technical: who may declare an incident, who may take a revenue-generating system offline, who may talk to the press, and who decides about a ransom demand. An incident response policy answers those questions in advance, with board-level authority, so the incident response plan and its playbooks can be executed without negotiating mandates at 3am. This template is the policy layer: it sets scope and triggers, roles and delegated authority, mandatory duties for each phase from detection to post-incident review, and the notification and evidence rules that cannot be left to judgement on the day. Operational detail such as severity matrices, call trees and playbooks belongs in the plan it mandates. It is written for CISOs, risk and legal teams and policy owners.

How to use this template

• Replace text in square brackets, such as [Organisation], [Incident Manager] and [24 hours], with your own names and values.
• "Must" is mandatory. "Should" is a recommended practice where a documented exception may be justified.
• Keep the policy stable and short. Severity definitions, contact lists, communication matrices and technical steps change often and belong in the Incident Response Plan Template, which this policy requires and authorises.
• Have the policy approved by [the board or executive committee], because section 2 delegates authority that otherwise sits with business owners.
• Have legal counsel confirm the notification duties in section 7 for every jurisdiction and sector you operate in. They change, and this template is not legal advice.

1. Scope and triggers

1.1 Purpose and scope

1. This policy establishes [Organisation]'s mandate to prepare for, detect, respond to and recover from information security incidents, and assigns the authority needed to do so.
2. It applies to all [Organisation] business units, subsidiaries, employees and contractors, to all information and systems owned or operated by or for [Organisation], including cloud, SaaS, operational technology and AI systems, and to third parties whose contracts require them to support [Organisation] incident response.
3. It covers incidents involving human and non-human identities, including service accounts, API keys, tokens, workload identities and AI agents.

1.2 Definitions

1. Security event: any observable occurrence that may be relevant to security.
2. Security incident: an event, or series of events, that actually or potentially jeopardises the confidentiality, integrity or availability of [Organisation] information or systems, or breaches a security policy.
3. Personal data breach: an incident leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data.
4. Major incident: an incident rated [SEV1 or SEV2] under the incident response plan.

1.3 Triggers

The incident response plan must be invoked when any of the following occurs or is reasonably suspected:

1. Unauthorised access to systems, accounts or data, including use of a stolen credential or token.
2. Malware or ransomware on any [Organisation] system.
3. Exposure of a secret, key or credential in a public or unauthorised location.
4. Loss or disclosure of Confidential or Restricted data, or any personal data breach.
5. A security incident at a supplier that affects [Organisation] data, systems or services.
6. Unexpected actions by an AI agent or automation with access to production systems or data.
7. Any event that [security operations] or the [Incident Manager] judges to meet the plan's declaration criteria.

2. Roles and contacts

2.1 Contacts

1. [Organisation] must maintain a 24x7 incident reporting route, [phone number and mailbox], published on the intranet and in onboarding material.
2. Every role in section 2 must have a named deputy. Contact details, including out-of-band contacts that do not depend on [Organisation] email or identity systems, must be held in the plan and verified [quarterly].

2.2 Delegated containment authority

1. The [Incident Manager] is authorised, without prior approval from the system owner, to isolate devices, disable or reset accounts, revoke tokens, keys and certificates, block network traffic, and suspend integrations or AI agents where this is necessary to contain an incident.
2. Taking a [critical business service, as listed in the business continuity plan] offline requires approval from the [executive sponsor] or deputy, except where delay would create an immediate risk to safety or of widespread compromise, in which case the [Incident Manager] may act and must inform the [executive sponsor] within [1 hour].

2.3 Reserved decisions

1. Any decision to pay, or to engage with, an extortion or ransom demand is reserved to [the CEO and board], after advice from [General Counsel], law enforcement contact and sanctions screening.
2. Public attribution of an incident to a named threat actor requires approval from [General Counsel and CISO].

3. Detection and triage

3.1 Reporting duty

1. Anyone who suspects an incident must report it to [security operations] immediately, and in any case within [1 hour], and must not investigate it themselves beyond what is needed to report it.
2. No one will be disciplined for reporting in good faith, including reporting their own mistake.
3. Line managers, suppliers and service providers must not delay a report to gather more information.

3.2 Detection and triage requirements

1. [Organisation] must collect and retain the logs defined in the [Logging and Monitoring Policy] so that incidents can be detected and investigated.
2. Reported and detected events must be triaged, recorded in [incident management system] and assigned a severity using the criteria in the plan within [the times the plan sets].
3. The time an incident was detected, reported, declared and its severity set must be recorded, because regulatory notification clocks may run from awareness.

4. Containment

1. Containment must prioritise stopping harm while preserving evidence. Systems should be isolated rather than powered off or rebuilt until the [technical lead] confirms that evidence needed for the investigation has been captured.
2. When a credential, key or token may be compromised, it must be revoked or rotated, and active sessions and refresh tokens invalidated, not only the password changed. This applies equally to service accounts and other non-human identities. See the Identity Incident Response Playbook.
3. Coordination about the incident must move to [out-of-band channel] if there is any indication that email, chat or the identity provider is compromised.

5. Eradication

1. The root cause and every persistence mechanism found, including new accounts, OAuth grants, keys, scheduled tasks and modified configuration, must be removed before affected systems return to normal operation.
2. Eradication must be confirmed by [the technical lead] and recorded, with the evidence used to confirm it.

6. Recovery

1. Systems must be restored from known-good sources (trusted images, verified backups or rebuilt infrastructure as code) and monitored with heightened alerting for [30 days] after restoration.
2. Recovery priorities must follow the business impact analysis in the [business continuity plan]. The [executive sponsor] approves returning critical services to production.
3. The incident is closed only when the [Incident Manager] confirms that containment, eradication, recovery and all notifications are complete.

7. Communication and notification

1. Only [Head of Communications] may issue external statements about an incident, with approval from [General Counsel]. Staff must refer all enquiries to them.
2. [General Counsel] and [DPO] must assess every major incident and every personal data breach against the notification duties in the plan's notification register, which must list each applicable regulator, deadline, threshold and the role that files the notice. Examples include the GDPR Article 33 duty to notify the supervisory authority within 72 hours of becoming aware of a personal data breach, where feasible, and sector or national incident reporting rules such as those under NIS2.
3. Contractual notification duties to customers, insurers and partners must be recorded in the same register and met.
4. Incidents must not be concealed, downplayed or misdescribed to regulators, customers, auditors or the board, and payments to attackers must never be presented as anything else.
5. Investigation communications should be directed through [General Counsel] where legal privilege may apply. See the Legal Privilege in Incident Response Guide.

8. Post-incident review

8.1 Evidence and records

1. Evidence must be collected and stored with a recorded chain of custody where legal action, regulatory enquiry or insurance claims are possible.
2. Incident records, decision logs and evidence must be retained for [6 years] or longer if a legal hold applies.

8.2 Learning

1. A blameless post-incident review must be held within [10 business days] of closure for every major incident, and should be held for any incident that reveals a control gap.
2. Actions from reviews must have an owner and a due date, be tracked in [risk or action register], and be reported to [risk committee] until closed.

8.3 Preparation, testing and policy review

1. The incident response plan and playbooks must be reviewed at least [annually] and after every major incident.
2. Incident response staff must be trained on joining the team and [annually]. A tabletop exercise including executives must run at least [annually], and a technical exercise at least [annually].
3. This policy is owned by [CISO], approved by [board or risk committee], and reviewed at least [annually] or after a major incident or a change in law. Exceptions to it may be granted only by [executive sponsor] and must be recorded.

Implementation guidance

Policy, plan and playbooks

NIST SP 800-53 Rev. 5 makes the same split: IR-1 requires an incident response policy addressing purpose, scope, roles, responsibilities, management commitment and coordination, while IR-8 requires a separate incident response plan. NIST SP 800-61 Rev. 3 (final, April 2025) replaced the Rev. 2 lifecycle with recommendations organised around the NIST CSF 2.0 functions, which is why this policy places preparation and learning under Govern, Identify and Protect activities as well as response.

Rollout

1. Agree the delegated authority in section 2.2 with the owners of critical services before seeking approval. This is where most objections arise, and it is better to settle them in a meeting than in an incident.
2. Build the notification register with legal counsel and confirm each regime's current status and deadline.
3. Publish the reporting route, and add it to onboarding, the intranet and supplier contracts.
4. Run a tabletop exercise that forces use of sections 2.2 and 2.3, such as ransomware on a critical service, and refine the wording based on what the executives actually asked.

Measures

• Time to report: median time from first detection or user awareness to report.
• Time to declare and contain: median time from report to declaration, and from declaration to containment, for major incidents.
• Notification compliance: percentage of notifications filed within their deadline.
• Review actions closed: percentage of post-incident actions closed by their due date.
• Exercise coverage: executives and deputies who took part in an exercise in the last [12 months].

Failure patterns this policy is written to prevent

• Concealment: in the Uber 2016 breach, the company paid the attackers $100,000 through its bug bounty provider and did not disclose the breach for about a year, which led to an expanded FTC settlement and the conviction of its former chief security officer. Section 2.3 and section 7, item 4, reserve payment decisions and forbid misdescribing them.
• Undefined authority to stop operations: in the Colonial Pipeline ransomware attack, the company proactively shut down its pipeline and its CEO later told the Senate he made the decision to pay. Sections 2.2 and 2.3 decide in advance who makes each of those calls.
• Password reset as containment: resetting a password while leaving sessions, tokens and service account keys valid lets an attacker stay in. Section 4, item 2, requires revoking all of them.
• Coordinating on compromised channels: discussing the response on email or chat the attacker can read. Section 4, item 3, requires an out-of-band channel.

Framework mapping

Sources for the design choices

• NIST: SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management
• NIST: SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations
• NIST: Cybersecurity Framework 2.0
• ISO: ISO/IEC 27001:2022 Information security management systems, Requirements

Related NHI Mgmt Group resources: Incident Response Plan Template · Incident Response Guide · NIST SP 800-61 Incident Response Guide · Incident Response Contact and Call Tree Template · Incident Response Readiness Assessment Checklist