Responsibilities and procedures

ISO/IEC 27018:2019 Clause 16.1.1 requires you to assign clear management ownership and documented procedures for incident response, including specific playbooks for PII breach notification. To operationalize it, define decision rights, escalation paths, notification triggers, and evidence capture so your response is fast, coordinated, and defensible under customer and regulatory expectations. ¹

Key takeaways:

• Name accountable incident leaders and back-ups, with documented authority to declare incidents and approve PII breach notifications.
• Maintain a PII-specific breach notification procedure that covers containment, customer communication, and regulatory reporting duties.
• Prove it works with retained artifacts: runbooks, call trees, incident logs, notification records, and post-incident reviews. ¹

“Responsibilities and procedures” sounds like paperwork until you fail an incident. ISO/IEC 27018:2019 Clause 16.1.1 is a requirement to turn incident response into an executable operating model: people with authority, documented workflows, and a PII breach notification process that can run under pressure. For cloud service providers acting as PII processors, this clause is where security operations meets contractual and privacy obligations. ¹

Compliance owners usually inherit fragments: a SOC runbook, a legal escalation list, a generic “incident policy,” and customer contract commitments scattered across sales folders. This requirement forces consolidation. The outcome you want is simple: any responder can identify a likely PII breach, escalate it correctly, contain it quickly, and trigger a controlled notification process with the right approvals and documentation.

This page translates the clause into an implementation checklist you can run with your security, privacy, legal, and customer teams. It also covers evidence to retain and the exam questions that tend to stall teams. ¹

Regulatory text

Requirement (ISO/IEC 27018:2019 Clause 16.1.1): “Management responsibilities and procedures shall be established to ensure a quick, effective and orderly response to information security incidents, with specific procedures for PII breach notification.” ¹

What the operator must do:
You must (1) assign management-level responsibility and decision rights for incident response, (2) document procedures that drive a coordinated response, and (3) create explicit procedures for PII breach notification that address customer notification obligations, regulatory reporting requirements, and breach containment. ¹

Plain-English interpretation

This clause expects you to run incidents like an operational discipline, not an ad hoc scramble. “Quick, effective and orderly” translates into:

• Quick: responders know who to call, what to do first, and how to escalate without waiting for a meeting.
• Effective: containment and investigation steps are defined and repeatable.
• Orderly: decisions are documented, approvals are clear, communications are controlled, and evidence is preserved.

The PII breach notification piece is the differentiator. A generic security incident process is not enough; you need a PII-aware path that can answer: “Do we have a PII breach?”, “Who must we notify (customers, regulators)?”, and “What do we say and when?” ¹

Who it applies to

Entity scope: Cloud Service Providers acting as PII processors. ¹

Operational context where auditors focus:

• You process customer PII in multi-tenant systems or managed services.
• You rely on multiple internal teams (SOC, SRE/infra, app engineering, privacy/legal, customer support).
• You use third parties in the delivery chain (subprocessors, monitoring providers, managed detection) that affect evidence collection and notification content.

What you actually need to do (step-by-step)

1) Assign “incident management responsibilities” with real authority

Create an incident governance model with named roles, decision rights, and backups.

• Incident Commander (IC): authority to declare an incident, set severity, pull resources.
• Security lead/SOC lead: triage, investigation coordination, evidence handling.
• Privacy/PII lead: determines whether impacted data is PII and which customers are affected.
• Legal/contract lead: maps notification commitments to customer contracts and regulatory expectations.
• Comms/customer lead: controls outbound messaging, customer ticketing, status pages where applicable.
• Executive sponsor: unblocker for high-impact events.

Artifact: RACI matrix + on-call roster/call tree covering after-hours escalation. Keep it current.

2) Document an incident response procedure that is runnable

Write a procedure that an on-call team can follow. Minimum elements:

• Incident definition and severity criteria (include “suspected PII exposure” as a trigger for heightened handling).
• Escalation steps (who is paged at each severity, what information is required).
• Containment options (isolation, credential rotation, disabling access paths).
• Investigation workflow (log sources, forensics steps, chain-of-custody approach).
• Internal communications cadence (war room setup, update intervals, stakeholder list).
• Decision log requirement (what must be documented, by whom).

Operator tip: keep the “policy” short, and put the operational steps in runbooks/playbooks.

3) Build specific procedures for PII breach notification

This is the part that tends to be vague. Make it explicit.

Your PII breach notification procedure should include:

• Trigger criteria: what constitutes a “PII breach scenario” in your environment (confirmed access, credible exfiltration evidence, misconfiguration exposing PII, lost encryption keys, etc.). ¹
• Triage questions:
  • What PII categories were potentially involved?
  • Which tenants/customers?
  • Is data encrypted, and are keys potentially compromised?
  • Was access authenticated, privileged, or anomalous?
• Notification decision workflow: who recommends notification, who approves, and who sends.
• Regulatory reporting requirements mapping: a maintained mapping from key jurisdictions/commitments to reporting expectations (don’t guess during an incident). ¹
• Customer notification obligations mapping: tie the procedure to your contract templates, DPAs, and security addenda so you can quickly determine required recipients and content. ¹
• Message control: approved templates, review process, and a single outbound channel owner to prevent inconsistent communications.
• Containment before notification: define what “minimum containment” looks like so you aren’t notifying while the breach is still actively expanding. ¹
• Subprocessor coordination: how you obtain facts/evidence quickly if a third party is involved, including who engages them and what you demand (timeline, indicators, affected data). Keep it procedural.

Practical tooling note: If you’re using Daydream to run third-party risk and due diligence, store subprocessor incident obligations, breach notification contacts, and evidence request checklists in the third-party record so incident response doesn’t start with contract archaeology.

4) Train and test the procedures (tabletops + after-action)

A procedure that hasn’t been tested is a document, not a control.

• Run tabletop scenarios that include a PII breach decision point and customer notification drafting.
• Capture gaps as corrective actions and assign owners and due dates (without overcomplicating the governance).

Artifact: tabletop agenda, attendee list, scenario narrative, decisions made, corrective action register.

5) Make evidence retention part of the process, not a clean-up task

Add “evidence pack” creation to the incident checklist:

• preserve relevant logs
• preserve copies of notifications
• preserve the decision trail (why you notified or why you didn’t)

This supports later audits, customer inquiries, and any dispute over contract performance.

Required evidence and artifacts to retain

Keep artifacts in a controlled repository with access logging where feasible.

Core documents

• Incident Response Policy (high-level)
• Incident Response Procedures / Runbooks (operational steps)
• PII Breach Notification Procedure (separate or clearly sectioned)
• RACI and escalation call tree (with backups)
• Contract/DPA obligation mapping for notification and reporting (maintained)

Operational records

• Incident tickets/case records (timestamps, severity changes, assignees)
• War room notes and decision log
• Forensic/evidence handling records (what was collected, where stored, who accessed)
• Customer and regulator notification records (final content, recipients, timestamps)
• Post-incident review report + corrective action tracking

Common exam/audit questions and hangups

Expect these questions, and prepare evidence that answers them fast:

1. Who can declare a security incident, and who can declare a PII breach? Show named roles and decision rights.
2. Show me the procedure used for the last incident. Auditors want the “as executed” workflow, not just the policy.
3. How do you decide whether notification is required? Point to trigger criteria, triage questions, and approval steps. ¹
4. How do you meet customer notification obligations? Produce the obligation mapping and example notifications. ¹
5. How do subprocessors fit into your process? Provide a subprocessor contact list and evidence request checklist.

Hangup to anticipate: teams often cannot show a maintained link between contract commitments and incident procedures. Fix this by making legal/CCO accountable for the mapping artifact and updating it with every contract template change.

Frequent implementation mistakes and how to avoid them

• Mistake: “Incident response” owned by security only.
  Fix: document management responsibilities that include privacy, legal, and customer communication owners, with backups. ¹

• Mistake: PII breach notification reduced to a template email.
  Fix: require trigger criteria, decision workflow, and evidence requirements in the procedure. ¹

• Mistake: No decision log.
  Fix: add a mandatory “decision record” step in the runbook, including rationale for notify/no-notify.

• Mistake: You can’t identify affected customers quickly.
  Fix: predefine tenant/PII scoping steps and required telemetry sources as part of investigation.

• Mistake: Subprocessor incident facts arrive late and incomplete.
  Fix: pre-negotiate incident cooperation expectations and keep an evidence request checklist in your third-party file (this is where Daydream can reduce scramble by centralizing third-party obligations and contacts).

Enforcement context and risk implications

No public enforcement cases were provided for this requirement in the source catalog, so you should treat enforcement risk as indirect: failure here increases the likelihood of delayed response, inconsistent notification, and contractual breaches. The operational risk is also straightforward: unclear responsibilities cause delays; unclear procedures cause errors; weak evidence capture makes outcomes hard to defend.

Practical execution plan (30/60/90)

You asked for speed. This plan focuses on shippable artifacts and tested workflows.

First 30 days (Immediate stabilization)

• Assign incident management roles and backups; publish an escalation call tree.
• Inventory current incident response documents, runbooks, and customer notification clauses.
• Draft or update a single incident response procedure that includes evidence capture steps.
• Stand up a “PII breach notification” addendum: triggers, approvals, customer comms owner, and where templates live. ¹

By 60 days (Operational readiness)

• Build the contract/DPA notification obligation mapping for your standard offerings.
• Run a tabletop that forces a PII breach notification decision; capture corrective actions.
• Create an incident evidence pack checklist and integrate it into your ticketing workflow.
• Confirm subprocessor incident contacts and cooperation steps are documented in third-party records.

By 90 days (Prove repeatability)

• Close or formally accept the top corrective actions from the tabletop.
• Run a second exercise, this time including a third party/subprocessor fact pattern.
• Audit your own evidence: pick any recent incident and verify you can reconstruct timeline, decisions, and communications from retained artifacts.
• Operationalize maintenance: assign owners for quarterly review of call trees, templates, and obligation mappings (set a cadence that matches your change rate).

Frequently Asked Questions

Do we need a separate incident response policy and procedure?

ISO/IEC 27018:2019 Clause 16.1.1 requires “responsibilities and procedures,” so auditors typically expect both a governance document and runnable steps. You can combine them if the final document remains clear and operational. ¹

What makes the “PII breach notification procedure” different from standard incident comms?

It must explicitly address PII breach scenarios, including customer notification obligations, regulatory reporting requirements, and containment steps tied to PII exposure. Generic “security incident communication” language rarely covers those decision points. ¹

Who should approve sending a breach notification?

Define this in your procedure and align it to your operating model; common approvers include privacy/legal and an executive incident sponsor, with security providing the factual basis. What matters for the requirement is that approval responsibility is pre-assigned and documented. ¹

How do we handle incidents that involve a third party/subprocessor?

Add a subprocessor track to the runbook: who engages the third party, required facts to collect, and how their inputs feed your PII breach notification decision. Keep contacts and contractual cooperation obligations easy to retrieve during an incident.

What evidence do auditors ask for most often?

They usually ask for the written procedures, proof of assigned responsibilities, and proof the process ran: incident tickets, decision logs, notification records, and post-incident reviews. Retain artifacts in a way that allows you to reconstruct timeline and decision-making.

We have few incidents. How do we prove the control works?

Use tabletop exercises with documented outputs: scenarios, attendees, decisions, and corrective actions. This demonstrates your ability to execute “quick, effective and orderly” response even without frequent real incidents. ¹

Footnotes

1. ISO/IEC 27018:2019 Information technology — Security techniques — Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors