Notifying the customer of an incident: the clause the question tests
How fast, by whom and by what route the customer hears about an incident that touches its data.
How the customer usually asks it
example"Describe your process for notifying customers of a security incident, including timeframes."
Anchor clauses
6 frameworks| Framework | Anchor clause |
|---|---|
| ISO/IEC 27001:2022 | 5.24 Information security incident management planning and preparation · 5.25 Assessment and decision on information security events · 5.26 Response to information security incidents |
| SOC 2 (Trust Services Criteria) | CC7.4 Responds to identified security incidents through defined procedures |
| SIG (Shared Assessments) | domain J Cybersecurity Incident Management |
| CSA Cloud Controls Matrix v4.0.1 | SEF-07 Security Breach Notification |
| HIPAA Security Rule (45 CFR 164) | 164.308(a)(6)(ii) Response and Reporting (Required) |
| GDPR, Regulation (EU) 2016/679 | Art. 33 Notification of a personal data breach to the supervisory authority |
Every framework that anchors this family is listed here; a register shows the ones ticked for the customer.
Evidence expected
The customer notification procedure with its clock, the named contact route, and the contract clause that fixes the period.
The clauses, with what an assessor asks for
ISO 27001 5.24 Information security incident management planning and preparationDefine incident roles, processes and readiness before an incident happens.
Where answers usually fall short: Roles are defined but not formally assigned or approved; Plans are outdated and lack version control
Source: ISO/IEC 27001:2022
ISO 27001 5.25 Assessment and decision on information security eventsTriage security events and decide which become incidents.
Where answers usually fall short: No documented triage steps; Decisions not recorded or lack timestamps
Source: ISO/IEC 27001:2022
ISO 27001 5.26 Response to information security incidentsRespond to incidents according to the documented procedures.
Where answers usually fall short: Plans not tested regularly; Incident logs incomplete or inconsistent
Source: ISO/IEC 27001:2022
SOC 2 CC7.4 Responds to identified security incidents through defined proceduresNamed, not quoted: the criteria text is not held in full here.
Where answers usually fall short: A response plan exists but no incident record shows it was followed; Containment recorded while the vulnerability that allowed the incident stays open
Source: SOC 2 (Trust Services Criteria)
SIG domain J Cybersecurity Incident ManagementWhat it asks for, in one line (the standard's own text is not quoted here):
Maintain an incident response capability with defined plans, classifications, escalation paths, communications protocols, evidence handling, lessons learned, and regulatory and customer notification procedures.
Where answers usually fall short: No tabletop exercises within 12 months; Customer notification timelines not tracked
Source: SIG (Shared Assessments)
CSA CCM SEF-07 Security Breach NotificationWhat it asks for, in one line (the standard's own text is not quoted here):
Notify affected parties of security breaches, including breaches reaching the organisation through its supply chain, within the timeframes set by service agreements, law and regulation.
Where answers usually fall short: Regulatory timeframes documented while contractual ones are not; Supplier breach not treated as a notifiable event for the organisation's own customers
Source: CSA Cloud Controls Matrix v4.0.1
HIPAA 164.308(a)(6)(ii) Response and Reporting (Required)Identify and respond to suspected or known incidents, mitigate harmful effects, and document incidents and their outcomes. NIST recommends linkage to HIPAA Breach Notification Rule timelines.
Where answers usually fall short: Incident closure without root cause; Breach risk assessment not performed
Source: HIPAA Security Rule (45 CFR 164)
GDPR Art. 33 Notification of a personal data breach to the supervisory authorityOn becoming aware of a personal data breach, notify it to the competent supervisory authority without undue delay and, where feasible, not later than 72 hours after becoming aware, unless the breach is unlikely to result in a risk to the rights and freedoms of natural persons; a notification made later than 72 hours must be accompanied by the reasons for the delay. A processor must notify its controller without undue delay after becoming aware of a breach. The notification must at least describe the nature of the breach including, where possible, the categories and approximate number of data subjects and of personal data records concerned, give the name and contact details of the data protection officer or other contact point, describe the likely consequences, and describe the measures taken or proposed including any measures to mitigate adverse effects. Information may be provided in phases where it cannot all be given at once. Document every personal data breach, including the facts, its effects and the remedial action taken, so the supervisory authority can verify compliance with this Article.
Where answers usually fall short: The awareness clock started at the end of the investigation rather than at the point of reasonable certainty that a breach had occurred; Breaches judged not notifiable with no documented assessment, leaving nothing for the authority to verify under Article 33(5)
Source: GDPR, Regulation (EU) 2016/679