Information Security Incident Response Policy
An information security incident response policy template for identifying, escalating, containing, notifying, and reviewing security incidents. Use it to define who acts, what gets documented, and when legal or regulatory notices are triggered.
Trusted by frontline teams 15 years of frontline software AI customization in seconds
Built for: Healthcare · Financial Services · Retail · Technology · Manufacturing
Overview
This Information Security Incident Response Policy template sets the rules for identifying, escalating, containing, notifying, and reviewing security incidents. It is built for organizations that need a clear policy holder, defined response roles, and a documented path from first report to post-incident review.
Use it when your organization handles employee data, customer data, regulated records, or systems that could be disrupted by phishing, malware, unauthorized access, lost devices, or ransomware. The template helps you define what counts as an incident, who must be notified, how quickly containment should begin, and when Legal, HR, Privacy, or outside counsel must be involved. It also gives you a place to document evidence preservation, internal communications, and lessons learned.
Do not use it as a generic IT troubleshooting guide. If you only need a help desk escalation workflow for routine outages, a lighter incident ticketing process may be enough. This policy is meant for events with security, privacy, employment, or regulatory implications, including incidents involving employee records, protected data, or vendor systems. It should be customized for your jurisdictions, data types, and reporting obligations, and it should be paired with training so employees know how to report suspicious activity quickly.
Standards & compliance context
- Align the policy with privacy and breach-response obligations under applicable state breach notification laws, and tailor notice timing for the jurisdictions where you operate.
- Where employee records are involved, coordinate with FLSA, FMLA, ADA, Title VII, ADEA, and EEOC-related confidentiality and anti-retaliation concerns before sharing incident details broadly.
- Preserve protected concerted activity rights under NLRA Section 7 when employees report security concerns or discuss workplace conditions tied to a security event.
- If the incident involves accommodation records or medical information, limit access and apply the ADA interactive process and confidentiality rules to the response file.
- For California employees, review CCPA/CPRA privacy handling and any state breach notice requirements; for other states, confirm local breach and whistleblower rules before external communication.
General regulatory context for orientation only — verify current requirements with counsel or the relevant agency before relying on this template for compliance.
What's inside this template
Purpose
Explains why the policy exists and what kinds of incidents it is meant to control.
-
This policy establishes a consistent process for identifying, escalating, containing, notifying, documenting, and reviewing information security incidents. The goal is to reduce harm, support timely decision-making, meet legal and contractual obligations, and preserve evidence for investigation and remediation.
Scope
Defines which people, systems, data, locations, and vendors are covered so there is no ambiguity during a real event.
-
This policy applies to all employees, contractors, temporary workers, interns, and third parties who access company systems, networks, devices, or data. It applies to incidents involving company-owned or personal devices used for business purposes, cloud services, email, messaging platforms, removable media, and paper records containing sensitive data. **Applicable jurisdictions:** This policy applies in the United States and must be interpreted together with any state breach-notification laws, sector-specific requirements, and any non-U.S. privacy or incident reporting obligations that apply to the company.
Definitions
Clarifies terms like incident, breach, containment, and reportable event so employees use the same language.
-
For purposes of this policy: - **Information Security Incident** means any suspected or confirmed event that may compromise confidentiality, integrity, or availability. - **Security Breach** means unauthorized access to or disclosure of protected information where notice may be required by law. - **Containment** means immediate steps to limit further damage or exposure. - **Escalation** means notifying the designated internal contacts based on severity and impact. - **Good-faith report** means a report made honestly and promptly based on the employee's reasonable belief that an incident may have occurred.
Policy Statement
States the organization’s required response standard, including prompt reporting, escalation, and documentation.
-
All personnel must promptly report suspected information security incidents as soon as they are discovered. Employees must not attempt to conceal, delete, or independently investigate an incident beyond basic containment steps authorized by IT Security or Legal. The company will assess each incident in good faith, determine severity, preserve evidence, and take appropriate containment and notification actions. Where employee data is involved, HR must coordinate with Legal and Compliance to determine whether employee notices, internal communications, or employment-related actions are required. The company will comply with mandatory cyber incident reporting requirements, applicable breach-notification laws, and contractual notification obligations. The company will also maintain accurate records of incident response actions and corrective measures.
Procedure
Lays out the step-by-step actions from first report through containment, notification, recovery, and review.
-
### 1. Identify and report Employees must report any suspected incident immediately to the Service Desk, IT Security, or the designated incident hotline/email. Examples include phishing, malware, lost or stolen devices, unauthorized access, misdirected emails, accidental data sharing, suspicious account activity, and physical theft of records. ### 2. Initial escalation The receiving team must log the report, assign a severity level, and notify IT Security leadership, Legal, Compliance, and HR when employee data, employee accounts, or workplace systems are involved. ### 3. Containment IT Security may isolate devices, disable accounts, reset credentials, block traffic, quarantine files, or suspend integrations to prevent further exposure. Employees must cooperate with containment instructions and preserve affected devices, messages, and records. ### 4. Investigation and evidence preservation The incident response team will collect relevant logs, timestamps, screenshots, access records, and witness statements as needed. Evidence must be preserved in a manner that supports legal review and potential regulatory reporting. ### 5. Notification decision Legal and Compliance will determine whether notice is required to regulators, affected individuals, customers, business partners, insurers, or law enforcement. HR will support employee-facing communications when employee records or employee systems are affected. ### 6. Remediation and recovery The responsible teams will restore systems, rotate credentials, patch vulnerabilities, revoke access where needed, and implement safeguards to reduce recurrence. ### 7. Post-incident review After closure, the incident response team will complete a documented review covering root cause, timeline, impact, response effectiveness, policy gaps, and corrective actions. Action items must be assigned owners and due dates.
Roles & Responsibilities
Assigns ownership so Security, IT, HR, Legal, Privacy, and managers know who does what.
-
**All Employees** - Report suspected incidents immediately in good faith. - Follow containment instructions and preserve evidence. - Do not share incident details externally unless authorized. **Managers** - Escalate reports promptly and support employee cooperation. - Ensure non-exempt employees accurately record time spent on incident-related work. **IT Security** - Triage incidents, contain threats, preserve evidence, and coordinate technical recovery. - Maintain incident logs and technical documentation. **HR** - Coordinate employee communications, employee-data notifications, and workforce impacts. - Support disciplinary review when employee misconduct or policy violations are involved. **Legal / Compliance** - Determine legal notice obligations, regulatory reporting, privilege strategy, and retention requirements. - Review external communications before release. **Leadership** - Approve major response actions, resource allocation, and high-severity external notifications.
Compliance, Discipline, and Employment Law Considerations
Connects incident handling to legal duties, confidentiality, retaliation risk, and discipline for failures to follow the process.
-
Failure to report an incident promptly, intentional concealment, unauthorized disclosure of incident information, or interference with containment may result in corrective action up to and including termination, subject to applicable law. **FLSA:** Non-exempt employees must record all time spent responding to incidents, including after-hours work, and managers must ensure overtime is approved and paid in accordance with the Fair Labor Standards Act. **EEOC / HR:** If an incident involves employee records or workplace communications, HR must coordinate to avoid discriminatory treatment and to ensure any employee-facing actions are consistent with Title VII and other equal employment obligations. **NLRA:** Nothing in this policy is intended to restrict protected concerted activity, including employees discussing wages, hours, or working conditions, except to the extent such activity would unlawfully disclose confidential security information or violate applicable law. **State-specific carve-outs:** - **California employees:** Follow any applicable California data breach, privacy, and employee notice requirements, including CCPA/CPRA obligations where applicable. - **New York employees:** Escalate potential whistleblower-related concerns in a manner consistent with NY Labor Law Section 740. - **Washington employees:** Coordinate leave or sick-time impacts in accordance with Washington paid sick leave rules where applicable. - **Illinois employees:** Ensure scheduling or on-call response expectations do not conflict with the One Day Rest in Seven Act where applicable.
Review and Revision
Ensures the policy stays current after incidents, law changes, or system changes and is revisited on a set cadence.
-
This policy will be reviewed at least annually and after any material security incident, regulatory change, or major technology change. Revisions must be approved by HR, IT Security, Legal, and Compliance, with final approval by designated leadership. The policy holder is responsible for maintaining the current version, communicating updates, and ensuring acknowledgements are collected when required.
How to use this template
- 1. Fill in the policy holder, effective_date, version, applicable_jurisdictions, applicable_roles, and review_frequency fields before publishing the policy.
- 2. Define the incident types your organization treats as reportable, including suspected phishing, unauthorized access, malware, lost devices, data exposure, and vendor-related events.
- 3. Assign the response chain so employees know exactly who receives the first report, who leads containment, who approves external notice, and who documents the case file.
- 4. Train managers, HR, IT, and frontline staff on the reporting channel, evidence preservation steps, and the rule that incidents must be escalated immediately rather than investigated informally.
- 5. After each incident, complete the review and revision step by recording root cause, control gaps, corrective actions, discipline if warranted, and any policy updates needed.
Best practices
- Define a short, plain-language threshold for when a suspicious event becomes a reportable incident.
- Require immediate preservation of logs, emails, screenshots, and device status before systems are reimaged or accounts are reset.
- Separate containment authority from notification approval so the team can act quickly without guessing who can authorize next steps.
- Include a documented warning path for employees who delay reporting, ignore escalation rules, or interfere with evidence preservation.
- State that HR must be looped in when employee data, workplace misconduct, or discipline may be involved.
- Use a single incident log format so Legal, Security, Privacy, and HR can track decisions in one record.
- Review vendor and third-party notification obligations before the first incident occurs, not after.
What this template typically catches
Issues teams running this template most often surface in practice:
Common use cases
Frequently asked questions
What incidents does this policy template cover?
This template covers suspected or confirmed information security incidents such as malware, phishing, unauthorized access, lost devices, data exposure, ransomware, and accidental disclosure. It is written to help a policy holder define when an event becomes an incident and when escalation is required. You can narrow or expand the scope for your environment, but the policy should clearly distinguish routine IT issues from reportable security events.
How often should the policy be reviewed?
Review the policy at least annually, and sooner after a material incident, a major system change, or a change in applicable law. Annual review is important because notification timelines, vendor dependencies, and internal contacts change quickly. The template includes a review and revision section so the policy holder can keep the response process current.
Who should own and run the incident response process?
The policy is usually owned by Security, IT, Legal, or Compliance, with HR involved when employee data, workplace conduct, or disciplinary action may be implicated. Day-to-day coordination often sits with an incident response lead or security manager, while Legal and Privacy determine notice obligations. The template is designed so roles and escalation paths are explicit rather than improvised during an event.
Does this template address legal and regulatory notice obligations?
Yes, it is structured to support notice decisions under applicable federal and state requirements, including privacy, breach notification, and employment-law considerations where employee records are involved. It should be customized for the jurisdictions where you operate, since state breach laws and sector rules can vary. The policy should also preserve evidence and documentation needed for counsel, insurers, and regulators.
What are the most common mistakes this policy helps prevent?
Common failures include delayed escalation, unclear authority to isolate systems, missing documentation, and inconsistent decisions about external notice. Another frequent gap is not defining who may contact law enforcement, vendors, or affected individuals. This template helps reduce those problems by assigning responsibilities and requiring a documented response timeline.
How should this policy be customized for different business units?
Customize the incident categories, reporting channels, and response owners to match your systems, vendors, and data types. For example, a healthcare group may add patient data handling steps, while a retailer may emphasize payment systems and point-of-sale devices. The core structure should stay consistent so every business unit follows the same escalation and review framework.
Can this policy be integrated with other HR and compliance templates?
Yes, it works well alongside acceptable use, data retention, remote work, disciplinary action, and business continuity templates. It also pairs with training acknowledgments, vendor management, and privacy incident logs. Using related templates together helps the policy holder move from detection to containment, notice, and post-incident remediation without gaps.
How is this different from an ad hoc response process?
An ad hoc process depends on who happens to be available, which often leads to inconsistent containment and incomplete records. This template gives the organization a repeatable sequence for triage, escalation, notification, and post-incident review. That makes it easier to train staff, prove good-faith response, and identify recurring control failures.
Related templates
Ready to use this template?
Get started with MangoApps and use Information Security Incident Response Policy with your team — pricing built for small business.
