[Company] Incident Response Plan

• Version: 1.0
• Owner: Founder/CTO
• Approved by: Chief Executive Officer
• Effective date: [Effective date]
• Next review date: [Review date]

1. Purpose

This plan tells everyone at [Company] what to do when something goes wrong with a system, an account, or data that [Company] is trusted to protect. It sets out how to report a suspected problem, how the company decides how serious it is, who takes charge, and what steps to follow to contain and fix it. Because [Company] is a small, fully remote team, this plan is written to be usable by anyone under pressure, not just by a security specialist.

This plan supports [Company]'s information security policy and its work toward a SOC 2 report. It also helps [Company] meet its legal and contractual duties to customers, employees, and regulators when a security incident affects personal information or customer systems. Every employee and contractor must read this plan and know how to report a concern.

2. Scope

This plan applies to every employee and contractor of [Company], and to every system, account, and dataset the company uses or manages, including its cloud infrastructure on AWS, its Google Workspace environment, and its source code and repositories on GitHub. It covers security incidents affecting [Company]'s own systems as well as incidents that affect customer data processed by [Company] on behalf of its customers.

3. Incident and Event Definitions

An "event" is anything unusual that is noticed on a system, account, or network; most events are harmless or turn out to have an ordinary explanation. An "incident" is an event that has actually or potentially compromised the confidentiality, integrity, or availability of [Company]'s systems or data, and that requires a response under this plan.

• Events (not automatically incidents):
  • A single failed login attempt.
  • An automated vulnerability scan hitting a public endpoint.
  • A brief, unexplained service slowdown that resolves on its own.
• Incidents:
  • Unauthorized access to a customer's data or account.
  • A lost or stolen laptop or phone that had access to company systems.
  • Malware or ransomware found on a company device or cloud resource.
  • A phishing email that led an employee to enter their credentials.
  • Suspicious activity in AWS, Google Workspace, or GitHub, such as unrecognized logins, unexpected changes to permissions, or unauthorized code commits.
  • Accidental disclosure of personal information to the wrong recipient.

4. Incident Reporting

Anyone who notices a suspected incident, or anything that looks like one, must report it immediately using the team chat tool, in a dedicated incident channel if one exists, or by direct message to the Founder/CTO if not. If the team chat tool is unavailable or may itself be compromised, the report must be made by phone call to the Founder/CTO or the backup contact listed in Appendix A. Reports must never wait for confirmation that something is actually wrong; it is always better to raise a suspicion early than to wait.

Reporting a suspected incident that turns out to be a false alarm carries no penalty. [Company] wants employees to report early and often, and treats every report seriously until it is shown not to be an incident. Delaying a report because of uncertainty, or because the employee is worried about being blamed, is the outcome this plan is designed to prevent.

5. Severity Levels

[Company] assigns every confirmed incident one of the following severity levels, which determines how quickly it must be worked and who must be informed.

These targets apply during [Company]'s normal business hours. Outside business hours, [Company] does not commit to a fixed response time; anyone who believes an incident is urgent must call the Founder/CTO or backup contact directly by phone rather than waiting for a chat message to be seen.

6. Escalation and Internal Reporting

Every report of a suspected incident is escalated to the Founder/CTO, who acts as Incident Commander unless otherwise stated in Section 10. If the Founder/CTO is unavailable, or is themselves the subject of the suspected incident (for example, their account appears compromised), the report must be escalated to the backup contact named in Appendix A, who may be another team member or the outside adviser [External IT/security provider, if any].

Once an incident is confirmed, the Incident Commander is responsible for keeping the rest of the team informed, deciding who else needs to be involved, and communicating with the CEO and, where relevant, with affected customers. Because [Company] is a small team, most incidents are handled by two or three people at most, but the Incident Commander must never handle a Critical incident alone without informing at least one other team member.

7. Incident Documentation

Every confirmed incident must be documented using the Incident Collection Form in Appendix B, starting as soon as the incident is confirmed and updated as the response progresses. Documentation must capture what was known and when, what actions were taken, and what decisions were made, including decisions not to notify a customer or regulator and the reasoning behind them.

[Company] retains incident records for 3 years from the date the incident is closed, to support audits, customer questions, and its own learning from past incidents. Records must be stored in a location accessible to the Incident Commander and backup contact even if the primary chat or email account is unavailable, such as a shared drive outside the compromised account.

8. Incident Response Process

8.1 Summary

[Company]'s incident response follows five phases: identifying and confirming what has happened, containing it to stop further harm, removing the cause, restoring normal operation, and reviewing what happened afterward. Notification obligations to customers, regulators, or individuals must be assessed during containment, not left until the incident is fully resolved, because legal and contractual notification clocks often start running very early.

8.2 Detailed Process

Phase 1: Identification

1. Confirm whether the reported event is a genuine incident and assign it a severity level using Section 5.
2. Record the time of detection, the reporter, and initial details in the Incident Collection Form (Appendix B).
3. Notify the Incident Commander if not already involved.
4. Preserve evidence where possible, such as logs in AWS, Google Workspace admin logs, or GitHub audit logs, without altering the affected system.

Phase 2: Containment

1. Take immediate steps to stop the incident from spreading or worsening, such as disabling a compromised account, revoking API keys, or isolating an affected system.
2. Assess whether the incident affects customer data, employee data, or other personal information, and whether it triggers a legal or contractual notification duty under Section 9.3. This assessment must happen now, not after the incident is resolved.
3. Inform the CEO of any incident rated High or Critical.
4. Keep a record of every containment action taken and the time it was taken.

Phase 3: Eradication

1. Identify and remove the root cause, such as malware, a compromised credential, or a misconfigured permission.
2. Patch or reconfigure the affected system to close the gap that allowed the incident.
3. Confirm, as far as reasonably possible, that no other systems or accounts were affected in the same way.

Phase 4: Recovery

1. Restore affected systems and data from a known-good state, verifying integrity before returning them to normal use.
2. Monitor the restored system for signs of recurring or related activity.
3. Confirm with the Incident Commander that the incident is resolved before formally closing it.

Phase 5: Post-Incident Review

1. Hold an incident response meeting within 5 business days of closing a Medium, High, or Critical incident, using the agenda in Section 8.3.
2. Update the Incident Collection Form with the final outcome, root cause, and any notifications made.
3. Identify and assign any follow-up actions needed to prevent recurrence.
4. Update this plan or related security controls if the review shows a gap.

8.3 Incident Response Meeting Agenda

• What happened and when it was detected.
• What actions were taken and by whom.
• Whether the response met the targets in Section 5.
• Whether any notification duty applied and how it was handled.
• What worked well and what did not.
• Follow-up actions, owners, and target dates.

9. Special Considerations

9.1 Internal Issues

Where the suspected cause of an incident is an employee or contractor, or where the Founder/CTO or another response team member is the subject of the incident, the person affected must be excluded from leading or containing that incident. In that case, the backup contact named in Appendix A takes over as Incident Commander until the matter is resolved.

9.2 Compromised Communications

If the team chat tool or Google Workspace account normally used to run the incident response may itself be compromised, the response team must switch to phone calls as the fallback channel, since phone contact does not depend on the same accounts or provider. Contact numbers for this purpose must be kept up to date in Appendix A and stored somewhere accessible outside the primary accounts.

9.3 External Communications and Breach Reporting

Where [Company] processes personal data on behalf of a customer, its first duty is normally to notify that customer, who then decides whether to notify regulators or individuals; the applicable contract usually sets a notification deadline, and it is often shorter than the law requires, so the contract must always be checked. Where [Company] decides how the data is used, such as data about its own employees or contacts it has collected directly, it must notify affected individuals and, where required, regulators itself.

• Notification to individuals whose personal information was likely accessed or acquired without authorization is generally required under the data breach notification law of the individual's state of residence; these laws differ on both the trigger and the time allowed, so the applicable state's law must be checked for each affected individual.
• Notification to a state attorney general or other regulator is required only under some states' laws, typically once the number of affected residents passes a threshold set by that state; check whether the state's law requires it.
• Where a customer contract sets its own notification deadline for incidents affecting that customer's data, that deadline must be followed even if it is shorter than what the law requires.
• Where the trigger or deadline is unclear, [Company] must notify within the period the law or contract requires and confirm the exact trigger and deadline with [Legal counsel / outside adviser placeholder] before the notification is sent.

9.4 Mitigation and Remediation

Once an incident is contained, [Company] must take reasonable steps to reduce the chance of recurrence, such as rotating credentials, tightening access controls in AWS or GitHub, or adding monitoring for the type of activity seen. Remediation actions must be tracked to completion and reviewed at the post-incident meeting described in Section 8.3.

9.5 Cooperation with Customers, Data Controllers and Authorities

[Company] must cooperate fully and promptly with any customer, data controller, or authority investigating an incident that affects them, including providing timely and accurate information about what happened, what data was affected, and what steps have been taken. Where a customer acts as the data controller and [Company] processes data on its behalf, [Company] must follow that customer's reasonable instructions about further notification once the customer has been informed under Section 9.3.

10. Response Team Members

11. Testing and Review

[Company] runs a tabletop exercise at least once a year, walking through a realistic incident scenario with the response team to check that this plan works in practice. This plan is reviewed at least annually, and after any incident rated High or Critical, or after any material change to [Company]'s systems, tools, or team.

12. Management Commitment

[Company]'s leadership is committed to resourcing incident response appropriately for the size of the company, including making time available for testing, keeping this plan current, and ensuring that any incident is handled without regard to who caused it or how it looks. The CEO must be informed of every High or Critical incident and must support the response team in following this plan.

13. Exceptions

Any exception to this plan, such as skipping a documentation step during an active Critical incident to prioritize containment, must be noted in the Incident Collection Form and reviewed at the post-incident meeting.

14. Violations & Enforcement

Failure to report a suspected incident, or interference with an incident response, is treated as a serious matter and may result in disciplinary action up to and including termination of employment or contract. This plan does not penalize good-faith reports that turn out to be false alarms.

15. Appendix A: Contact Information Template

16. Appendix B: Incident Collection Form Template

• Date and time the incident was detected
• Name of the person reporting the incident
• Description of what was observed
• Systems, accounts, or data believed to be affected
• Severity level assigned and date/time assigned
• Containment actions taken and time taken
• Whether a notification duty was assessed, and the outcome of that assessment
• Notifications sent (to whom, when, and by what method)
• Root cause identified
• Eradication and recovery actions taken
• Date and time the incident was closed
• Follow-up actions, owners, and target dates
• Attendees and summary of the post-incident review meeting

Disclaimer

This document is provided for informational purposes only and does not constitute legal advice. It is provided "as is", without warranty of any kind, express or implied, and no liability is accepted for any loss or damage arising from its use. It is used at your own discretion. Review it with a qualified adviser before adopting it.

[Company] Incident Response Plan

• Version: 1.0
• Owner: Head of Security
• Approved by: Chief Operating Officer
• Effective date: [Effective date]
• Next review date: [Review date]

1. Purpose

This plan tells everyone at [Company] what to do when something has gone wrong, or might have gone wrong, with the confidentiality, integrity or availability of its systems or data. It is written to be used while an incident is happening, so it puts the steps to take before the reasons behind them, and keeps each step short enough to follow under pressure.

[Company] handles personally identifiable information and financial data for banks and other financial-services customers, and is subject to GDPR, UK GDPR, SOC 2 and ISO 27001, and to obligations under the Digital Operational Resilience Act (DORA) that its financial-services customers pass down through their contracts. A fast, well-run response protects those customers, their end users, and [Company]'s own standing and contractual commitments.

2. Scope

This plan applies to all [Company] employees, contractors and temporary staff, and to all systems, applications, cloud infrastructure and data that [Company] operates or manages, including its AWS environment, Okta identity platform, and Microsoft 365 tenant, wherever staff are working from under its hybrid working arrangements.

3. Incident and Event Definitions

An event is any observable occurrence in a system or network; most events are routine and harmless. An incident is an event, or series of events, that has compromised, or is reasonably suspected of having compromised, the confidentiality, integrity or availability of [Company]'s data or systems. Every incident is an event, but not every event is an incident.

• Examples of events: a failed login attempt, a routine antivirus scan alert that is resolved automatically, a temporary service outage caused by planned maintenance, an expected spike in AWS resource usage.
• Examples of incidents: unauthorised access to a customer's personal or financial data, a lost or stolen laptop or phone with access to company systems, a phishing email that leads to a compromised account, malware or ransomware on a company device, an outage caused by an attack rather than routine maintenance, a misconfigured AWS storage bucket exposing data, suspicious activity in Okta logs suggesting account takeover.

4. Incident Reporting

Any employee, contractor or temporary staff member who suspects an incident must report it immediately, without waiting for confirmation. Reports must be made in the #security-incidents channel of the team chat tool for anything that can wait a few minutes, by email to [Security contact email] for non-urgent matters, or by phone to a member of the security team for anything urgent or if the usual channels are unavailable. Do not wait until the end of the day, and do not try to investigate or fix the issue alone unless told to do so.

Reporting something that turns out to be a false alarm carries no penalty. [Company] would rather review ten reports that come to nothing than miss the one that matters, and staff are expected to report anything that looks wrong.

5. Severity Levels

Severity is assessed by the security team when an incident is reported and may be revised as more is known.

6. Escalation and Internal Reporting

Once an incident is reported, the security team triages it, assigns a severity level, and notifies the Incident Commander for anything rated High or Critical. The Incident Commander decides who else needs to be brought in, drawing on the roles listed in Section 10, and keeps the Executive Sponsor informed throughout Critical incidents and at the close of High incidents. Internal reporting must never wait for the incident to be fully understood; partial information reported early is more useful than complete information reported late.

Where an incident affects data or systems belonging to a financial-services or enterprise customer, the Incident Commander must also assess, from the earliest point in containment, whether the customer needs to be told, and by when their contract requires it (see Section 9.3). This assessment is not left until the incident is resolved, because notification clocks usually start well before that point.

7. Incident Documentation

Every incident rated Medium or above must be documented from the point it is first reported, using the form in Appendix B. Documentation must capture the timeline of what happened and when, who was involved, what actions were taken, what data or systems were affected, and what evidence was collected. Documentation is updated as the incident progresses, not written up only at the end.

Completed incident records must be retained for at least 6 years from the date the incident is closed, in line with the retention [Company] applies to its other risk and compliance records, and for longer where a specific contract or regulator requires it. Incident records and the contact list in Appendix A must remain reachable even if [Company]'s primary systems, including Microsoft 365 and Okta, are unavailable, for example by keeping an offline or independently hosted copy.

8. Incident Response Process

8.1 Summary

[Company]'s response to an incident moves through identification, containment, eradication and recovery, and post-incident review. These phases often overlap in practice, particularly identification and containment, and the process is designed to be worked through quickly rather than followed as a rigid sequence.

8.2 Detailed Process

Identification

1. Confirm whether the reported event is an incident, using the definitions in Section 3.
2. Assign a severity level using Section 5 and notify the Incident Commander if High or Critical.
3. Identify which systems, data and customers are potentially affected.
4. Open an incident record using the form in Appendix B.
5. Preserve relevant logs and evidence before they can be overwritten (for example, AWS and Okta logs).

Containment

1. Take immediate action to limit the spread or impact of the incident, such as disabling a compromised account in Okta, isolating an affected system, or revoking access keys.
2. Confirm whether affected data includes personal data, financial data, or data belonging to a customer.
3. Assess, at this point and not later, what notification duties apply and to what deadlines, using Section 9.3, and record the decision and reasoning in the incident record.
4. Notify the Data Protection Officer/Privacy Lead and Legal Counsel where personal data or a customer's data may be involved.
5. Agree and document a containment strategy with the Incident Commander before moving to eradication.

Eradication and Recovery

1. Remove the root cause of the incident, such as malware, an unauthorised account, or a vulnerable configuration.
2. Apply patches, configuration changes or credential resets needed to prevent recurrence.
3. Restore affected systems and data from a known-clean state, verifying integrity before returning them to service.
4. Monitor restored systems closely for signs of recurrence.
5. Confirm with the Incident Commander that the incident can be formally closed.

Post-Incident Review

1. Hold a review meeting within 10 business days of closure, using the agenda in Section 8.3.
2. Identify root causes and contributing factors.
3. Agree remediation actions, owners and target dates.
4. Update this plan, related runbooks, or system configurations as needed.
5. Close out the incident record, including confirmation that any required notifications were made.

8.3 Incident Response Meeting Agenda

• Summary of what happened and the current status
• Timeline of detection, containment, eradication and recovery
• Data, systems and customers affected
• Notification duties identified and actions taken
• What worked well and what did not
• Root cause and contributing factors
• Remediation actions, owners and deadlines
• Whether this plan or related processes need to change

9. Special Considerations

9.1 Internal Issues

Where an incident involves suspected misconduct by an employee or contractor, the Incident Commander must involve [HR contact/People team] and Legal Counsel before taking any action that could alert the individual concerned. Investigation details must be shared only with those who need to know, and normal disciplinary process must be followed alongside, not instead of, the technical response.

9.2 Compromised Communications

If the security team suspects that Microsoft 365, Okta or the team chat tool has itself been compromised, incident response communications must move to the fallback channel: phone calls between response team members using the numbers in Appendix A. The team chat tool and email must not be relied on as the sole channel for coordinating a response to an incident that may involve those very systems.

9.3 External Communications and Breach Reporting

Notification duties depend on whether [Company] is acting as a data processor for a customer or as the data controller for its own data, and each law or contract sets its own deadline and trigger point, so these must be checked, not assumed.

• Where [Company] processes personal data on behalf of a financial-services or enterprise customer, its first duty is to notify that customer, within the period their contract sets, so the customer can decide whether to notify its own regulator or affected individuals. These contractual periods are often shorter than the law requires and must be checked for each customer.
• As a supplier to EU financial entities subject to DORA, [Company] must notify those customers within the period their contract sets. DORA itself requires the financial entity, not [Company], to send its regulator an initial notification within 4 hours of classifying an incident as major, and no later than 24 hours after becoming aware of it; [Company]'s contractual deadline exists to make those limits achievable for the customer.
• Where [Company] acts as the data controller, for example for its own staff, job applicants or business contacts, it must notify the ICO (or, where an incident also affects EU individuals, the relevant regulator) within 72 hours of becoming aware of a personal data breach that is likely to result in a risk to individuals, and must notify affected individuals without undue delay where the risk is high, under GDPR and UK GDPR.
• Where a customer contract or regulator sets its own notification period, that period applies in addition to, and may be shorter than, the periods above; Legal Counsel must confirm the applicable period for each affected customer or regulator before a deadline is assumed.

9.4 Mitigation and Remediation

Once an incident is contained, [Company] must take reasonable steps to reduce ongoing harm to affected customers and individuals, such as forcing password resets, revoking compromised credentials, or providing customers with the information they need for their own risk assessments. Remediation actions agreed during the post-incident review must be tracked to completion, not left as recommendations.

9.5 Cooperation with Customers, Data Controllers and Authorities

Where [Company] acts as a processor, it must cooperate with the customer's own incident process, providing the information and evidence the customer needs to meet its regulatory obligations, including under DORA and GDPR. Where a regulator, law enforcement body, or a customer acting as data controller makes a direct request, Legal Counsel must be involved before any information is shared, and all such requests and responses must be recorded in the incident record.

10. Response Team Members

If the Head of Security is unavailable, or is the subject of the incident, a designated deputy from the security team assumes the Incident Commander role, and the Executive Sponsor confirms this at the start of the response. Roles may be combined where the security team's size requires it, but no role may be asked to notify or hand off to itself.

11. Testing and Review

[Company] runs a tabletop exercise, walking through a simulated incident against this plan, at least once a year, and reviews and updates this plan at least annually or after any incident rated High or Critical, whichever comes first. Findings from exercises and reviews are tracked as remediation actions under Section 8.2.

12. Management Commitment

Senior leadership at [Company] supports this plan by funding the security team, giving the Incident Commander the authority to take containment actions without prior approval during an active incident, and making time available for testing and review. The Executive Sponsor is accountable for ensuring the plan is followed and kept current.

13. Exceptions

Any exception to this plan, such as a different reporting channel for a specific system or customer, must be approved in advance by the Head of Security and recorded in writing.

14. Violations & Enforcement

Failure to report a suspected incident, to follow this plan, or to cooperate with an investigation may result in disciplinary action, up to and including termination of employment or contract, in line with [Company]'s other HR and disciplinary policies.

15. Appendix A: Contact Information Template

This table must be kept up to date and stored so that it remains reachable even if [Company]'s primary systems are unavailable.

16. Appendix B: Incident Collection Form Template

• Incident ID
• Date and time detected
• Date and time reported, and reported by
• Detection source (e.g. staff report, automated alert, customer report)
• Description of what happened
• Severity level assigned and date assigned
• Systems, data and customers affected
• Data types involved (e.g. personal data, financial data)
• Containment actions taken and by whom
• Notification duties assessed, decision reached, and who was notified and when
• Eradication actions taken
• Recovery actions taken
• Root cause
• Lessons learned and remediation actions agreed
• Date incident closed
• Approved by

Disclaimer

This document is provided for informational purposes only and does not constitute legal advice. It is provided "as is", without warranty of any kind, express or implied, and no liability is accepted for any loss or damage arising from its use. It is used at your own discretion. Review it with a qualified adviser before adopting it.

[Company] Incident Response Plan

• Version: 1.0
• Owner: Head of Security
• Approved by: Chief Executive Officer
• Effective date: [Effective date]
• Next review date: [Review date]

1. Purpose

This plan tells everyone at [Company] what to do when something may have gone wrong with the security or privacy of its systems or data. [Company] handles personally identifiable information (PII) and health data on behalf of hospitals and health systems, and acts as a HIPAA business associate to those customers. A fast, consistent response limits harm to patients and workforce members, protects [Company]'s contractual and legal obligations, and preserves the trust of its healthcare customers.

This plan sits beneath [Company]'s information security policy and puts that policy into action during a live incident. It is deliberately short and practical: every step is written to be followed under pressure, by the people [Company] actually has, not by a large team it does not have.

2. Scope

This plan applies to all [Company] employees and contractors, to all systems that store or process [Company] data (including its Microsoft Azure and Microsoft 365 environments), and to any suspected or confirmed event affecting the confidentiality, integrity, or availability of that data, wherever the affected system or workforce member is located, including hybrid and remote work settings.

3. Incident and Event Definitions

[Company] distinguishes between an "event," which is any observable occurrence in a system or network, and an "incident," which is an event that violates this plan, [Company]'s security policies, or the confidentiality, integrity, or availability of data, and that requires a response.

• Events (not necessarily incidents): a failed login attempt, a routine antivirus scan alert later found to be a false positive, a scheduled system restart, a single blocked phishing email caught by email filtering.
• Incidents: unauthorized access to a system containing PHI or PII, a lost or stolen laptop or phone that held [Company] data, a successful phishing attack leading to account compromise, malware or ransomware on a [Company] system, a misconfigured Azure storage account exposing data, a denial-of-service attack affecting the availability of [Company]'s clinical decision support product, or a workforce member using or disclosing PHI outside their job duties.

4. Incident Reporting

Any workforce member, contractor, or customer who suspects a security or privacy incident must report it immediately, using the team chat tool's designated incident channel, by email to [Security incident reporting email], or by calling the Head of Security directly at [Head of Security phone number]. Reports must not wait for confirmation that something is actually wrong; suspicion is enough to report.

Reporting a suspected incident that turns out to be a false alarm carries no penalty, and [Company] would rather receive ten false alarms than miss one real incident. Delaying a report, or failing to report a suspected incident at all, is treated as a policy violation under Section 14.

5. Severity Levels

[Company] assigns every incident one of four severity levels, which sets how quickly it must be acknowledged and worked.

[Company] does not operate a round-the-clock security team, so these targets apply during business hours. Outside business hours, anyone with a suspected Critical or High severity incident must call the Head of Security directly rather than wait for the next business day.

6. Escalation and Internal Reporting

Whoever detects or receives a report of a suspected incident notifies the Head of Security, who acts as Incident Commander and classifies its severity using the table in Section 5. For Critical or High severity incidents, the Head of Security immediately calls the Chief Executive Officer and assembles the response team named in Section 10, regardless of the time of day.

While an incident is active, the response team holds the meeting described in Section 8.3 at a frequency the Incident Commander sets based on severity, and keeps the Chief Executive Officer briefed between meetings on any material change. Information about a suspected incident is shared only with people who need it to respond, particularly where an insider or a specific workforce member's account is suspected of involvement.

7. Incident Documentation

Every reported incident, regardless of severity, is recorded using the incident collection form in Appendix B and logged in a central incident record maintained by the Head of Security. This record, and the contact list in Appendix A, are kept reachable even if [Company]'s primary systems, including Azure and Microsoft 365, are unavailable, so the response team is not locked out of the information it needs during an outage.

Incident records are retained for six years, matching the documentation retention period the HIPAA Security Rule requires, and are used to support audits, customer inquiries, and continuous improvement of this plan. Records are reviewed for completeness by the Head of Security when an incident is closed.

8. Incident Response Process

8.1 Summary

[Company] responds to incidents in six phases: detecting and reporting the issue, triaging and classifying it, containing it while assessing what notifications it may trigger, eradicating the cause, recovering normal operation, and reviewing what happened afterward. Each phase has its own short numbered steps below, and the response team may move back to an earlier phase if new facts emerge.

8.2 Detailed Process

Detection and Reporting

1. Any workforce member who observes a suspected event reports it immediately using the channels in Section 4.
2. The Head of Security acknowledges the report and opens an incident record within the response target for its likely severity.
3. Initial facts (what happened, when, which systems, and what data may be involved) are captured using the form in Appendix B.

Triage and Classification

1. The Head of Security reviews the initial facts and assigns a severity level per Section 5.
2. The Head of Security determines whether PII, PHI, or a clinical system is affected.
3. For Critical or High severity, the Head of Security notifies the Chief Executive Officer and convenes the response team in Section 10.

Containment and Notification Assessment

1. The response team isolates affected systems, accounts, or network segments to stop ongoing harm, including disabling compromised Azure or Microsoft 365 accounts where needed.
2. The Head of Security, with [External legal counsel], assesses which notification duties apply and when each one's clock starts, using Section 9.3.
3. The Customer Success Lead is briefed on which customers may need notice, without contacting them yet unless containment itself requires it.
4. Logs, system images, and access records are preserved before further changes are made, so the cause can be established later.

Eradication

1. The Engineering Lead removes malicious code, closes the exploited weakness, and revokes any compromised credentials.
2. The response team confirms the root cause has been addressed before any system is restored to service.

Recovery

1. The Engineering Lead restores affected systems from a known clean state or rebuilds them.
2. The response team monitors restored systems for signs the issue has recurred.
3. The Head of Security confirms normal operation before closing the incident as active.

Post-Incident Review

1. The response team holds a review meeting within 10 business days of closing a Critical or High severity incident.
2. The team records the root cause, timeline, what worked, and corrective actions in the incident record.
3. The Head of Security tracks corrective actions to completion and updates this plan where it finds a gap.

8.3 Incident Response Meeting Agenda

• Current severity level and status of the incident
• Summary of what is known and what remains unknown
• Actions taken since the last meeting
• Outstanding containment, eradication, or recovery actions and who owns them
• Notification duties and deadlines identified so far, and who is responsible for each
• Communications sent or planned, both internal and external
• Time and channel of the next update

9. Special Considerations

9.1 Internal Issues

Where a suspected incident may involve a workforce member's misconduct, or may involve the Head of Security personally, that person is excluded from the response for that incident and the Security Contractor acts as Incident Commander in their place. Access to the incident record for that matter is limited to those directly involved in resolving it, and any disciplinary steps follow [Company]'s standard employment procedures rather than this plan.

9.2 Compromised Communications

Where the team chat tool or email may itself be compromised, for example because an attacker has access to a Microsoft 365 account, the response team switches to phone calls as its fallback channel, since this does not depend on the same accounts or provider. The team avoids discussing details of an active compromise over any channel it believes the attacker may be able to read.

9.3 External Communications and Breach Reporting

[Company] acts as a HIPAA business associate to its hospital and health system customers, and separately controls PII it collects directly, such as workforce and job applicant data, so its notification duties differ depending on whose data is affected; the Head of Security and [External legal counsel] confirm which duty applies and its exact trigger and deadline before any notice is sent.

• As a business associate, [Company] notifies the affected covered entity customer of a breach of unsecured PHI without unreasonable delay, and no later than 60 days after discovering it; the business associate agreement with that customer may set a shorter deadline, which must be checked and followed. [Company] does not itself notify individuals, the Department of Health and Human Services, or the media unless the business associate agreement delegates that duty to it.
• For PII that [Company] controls directly, such as workforce or job applicant data, it notifies affected individuals within the period the applicable state's data breach notification law requires; that law also sets its own trigger for when the notification period begins, so this must be confirmed for each state involved.
• Where a state's law requires it, typically above a stated number of affected residents, [Company] also notifies that state's attorney general or other named regulator.
• Customer contracts, including business associate agreements and master service agreements tied to SOC 2 or HITRUST commitments, often set shorter notification deadlines than the law does; these must be checked for every affected customer.

9.4 Mitigation and Remediation

The response team applies temporary mitigations, such as isolating a system or resetting credentials, as soon as containment allows, and tracks permanent remediation, such as patching, architectural changes, or updated access controls, in the incident record until the Head of Security confirms it is complete. No incident is closed until both the immediate risk and its underlying cause have been addressed.

9.5 Cooperation with Customers, Data Controllers and Authorities

Because [Company] processes data on behalf of hospital and health system customers, it cooperates fully with those customers' own investigations and notification obligations, providing the facts they need in time for them to meet their own deadlines. [Company] also cooperates with a regulator, such as the Department of Health and Human Services Office for Civil Rights, or with law enforcement, on any lawful request, with such contact coordinated through the Head of Security and [External legal counsel].

10. Response Team Members

11. Testing and Review

[Company] runs a tabletop exercise of this plan at least once a year, walking the response team through a realistic scenario without affecting live systems. The Head of Security reviews this plan at least once a year, and after any Critical severity incident or material change to [Company]'s systems or regulatory obligations, and proposes updates for the Chief Executive Officer's approval.

12. Management Commitment

[Company]'s leadership funds and supports this plan, ensures the response team has the authority and resources it needs to act quickly, and reviews the outcome of every Critical or High severity incident and every tabletop exercise, so that gaps found are actually fixed.

13. Exceptions

Any deviation from this plan requires the approval of the Head of Security, and, for a Critical severity incident, of the Chief Executive Officer as well; the deviation and its reason are recorded in the incident record.

14. Violations & Enforcement

Failing to report a suspected incident, failing to cooperate with the response team, or otherwise not following this plan may lead to disciplinary action up to termination of employment, and, for contractors or vendors, to remedies under their contract, consistent with [Company]'s information security policy.

15. Appendix A: Contact Information Template

This contact list is kept reachable in a form that does not depend on [Company]'s primary systems, so it can still be used if Azure or Microsoft 365 is unavailable.

16. Appendix B: Incident Collection Form Template

• Incident ID / reference number
• Date and time detected
• Date and time reported, and by whom
• Description of what occurred
• Systems, applications, or accounts affected
• Data types involved (for example, PHI, PII)
• Suspected cause
• Severity level assigned, and by whom
• Containment actions taken, with timestamps
• Notification duties assessed, and outcome of that assessment
• Internal parties notified, and when
• External parties notified (customers, regulators, law enforcement), and when
• Eradication actions taken
• Recovery actions taken
• Root cause identified
• Corrective actions and their owners
• Date incident closed
• Date and outcome of post-incident review

Disclaimer

This document is provided for informational purposes only and does not constitute legal advice. It is provided "as is", without warranty of any kind, express or implied, and no liability is accepted for any loss or damage arising from its use. It is used at your own discretion. Review it with a qualified adviser before adopting it.

[Company] Incident Response Plan

• Version: 1.0
• Owner: Chief Information Security Officer (CISO)
• Approved by: Chief Executive Officer
• Effective date: [Effective date]
• Next review date: [Review date]

1. Purpose

This plan tells everyone at [Company] what to do when something looks wrong — a suspicious email, a locked-out account, an alert from a monitoring tool, or a call from a customer about unusual activity. It sets out how to report a suspected incident, who takes charge, how the response team investigates and contains the problem, and when [Company] must tell customers, regulators, or individuals what happened.

[Company] provides managed IT and security services to defense contractors and government agencies, and handles personally identifiable information (PII) and controlled unclassified information (CUI) on their behalf. A fast, well-run response protects [Company]'s customers, meets its contractual and regulatory obligations under CMMC and NIST SP 800-171, and limits harm to people whose data it holds. This plan works alongside [Company]'s information security policy and is the document to open first when an incident is suspected.

2. Scope

This plan applies to all [Company] employees, contractors, and temporary staff, and to all systems, networks, applications, and data that [Company] operates or manages, whether hosted in Microsoft Azure (including Azure Government), on-premises, or through Microsoft 365, and whether the incident is discovered internally, reported by a customer, or reported by a third party.

3. Incident and Event Definitions

An event is any observable occurrence in a system or network that may or may not indicate a problem. An incident is an event, or series of events, that has actually or potentially compromised the confidentiality, integrity, or availability of [Company]'s or a customer's systems or data, or that violates security policy.

• Events (require monitoring, not necessarily a response): a single failed login, a routine antivirus detection that was automatically blocked, a firewall rule change made through the normal change process, a service desk ticket about a slow application.
• Incidents (require the process in Section 8): a confirmed malware infection, unauthorized access to a customer's or [Company]'s systems, loss or theft of a device containing PII or CUI, a phishing attack that led to a compromised account, a denial-of-service attack, unauthorized disclosure of CUI, or misuse of access by an employee or contractor.

4. Incident Reporting

Anyone who suspects an incident — whether an employee, contractor, or customer — must report it immediately, without waiting to confirm it is genuine. Reporting a suspected incident that turns out to be a false alarm carries no penalty; [Company] would rather investigate ten false alarms than miss one real incident.

Incidents must be reported through the dedicated incident channel in the team chat tool or by emailing [Security incident email], both of which are monitored by the Security Operations Center (SOC) during business hours. Outside business hours, or for anything that looks serious, report it immediately by calling the SOC on-call phone line at [On-call phone number]. Do not wait for a scheduled meeting or use a ticket queue for anything that looks like an active incident.

5. Severity Levels

[Company] assigns every reported incident one of four severity levels, which determines how quickly the response team must act.

6. Escalation and Internal Reporting

The SOC on-call analyst who first triages a report assigns an initial severity level and notifies the Incident Commander immediately for Critical and High incidents, and during the next business day for Medium and Low incidents. The Incident Commander may raise or lower the severity level as more facts emerge, and must reassess severity throughout the incident rather than only at the start.

For Critical incidents, the Incident Commander notifies the executive leadership team within the response target set in Section 5, and provides regular updates until the incident is closed. For High incidents affecting a specific customer, the Incident Commander also notifies the Customer Success Lead so the customer can be kept informed in line with Section 9.3. Internal reporting must never wait for the incident to be fully resolved; leadership and affected functions need to know while the response is still underway.

7. Incident Documentation

The analyst who opens an incident record starts an incident log at the same time, using the template in Appendix B. The log must capture, from the moment of detection, what was observed, when, by whom, and every action the response team takes, including containment steps, systems affected, evidence preserved, and communications sent internally and externally. The log is a live document during the incident, not something written up afterward from memory.

[Company] keeps incident records, including the incident log, supporting evidence, and records of any notifications made, for 3 years from the date the incident is closed. Records must be stored in a location the response team can access even if the primary systems involved in the incident are unavailable, and access to incident records is restricted to the response team and those with a legitimate need, given that records may contain sensitive customer, CUI, or personal data.

8. Incident Response Process

8.1 Summary

[Company] follows a six-phase process: Preparation, Identification, Containment, Eradication, Recovery, and Post-Incident Review. Notification obligations are assessed during containment, as soon as the facts are known, not left until the incident is fully resolved, because legal and contractual deadlines can start running early.

8.2 Detailed Process

Preparation

1. The response team keeps the contact list in Appendix A current and accessible outside normal systems.
2. The SOC maintains monitoring and logging across Azure, Azure Government, on-premises systems, and Microsoft 365.
3. The CISO ensures the SOC on-call rotation is staffed, and that on-call staff can be reached at any hour.
4. [Company] provides security awareness training so staff can recognize and report suspected incidents.

Identification

1. Whoever detects a suspected incident reports it immediately, per Section 4.
2. The SOC on-call analyst triages the report, using AI-assisted service desk triage tools where applicable, and confirms whether it is an event or an incident.
3. The analyst assigns an initial severity level (Section 5) and notifies the Incident Commander.
4. The analyst opens an incident record and starts the incident log (Section 7).

Containment

1. The response team isolates affected systems, accounts, or network segments to stop the incident from spreading.
2. The response team preserves evidence, such as logs, disk images, or memory captures, before making further changes, where practical.
3. The Compliance Manager and Legal Counsel assess notification duties (Section 9.3) as soon as the facts allow; this assessment starts now, not after recovery.
4. The Incident Commander decides whether to activate the compromised communications procedure (Section 9.2).
5. All containment actions are recorded in the incident log.

Eradication

1. The response team removes the root cause, such as malware, an unauthorized account, or an exploited vulnerability.
2. The response team patches or reconfigures affected systems.
3. The response team confirms no backdoors, unauthorized accounts, or other persistence mechanisms remain.

Recovery

1. The response team restores systems from clean backups or rebuilds them as needed.
2. The response team monitors restored systems closely for signs of recurrence.
3. The Incident Commander confirms normal operations before formally closing the incident.
4. The response team completes any outstanding notification or reporting obligations.

Post-Incident Review

1. The response team holds a lessons-learned meeting within 5 business days of closing the incident.
2. The team documents the root cause, timeline, and corrective actions in the incident record.
3. The Compliance Manager confirms that every required notification was made and recorded.
4. The team updates this plan and related controls based on the findings.

8.3 Incident Response Meeting Agenda

• Current status and severity level
• Actions taken since the last meeting
• Outstanding containment, eradication, or recovery tasks
• Notification obligations and their status
• Communications sent or planned, internal and external
• Blockers and resources needed
• Next steps, owners, and time of next meeting

9. Special Considerations

9.1 Internal Issues

Where the suspected incident involves an employee or contractor, such as suspected misuse of access or data theft, the Incident Commander involves Human Resources and Legal Counsel from the outset, and keeps the investigation confidential on a need-to-know basis. If the person implicated in the incident is the Incident Commander or another response team member, that person is excluded from the response and their designated backup (Section 10) takes over.

9.2 Compromised Communications

Where the team chat tool, email, or other primary channel may itself be compromised, or where using them could tip off an attacker, the response team switches to phone (landline or mobile), which does not depend on the same accounts, cloud tenant, or provider. The Incident Commander decides when to activate this fallback and tells the team which channel to use for the remainder of the incident.

9.3 External Communications and Breach Reporting

[Company] handles two distinct roles: it processes data on behalf of its customers, and it controls data about its own staff and contacts. Deadlines and triggers differ by law and contract, so the Compliance Manager and Legal Counsel must confirm which applies before any external notification is sent.

• Where [Company] processes a customer's data (including CUI or PII held on a customer's behalf), its first duty is usually to notify that customer, not the customer's regulators or individuals directly; contracts often set a shorter deadline than any underlying law, so the applicable contract must be checked.
• Where a contract with [Company] includes the DFARS 252.204-7012 clause, [Company] must report cyber incidents affecting covered defense information to the Department of Defense within 72 hours of discovery, as that clause requires.
• CMMC and NIST SP 800-171 require incidents to be reported but do not themselves set a deadline; the deadline comes from the relevant contract clause and must be confirmed for each affected contract.
• Where a breach affects PII about [Company]'s own staff or contacts, [Company] must notify affected individuals under the data breach notification law of each affected person's state; the trigger and the deadline are set by that state's law and must be confirmed for each state involved.
• Some states also require notice to the state attorney general or another regulator, often only above a threshold number of affected residents, where the state's law requires it.
• Where a customer is itself subject to its own regulatory reporting duties (for example, a government agency's own incident reporting rules), [Company] cooperates with that customer's process rather than reporting to that regulator directly, unless the contract says otherwise.

9.4 Mitigation and Remediation

The response team prioritizes stopping further harm over restoring convenience, which may mean disabling accounts, taking systems offline, or blocking network traffic even where this disrupts service. Once the root cause is confirmed, the team applies patches, tightens configurations, updates detection rules, and validates fixes with the SOC's monitoring tools before considering the incident closed, and captures any gaps found for the Post-Incident Review.

9.5 Cooperation with Customers, Data Controllers and Authorities

For most incidents, [Company] acts as a service provider to its defense contractor and government customers, who remain responsible for deciding whether to notify their own regulators or the individuals whose data they control. [Company] must give those customers timely, accurate information, including logs and evidence on request, so they can meet their own obligations, and must cooperate with law enforcement, the Department of Defense, or the relevant regulator where a customer, contract, or law requires it.

10. Response Team Members

11. Testing and Review

[Company] runs a tabletop exercise, walking the response team through a simulated incident, at least twice a year, and after any major change to its systems or customer base. This plan is reviewed at least once a year, and after every Critical or High severity incident, to incorporate lessons learned and changes to systems, contracts, or applicable law.

12. Management Commitment

Executive leadership funds and staffs the response team described in Section 10, gives the Incident Commander the authority to take systems offline or restrict access without prior sign-off during an active incident, and reviews the outcome of every Critical incident. Leadership treats incident response as an ongoing operational responsibility, not a one-off project.

13. Exceptions

Any deviation from this plan, such as skipping a phase or using an alternative communication channel, must be approved by the Incident Commander and recorded in the incident log along with the reason.

14. Violations & Enforcement

Failure to report a suspected incident, interference with an investigation, or failure to follow this plan may result in disciplinary action, up to and including termination, and, where a contractor or supplier is involved, termination of the relevant contract. This is separate from, and does not replace, any legal or regulatory consequence that may follow from the underlying incident.

15. Appendix A: Contact Information Template

16. Appendix B: Incident Collection Form Template

• Incident ID and date opened
• Name and role of person reporting the incident
• Date and time the incident was detected
• Date and time the incident began, if known
• Systems, applications, or data affected (including whether CUI or PII is involved)
• Customer(s) affected, if any
• Initial severity level and any changes made, with reasons
• Description of what was observed
• Actions taken, by whom and when, for each phase (containment, eradication, recovery)
• Evidence collected and where it is stored
• Notifications sent (internal, customer, regulator), to whom, when, and by what method
• Root cause, once identified
• Date and time the incident was closed
• Lessons-learned meeting date and follow-up actions assigned

Disclaimer

This document is provided for informational purposes only and does not constitute legal advice. It is provided "as is", without warranty of any kind, express or implied, and no liability is accepted for any loss or damage arising from its use. It is used at your own discretion. Review it with a qualified adviser before adopting it.

[Company] Incident Response Plan

• Version: 1.0
• Owner: Chief Information Security Officer (CISO)
• Approved by: Board of Directors
• Effective date: [Effective date]
• Next review date: [Review date]

1. Purpose

This plan tells everyone at [Company] what to do when something goes wrong: a suspected data breach, a system outage, unauthorized access, or any other event that threatens the confidentiality, integrity, or availability of [Company]'s systems or data. It is written to be followed under pressure, so it favors short, direct instructions over lengthy explanation. Anyone who suspects an incident should be able to open this document and know their first step within seconds.

[Company] handles personal, financial, and sensitive personal data for enterprise customers across the United States, the United Kingdom, the European Union, and India, and is bound by contractual security commitments and by frameworks including ISO 27001 and SOC 2. A fast, well-coordinated response limits harm to customers and individuals, protects [Company]'s reputation and contractual standing, and satisfies legal and regulatory notification duties that begin very early in an incident, often before the underlying problem is fixed.

2. Scope

This plan applies to all [Company] employees, contractors, and third parties with access to [Company] systems or data, and covers all incidents affecting [Company]'s cloud infrastructure (AWS, Microsoft Azure, and Google Cloud), corporate systems, identity provider (Okta), applications, and any data [Company] processes on its own behalf or on behalf of its customers, regardless of the office or region where the incident is detected.

3. Incident and Event Definitions

An "event" is any observable occurrence in a system or network; most events are routine and require no action. An "incident" is an event, or series of events, that indicates a violation or imminent threat of violation of security policy, acceptable use, or law, and that requires a response under this plan. Distinguishing the two quickly is the job of whoever first notices something unusual.

• Events (routine, logged, no incident response needed): a failed login attempt, a routine vulnerability scan alert already known and tracked, a firewall rule blocking expected traffic.
• Incidents (this plan applies): unauthorized access to a system or account, a suspected or confirmed data breach involving personal, financial, or sensitive personal data, malware or ransomware on any device, a distributed denial-of-service attack affecting customer-facing services, loss or theft of a device containing [Company] or customer data, a successful phishing attack resulting in credential compromise, and any misuse of [Company] systems by an insider.

4. Incident Reporting

Any employee, contractor, or third party who suspects a security incident must report it immediately, without waiting for confirmation. Reports go to the Security Operations on-call analyst through the team chat tool's dedicated security incident channel, by email to [Security incident reporting email], or by calling [Security on-call phone number] for anything urgent. Reports may also be logged directly in [Company]'s IT service management tool.

Speed matters more than certainty: staff must report anything that looks wrong even if they are not sure it is a real incident. Reporting a false alarm carries no penalty and is always the right call over staying silent. The Security Operations team triages every report and closes out non-incidents quickly.

5. Severity Levels

[Company] classifies every incident into one of four severity levels, which determines who responds and how fast.

Because Security Operations coverage spans [Company]'s US, UK, EU, and India offices, Level 1 and Level 2 incidents are responded to at any time of day. Level 3 and Level 4 incidents are handled during business hours; anything urgent discovered outside business hours must be raised immediately by phone call to the on-call analyst rather than waiting for the next business day.

6. Escalation and Internal Reporting

The Security Operations on-call analyst escalates every Level 1 or Level 2 incident to the Incident Commander immediately upon classification, and the Incident Commander decides, within the first update, which additional response team members from Section 10 to bring in. Level 3 and Level 4 incidents are tracked through normal ticketing and summarized to the Incident Commander in the next scheduled update rather than escalated individually.

The CISO is briefed on all Level 1 incidents as soon as they are opened and receives a daily summary of Level 2 incidents. Executive leadership and, where the Board of Directors has a security or risk committee, that committee, are briefed on any incident that is likely to affect customers materially, trigger a regulatory notification duty, or attract media attention. Internal reporting must never wait for the incident to be fully resolved; stakeholders need early, honest updates even when facts are incomplete.

7. Incident Documentation

Every incident, regardless of severity, is logged in [Company]'s IT service management tool (or Appendix B's collection form where the tool is unavailable) from the moment it is first reported. The record must capture the initial report, every escalation, each action taken and by whom, evidence collected, and all internal and external communications sent.

Documentation continues throughout the incident, not just at the end, because notification deadlines and legal assessments depend on dates recorded early (such as when the incident was first detected or first assessed as a personal data breach). [Company] retains incident records for 3 years from closure, or longer where a legal hold, contract, or ongoing investigation requires it. The Incident Commander is responsible for confirming the record is complete before closing an incident.

8. Incident Response Process

8.1 Summary

[Company] follows a five-phase process for every incident: identify and triage it, contain it while assessing notification obligations in parallel, eradicate the root cause, recover normal operations, and review what happened afterward. Severity and available resources determine how many people and how much formality each phase involves, but the sequence and the requirement to assess notification duties during containment, not at the end, apply to every incident.

8.2 Detailed Process

Phase 1: Identification and Triage

1. Whoever detects or receives a report of a suspected incident logs it via [Company]'s IT service management tool or notifies the Security Operations on-call analyst through the team chat tool's incident channel.
2. The on-call analyst validates the report, assigns a severity level under Section 5, and opens an incident record.
3. The on-call analyst notifies the Incident Commander immediately for Level 1 and Level 2 incidents, and includes Level 3 and Level 4 incidents in the next scheduled summary.
4. The Incident Commander confirms which response team members from Section 10 are needed and opens a video call or dedicated incident channel to coordinate.

Phase 2: Containment and Notification Assessment

1. The team isolates affected systems, accounts, or network segments to stop further damage, using the access controls available in AWS, Azure, Google Cloud, and Okta as applicable.
2. The team preserves evidence, such as logs, system images, or memory captures, before taking any action that could destroy forensic data.
3. In parallel with containment, Legal Counsel and the Data Protection Officer assess whether the incident triggers a notification duty to a regulator, a customer, or affected individuals under Section 9.3, and record that assessment, its trigger, and its date in the incident record.
4. The Incident Commander updates the response team and, where required, executive stakeholders on containment status and any notification timelines identified.

Phase 3: Eradication

1. The team identifies and removes the root cause, such as malware, unauthorized access, or a misconfiguration.
2. The team applies patches, revokes compromised credentials, and closes exploited vulnerabilities.
3. The team confirms eradication through scanning, log review, or validation testing before moving to recovery.

Phase 4: Recovery

1. The team restores affected systems from clean backups or rebuilds them, prioritizing systems that support customer-facing services.
2. The team monitors restored systems closely for signs of recurring compromise.
3. The Incident Commander confirms with system owners that normal operations have resumed before closing the incident.

Phase 5: Post-Incident Review

1. The Incident Commander schedules a post-incident review within 10 business days of closure.
2. The team documents the root cause, timeline, response effectiveness, and lessons learned.
3. The team assigns corrective actions with owners and target dates, and tracks them to completion.
4. The CISO reports significant incidents and their lessons learned to executive leadership.

8.3 Incident Response Meeting Agenda

• Current severity level and status
• What is known, and what remains unknown
• Actions completed since the last update
• Blockers and resources needed
• Notification and legal obligation status
• Communications sent or planned, internal and external
• Next steps and owner assignments
• Time of the next update

9. Special Considerations

9.1 Internal Issues

Where an incident involves an employee, a contractor, or a member of the response team, the Incident Commander escalates directly to Human Resources and Legal Counsel and keeps the investigation confined to those who need to know. If the CISO or the Incident Commander is the subject of the incident, or is otherwise conflicted, the Deputy Incident Commander (Head of Security Operations) takes over leadership of the response.

9.2 Compromised Communications

Where the response team suspects that the primary incident channel, email, or identity provider may itself be compromised, the team switches immediately to phone calls or text messages among response team members, using the numbers in Appendix A, and avoids discussing sensitive details over any system suspected of compromise until it has been isolated or confirmed safe.

9.3 External Communications and Breach Reporting

[Company] processes personal data both as a processor on behalf of enterprise customers and as a controller for its own staff, contacts, and data it collects directly, and the notification duty differs depending on which role applies. Where [Company] processes data on behalf of a customer, its first duty is to notify that customer within the period its contract requires, so the customer can meet its own regulatory obligations; contracts often set shorter deadlines than the law, and Legal Counsel must confirm the applicable deadline for each affected customer. Where [Company] acts as controller, it must notify the relevant regulator and affected individuals itself, within the period the applicable law requires:

• Under GDPR and UK GDPR, [Company] notifies the relevant supervisory authority within 72 hours of becoming aware of a personal data breach, and affected individuals without undue delay where the breach is likely to result in high risk to them.
• Under each applicable US state's data breach notification law, the trigger and the notification period differ by state; Legal Counsel must confirm the requirements for every state involved before the deadline is set.
• Under the India DPDP Act, [Company] notifies the relevant regulator and affected individuals within the period the law requires; Legal Counsel must confirm the current requirement before responding.

Legal Counsel leads the assessment of which duties apply and coordinates the actual notifications; Communications leads messaging to customers, the press, and the public once Legal Counsel confirms what must be said and by when.

9.4 Mitigation and Remediation

The team applies immediate mitigations during containment to stop ongoing harm, then tracks longer-term remediation, such as patching, architecture changes, or process fixes, to closure through the incident record. The Incident Commander confirms that a mitigation has actually worked, through testing or monitoring, before marking the related action complete.

9.5 Cooperation with Customers, Data Controllers and Authorities

Where [Company] processes data on behalf of a customer that is itself a data controller, [Company] cooperates fully with that customer's own investigation and regulatory notifications, providing the information the customer needs promptly and in the format it reasonably requests. Where a regulator, law enforcement body, or auditor opens an inquiry related to an incident, Legal Counsel coordinates [Company]'s response and is the only function authorized to communicate with that authority on [Company]'s behalf.

10. Response Team Members

The Deputy Incident Commander (Head of Security Operations) leads the response whenever the CISO or the primary Incident Commander is unavailable or is the subject of the incident.

11. Testing and Review

The Security Operations team runs a tabletop exercise at least twice each year, and includes Legal Counsel, the Data Protection Officer, Communications, and representatives of affected business units in at least one exercise annually to test cross-functional coordination. [Company] reviews this plan at least once a year and after any significant incident, updating roles, contact details, and procedures to reflect lessons learned and any change to systems, regulations, or the response team.

12. Management Commitment

Executive leadership and the Board of Directors support this plan with the budget, staffing, and authority the response team needs to act quickly, including the authority to isolate systems or suspend services without prior sign-off during a Level 1 or Level 2 incident. The CISO reports on incident trends and the state of incident readiness to executive leadership and the Board at least annually.

13. Exceptions

Any deviation from this plan, such as skipping a phase or using an alternative process for a specific incident, requires the Incident Commander's approval at the time and must be documented in the incident record along with the reason.

14. Violations & Enforcement

Failure to report a suspected incident, to follow this plan, or to cooperate with an incident response is treated as a violation of [Company]'s information security policy and may result in disciplinary action, up to and including termination of employment or contract, consistent with [Company]'s HR and vendor management policies.

15. Appendix A: Contact Information Template

16. Appendix B: Incident Collection Form Template

• Date and time of detection
• Date and time reported
• Reported by (name and role)
• Severity level assigned
• Systems, applications, or data affected
• Description of the incident
• Indicators observed (logs, alerts, error messages)
• Initial containment actions taken and by whom
• Evidence preserved (location and description)
• Notification assessment outcome and trigger date, if applicable
• Regulators, customers, or individuals notified, and when
• Root cause identified
• Remediation actions and owners
• Date incident closed
• Post-incident review date and key findings

Disclaimer

This document is provided for informational purposes only and does not constitute legal advice. It is provided "as is", without warranty of any kind, express or implied, and no liability is accepted for any loss or damage arising from its use. It is used at your own discretion. Review it with a qualified adviser before adopting it.

[Company] Incident Response Plan

• Version: 1.0
• Owner: Operations Manager
• Approved by: Executive Director
• Effective date: [Effective date]
• Next review date: [Review date]

1. Purpose

This plan tells everyone at [Company] what to do when something goes wrong with the security of its systems or data. It sits beneath [Company]'s information security policy and turns that policy's principles into concrete steps: how to spot a problem, who to tell, how to contain it, and how to meet [Company]'s legal and contractual obligations to donors, beneficiaries, payment partners and regulators.

[Company] handles donor and beneficiary personal information, sensitive personal data, and payment card data collected through online donations. A fast, well-organized response protects the people it serves, limits financial and reputational harm, and satisfies the notification duties that come with handling this kind of data. This plan is written to be followed under pressure, so it favors short, clear steps over lengthy explanation.

2. Scope

This plan applies to all [Company] staff, volunteers, board members, and contractors, and to [Company]'s outsourced IT/security provider, wherever they work under [Company]'s hybrid model. It covers every system and dataset [Company] uses or relies on, including its Microsoft 365 environment, its online donation platform, and any other SaaS tool that stores or processes donor, beneficiary, staff, volunteer or payment information, regardless of where that tool's infrastructure is hosted.

3. Incident and Event Definitions

An "event" is anything observable happening on a system or network; most events are routine and harmless. An "incident" is an event that actually or potentially compromises the confidentiality, integrity or availability of [Company]'s data or systems, or that violates [Company]'s information security policy. Recognizing the difference quickly helps staff avoid both under-reacting to real problems and overwhelming the response team with noise.

Examples of events (usually no action needed beyond normal monitoring):

• A single failed login attempt.
• A routine antivirus scan completing normally.
• An expected software update or system restart.

Examples of incidents (must be reported):

• A lost or stolen laptop, phone or other device that can access [Company] systems or data.
• A phishing email that a staff member or volunteer clicked on or responded to.
• Unauthorized access to a Microsoft 365 account, the donation platform, or any system holding donor, beneficiary or payment data.
• Ransomware, malware, or other suspicious software on a [Company] device.
• Suspected or confirmed exposure of payment card data, sensitive personal data, or other personal information.
• Denial-of-service activity or unexplained system outages affecting [Company]'s ability to operate.

4. Incident Reporting

Any staff member, volunteer, board member or contractor who notices or suspects a security incident must report it immediately, no matter how minor it seems or how uncertain they are that it is really a problem. Reports go to the Incident Commander or [Company]'s outsourced IT/security provider at [Security contact email] or by phone at [Security contact phone number]. Do not wait for confirmation before reporting: early reporting, even of something that turns out to be nothing, gives [Company] the best chance of limiting harm.

Reporting a suspected incident that turns out to be a false alarm carries no penalty. [Company] would rather review ten false alarms than miss one real incident, and staff and volunteers must never be discouraged from reporting something that looks wrong.

5. Severity Levels

[Company] assigns every incident a severity level to determine how quickly it must respond and who needs to be involved.

[Company] operates during standard business hours, Monday through Friday. It has no around-the-clock security team, so no response target is set for evenings, weekends or holidays; any incident that appears urgent outside business hours must be raised immediately by phone call to the Incident Commander or the outsourced IT/security provider.

6. Escalation and Internal Reporting

Once a report is received, the Incident Commander (or the outsourced IT/security provider, if the report comes in through that channel) assigns a severity level and decides who else needs to be told. Critical and High severity incidents must be escalated to the Executive Director without delay, and to the Board of Directors where the incident is likely to affect donors, beneficiaries or [Company]'s ability to operate. Medium and Low severity incidents are tracked and reviewed by the Incident Commander but do not require immediate escalation beyond the response team.

Throughout an incident, the Incident Commander keeps a running internal update available to the response team and, for Critical and High severity incidents, to the Executive Director and Board. This internal reporting is kept separate from any external communication, which is handled under Section 9.3, so that internal coordination is never delayed by external messaging decisions.

7. Incident Documentation

Every reported incident, regardless of severity, must be logged using the Incident Collection Form template in Appendix B. The log captures what was reported, when, by whom, what was found, what actions were taken, and how the incident was closed. This record is what allows [Company] to demonstrate to auditors, customers, payment partners and regulators that it responded appropriately, and it is the basis for the lessons-learned review described in Section 8.

[Company] retains incident records for 3 years from the date the incident is closed. This period may be extended where a contract, an active legal matter, or advice from [External legal counsel] requires a longer retention period; the Incident Commander must confirm this on a case-by-case basis. Incident records and the contact list in Appendix A must remain reachable even if [Company]'s primary systems, including Microsoft 365, are unavailable, so a copy must be kept outside those systems.

8. Incident Response Process

8.1 Summary

[Company] responds to incidents in five phases: identifying and triaging the incident, containing it while assessing what must be reported and to whom, eradicating the cause, recovering normal operations, and reviewing what happened afterward. The steps below are short by design so they can be followed under pressure; the Incident Commander decides which steps apply to a given incident and in what order, based on its severity.

8.2 Detailed Process

Phase 1: Identification and Triage

1. Log the report in the Incident Collection Form (Appendix B) as soon as it is received.
2. Confirm whether the report describes an event or an incident, using the definitions in Section 3.
3. Assign a severity level using the table in Section 5.
4. Notify the Incident Commander and, based on severity, escalate per Section 6.
5. Assemble the relevant members of the response team from Section 10.

Phase 2: Containment

1. Take immediate steps to stop the incident from spreading or getting worse, such as isolating an affected device, disabling a compromised account, or revoking access tokens.
2. Preserve evidence before making changes wherever possible, for example by taking screenshots or exporting logs before resetting an account.
3. Identify what data and systems are affected, including whether donor, beneficiary, staff, volunteer or payment card data is involved.
4. Assess, together with the Privacy & Legal Advisor, whether the incident triggers any notification duty under Section 9.3. This assessment must start now, in containment, because most notification deadlines run from when the incident is discovered or classified, not from when it is fully resolved.
5. Record containment actions and the notification assessment in the incident log.

Phase 3: Eradication

1. Identify and remove the root cause of the incident, such as malware, a vulnerability, or a compromised credential.
2. Confirm with the outsourced IT/security provider that the cause has been fully removed from all affected systems.
3. Change any passwords, keys or access credentials that may have been exposed.
4. Update the incident log with the actions taken and their outcome.

Phase 4: Recovery

1. Restore affected systems and data from a known-good state, verifying integrity before returning them to normal use.
2. Monitor restored systems closely for signs that the incident is recurring.
3. Confirm with affected staff, volunteers or the outsourced IT/security provider that normal operations have resumed.
4. Send any external notifications identified in Phase 2 that have not already been sent, and confirm they were sent within their required deadlines.
5. Close the incident in the log once the Incident Commander confirms it is fully resolved.

Phase 5: Post-Incident Review

1. Hold an incident response meeting using the agenda in Section 8.3 within 10 business days of closing the incident.
2. Identify what worked, what did not, and what should change in [Company]'s controls, training or this plan.
3. Assign an owner and a deadline for each follow-up action.
4. Update the incident log with the outcome of the review and file it for the retention period set in Section 7.

8.3 Incident Response Meeting Agenda

• Summary of the incident: what happened, when, and how it was discovered.
• Timeline of detection, containment, eradication and recovery actions.
• Data and systems affected, and confirmation of any notifications sent.
• Root cause and how it was addressed.
• What worked well and what did not.
• Follow-up actions, owners and deadlines.
• Whether this plan, [Company]'s security controls, or staff/volunteer training need to change as a result.

9. Special Considerations

9.1 Internal Issues

Where an incident may involve wrongdoing by a staff member, volunteer or contractor, the Incident Commander must handle it with discretion, involve the Executive Director, and avoid alerting the individual concerned before evidence is preserved. If the Incident Commander is the person suspected of involvement, or is otherwise conflicted, the Executive Director takes over as Incident Commander for that incident.

9.2 Compromised Communications

[Company]'s primary channel for coordinating an incident is email through Microsoft 365. If an incident involves a suspected compromise of Microsoft 365 accounts, the response team must stop discussing the incident over email and switch to phone calls or WhatsApp, since these do not depend on the same accounts or provider. The outsourced IT/security provider must be asked to secure or reset affected Microsoft 365 accounts as part of containment before communication returns to email.

9.3 External Communications and Breach Reporting

[Company] collects donor, beneficiary, staff and volunteer data directly and decides how it is used, so [Company] itself is responsible for notifying individuals and regulators where a notification duty applies; it does not rely on a customer to do this for it.

• Individuals: Notify affected individuals as required by the data breach notification law of each affected individual's state of residence. These laws differ in what triggers the notification clock and how long [Company] has to notify, so the Incident Commander must identify the applicable state law(s) for each incident and confirm the deadline with [External legal counsel].
• State regulators: Notify the state attorney general or other state regulator where that state's law requires it, which is often only above a set number of affected residents.
• Payment card data: Where payment card data is or may be involved, notify [Payment processor / acquiring bank] within the period its merchant agreement requires, and cooperate with any card brand-required forensic investigation. This is a contractual duty, separate from the state law duties above.
• Contracts: Check donation platform, payment processor and other vendor contracts for their own notification deadlines, since these are often shorter than what the law requires.

Where [Company] is uncertain whether a notification duty applies, or what its deadline is, it must treat the situation as if a duty applies and confirm the position with [External legal counsel] without delay, rather than waiting until the incident is fully resolved.

9.4 Mitigation and Remediation

Mitigation and remediation actions, such as patching a vulnerability, rotating credentials, or reconfiguring a SaaS tool's security settings, must be carried out by or with the outsourced IT/security provider and recorded in the incident log. Where a review under Section 8.3 identifies a gap in [Company]'s controls, training or vendor configuration, the Incident Commander must assign an owner and a deadline to close that gap.

9.5 Cooperation with Customers, Data Controllers and Authorities

[Company] cooperates fully with law enforcement, state regulators, its payment processor, and any other party that requests information needed for its own investigation or notification obligations arising from the incident. Where a vendor or partner, such as the donation platform or payment processor, is itself investigating an incident affecting [Company]'s data, [Company] must provide the information that vendor reasonably needs, while continuing to run its own response under this plan.

10. Response Team Members

At [Company]'s size, some individuals hold more than one role below. Each role's entry names a backup to cover unavailability or a conflict of interest.

11. Testing and Review

[Company] runs a tabletop exercise, a walkthrough of a realistic incident scenario, at least once a year with the response team and the outsourced IT/security provider. This plan is reviewed at least once a year, and after any incident that reveals a gap in it, with updates approved by the Executive Director.

12. Management Commitment

The Executive Director and Board of Directors are committed to resourcing [Company]'s incident response capability, including its outsourced IT/security provider, and to supporting the response team's decisions during an active incident. This commitment includes making time and budget available for the annual test required under Section 11 and for any follow-up actions it identifies.

13. Exceptions

Any deviation from this plan during an actual incident must be approved by the Incident Commander, or by the Executive Director if the Incident Commander is unavailable or conflicted, and recorded in the incident log along with the reason for it.

14. Violations & Enforcement

Failure to report a suspected incident, or failure to follow this plan without an approved exception, may result in disciplinary action for staff, up to and including termination of employment, and may result in the end of a volunteer's engagement with [Company], consistent with [Company]'s information security policy.

15. Appendix A: Contact Information Template

This contact list must be kept up to date and stored somewhere reachable even if Microsoft 365 is unavailable, such as printed copies or a personal device.

16. Appendix B: Incident Collection Form Template

• Date and time the incident was discovered
• Date and time the incident was reported, and by whom
• Person receiving the report
• Description of the incident
• Systems, accounts and data types affected (including whether donor, beneficiary, staff, volunteer or payment card data is involved)
• Severity level assigned and the reason for it
• Response team members involved
• Containment actions taken and when
• Notification assessment outcome (whether any law or contract requires notification, and to whom)
• Eradication actions taken and when
• Recovery actions taken and when
• External notifications sent, to whom, and when
• Date and time the incident was closed
• Post-incident review date and key findings
• Follow-up actions, owners and deadlines

Disclaimer

This document is provided for informational purposes only and does not constitute legal advice. It is provided "as is", without warranty of any kind, express or implied, and no liability is accepted for any loss or damage arising from its use. It is used at your own discretion. Review it with a qualified adviser before adopting it.