Free Incident Management Policy Builder

1. Purpose

This policy establishes requirements and procedures for detecting, responding to, and recovering from security incidents. The goal is to minimize damage, reduce recovery time, and ensure effective communication during incidents to meet SOC 2 compliance requirements.

2. Scope

Applies to all security incidents affecting the organization's information systems, data, networks, applications, and services. Covers all employees, contractors, and third parties who access organization systems. Includes incidents related to data breaches, system compromises, malware, denial of service, unauthorized access, and privacy violations.

3. Roles

• Chief Security Officer (CSO) – owns this policy, approves Incident Response Plan, leads major incident response
• Incident Response Team (IRT) – detects, triages, and responds to security incidents
• Incident Commander – coordinates response activities during active incidents
• Security Operations Center (SOC) – monitors systems, detects threats, escalates incidents
• Communications Lead – manages internal and external communications during incidents
• Legal/Compliance – advises on regulatory notifications and legal implications
• All Employees – report suspected incidents, follow incident response procedures

4. Core Principles

• Quick detection and response – minimize time between incident occurrence and containment
• Structured approach – follow documented procedures for consistent, effective response
• Clear communication – keep stakeholders informed throughout the incident lifecycle
• Continuous improvement – learn from incidents through post-mortem analysis

5. Incident Classification

Incidents are classified by severity to determine response urgency and escalation:

Priority 1 (P1) - Critical

• Complete service outage affecting all customers
• Confirmed data breach with customer data exfiltration
• Ransomware infection affecting production systems
• Unauthorized access to critical systems or databases
• Response SLA: Acknowledge within 15 minutes, Incident Commander assigned immediately

Priority 2 (P2) - High

• Partial service degradation affecting multiple customers
• Suspected data breach requiring investigation
• Malware detection on production systems
• Successful phishing attack compromising employee accounts
• Response SLA: Acknowledge within 1 hour, response within 4 hours

Priority 3 (P3) - Medium

• Security event requiring investigation (suspicious activity)
• Failed intrusion attempt or security alert
• Non-critical system vulnerability requiring remediation
• Policy violation requiring review
• Response SLA: Acknowledge within 4 hours, response within 24 hours

Priority 4 (P4) - Low

• Security informational events
• Low-risk security findings from scans
• Minor policy violations
• Response SLA: Acknowledge within 24 hours, response within 5 business days

6. Incident Response Plan

The Incident Response Plan documents our approach to managing security incidents. The plan includes:

• Incident Detection: Monitoring tools, alerting mechanisms, and threat detection procedures
• Incident Triage: Classification criteria, severity assessment, and escalation procedures
• Response Procedures: Step-by-step response actions for each incident type
• Communication Protocols: Internal and external notification procedures
• Incident Tracking: Ticketing system and documentation requirements
• Recovery Procedures: System restoration and return to normal operations
• Post-Incident Activities: Root cause analysis, lessons learned, and corrective actions
• Contact Information: IRT members, management, vendors, legal counsel, law enforcement

Plan Review: IRP is reviewed and approved annually by CSO, or when major changes occur

7. Incident Response Lifecycle

Phase 1: Detection and Identification

• Security monitoring tools detect anomalies or threats
• Employees report suspicious activity via security@company.com or Slack #security-incidents
• SOC team reviews alerts and determines if an incident has occurred
• Initial incident ticket created in incident management system (PagerDuty, ServiceNow, Jira)

Phase 2: Triage and Classification

• Incident Responder assesses severity using classification criteria
• Priority level assigned (P1-P4)
• Incident Commander assigned for P1 and P2 incidents
• Stakeholders notified based on severity and type

Phase 3: Containment

• Immediate actions to prevent further damage
• Isolate affected systems from network
• Disable compromised accounts
• Block malicious IPs or domains at firewall/WAF
• Preserve evidence for forensic analysis

Phase 4: Eradication

• Remove the root cause of the incident
• Delete malware, close vulnerabilities, revoke unauthorized access
• Apply security patches and configuration changes
• Validate eradication through scanning and monitoring

Phase 5: Recovery

• Restore systems to normal operations
• Verify system integrity and functionality
• Monitor for signs of re-infection or persistence
• Communicate service restoration to affected parties

Phase 6: Post-Incident Activity

• Conduct post-mortem meeting within 5 business days
• Document root cause, timeline, response actions, and impact
• Identify lessons learned and improvement opportunities
• Create corrective action plan with owners and due dates
• Update incident response procedures based on learnings

8. Incident Reporting

Internal Reporting Channels

• Email: security@company.com (monitored 24/7)
• Slack: #security-incidents channel
• Incident Hotline: 1-800-XXX-XXXX (24/7 SOC hotline)
• Direct Contact: Contact any Incident Response Team member

What to Report: Suspicious emails, unusual system behavior, unauthorized access, data loss, malware alerts, security tool alerts, lost/stolen devices, policy violations

External Reporting Contact

Organization provides a public security contact for external parties to report vulnerabilities and incidents:

• Security Email: security@yourcompany.com
• Bug Bounty Program: https://yourcompany.com/security/bug-bounty
• Security Page: https://yourcompany.com/security with reporting instructions

9. Communication Protocols

Internal Communication

• Executive Notification: P1 incidents require immediate notification to CEO, CTO, CSO
• Status Updates: Incident Commander provides updates every 2 hours for P1, every 4 hours for P2
• All-Hands Communication: Company-wide notification for incidents affecting all employees
• Incident Channel: Dedicated Slack channel created for each P1/P2 incident

External Communication

• Customer Notification: Required for P1/P2 incidents affecting customer service or data
• Status Page: Public status page updated within 30 minutes for customer-facing outages
• Regulatory Notification: Legal/Compliance determines if regulatory notification required (GDPR, CCPA, HIPAA, etc.)
• Law Enforcement: Contact law enforcement for criminal activity, data theft, or as legally required
• Media: All media inquiries directed to Communications Lead; no individual responses

Regulatory Notification Requirements

• GDPR: Personal data breach notification within 72 hours to supervisory authority
• CCPA: Notification to California Attorney General for breaches affecting 500+ California residents
• State Breach Laws: Notification as required by applicable state laws
• Contractual Obligations: Customer contract notification requirements per SLA

10. Incident Response Team

The Incident Response Team consists of:

• Incident Commander (IC): CSO or designated security leader – overall authority and decision-making
• Security Analysts: Detect, triage, investigate, and respond to incidents
• Security Engineers: Implement technical containment, eradication, and recovery actions
• System Administrators: Assist with system isolation, restoration, and configuration
• Communications Lead: Manage stakeholder communications (Marketing/PR Director)
• Legal Counsel: Advise on regulatory obligations, evidence preservation, law enforcement coordination
• Compliance Officer: Assess compliance impact, coordinate regulatory notifications

On-Call Rotation: 24/7 on-call coverage with primary and secondary responders

11. Incident Documentation

All incidents must be documented with the following information:

• Incident Details: Date/time detected, severity, type, affected systems, impacted users
• Timeline: Chronological log of detection, response actions, and communications
• Root Cause: Analysis of how the incident occurred and what allowed it
• Impact Assessment: Data affected, systems compromised, customer impact, downtime
• Response Actions: Containment, eradication, and recovery steps taken
• Evidence Preservation: Logs, screenshots, forensic images, network captures
• Lessons Learned: What went well, what could be improved, corrective actions

Retention: Incident records retained for 7 years per legal and compliance requirements

12. Incident Response Testing

We test our incident response capabilities at least annually:

• Tabletop Exercises: Quarterly scenario-based discussions with IRT
• Simulation Exercises: Annual live simulation of security incident with full IRT participation
• Red Team Exercises: Periodic simulated attacks to test detection and response capabilities
• Test Scenarios: Ransomware, data breach, DDoS, insider threat, phishing campaign
• Test Documentation: Record test date, scenario, participants, results, gaps identified, improvements

13. Threat Intelligence and External Coordination

• Threat Intelligence Feeds: Subscribe to security advisories from CISA, US-CERT, vendors
• Industry Sharing: Participate in information sharing groups (ISACs, industry forums)
• Vendor Coordination: Coordinate with security vendors during incidents (cloud providers, SaaS vendors)
• Law Enforcement: Maintain relationships with FBI, Secret Service for cybercrime investigations

14. Evidence Preservation and Forensics

• Preserve evidence for potential legal action or law enforcement investigation
• Maintain chain of custody for forensic evidence
• Create forensic images of compromised systems before remediation
• Collect and preserve logs, network captures, memory dumps
• Engage third-party forensic specialists for complex incidents

15. Training and Awareness

• All employees complete annual security awareness training including incident reporting procedures
• Incident Response Team receives specialized incident handling training
• New employees receive incident reporting overview during onboarding
• Quarterly security bulletins communicate recent threats and reporting reminders

16. Exceptions

Exceptions to this policy require Chief Security Officer approval with documented business justification and risk assessment.

17. Enforcement

Failure to report security incidents or follow incident response procedures may result in disciplinary action up to and including termination.

18. References

• SOC 2 – Security Incident Management Controls
• NIST SP 800-61 – Computer Security Incident Handling Guide
• [Your Company] Information Security Policy
• [Your Company] Business Continuity Policy
• [Your Company] Data Breach Response Plan
• [Your Company] Communications and PR Policy

19. Revision History

Date	Version	Author	Description
[Date]	1.0	Chief Security Officer	Initial release