1. Purpose and Scope
Northwind Health (sample) is a Healthcare SaaS provider serving customers whose data includes Protected Health Information (PHI) and customer Personally Identifiable Information (PII). This Incident Management Policy establishes the framework for identifying, reporting, triaging, containing, eradicating, recovering from, and learning from information security incidents. It is designed to satisfy the requirements of ISO/IEC 27001:2022 Clause 8.1 (Operational Planning and Control), Clause 10.1 (Nonconformity and Corrective Action), and Annex A control A.5.24 (Information Security Incident Management Planning and Preparation), which requires the organization to plan and prepare for managing information security incidents by defining responsibilities, establishing procedures, and ensuring resources are available.
This policy applies to all employees, contractors, interns, and third parties accessing Northwind Health (sample) systems, data, or facilities ("Personnel"). It covers all information assets processed, stored, or transmitted by Northwind Health (sample), including but not limited to production infrastructure hosted in Amazon Web Services (AWS), source code and pipelines in GitHub and GitHub Actions, identity and collaboration services in Google Workspace, endpoint devices managed via Kandji, communication channels in Slack, monitoring and detection signals in Datadog, and HR records maintained in Gusto.
The objectives of this policy are to: (a) provide a consistent, repeatable process for responding to incidents in alignment with ISO/IEC 27001:2022 Clause 6.1.2 (Information Security Risk Assessment), which requires the organization to define and apply an information security risk assessment process that identifies risks associated with the loss of confidentiality, integrity, and availability of information; (b) define severity levels that reflect the potential impact to PHI, customer PII, and business operations; (c) assign clear roles and responsibilities for the Security Incident Response Team (SIRT); (d) ensure that evidence is collected and preserved in a forensically sound manner; and (e) drive continuous improvement through post-incident reviews that inform the Information Security Management System (ISMS) in accordance with ISO/IEC 27001:2022 Clause 10.2 (Continual Improvement). This policy is further supported by Annex A control A.5.25 (Assessment of and Decision on Information Security Events), which requires the organization to assess information security events and determine whether they should be classified as information security incidents.
2. Incident Classification
Northwind Health (sample) classifies security incidents into four severity levels, SEV 1 through SEV 4, based on the potential or actual impact to the confidentiality, integrity, and availability of PHI, customer PII, and critical business services. This classification framework directly supports ISO/IEC 27001:2022 Annex A control A.5.24, which mandates that the organization establish criteria for classifying incidents and assign appropriate response priorities, and Annex A control A.5.25, which requires a structured assessment of information security events to determine their severity and appropriate response.
| Severity | Definition | Examples | Initial Response Target |
|---|---|---|---|
| SEV 1, Critical | Confirmed breach involving PHI or customer PII; active data exfiltration; complete loss of production service availability; ransomware encryption of production systems; unauthorized administrative access to AWS production accounts or core customer data repositories. | Data leak of patient records to an unauthorized third party; production database exposed publicly with confirmed unauthorized access; AWS root account compromise. | Immediate mobilization; SIRT Lead notified within 15 minutes; containment initiated within 1 hour. |
| SEV 2, High | Suspected compromise with potential impact on PHI or PII; partial degradation of production service; unauthorized access to non-production but sensitive systems; credential compromise for a privileged user without confirmed data access. | Phishing credential submission by an employee with administrative access; exposed AWS S3 bucket containing PHI with no confirmed download; GitHub Actions token leakage with uncertain impact. | SIRT Lead notified within 1 hour; containment initiated within 4 hours. |
| SEV 3, Medium | Security event with limited scope; isolated malware on a single endpoint without lateral movement; minor vulnerability actively exploited with no sensitive data impact; non-compliance with policy that does not expose PHI or PII. | Malware detected and isolated by Kandji on a single employee laptop; misconfigured security group exposing a non-sensitive development service. | Response initiated within 1 business day. |
| SEV 4, Low | Informational events, policy deviations with minimal risk, or unconfirmed suspicious activity requiring investigation; security observations that do not constitute an active incident. | Spam or phishing email reported by a user without credential submission; unsuccessful brute-force attempt blocked by AWS WAF; minor security misconfiguration. | Triage and assessment within 3 business days. |
Incident categorization shall be recorded using the following taxonomy: Type (Malware/Ransomware, Unauthorized Access, Data Breach/Exfiltration, Denial of Service, Phishing/Social Engineering, Insider Threat, Misconfiguration, Lost/Stolen Asset, Other), Vector (Email, Web Application, API, Network, Physical, Human Error, Supply Chain/Third Party), and Affected Asset (Production AWS Environment, GitHub Repository, Google Workspace Account, Endpoint Device, Third-Party Service). This structured categorization supports the incident metrics and trend analysis required by ISO/IEC 27001:2022 Clause 9.1 (Monitoring, Measurement, Analysis, and Evaluation) and enables the organization to identify recurring patterns and systemic weaknesses.
Reclassification of an incident's severity may occur at any time as new information becomes available. The Security Officer, in consultation with the SIRT Lead, has the authority to adjust severity upward or downward, and any changes must be documented within the incident record within 24 hours of the adjustment.