INC-006 Customer Incident and Cyber Threat Notification
Description
A documented process notifies affected customers of security incidents that affect the confidentiality, integrity or availability of their data or service. Notification timelines, communication channels and required content are defined. Where the organisation processes personal data on a customer's behalf, the customer is notified of a personal data breach without undue delay after the organisation becomes aware of it, whatever longer timeline the contract allows. Notification decisions and the content of each communication are recorded. The process names, for each customer commitment and each regulation that binds the service, the events that trigger a notification to that customer and the period within which it is owed, measured from the point at which the organisation became aware. Those triggers include events wider than an effect on the customer's data or service where a commitment makes them notifiable, among them an attempted unauthorised access, use, disclosure, modification or destruction and an interference with system operations that changed nothing. Each notification record carries the date of awareness, the date sent and the period it was measured against. Where the service is affected by a significant cyber threat that could affect customers, those customers are told without undue delay of the measures or remedies available to them, and the record of each advisory states whether the threat itself was disclosed and why. The process states the assistance available to an affected customer during that customer's own response and the point of contact for it, and the basis on which that assistance is charged is fixed before an incident rather than quoted during one.
Rationale
Customer notification is both a contractual and reputational obligation, distinct from regulatory notification. Many enterprise contracts specify notification timelines shorter than those required by regulation. Three things sit behind the additions. Stating the trigger and the period per commitment lets one process serve a contract that asks for any attempted event alongside a regulation that asks only for an effect, without the description becoming a schedule of clocks that goes stale with the next instrument; INC-005 uses the same device for statutory reporting and the profile row carries each regime's figure. An advisory fires before anything has happened, so the register distinguishes it from a notification and records whether the threat itself was disclosed, which is a judgement about arming an attacker and has to be visible. Assistance is a different thing from notification: a provider that says what happened and then bills the investigation at its prevailing professional services rate has notified and not assisted, which is why the charging basis is fixed in advance. Boundary: VND-011 announces a planned change to the shared responsibility boundary, APP-014 receives a vulnerability report inbound and MON-010 carries service state during a degradation in progress. None of the three is an outbound advisory about a threat that has not yet done anything.
Applicability (9 profiles)
The deployer is the customer notified. The provider's commitment is contracted under VND-002 and the deployer's own duties to data subjects and authorities run through INC-005. Where the deployer processes personal data for its own customers, the row is its own.
The deployer is the customer notified. The provider's commitment is contracted under VND-002 and the deployer's own duties to data subjects and authorities run through INC-005. Where the deployer processes personal data for its own customers, the row is its own.
Art. 30(2)(f) is now stated. The incident communication process names the assistance available to a customer during that customer's own response, the point of contact for it and the basis on which it is charged, with the basis fixed before an incident rather than quoted during one. The duty binds every contract, not only those covering critical or important functions.
The heaviest single addition in the overlay, now stated. The process names the notification triggers owed under each customer commitment and each regulation binding the service, expressly including an attempt that changed nothing, and names the period owed for each measured from the point of awareness, with every notification recorded against it. For a business associate those entries are 164.314(a)(2)(i)(C), every security incident it becomes aware of reported to the covered entity on the wide 164.304 definition, and the 164.410 clock it imports, without unreasonable delay and in no case later than 60 days after discovery. The control text carries the discipline; this row carries the figure.
Both outbound messages are now stated. Art. 23(1) requires recipients to be notified without undue delay of a significant incident likely to adversely affect the provision of the service, whether or not personal data is involved, which the control carries as a trigger and a period named per regulation that binds the service. Art. 23(2) is the second message on a different trigger, a significant cyber threat with the measures or remedies the recipient can take, and the control now holds the advisory and the recorded decision on whether the threat itself was disclosed.
Framework Mappings (11)
| SEF-08 | Security Breach Notification | partial |
| SEF-08 | Security Breach Notification | partial |
| DORA-Art.30.2.f | Incident assistance at no additional or ex-ante determined cost | full |
| EU-DA-Art.32.5 | Customer Notification of a Third-Country Request | informative |
| GDPR-Art.33.2 | Processor Notification of a Breach to the Controller | full |
| GDPR-Art.34.1 | Breach Communication to Data Subjects | informative |
| HIPAA-164.314.a.2.i.C | Business Associate Contract Security Incident Reporting Term | full |
| NIS2-Art.23.1 | Notification of Significant Incidents | partial |
| NIS2-Art.23.2 | Communication to Recipients on Significant Cyber Threats | full |
| P6.5 | Notification of Privacy Breaches | informative |
| P6.6 | Remediation of Privacy Breaches | informative |
Evidence (3)
Customer breach notification procedure defining notification timelines, communication channels, required content, and decision authority for customer-facing security incident communications.
Example: Customer Notification Procedure document or IRP section on customer communications (version-controlled, reviewed within last 12 months) with notification timeline commitments, approved communication templates, and escalation path to legal and PR
Test: Request the customer notification procedure. Verify: (1) notification timelines are defined for each severity level; (2) required communication content is specified; (3) the procedure references relevant contractual notification obligations; (4) a named role or function is responsible for approving customer notifications; (5) the procedure was reviewed within the last 12 months. (6) the procedure names the notification triggers and the period owed for each customer commitment and each regulation that binds the service, including any trigger wider than an effect on the customer's data or service; (7) it states the assistance available to a customer during that customer's own response, the point of contact for it and the basis on which it is charged, and that basis is stated rather than left to be quoted at the time.
Customer notification records from incidents where customer notification was required, demonstrating notifications were sent within defined timelines with required content.
Example: Customer notification email archive or incident record showing notification date, recipient list (customers affected), notification content, and timeline comparison against the contractual obligation, or a documented record confirming no customer-impacting incidents occurred in the review period
Test: Request customer notification records for any incidents in the last 12 months that met notification criteria. Verify: (1) notification was sent within the timeline defined in the procedure and/or applicable contracts; (2) notification content addressed the nature of the incident, impact, and remedial actions; (3) notification decisions (including decisions not to notify) are documented with rationale and a named decision-maker.
Customer notification register covering incident notifications and cyber threat advisories alike, with the trigger that applied, the decision taken and the content of each.
Example: Customer Notification Register 2026-H1, v4.2, exported 3 July 2026.
Test: Verify: (1) the register distinguishes an incident notification from a cyber threat advisory and records which trigger applied to each entry, (2) each entry carries the date of awareness, the date sent and the period it was measured against, and a period missed carries a recorded reason and a corrective action, (3) each advisory names the measures or remedies available to the recipient rather than only describing the threat, (4) each advisory records the decision on whether the threat itself was disclosed and the reason for it, (5) for at least one period in which a publicly disclosed vulnerability affected a component of the service, either an advisory exists or a recorded decision explains why none was needed, (6) where a commitment makes an attempted event notifiable, the register shows such an event notified or a recorded decision that none occurred in the period.
Questions (3)
Does your organisation have a documented process for notifying affected customers of security incidents?
Customer notification timelines are often defined in enterprise contracts at shorter intervals than regulatory requirements. The procedure should reference contractual obligations and include approved communication templates.
What is the standard customer notification timeline for a confirmed high-severity security incident affecting customer data?
Many enterprise contracts specify 24–72 hour notification timelines. A defined standard timeline shorter than or equal to the contractual obligation is the expected answer.
Which of the following does the customer communication process cover?
Options follow the process from the trigger to the help offered afterwards. Tick an item only where the process states it; a practice followed by the incident team but written down nowhere does not count here. The last two are the ones a customer in a regulated sector asks about first, because its own regulator gives it a clock it cannot meet without facts the provider holds.