Incident response: who owns it on each service model
Detecting, reporting and handling an incident. Always both sides: the provider must tell you, you must tell the provider, and each runs its own response.
The split by service model
| Service model | Owner | Why, and the clause |
|---|---|---|
| Infrastructure as a service | shared | Both sides respond: the provider must report incidents affecting your data within the agreed time, and you must detect and handle incidents in what you run and report to the provider what affects its service. ISO/IEC 27017 16.1.2 |
| Platform as a service | shared | Both sides respond: the provider must report incidents affecting your data within the agreed time, and you must detect and handle incidents in what you run and report to the provider what affects its service. ISO/IEC 27017 16.1.2 |
| Software as a service | shared | Both sides respond: the provider must report incidents affecting your data within the agreed time, and you must detect and handle incidents in what you run and report to the provider what affects its service. ISO/IEC 27017 16.1.2 |
| Serverless functions and event services | shared | Both sides respond: the provider must report incidents affecting your data within the agreed time, and you must detect and handle incidents in what you run and report to the provider what affects its service. ISO/IEC 27017 16.1.2 |
| Hosted AI models and AI platforms | shared | Both sides respond: the provider must report incidents affecting your data within the agreed time, and you must detect and handle incidents in what you run and report to the provider what affects its service. ISO/IEC 27017 16.1.2 |
The clauses each framework attaches
7 quoted| Framework | Clause |
|---|---|
| Cloud Controls Matrix v4.0.1 | CCM-SEF-07 Security Breach Notification |
| ISO/IEC 27017:2015 | ISO/IEC 27017 16.1.2 Reporting information security events |
| ISO/IEC 27018:2019 | ISO/IEC 27018 A.10.1 Notification of a data breach involving PII |
| SOC 2 Trust Services Criteria | SOC 2 CC7.4 Responds to identified security incidents through defined procedures |
| ISO/IEC 27001:2022 Annex A | ISO/IEC 27001 5.26 Response to information security incidents |
| CMMC 2.0 | CMMC IR.L2-3.6.2 Incident Reporting |
| C5 cloud criteria catalogue | C5-OPS-21 Involvement of Cloud Customers in the Event of Incidents |
CCM-SEF-07 Security Breach NotificationNotify affected parties of security breaches, including breaches reaching the organisation through its supply chain, within the timeframes set by service agreements, law and regulation.
- The breach notification procedure with the timeframes from each obligation
- The obligations register showing notification requirements per jurisdiction and contract
- Notification records for actual breaches with timestamps
- Evidence supply chain breaches are captured and assessed for notification
- Regulatory timeframes documented while contractual ones are not
- Supplier breach not treated as a notifiable event for the organisation's own customers
- Notification decision made without legal input and recorded only informally
ISO/IEC 27017 16.1.2 Reporting information security eventsThe provider should give the customer a mechanism to report information security events it observes in the cloud service, and should report to the customer events and incidents affecting the customer's information within the agreed time. The customer should report to the provider events it detects that may affect the service, and should tell its own users how to report events involving cloud services.
- Provider reporting channel and notification commitment
- Customer procedure for reporting events to the provider
- Records of events reported in each direction
- Incident notification obligation in the contract with no working contact behind it
- Customer users unaware that cloud service events should be reported
ISO/IEC 27018 A.10.1 Notification of a data breach involving PIIThe public cloud PII processor should promptly notify the relevant cloud service customer in the event of any unauthorised access to PII or unauthorised access to processing equipment or facilities resulting in loss, disclosure or alteration of PII, within the period and with the content agreed in the contract, and should cooperate in the customer's response.
- Breach notification procedure with contractual timescales
- Notification records
- Evidence of cooperation with customer investigations
- Breach determination left to the customer with no processor assessment
- Notification sent after the customer's own regulatory deadline
SOC 2 CC7.4 Responds to identified security incidents through defined proceduresExecutes a defined incident response program once a security incident is identified, with roles and responsibilities assigned, the nature and severity of the incident understood, the active threat contained and mitigated, the underlying vulnerability remediated, operations restored to a state that meets objectives, and the incident and the actions taken communicated to affected parties, with the effectiveness of the response evaluated periodically.
- Incident response program naming roles, escalation paths and the use of external resources
- Incident tickets carrying detection, containment, eradication and recovery timestamps
- Severity assessment and containment strategy record for individual incidents
- Remediation records tying each incident to closure of the underlying vulnerability
- Records of communication to affected parties and, where privacy is in scope, to data subjects and regulators
- Periodic evaluation or exercise of the response program with resulting changes
- A response plan exists but no incident record shows it was followed
- Containment recorded while the vulnerability that allowed the incident stays open
- No evidence that affected parties were told anything
- Effectiveness never evaluated, so the same root cause recurs across periods
- Roles named in the plan no longer match the people who actually respond
ISO/IEC 27001 5.26 Response to information security incidentsRespond to incidents according to the documented procedures.
- Incident response plan
- Incident handling records
- Post incident analysis
- Stakeholder communication
- Plans not tested regularly
- Incident logs incomplete or inconsistent
- No formal post‑incident review process
- Communication with affected parties delayed
CMMC IR.L2-3.6.2 Incident Reporting Level 2Track, document and report incidents to the designated internal officials and to external authorities where required.
- Incident register with tracking and documentation per incident
- Defined internal officials and external reporting obligations
- Evidence of reports made within required timeframes
- External reporting obligations unidentified
- Incidents handled informally and never documented
- Reporting timeframes undefined so notifications are late
C5-OPS-21 Involvement of Cloud Customers in the Event of IncidentsKeep affected cloud customers informed at regular intervals on the status of incidents concerning them, involve them in resolution where appropriate and necessary, and tell them what action was taken once the incident is resolved, all as the contract provides.
- Notification timeline for a sampled incident showing each update issued to the customer
- Contractual communication commitments listing notification intervals and channels
- Status page history or portal notices published for the same incident
- Closure notice describing the actions taken and any customer follow up required
- Customers told at the start and at closure with nothing in between during a long incident
- Only the technical contact notified while the contractual escalation contact is missed
- Closure message omits what was actually done, leaving the customer nothing to act on
- Notification intervals promised in the contract absent from the incident procedure