Incident Response Policy¶
Template version: 1.0 Document type: Security Policy Review cycle: Annual Owner: CISO / VP Security Operations
How to use this template Replace all
[BRACKETED]placeholders with organization-specific values. Review each section against your regulatory obligations and incident history before finalizing. This template implements Nexus SecOps-061 through Nexus SecOps-070 and aligns with NIST SP 800-61 Rev. 2.
1. Purpose¶
This policy establishes [ORGANIZATION NAME]'s requirements for preparing for, detecting, containing, eradicating, and recovering from information security incidents. It defines roles, responsibilities, escalation paths, and notification obligations applicable to all personnel and systems.
Effective incident response reduces harm to [ORGANIZATION NAME], its customers, employees, and partners by ensuring that security events are handled in a consistent, documented, and legally defensible manner.
2. Scope¶
This policy applies to:
- All employees, contractors, temporary workers, and third parties with access to [ORGANIZATION NAME] systems or data
- All information systems, networks, cloud environments, and applications owned or operated by [ORGANIZATION NAME]
- All third-party managed services that process [ORGANIZATION NAME] data
3. Definitions¶
| Term | Definition |
|---|---|
| Security Event | Any observable occurrence on a system or network that may have security relevance |
| Security Incident | A security event that has been confirmed to have a negative impact on confidentiality, integrity, or availability of organizational assets |
| Data Breach | An incident involving unauthorized access to, disclosure of, or loss of personal data |
| Critical Incident | An incident affecting critical infrastructure, executive systems, or triggering regulatory notification obligations |
| MTTD | Mean Time to Detect — elapsed time from incident start to detection |
| MTTR | Mean Time to Respond — elapsed time from detection to containment |
| CIRT | Computer Incident Response Team — the team responsible for managing security incidents |
| IOC | Indicator of Compromise — artifact observed on a network or system indicating a potential intrusion |
| TTPs | Tactics, Techniques, and Procedures — attacker behaviors documented in frameworks such as MITRE ATT&CK |
4. Policy Statements¶
4.1 Incident Response Program¶
[ORGANIZATION NAME] SHALL maintain a documented incident response program that includes:
a. Formal incident response procedures aligned with this policy b. A trained and designated Computer Incident Response Team (CIRT) c. Defined escalation paths for all incident severity levels d. Pre-established relationships with legal counsel, external IR firms, and regulatory bodies e. Tested incident response capabilities, validated through exercises at least annually
4.2 Severity Classification¶
All security incidents SHALL be classified using the following framework:
| Severity | Criteria | Examples | Response SLA |
|---|---|---|---|
| P1 — Critical | Active attack impacting critical systems; regulatory breach confirmed; executive systems compromised; ransomware active | Ransomware spreading; data exfiltration confirmed; production system compromise | Incident Commander engaged within 15 min; all-hands within 30 min |
| P2 — High | Confirmed compromise of non-critical systems; significant malware; privilege escalation | Single workstation malware; insider threat activity; credential theft | Tier 2 engaged within 30 min; CISO notified within 1 hour |
| P3 — Medium | Suspicious activity requiring investigation; potential compromise; policy violations | Phishing investigation; anomalous user behavior; unauthorized access attempt | Tier 1 begins investigation within 2 hours |
| P4 — Low | Security events requiring review but low risk of harm | Single failed login event; scan from external IP; minor policy deviation | Reviewed within 8 hours |
Severity SHALL be re-assessed at each major phase transition and escalated if new information warrants it. Severity SHALL NOT be downgraded during active containment without CISO approval.
4.3 Incident Response Lifecycle¶
[ORGANIZATION NAME] adopts the PICERL lifecycle model for incident response:
Phase 1 — Preparation - Maintain and test IR plans, runbooks, and playbooks - Ensure tooling (SIEM, EDR, SOAR, forensic tools) is operational and current - Conduct tabletop exercises at least [QUARTERLY/SEMI-ANNUALLY] - Maintain retainer with external IR firm
Phase 2 — Identification - All security events detected by automated monitoring SHALL be triaged within SLA - The Incident Commander SHALL be engaged for P1 and P2 events - An incident ticket SHALL be opened within 15 minutes of P1 detection
Phase 3 — Containment - Short-term containment actions (network isolation, account disable, IP block) MAY be taken immediately by authorized CIRT members - Actions that affect production services or business partner connectivity REQUIRE Incident Commander approval - All containment actions SHALL be documented in the incident ticket in real time
Phase 4 — Eradication - Root cause SHALL be identified before eradication begins - Eradication steps SHALL be verified before proceeding to recovery - Evidence SHALL be preserved before any eradication actions that would destroy artifacts
Phase 5 — Recovery - Affected systems SHALL be verified clean before reconnection to the network - Recovery SHALL be validated by the Incident Commander - Business owner sign-off is REQUIRED before resuming critical business processes
Phase 6 — Lessons Learned - A Post-Incident Review (PIR) SHALL be conducted within [5 / 10] business days for all P1/P2 incidents - PIR SHALL identify root cause, gaps, and specific, time-bound remediation actions - PIR findings SHALL be tracked to closure
4.4 Roles and Responsibilities¶
| Role | Responsibilities |
|---|---|
| Incident Commander | Overall incident ownership; stakeholder communication; authorization of high-impact containment actions; escalation decisions |
| CIRT Lead | Technical investigation coordination; resource allocation; tool orchestration |
| Tier 1 Analyst | Initial triage; alert verification; enrichment; escalation to Tier 2 per SLA |
| Tier 2 Analyst | Deep investigation; containment execution; forensic collection; escalation to CIRT Lead |
| CISO | P1 notification; board and executive briefing; regulatory liaison |
| Legal Counsel | Regulatory notification; evidence preservation; litigation hold; regulatory communication |
| HR | Insider threat investigations; personnel actions |
| Communications | External communication; media relations; customer notification |
| IT Operations | System recovery; backup restoration; network changes |
4.5 Communication Requirements¶
Internal communication: - Incident details SHALL be shared only on a need-to-know basis during active response - A dedicated incident bridge (call, chat channel, or war room) SHALL be established for P1/P2 incidents - Incident details SHALL NOT be shared via personal email, personal messaging apps, or public channels
External communication: - No public statements regarding a security incident SHALL be made without authorization from Legal and Communications - Regulatory notifications SHALL be coordinated by Legal with input from the CIRT - Customer notification SHALL be coordinated by Communications with Legal review
Documentation: - All decisions, actions, and communications during an incident SHALL be logged in the incident ticket - The incident log SHALL be treated as potential legal evidence
4.6 Evidence Preservation¶
[ORGANIZATION NAME] SHALL preserve digital evidence according to the following requirements:
a. Evidence SHALL be collected in order of volatility: memory → running process state → network connections → disk → logs b. Forensic images SHALL be collected using write-blocking technology or verified imaging tools c. Hash values (SHA-256) SHALL be computed for all evidence at time of collection d. Chain of custody documentation SHALL be maintained for all evidence e. Evidence SHALL be preserved for a minimum of [12 / 24 / 36] months, or longer if required by regulation or litigation hold f. Evidence SHALL NOT be deleted or overwritten without written approval from Legal
4.7 Regulatory Notification¶
Regulatory notification requirements vary by jurisdiction and data type. At minimum:
| Regulation | Trigger | Notification Deadline | Recipient |
|---|---|---|---|
| GDPR Art. 33 | Breach of personal data of EU residents | 72 hours from becoming aware | Supervisory authority (SA) |
| GDPR Art. 34 | High-risk breach to individual rights | Without undue delay | Affected individuals |
| [STATE] Data Breach Law | Breach of [STATE] resident personal data | [X] days | [STATE AG / Residents] |
| PCI DSS | Cardholder data compromise | Immediately | Card brands + acquiring bank |
| HIPAA | PHI breach | 60 days (individual); annual report (HHS) | HHS + affected individuals |
| [SECTOR REGULATION] | [TRIGGER] | [DEADLINE] | [RECIPIENT] |
Legal counsel SHALL be notified within 1 hour of any P1 incident to assess notification obligations.
4.8 Third-Party and Supply Chain Incidents¶
When a security incident involves or originates from a third-party vendor or supply chain partner:
a. The affected vendor SHALL be notified and engaged within [4 / 8 / 24] hours b. The CIRT SHALL assess whether [ORGANIZATION NAME]'s own systems have been affected c. Contract obligations for incident reporting SHALL be enforced d. The vendor incident SHALL be logged and tracked separately from internal response e. Vendor security posture SHALL be reviewed as part of PIR follow-up
4.9 Automation and AI-Assisted Response¶
Automated response actions (via SOAR or AI-assisted tooling) are subject to the following constraints:
a. Automated actions that affect availability (host isolation, account disable, IP block) REQUIRE defined human approval gates (Nexus SecOps-099) b. Fully automated response is permitted only for actions classified as low blast radius and fully reversible c. All automated actions SHALL be logged with attribution identifying the playbook and triggering condition d. AI-generated recommendations SHALL be validated by an analyst before being acted upon for P1/P2 incidents (Nexus SecOps-185)
5. Prohibited Actions¶
The following actions are PROHIBITED without explicit written authorization from the Incident Commander and CISO:
- Accessing suspect systems without documented authorization
- Executing offensive or counter-intrusion measures against external systems (hacking back)
- Deleting or modifying evidence
- Paying ransom demands without board and legal approval
- Making public statements about an incident
- Sharing incident details with external parties other than as required by law or this policy
6. Exceptions¶
Exceptions to this policy require written approval from the CISO and SHALL be documented with: - Justification for the exception - Compensating controls in place - Duration of the exception - Review and renewal schedule
7. Enforcement¶
Violations of this policy may result in disciplinary action up to and including termination of employment or contract, and may be referred to law enforcement where criminal activity is suspected.
8. Related Documents¶
| Document | Location |
|---|---|
| Incident Response Procedures | [LINK] |
| Alert Triage SOP | [LINK] |
| Detection Change Control SOP | [LINK] |
| Logging Policy | [LINK] |
| AI Use Policy | [LINK] |
| SOAR Playbook Catalog | [LINK] |
| External IR Retainer | [LINK — Confidential] |
| Regulatory Notification Runbook | [LINK] |
9. Policy Review¶
This policy SHALL be reviewed annually and updated following any P1 incident, significant regulatory change, or material change to the organization's technology environment.
| Version | Date | Changes | Approved By |
|---|---|---|---|
| 1.0 | [DATE] | Initial version | [CISO Name] |
Template aligns with: NIST SP 800-61 Rev. 2 | ISO/IEC 27035 | Nexus SecOps-061–070 | NIST CSF RS.RP-1