{"description":"Personal-data breach response, anchored on a breach-register Issue item created for the breach (issue_type: exception, source: management_identified, identified_date = the awareness timestamp); the workflow instance attaches to that Issue and the breach register is the queryable set of these Issues. Consumes the Incident Management Lifecycle workflow's handoff package (incident record, containment status, investigation timeline) and drives it from handoff to closure: a frozen, dated exposure inventory; a per-jurisdiction notifiability determination against GDPR Article 33, US state (California/CCPA included), and HIPAA clocks; regulator and data-subject notifications with milestone tracking; processor coordination against the processor's Vendor record and DPA; remediation and support Issue items; the Article 33(5) breach-register entry; and a post-breach review that hands off to the DPIA / Privacy Impact Assessment workflow for each affected processing activity. In scope: the notifiability judgment and notification execution downstream of the incident handoff; out of scope: incident containment and forensics, which stay with incident response.","edges":[{"id":"e-determine-breach-origin-coordinate-with-processor","label":"Processor origin","source":"determine-breach-origin","target":"coordinate-with-processor","whenValue":"processor_originated"},{"id":"e-determine-breach-origin-assess-risk-of-harm","label":"Internal origin","source":"determine-breach-origin","target":"assess-risk-of-harm","whenValue":"internal_systems"},{"id":"e-scope-personal-data-exposure-coordinate-with-processor","source":"scope-personal-data-exposure","target":"coordinate-with-processor"},{"id":"e-coordinate-with-processor-assess-risk-of-harm","source":"coordinate-with-processor","target":"assess-risk-of-harm"},{"id":"e-scope-personal-data-exposure-assess-risk-of-harm","source":"scope-personal-data-exposure","target":"assess-risk-of-harm"},{"id":"e-assess-risk-of-harm-notify-regulators","label":"Notifiable","source":"assess-risk-of-harm","target":"notify-regulators","whenValue":"notifiable"},{"id":"e-notify-regulators-decide-data-subject-notice","source":"notify-regulators","target":"decide-data-subject-notice"},{"id":"e-assess-risk-of-harm-post-breach-review","label":"Not notifiable","source":"assess-risk-of-harm","target":"post-breach-review","whenValue":"not_notifiable"},{"id":"e-decide-data-subject-notice-notify-data-subjects","label":"Notify individuals","source":"decide-data-subject-notice","target":"notify-data-subjects","whenValue":"notice_required"},{"id":"e-decide-data-subject-notice-implement-remediation-and-support","label":"No individual notice","source":"decide-data-subject-notice","target":"implement-remediation-and-support","whenValue":"notice_not_required"},{"id":"e-notify-data-subjects-implement-remediation-and-support","source":"notify-data-subjects","target":"implement-remediation-and-support"},{"id":"e-notify-regulators-implement-remediation-and-support","source":"notify-regulators","target":"implement-remediation-and-support"},{"id":"e-implement-remediation-and-support-post-breach-review","source":"implement-remediation-and-support","target":"post-breach-review"}],"isPublic":true,"metadata":{"capabilities":[],"controlVerbs":{},"controls":["UC-IR-05","UC-IR-08","UC-IR-10","UC-LOG-06","UC-DATA-15","UC-DATA-16"],"department":"privacy","domains":["reg"],"library":{"aliases":[],"canonicalUrl":"https://workflow-library.com/all/?w=reg-privacy-breach-notification","contentDigest":"sha256:b6d82ac360dbc52b9d28da072da02bf71b207adfa96d8d8119353ae4692a80e4","prerequisites":{"status":"undeclared"},"provenance":[],"releaseId":"sha256:b6d82ac360dbc52b9d28da072da02bf71b207adfa96d8d8119353ae4692a80e4","schemaVersion":1,"sourceTemplateId":"workflow-library:reg-privacy-breach-notification"},"lineOfDefense":"operate","mappingStatus":"mapped","risks":[],"slug":"reg-privacy-breach-notification","source":"coworkcanvas-gallery","standards":["gdpr","hipaa","ccpa"],"teams":["privacy","it"]},"name":"Privacy Breach Assessment & Notification","nodes":[{"data":{"description":"Agent anchors the awareness clock and controller/processor role from the incident handoff, then builds the exposure inventory by data category, volume, subject group, and jurisdiction; the privacy lead and team confirm the timestamp, roles, and inventory against investigation evidence","instructions":"**Objective** — Open the breach assessment from the incident-response handoff with a defensible awareness timestamp anchored — every statutory notification clock, GDPR's 72 hours first among them, counts from it — then establish exactly which personal data was exposed, whose, in what volumes, and in which jurisdictions, so notifiability can be judged statute by statute from a frozen fact base.\n\n**Inputs**\n- The handoff package from the Incident Management Lifecycle workflow, consumed as a document on this step: the incident record (that workflow's anchor Issue, linked here), containment status, affected systems and accounts, and the investigation timeline.\n- The data inventory and records of processing (RoPA) for the affected systems — data elements, subject categories, storage locations — uploaded as a PBC/extract on this step; the affected processing activities are existing Process items linked to the breach Issue, and the data processing agreements that establish controller/processor roles are uploaded on the processor branch (no native RoPA or contract type — the RoPA extract and DPA stay documents).\n- The privacy incident roster (privacy lead, DPO, legal counsel, security liaison, communications), captured in the engagement brief document on this step.\n\n**Procedure**\n1. Link the incident record and pull the investigation timeline. Do not repeat response work — containment and forensics stay with incident response; this workflow judges notifiability and executes notification.\n2. Fix the moment of awareness: when the organization had a reasonable degree of certainty that a security incident occurred and that personal data was compromised (EDPB Guidelines 9/2022). Detecting an anomaly is not awareness; confirming personal data was affected is. Record the evidence behind the chosen moment — the forensic finding, the processor's notice, the verified report — because regulators probe this timestamp whenever a notification looks late.\n3. Compute the first deadline checkpoints from that timestamp — the 72-hour GDPR Article 33 mark first — and note that the shortest applicable clock sets the cadence for everything downstream.\n4. Determine the organization's role for the affected processing from the RoPA and contracts: controller, joint controller, or processor. If the organization is only a processor for the affected data, its duty is Article 33(2) notice to the controller without undue delay — confirm the correct workflow shape before proceeding.\n5. Draft the engagement brief: jurisdictions plausibly in play from the customer and employee footprint (EU/EEA member states, US states of residence, HIPAA if PHI is in scope), the named response bench, and the counsel-engagement note — keep facts separate from legal-risk analyses prepared at counsel's direction where privilege is intended.\n6. The privacy lead confirms the awareness timestamp is defensible, corrects the roles and jurisdiction list, and confirms the DPO and counsel are engaged before scoping proceeds.\n7. Open the breach register entry and enumerate the affected data elements from the data inventory, records of processing, and incident evidence: direct identifiers (name, government ID, SSN, driver's license), financial and account data (card numbers, bank accounts with access codes), credentials (username-password pairs, security answers), GDPR Article 9 special categories (health, biometric, and similar), and PHI where a HIPAA covered-entity or business-associate context applies. Record an approximate record volume and a confidence level per element — confirmed, probable, cannot rule out. Statutes bite on what cannot be ruled out, so uncertainty resolves conservatively upward.\n8. Classify the breach per the EDPB taxonomy — confidentiality (unauthorized disclosure or access), integrity (unauthorized alteration), availability (loss of access or destruction). More than one can apply, and an availability-only breach is still a breach.\n9. Segment data subjects into groups (customers, employees, patients, minors and other vulnerable groups) and count them by jurisdiction of residence — attorney-general thresholds and supervisory-authority competence attach per jurisdiction. Where residence is unknown, estimate from billing or account metadata and record the method.\n10. Record the exposure characteristics that move the risk needle: encryption or tokenization state and whether keys or the token vault were compromised (intact-key encryption may qualify for safe harbors); exfiltration confirmed versus exposure only; evidence of actual acquisition or viewing (access logs, data appearing for sale); and the length of the exposure window.\n11. Validate the inventory against the investigation evidence with the privacy team, resolve volume disputes conservatively, then freeze the version the risk-of-harm assessment will use. Later fact changes are new dated versions, never silent edits.\n\n**Record in AssureSwarm**\n- Create the breach Issue item that doubles as the breach-register entry: `issue_type: exception`, `source: management_identified`, `severity` from the exposure, `identified_date` = the awareness timestamp, with the awareness evidence basis and computed deadline checkpoints recorded in `description`. The workflow instance attaches to this Issue, and the breach register is the queryable set of these Issues.\n- Link the incident record — the Incident Management Lifecycle workflow's anchor Issue — to the breach Issue (Issue ↔ Issue), and link the affected processing activities as Process items (Issue ↔ Process).\n- Attach the engagement brief (roster, jurisdiction long-list, privilege notes) as a document on this step.\n- Attach the frozen exposure inventory as a dated XLSX document on this step — elements with volumes and confidence levels, subject groups by jurisdiction, breach type, and exposure characteristics — with the source queries and extracts behind the counts attached so the numbers are reproducible. No native item type fits the inventory, so it lives as this versioned document linked from the breach Issue.\n- Record the frozen version's date on the document; later fact changes are new dated versions, never silent edits.\n\n**Exit criteria** — Awareness timestamp recorded with its evidence basis and confirmed by the privacy lead; controller or processor role determined; jurisdiction long-list and roster recorded; incident record linked; DPO and counsel engaged; exposure inventory frozen and dated with per-element volumes and confidence levels, subject counts by jurisdiction, breach-type classification, and exposure characteristics, validated against investigation evidence with the sources attached.","label":"Scope the personal-data exposure","performedBy":{"primitives":["coach-item-create","coach-query-data","coach-items-link"]}},"id":"scope-personal-data-exposure"},{"data":{"decisionField":"breach_origin","description":"Agent traces where the breach originated; the privacy lead routes processor-originated breaches through vendor coordination","formData":{"fields":[{"key":"breach_origin","label":"Determine breach origin","options":[{"label":"Originated in our environment","value":"internal_systems"},{"label":"Originated at a processor or vendor","value":"processor_originated"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Resolve where the breach originated — the organization's own environment or a processor handling personal data on its behalf — because a processor-side breach adds a contractual notification chain and a fact-supply dependency before risk can be assessed. The privacy lead owns the call.\n\n**Decision criteria**\n- **`internal_systems` — Originated in our environment.** The incident findings trace the exposure to systems, workforce, or accounts the organization operates: its own infrastructure, SaaS tenants it administers, or insider action. Choose this even where a vendor product was the attack vector, if the compromised instance and the data were under the organization's operational control. The workflow proceeds straight to the risk-of-harm assessment; no processor coordination is owed.\n- **`processor_originated` — Originated at a processor or vendor.** The exposure occurred at a processor, sub-processor, or other vendor processing personal data on the organization's behalf (an Article 28 relationship): the processor's environment was compromised, its workforce erred, or its sub-processor lost the data. Two facts matter immediately: the controller's awareness clock is generally already running — awareness attaches when the processor's Article 33(2) notice arrives, not when its forensics conclude — and the data processing agreement defines what the processor owed: the notification deadline (commonly 24–48 hours contractually, without undue delay at minimum) and cooperation and fact-supply duties. Pull the DPA and record the clause references, what the processor actually sent, and when.\n- **Mixed origin** (both environments implicated): select `processor_originated` so the coordination step runs, and state the internal component in the rationale — the risk assessment will consume facts from both sides.\n\n**Record in AssureSwarm**\n- Submit the decision form: `breach_origin` (select), the step result with evidence references (incident-finding citations; DPA clause references on the processor branch), and the step's approver record.\n- On the processor branch, upload the DPA as a document on this step — its breach-notification clause has no native contract field, so it stays a document (the processor's Vendor item is linked at the coordination step).\n\n**Exit criteria** — Form submitted with the origin call, an evidence-referenced rationale, and the owner recorded; on the processor branch the DPA's breach-notification clause is identified; the unused branch is prunable.","kind":"decision","label":"Determine breach origin","performedBy":{"primitives":["coach-form-fill","coach-document-upload"]}},"id":"determine-breach-origin"},{"data":{"description":"Agent runs the fact exchange with the processor and tracks its contractual duties; the privacy lead directs the joint response","instructions":"**Objective** — Run the controller–processor coordination so processor-held facts reach this assessment fast enough to beat the notification clocks, and the processor's contractual duties are enforced and documented.\n\n**Inputs**\n- The processor's breach notice and the executed data processing agreement: breach-notification clause, Article 28(3)(f) assistance duties, sub-processor terms.\n- The frozen exposure inventory (to be re-versioned as processor facts land) and the deadline checkpoints from the exposure scoping step.\n- The vendor-management or contract owner for the processor relationship.\n\n**Procedure**\n1. File the processor's notice and test it against the DPA and Article 33(2): did it arrive within the contractual window and without undue delay, and does it carry usable substance? Log any gap with dates — supervisory authorities weigh delays along the notification chain, and processor lateness becomes part of the controller's delay explanation if the 72-hour mark slips.\n2. Send a structured fact request with response deadlines aligned to the master clock: affected data elements and volumes by jurisdiction, exposure window, forensic findings with confidence levels, containment status, sub-processor involvement, and whether other controllers on the same environment are affected. Track every question to an answer; anything unanswered when the risk assessment must run is treated as cannot rule out.\n3. Fold each verified answer into the exposure inventory as a new dated version; keep processor-asserted facts flagged until corroborated by its forensics report or independent evidence.\n4. Settle the division of duties in writing: the legal duty to notify regulators and data subjects stays with the controller regardless of fault. Record any contractual arrangement for the processor to execute mechanics (a mailing house, call-center funding), the remediation the processor owes, cost and indemnity positions per counsel, and whether audit, corrective-action, or termination rights are triggered.\n5. The privacy lead, with counsel, confirms the duty division is contractually correct and the processor's facts are reliable enough for the risk-of-harm assessment to proceed.\n\n**Record in AssureSwarm**\n- Link the processor's Vendor register item (`category: data_processing`, with its `tier`, `data_classification`, `business_owner`, `risk_owner`) to the breach Issue (Issue ↔ Vendor) so the coordination is attributed to the third party of record.\n- Upload the processor's notice, the fact-request correspondence, and its forensics report as documents on this step; re-attach the re-versioned exposure inventory with the source queries behind each revised count.\n- Record the coordination log — questions, deadlines, answers, and open items with owners — as a document on this step; the DPA clause references and the DPA gap log have no native contract field, so they live here too.\n- Note the duty-division decision and any contract rights triggered (audit, corrective-action, termination) in the coordination log.\n\n**Exit criteria** — Processor notice filed and tested against the DPA with gaps logged; fact request answered or open items conservatively dispositioned; exposure inventory re-versioned and re-frozen; duty division confirmed by the privacy lead and counsel.","label":"Coordinate with the processor","performedBy":{"primitives":["coach-document-upload","coach-items-link"]}},"id":"coordinate-with-processor"},{"data":{"decisionField":"notifiability","description":"Agent drafts the per-jurisdiction notifiability analysis with a deadline table; the DPO and counsel decide whether regulator notification is required","formData":{"fields":[{"key":"notifiability","label":"Assess risk of harm and notifiability","options":[{"label":"Notifiable — regulator notification required","value":"notifiable"},{"label":"Not notifiable — document the assessment","value":"not_notifiable"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Decide whether this breach is notifiable to regulators, jurisdiction by jurisdiction, before the shortest clock expires — the GDPR 72-hour mark from awareness is usually the binding one. The DPO and counsel own the decision.\n\n**Decision criteria**\nBuild the per-jurisdiction obligation matrix from the frozen exposure inventory before judging any single statute:\n\n- **GDPR Article 33** — notify the competent supervisory authority within 72 hours of awareness unless the breach is *unlikely to result in a risk* to the rights and freedoms of natural persons. The bar is risk, not high risk — the higher bar belongs to the individual-notice decision. Assess with the EDPB Guidelines 9/2022 factors: breach type; nature, sensitivity, and volume of the data; ease of identifying individuals; severity and reversibility of consequences; special characteristics of the data subjects (children, vulnerable groups) and of the controller; and the number affected. For cross-border processing identify the lead supervisory authority; with no EU establishment, each affected member state's authority is in play.\n- **US state statutes** — for every state with affected residents, work the statute's own frame: does the exposed combination meet its personal-information definition (typically name plus SSN, driver's license, or financial account with access code; many states add credentials, biometric, or medical data); does it carry a risk-of-harm trigger or require notice regardless; are attorney-general or regulator thresholds met at the affected-resident count; and what deadline applies — \"most expedient time possible\" in many states, fixed 30–60 day windows in others. Pull the California/CCPA thread explicitly where California residents are affected: CCPA's breach definition (name plus a data element, or account credentials) triggers resident notice, and its statutory private right of action for unencrypted, unredacted personal information is the driver behind the multi-year retention posture set at closure in the post-breach review — flag it here so retention is scoped correctly downstream.\n- **HIPAA Breach Notification Rule** — where PHI is involved in a covered-entity or business-associate context, an impermissible use or disclosure is *presumed* a breach unless the four-factor assessment demonstrates a low probability that PHI was compromised: (1) the nature and extent of the PHI, including identifier types and re-identification risk; (2) the unauthorized person who used or received it; (3) whether PHI was actually acquired or viewed; (4) the extent of mitigation. Document all four factors even when one is decisive.\n- **Exceptions — apply honestly:** encryption safe harbors only where keys verifiably stayed secure; good-faith acquisition by workforce acting within authority and without further use or disclosure; data already lawfully public. An exception claimed without evidence reads worse at examination than a notification made.\n- **`notifiable`** — any jurisdiction's trigger is met: the GDPR risk threshold is reached, at least one state definition and trigger are satisfied, or the HIPAA presumption stands unrebutted. One notifiable jurisdiction routes the workflow to the notification steps; the matrix determines which regulators.\n- **`not_notifiable`** — every applicable trigger fails on evidence: risk to rights and freedoms genuinely unlikely (for example securely encrypted data with intact keys), no state definition met or safe harbors hold across the board, and any HIPAA four-factor analysis demonstrates low probability. The controller carries the burden of proof — this branch still requires the full documented assessment and lands in the breach register.\n\nScore the likelihood and severity of harm to affected individuals — identity theft, financial fraud, discrimination, physical harm, reputational harm — and record a per-jurisdiction recommendation. Lock the deadline table: every notifiable jurisdiction, its regulator and channel, the deadline computed from the awareness timestamp, and the content requirements. The harm scoring also feeds the later individual-notice decision.\n\n**Record in AssureSwarm**\n- Submit the decision form: `notifiability` (select), the step result with evidence references (frozen inventory version, obligation matrix, harm scoring), and the step's approver record.\n- Attach the obligation matrix and the locked per-jurisdiction deadline table as an XLSX document on this step, linked from the breach Issue.\n\n**Exit criteria** — Form submitted by the DPO and counsel with rationale and owner recorded; obligation matrix and harm scoring attached; deadline table locked with deadlines computed from the awareness timestamp; the unused branch is prunable.","kind":"decision","label":"Assess risk of harm and notifiability","performedBy":{"agent":"reg-artist","note":"drafts the per-jurisdiction notifiability analysis for the DPO and counsel decision","primitives":["coach-form-fill"]}},"id":"assess-risk-of-harm"},{"data":{"description":"Agent drafts every regulator notification and tracks each statutory clock with milestone timestamps; counsel approves and the privacy lead submits","instructions":"**Objective** — Deliver every regulator notification the locked deadline table requires — on the statutory clock, or with the delay reasoned on the record — with content complete, consistent across jurisdictions, and milestone-timestamped against the awareness clock.\n\n**Inputs**\n- The locked deadline table and obligation matrix from the notifiability decision.\n- The frozen exposure inventory and harm scoring — the single source for every figure filed.\n- Regulator channels: the supervisory authority's breach-notification portal, state attorney-general filing forms, the HHS breach portal.\n- DPO contact details and counsel's approval path.\n\n**Procedure**\n1. Draft each notification to its prescribed content. GDPR Article 33(3): the nature of the breach including categories and approximate numbers of data subjects and records concerned; the DPO's name and contact point; likely consequences; and measures taken or proposed. State attorney-general filings follow each state's form — incident and discovery dates, resident counts, data types, a copy of the consumer notice, remediation offered. HIPAA: file with HHS within 60 days of discovery when 500 or more individuals are affected, and notify prominent media in any state or jurisdiction where 500 or more residents are affected; breaches under 500 go to the annual HHS log filed within 60 days after the calendar year ends.\n2. Never trade timeliness for completeness. Where facts are still firming, notify in phases under Article 33(4): submit on time with what is known, flag what is pending, and commit to supplemental updates. If the 72-hour window has already passed, include the reasoned delay explanation the Article requires — the concrete cause, such as awareness arriving late through a processor, not a generic apology.\n3. Hold consistency discipline: every figure in every filing traces to the cited frozen inventory version. Discrepancies between jurisdictions' filings are what follow-up examinations open with.\n4. Counsel approves each notification's final content; the privacy lead submits through the designated channel and captures proof — portal receipt, confirmation email, filing reference.\n5. Log each acknowledgment and regulator follow-up question as it arrives, with an owner and an owed-response date; schedule the supplemental updates promised in any phased filing.\n\n**Record in AssureSwarm**\n- Upload each submitted notification (PDF) with its proof of submission and acknowledgment as documents on this step.\n- Record the milestone timestamps per jurisdiction — drafted, approved, submitted, acknowledged, measured against the awareness clock — in the step's dispatch/tracking document.\n- Create one Issue item per regulator follow-up (`issue_type: observation`, `source: regulatory_exam`, `issue_owner`, `target_remediation_date`) and link each to the breach Issue (Issue ↔ Issue).\n\n**Exit criteria** — Every deadline-table jurisdiction has a submitted notification with proof and milestone timestamps, or a documented delay rationale accompanying a late one; phased-filing supplements scheduled; regulator follow-ups logged with owners; counsel approval recorded on each filing.","label":"Notify regulators and track clocks","performedBy":{"primitives":["coach-document-upload","coach-item-create","coach-items-link"]}},"id":"notify-regulators"},{"data":{"decisionField":"subject_notice","description":"Agent tests the individual-notice triggers and exceptions and recommends a channel; the DPO and counsel decide","formData":{"fields":[{"key":"subject_notice","label":"Decide data-subject notification","options":[{"label":"Individual notification required","value":"notice_required"},{"label":"Individual notification not required","value":"notice_not_required"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Decide whether affected individuals must be told, and through which channel. The individual-notice bar differs from the regulator bar — GDPR requires *high* risk, most US state duties run to residents directly once triggered, and HIPAA requires individual notice outright — so the call is made per jurisdiction. The DPO and counsel own it.\n\n**Decision criteria**\n- **`notice_required` — Individual notification required** when any of the following holds: the GDPR Article 34 threshold is met — the breach is *likely to result in a high risk* to rights and freedoms (exposed credentials, financial data enabling fraud, special-category data, data enabling harm to children or vulnerable people, easy identifiability at scale) — and no Article 34(3) exception survives scrutiny; a state statute mandates resident notice for the exposed data, on the state's own deadline; HIPAA applies — individuals must be notified without unreasonable delay and no later than 60 days from discovery, with no separate high-risk test once the breach presumption stands; or a supervisory authority directs notification under its Article 34(4) power. Choose this branch, too, when direct contact is impracticable but notice is owed — disproportionate effort converts the duty into public communication or substitute notice, it does not remove it.\n- **`notice_not_required` — Individual notification not required** only when every jurisdiction clears: the GDPR high-risk threshold fails on the documented harm scoring, or an Article 34(3) exception holds with evidence — appropriate technical and organisational protection rendered the data unintelligible to unauthorized parties (encryption with verified key custody), or subsequent measures ensure the high risk is no longer likely to materialise (forced credential resets before any misuse, verified recovery before access) — and no state or HIPAA mandate stands. Record the analysis for each exception invoked; the burden of proof stays with the controller.\n- **Channel recommendation** (consumed by the notification step when notice is required): direct written or electronic notice where contact details are reliable; substitute notice — conspicuous website posting, statewide media, a toll-free line — only where the statute permits it, typically on cost, class-size, or insufficient-contact-information grounds; public communication under GDPR where direct contact would be disproportionate effort.\n\n**Record in AssureSwarm**\n- Submit the decision form: `subject_notice` (select), the step result citing each jurisdiction's trigger outcome and any exception applied with its evidence, and the step's approver record.\n- On the notice-required branch, attach the channel recommendation and timing plan as a document on this step, linked from the breach Issue.\n\n**Exit criteria** — Form submitted by the DPO and counsel with per-jurisdiction rationale and owner; every exception invoked is evidence-backed; channel strategy approved on the notice-required branch; the unused branch is prunable.","kind":"decision","label":"Decide data-subject notification","performedBy":{"primitives":["coach-form-fill"]}},"id":"decide-data-subject-notice"},{"data":{"description":"Agent prepares the notice package, distribution run, and delivery tracking; the privacy lead approves dispatch and verifies the support channel is live","instructions":"**Objective** — Notify every affected individual clearly, on time, and through the approved channel, with delivery evidence retained to prove the duty was discharged.\n\n**Inputs**\n- The subject-notice decision with the approved channel strategy and timing plan.\n- Subject segments by jurisdiction from the exposure inventory, with contact details and a reliability read on them.\n- The locked deadline table (individual-notice deadlines per jurisdiction).\n- The approved support offer the notice will describe — credit monitoring or identity-protection terms and the enrollment route (delivery is verified in the remediation step).\n\n**Procedure**\n1. Draft the notice in clear, plain language with each statute's required content: what happened and when; the data categories involved; what the organization has done; what individuals should do (password resets, fraud alerts, credit freezes); the support offered and how to enroll; and contact points. GDPR Article 34(2) requires at least the DPO contact, the likely consequences, and the measures taken or proposed. California prescribes standardized headings — \"What Happened\", \"What Information Was Involved\", \"What We Are Doing\", \"What You Can Do\", \"For More Information\". HIPAA notices go by first-class mail unless the individual agreed to electronic notice, and include a toll-free contact.\n2. Keep the notice honest: no framing that contradicts the regulator filings, no burying the data types mid-paragraph, no marketing content. Regulators and plaintiffs read these notices against the filings.\n3. Build the distribution run: deduplicate recipients across segments (a person in two groups gets one notice — the more protective variant), map each recipient to a channel by jurisdiction rule and contact reliability, stage dispatch against the deadline table, and prepare language and accessibility variants for the affected populations.\n4. Execute substitute notice exactly as approved where direct contact fails or was excused — conspicuous website posting for the statutory duration, media placement, toll-free line — and capture placement evidence: dated screenshots, tear sheets, line-activation records.\n5. Track delivery end to end: dispatch timestamps per batch, bounce and returned-mail handling with re-attempt or fall-to-substitute decisions, and a final reconciliation of recipients versus delivered versus undeliverable.\n6. Stand up the intake channel before the first send: a staffed line or dedicated mailbox, agent scripts, an FAQ covering the expected questions, and an escalation path to privacy for legal threats or regulator mentions.\n7. The privacy lead approves the final notice and dispatch plan, confirms deliverability handling, and verifies the support channel is staffed before the send.\n\n**Record in AssureSwarm**\n- Upload the final notice, its jurisdiction variants (DOCX/PDF), and the substitute-notice evidence as documents on this step.\n- Record the dispatch log (XLSX/CSV) — batches, timestamps, counts, bounce handling, and the delivered-versus-undeliverable reconciliation — as a document on this step.\n- Attach the support-channel go-live evidence (agent scripts, FAQ) as a document on this step.\n\n**Exit criteria** — Direct notice dispatched or substitute notice executed for every affected individual within the deadline table; delivery reconciliation complete with undeliverables dispositioned; support channel live and staffed; the privacy lead's approval recorded before dispatch.\n\n> **⚡ Audit Artist accelerator:** `/coach-notify` runs the staged dispatch and reminder passes with a logged delivery trail where notice goes out by electronic channel.","label":"Notify affected individuals","performedBy":{"primitives":["coach-document-upload","coach-notify"]}},"id":"notify-data-subjects"},{"data":{"description":"Agent stands up tracked remediation actions and credit-monitoring enrollment where owed; owners confirm every promised measure is live","instructions":"**Objective** — Stand up the harm-reduction measures the notifications promised and the statutes or risk posture require, so every commitment traces to a live, owned action.\n\n**Inputs**\n- Breach facts and root-cause findings from the incident record and, where that branch ran, the processor coordination.\n- The commitments made: \"measures taken or proposed\" from the regulator filings and, where individuals were notified, the notice's promises.\n- Support mandates in scope — several states require credit monitoring after SSN breaches, commonly 12–24 months — and the organization's support decision for high-risk exposures.\n\n**Procedure**\n1. Create a tracked action per remediation measure, each with an owner and due date: credential resets and forced reauthentication for compromised accounts; key and certificate rotation where key material may have been exposed; access revocations; verified deletion or recovery of data from unintended recipients where feasible — obtain a signed destruction attestation, since an informal email assurance is weak evidence; and fixes to the control weaknesses the breach exploited (patch, configuration, detection rule, process change).\n2. Stand up individual support where owed or offered: credit-monitoring or identity-protection enrollment sized to the mandate or the risk — standard practice for SSN or financial-credential exposure — with enrollment codes tied to the notified population, an enrollment window matching the notice, and uptake tracked.\n3. Reconcile promised versus delivered line by line: every measure named in a regulator filing or individual notice must trace to a completed or scheduled action item. A promised measure that quietly lapses is the finding a follow-up examination writes itself.\n4. Action owners confirm each measure live on its action item; the privacy lead verifies the reconciliation closes with nothing unimplemented and routes residual improvement ideas to the post-breach review's corrective-action list.\n\n**Record in AssureSwarm**\n- Create one Issue item per remediation or support measure (`issue_owner`, `target_remediation_date`, `remediation_plan`, and `actual_remediation_date` with completion evidence on close) and link each to the breach Issue (Issue ↔ Issue).\n- Record the promised-versus-delivered reconciliation as a document on this step, linking each commitment to its remediation Issue.\n- Track enrollment statistics against the notified population in that reconciliation document.\n\n**Exit criteria** — Every remediation action complete or scheduled with an owner; support measures live with enrollment tracked; promised-versus-delivered reconciliation closed with owner confirmations; residual items handed to the post-breach review.","label":"Implement remediation and support measures","performedBy":{"primitives":["coach-item-create","coach-items-link"]}},"id":"implement-remediation-and-support"},{"data":{"description":"Convert the breach into owned corrective actions and reopened privacy assessments, then close it with a complete, retrievable audit trail and every surviving obligation transferred to a tracker that outlives this workflow.","instructions":"**Objective**\nConvert the breach into owned corrective actions and reopened privacy assessments, then close it with a complete, retrievable audit trail and every surviving obligation transferred to a tracker that outlives this workflow.\n\n**Inputs**\nThe final exposure inventory version, both decision forms, and the harm scoring.\n- On the notified path: every regulator filing and individual-notice package with milestone timestamps and delivery evidence, plus the remediation reconciliation.\n- On the not-notifiable path: the documented assessment and the evidence behind each exception or risk conclusion.\n- Processor correspondence where the processor branch ran.\n\nThe certified breach register entry and its linked artifact chain.\n- Clock performance: milestone timestamps versus statutory windows for every filing and the individual-notice dispatch.\n- Support-channel logs (volumes, question themes), the delivery reconciliation, and open regulator follow-ups.\n- Residual items flagged from remediation, and the register history for trend reading.\n- The open-obligation list: pending regulator responses, promised supplemental filings, credit-monitoring enrollment windows, corrective actions, reopened DPIAs.\n- The stakeholder list from the engagement brief compiled during exposure scoping; retention requirements and litigation-hold status.\n\n**Procedure**\n*Agent retrieval, preparation and filing absorb “Record the breach register entry”; the responsible roles retain their judgments and all independent sign-offs within this checkpoint.*\n\n1. Assessment scope for Record the breach register entry: Complete the accountability record GDPR Article 33(5) and its analogues require for every personal-data breach — notified or not — written so a supervisory authority could verify compliance from the record alone.\n\n2. Finalize the register entry around the Article 33(5) triad: the facts of the breach (what happened, when, how, breach type), its effects (data and subjects affected by category and jurisdiction, the risk-of-harm outcome), and the remedial action taken. Write it to be read cold years later: absolute dates, volumes with their confidence levels, decisions with named owners.\n3. For a not-notifiable outcome, record the reasoning that carries the controller's burden of proof: which exception or risk conclusion applied, the specific evidence it rests on — for example the encryption attestation and the key-custody verification — and who concurred. A conclusory \"risk was low\" fails at examination; the documented factor analysis stands.\n4. For notified breaches, link every notification with its milestone timestamps laid against the statutory windows, showing each clock met or the delay explanation filed alongside.\n5. Link the chain end to end — incident record, exposure inventory versions, both decision forms, processor correspondence, notification packages, remediation actions — so awareness to closure is traversable from the register entry without hunting.\n6. Scan the register for patterns while the entry is fresh: repeat root causes, the same processor recurring, the same data store — flag any into the post-breach review.\n7. The DPO certifies the entry complete and defensible, whichever branch the breach took.\n\n8. Assessment scope for Run the post-breach review: Convert the breach into owned corrective actions and reopened privacy assessments, then close it with a complete, retrievable audit trail and every surviving obligation transferred to a tracker that outlives this workflow.\n\n9. Compile the review pack and put the numbers on a dashboard: notification-clock performance per jurisdiction (hours from awareness to submission versus allowed), where facts were slow to firm and why (forensics lag, processor lag, inventory gaps), processor-chain performance against contract, individual-notice delivery rates and undeliverable dispositions, support-channel volumes and themes, and regulator follow-ups still open.\n10. Read the misses honestly: a filing that made the 72-hour mark at hour 68 because counsel worked a weekend is a process weakness, not a win. Ask what would have broken at twice the scale.\n11. Draft corrective actions beyond the immediate remediation, each with an owner and date: playbook and policy updates, workforce training, DPA clause hardening where the processor chain underperformed (notification deadline, fact-package requirements, audit rights), detection improvements that would have shortened time to awareness, and data-minimization or retention fixes where the exposure was larger than the business need.\n12. Read the register trends: recurring root causes, repeat processors, repeat data stores. A second occurrence converts an incident into a program finding.\n13. Identify each processing activity whose risk picture this breach changed and initiate the DPIA / Privacy Impact Assessment workflow for it, passing the breach facts and risk findings so the reassessment starts from evidence rather than assumptions.\n14. Assemble the archive package against a completeness checklist: the certified breach register entry, exposure inventory versions, both decision forms with rationale, every regulator filing with proof and acknowledgments, individual-notice packages with delivery evidence and substitute-notice proof, processor correspondence with the DPA gap log, remediation confirmations with the promised-versus-delivered reconciliation, and the review pack with its corrective actions.\n15. Build the surviving-obligation register so each open obligation survives closure in its own tracker with an owner and a date: regulator follow-ups and promised supplements, enrollment windows still open, corrective actions, reopened DPIAs. Closing with an orphaned obligation is the classic post-breach failure mode.\n16. Check the retention position: hold breach records for the longest applicable limitation horizon — private rights of action (for example under CCPA for certain breaches) argue for multi-year retention — and confirm any litigation hold covers the set before archiving.\n17. Export the workflow record for the audit file and notify the stakeholders identified during scoping of the closure and any conditions attached.\n18. The privacy team approves the corrective actions and confirms which DPIAs are reopened; the DPO notes the review outcome for governance reporting; the privacy lead verifies the archive is complete against the checklist and every open obligation has an owner, and closes the breach record. Archive confirmation is recorded; post-archive corrections are new dated addenda, never edits to the archived set.\n\n**Record in AssureSwarm**\nUpdate the anchor breach Issue with the Article 33(5) triad: the facts and effects in `description` and `root_cause`, the remedial action in `remediation_plan`, the not-notifiable / exception reasoning in `management_response`, `actual_remediation_date` for the closure milestone, and `verified_date` = the DPO's certification date.\n- Link the incident Issue, the exposure inventory and notification/delivery documents, both decision forms, the processor Vendor and its correspondence, the affected Process items, and the remediation Issues to the breach Issue so awareness-to-closure is traversable from the register entry.\n\nCreate the review dashboard covering notification-clock performance per jurisdiction, individual-notice delivery, and support-channel metrics; attach the review pack as a document on this step.\n- Create one Issue item per corrective action (`issue_type: finding` for a control gap or `opportunity` for an improvement, `source: management_identified`, `issue_owner`, `target_remediation_date`) and link each to the breach Issue.\n- Where the breach changed a privacy Risk item's picture, update it (`category: privacy`, `residual_rating`, `treatment`); for each affected processing activity, hand its Process item plus the breach facts and risk findings to the DPIA / Privacy Impact Assessment workflow, and record the DPO's governance note on the dashboard.\n- Export the workflow instance as the archive backbone and attach the archive package with its completeness checklist as a document on this step.\n- Record the surviving-obligation register as a document on this step — pending regulator responses, promised supplements, open enrollment windows, corrective-action Issues, reopened DPIAs — each with an owner and a link to its tracker; the register has no native type, so it is a document over the underlying Issue action items.\n- Record the privacy lead's closure confirmation and the stakeholder closure notice as documents on this step; the closed workflow instance stands as the audit trail against the breach Issue.\n\n**Exit criteria**\nRegister entry states facts, effects, and remedial action to Article 33(5) sufficiency; on the not-notifiable branch the reasoning is evidence-backed with concurrence recorded; all artifacts linked; DPO certification recorded. Review pack compiled with clock-performance analysis; corrective actions created with owners and approved by the privacy team; every affected DPIA initiated with the breach evidence attached; the DPO's governance note recorded; archive package complete per the checklist and the workflow record exported; every surviving obligation tracked with an owner outside this workflow; retention and hold position confirmed; the breach closed on the privacy lead's confirmation recorded here.\n\n> **⚡ Audit Artist accelerator:** `/coach-workflow-export` exports the full workflow record — steps, decisions, forms, and attachments — as the archive backbone.","label":"Run the post-breach review","performedBy":{"note":"","primitives":["coach-dashboard-create","coach-item-create","coach-items-link","coach-item-update","coach-workflow-export"]}},"id":"post-breach-review"}],"sourceTemplateId":"workflow-library:reg-privacy-breach-notification"}