SIAS-INC-01 Incident response plan, roles and escalation
- Mandatory
- Yes
- Severity
- High
- Applies
- All scopes
- SecurityInspect Verified profiles
- None
Control objective
When something goes wrong in the stated scope, people know how to report it, who leads the response, how fast it must be escalated and what steps to follow.
Testable requirement
- (a)The applicant shall maintain a written incident response plan for the stated scope, approved by the accountable executive, that covers: definitions of security event and security incident; severity levels with criteria; roles (incident lead, technical responders, communications, counsel liaison and executive decision-maker), each with a named primary and a named backup; detection sources and reporting routes; triage, containment, eradication and recovery steps; evidence preservation (SIAS-INC-03); notification decisions (SIAS-INC-04); when and how external incident response help is engaged; and post-incident review.
- (b)The applicant shall provide a documented channel through which workforce members and third parties with in-scope access can report a suspected incident, state the hours during which it is monitored, and acknowledge reports within a time the plan states.
- (c)The applicant shall maintain playbooks for at least three incident types chosen from its risk assessment, which shall include credential compromise and exposure of sensitive data.
- (d)The plan shall set escalation times. Incidents at the highest severity level shall reach the incident lead and the accountable executive within 1 hour of classification, and incidents at the second-highest level within 4 hours.
- (e)The applicant shall review the contact details in the plan at least every 6 months and keep a copy of the plan and contacts that can be reached if primary systems are unavailable.
- (f)The applicant shall review the plan at least every 12 months and after each incident at the two highest severity levels.
Applicability and scope
All scopes. It cannot be marked not applicable. SecurityInspect Verified profiles: not included.
Pass criteria
- 1.An approved plan contains every element in requirement (a) and reflects the current environment (A1, M1).
- 2.Every role has a named primary and backup, and every named person is active (A2).
- 3.Playbooks exist for at least three incident types, including credential compromise and exposure of sensitive data (M2).
- 4.The reporting-channel test was acknowledged within the time the plan states (A4, M4).
- 5.Escalation of incidents at the two highest severity levels in the look-back met the plan's times, or each miss is explained in the incident record (A3, M3).
- 6.Contacts were reviewed in the last 6 months, and a copy reachable when primary systems are down exists (A5, E5).
- 7.The plan was reviewed in the last 12 months and after each incident at the two highest severity levels (A5).
- 8.The interviewed workforce member described a reporting route that matches the plan (I3).
Severity
High. Standard escalation triggers apply; none is specific to this control.
Informative framework mappings
- HIPAA Security Rule
- §164.308(a)(6)(i), §164.308(a)(6)(ii)
- PCI DSS v4.0.1
- 12.10
- Trust Services Criteria
- CC7.3, CC7.4
- ISO/IEC 27001:2022
- A.5.24, A.5.26, A.6.8
- Theme (SecurityInspect wording)
- a documented, staffed response with escalation times
SIAS-INC-02 Incident response exercises
- Mandatory
- Yes
- Severity
- Medium
- Applies
- All scopes
- SecurityInspect Verified profiles
- None
Control objective
The people named in the plan have practised using it on a realistic scenario, and what the practice revealed has been fixed.
Testable requirement
- (a)The applicant shall hold an incident response exercise at least every 12 months, at minimum a facilitated tabletop, using a scenario relevant to the in-scope systems and drawn from the risk assessment or the playbooks.
- (b)At least four roles from the plan shall take part, including the incident lead and the accountable executive or a delegate.
- (c)At least every 24 months, the exercise shall include a technical component in which responders carry out real response steps on in-scope or representative systems (for example disabling a compromised account, isolating a host, rotating a key or retrieving logs for a time window).
- (d)The applicant shall complete an after-action report within 30 days, recording participants, scenario, timeline, what worked, gaps, and actions with owners and due dates, and shall track the actions to closure.
- (e)A real incident at one of the two highest severity levels that exercised the plan from detection to recovery, with a completed post-incident review, may count as the exercise for that 12-month period.
Applicability and scope
All scopes. It cannot be marked not applicable. SecurityInspect Verified profiles: not included. An initial applicant must hold at least one exercise before fieldwork starts.
Pass criteria
- 1.An exercise with a scenario relevant to the scope was held in the last 12 months, or a qualifying real incident took its place (A1, M1).
- 2.At least four plan roles took part, including the incident lead and the accountable executive or a delegate (A1).
- 3.A technical component with system records took place in the last 24 months (A3, E3).
- 4.An after-action report was completed within 30 days, with actions, owners and due dates (M2).
- 5.Every exercise action is closed or within its due date, and none is more than 90 days overdue without a recorded escalation (A2, M3).
- 6.In the observation or spot check, participants located the plan and described their role's first steps and escalation route (M4).
Severity
Medium. Standard escalation triggers apply; none is specific to this control.
Informative framework mappings
- HIPAA Security Rule
- No direct mapping
- PCI DSS v4.0.1
- 12.10
- Trust Services Criteria
- CC7.4
- ISO/IEC 27001:2022
- A.5.24
- Theme (SecurityInspect wording)
- regular exercises with tracked lessons
SIAS-INC-03 Incident records, evidence preservation and lessons learned
- Mandatory
- No
- Severity
- Medium
- Applies
- All scopes
- SecurityInspect Verified profiles
- None
Control objective
Every incident leaves a complete record, evidence from serious incidents is preserved so that it can be relied on later, and each serious incident leads to changes that reduce the chance of a repeat.
Testable requirement
- (a)The applicant shall record every security incident, and every event escalated for investigation, in a system that captures: a unique identifier; detection time and source; classification and severity; affected systems and data; a timeline of actions with times and time zone; decision-makers; containment, eradication and recovery steps; notification decisions (SIAS-INC-04); root cause; and closure date.
- (b)For incidents at the two highest severity levels, and for any incident that may involve unauthorized access to sensitive data, the applicant shall preserve relevant logs, disk or memory images, snapshots and other artifacts, record a SHA-256 hash for each and keep a chain-of-custody record, and shall place retention holds so that normal log retention does not delete relevant records.
- (c)The applicant shall maintain an evidence-preservation procedure stating who may collect evidence, which tools are used, where evidence is stored (access limited to named roles and protected against deletion) and how long it is kept (at least 12 months after closure, or longer where obligations or legal holds require).
- (d)The applicant shall complete a post-incident review within 30 days of closure for each incident at the two highest severity levels, identifying root cause and actions and tracking the actions to closure.
- (e)The applicant shall analyze incident trends at least every 12 months and present the analysis at management review (SIAS-GOV-05).
Applicability and scope
All scopes. It cannot be marked not applicable. SecurityInspect Verified profiles: not included. If no incident at the two highest severity levels occurred in the look-back, criteria 2 and 4 are assessed on the records of the SIAS-INC-02 technical component or of a demonstration under I2.
Pass criteria
- 1.Every incident in the look-back is recorded with all required fields. A field completed after the event is annotated with the date it was added (A1).
- 2.Every qualifying incident has preserved evidence with hashes and chain of custody, and the recomputed hashes match (A3, M3).
- 3.Access to the evidence store is limited to named roles and deletion is protected (A4).
- 4.A post-incident review was completed within 30 days of closure for each qualifying incident, with actions tracked (A2, M4).
- 5.A retention hold on a log source was demonstrated or is on record (E5).
- 6.An incident trend analysis was presented at a management review in the last 12 months.
- 7.No alert marked as an incident lacks an incident record (A5).
Severity
Medium. Standard escalation triggers apply; none is specific to this control.
Informative framework mappings
- HIPAA Security Rule
- §164.308(a)(6)(ii)
- PCI DSS v4.0.1
- 12.10
- Trust Services Criteria
- CC7.4, CC7.5
- ISO/IEC 27001:2022
- A.5.27, A.5.28
- Theme (SecurityInspect wording)
- complete records, preserved evidence, lessons applied
SIAS-INC-04 Notification obligations and stakeholder communication
- Mandatory
- Yes
- Severity
- High
- Applies
- All scopes (SIAS checks that obligations are identified and procedures exist; legal determinations stay with the applicant's counsel)
- SecurityInspect Verified profiles
- None
Control objective
When an incident may trigger a duty to tell someone (customers, individuals, regulators, partners or insurers), the applicant already knows the duty, the recipient and the deadline, and decides promptly with counsel involved.
Testable requirement
- (a)The applicant shall record in its SIAS-GOV-04 register the incident notification obligations that apply to the in-scope systems and data, such as state breach-notification laws, sector rules, customer contract clauses, business associate agreements, insurer conditions and payment-card acquirer requirements, each with its trigger, recipient, content requirements and deadline.
- (b)The applicant shall maintain a notification decision procedure that states who assesses whether an incident triggers an obligation, when counsel is engaged, who approves each notification, and how deadlines are tracked from the time of discovery.
- (c)The applicant shall maintain notification templates for customers, affected individuals and regulators, reviewed by counsel, and a current contact list for recipients that must be notified directly (for example customers with contractual notice clauses and the cyber insurer, if any).
- (d)The procedure shall name an approved spokesperson and control internal communications so that disclosure is coordinated.
- (e)The procedure shall include the SIAS program obligation on a certificate holder to notify SecurityInspect of a serious security incident affecting the certified scope within 72 hours of confirming that the scope is affected (see the SIAS renewal, suspension and revocation rules).
- (f)The applicant shall record each notification decision (notify or not, the reasoning, the approver and the time) in the incident record (SIAS-INC-03).
- (g)The applicant shall review the procedure, templates and contact list at least every 12 months.
Applicability and scope
All scopes (SIAS checks that obligations are identified and procedures exist; legal determinations stay with the applicant's counsel). It cannot be marked not applicable. SecurityInspect Verified profiles: not included. Breach-notification law, including the HIPAA Breach Notification Rule (45 CFR Part 164, Subpart D), is outside SIAS. SecurityInspect never decides whether a notification was legally required or legally sufficient.
Pass criteria
- 1.For each sensitive data type and each sampled contract with notice terms, the register records the trigger, recipient and deadline, or records who determined that no obligation applies (M1, M2).
- 2.The procedure names decision-makers, counsel engagement, approvals and deadline tracking from discovery, names a spokesperson, and includes the 72-hour notice to SecurityInspect (M4, E1).
- 3.Templates exist for customers, individuals and regulators, and counsel's review of them in the last 12 months is recorded (M3, A3).
- 4.No recorded obligation has a deadline shorter than the procedure's decision timeline without a specific handling rule for it (A1).
- 5.Every qualifying incident in the look-back has a recorded notification decision with reasoning, approver and time (A2, M5).
- 6.The walkthrough showed the roles and the deadline tracking working as the procedure describes (M4).
Severity
High. Standard escalation triggers apply; none is specific to this control.
Informative framework mappings
- HIPAA Security Rule
- §164.308(a)(6)(ii), §164.314(a)(2)(i)
- PCI DSS v4.0.1
- 12.10
- Trust Services Criteria
- CC2.3, CC7.4
- ISO/IEC 27001:2022
- A.5.5, A.5.26
- Theme (SecurityInspect wording)
- known notification duties, decided and recorded. Breach-notification law, including HIPAA Subpart D, is outside SIAS; SIAS checks that obligations are identified and procedures exist, not legal compliance
