{"description":"Personal Data Quality & De-identification runs as a recurring operate cycle attached to the existing Control for personal-data quality & de-identification (framework gdpr/hipaa/ccpa/nist-800-53, domain data_protection_privacy): each period is a workflow instance that enriches that Control's operating record — never a new Control. The cycle consumes the data map / RoPA, the data-quality ruleset and retention schedule (Policy items), the individual correction-request queue, the disclosure log and the recipient/processor Vendor register, and the de-identification policy; it checks PII accuracy, relevance, timeliness, and completeness, corrects or deletes failing records and notifies downstream recipients under GDPR Art. 19, adjudicates individual correction requests within statutory deadlines, and de-identifies datasets that do not require full identifiers. It produces the exception register (exception Issue items), the corrected-and-deleted set, the recipient correction/deletion notices, and the de-identification and residual-risk reports; systemic findings hand off to the internal privacy backlog as Issue items. This is a terminal operate cycle — the archived, regulator-ready cycle record is the deliverable, not a handoff package for a named downstream workflow.","edges":[{"id":"e-correct-and-purge-failing-records-notify-downstream-recipients","source":"correct-and-purge-failing-records","target":"notify-downstream-recipients"},{"id":"e-adjudicate-correction-requests-execute-approved-amendments","label":"Granted","source":"adjudicate-correction-requests","target":"execute-approved-amendments","whenValue":"grant"},{"id":"e-adjudicate-correction-requests-notify-downstream-recipients","label":"Denied","source":"adjudicate-correction-requests","target":"notify-downstream-recipients","whenValue":"deny"},{"id":"e-execute-approved-amendments-notify-downstream-recipients","source":"execute-approved-amendments","target":"notify-downstream-recipients"},{"id":"e-notify-downstream-recipients-close-and-archive","source":"notify-downstream-recipients","target":"close-and-archive"},{"id":"e-verify-deidentification-and-risk-close-and-archive","label":"Released","source":"verify-deidentification-and-risk","target":"close-and-archive","whenValue":"release"},{"id":"e-verify-deidentification-and-risk-strengthen-deidentification","label":"Rework","source":"verify-deidentification-and-risk","target":"strengthen-deidentification","whenValue":"rework"},{"id":"e-strengthen-deidentification-close-and-archive","source":"strengthen-deidentification","target":"close-and-archive"}],"isPublic":true,"metadata":{"capabilities":[],"controlVerbs":{},"controls":["UC-DATA-07","UC-DATA-12"],"department":"privacy","domains":["reg"],"library":{"aliases":[],"canonicalUrl":"https://workflow-library.com/all/?w=reg-personal-data-quality-deidentification","contentDigest":"sha256:41e943265957da605901310ca4952729a53a437e317359b1b0dc2c0788e1783a","prerequisites":{"status":"undeclared"},"provenance":[],"releaseId":"sha256:41e943265957da605901310ca4952729a53a437e317359b1b0dc2c0788e1783a","schemaVersion":1,"sourceTemplateId":"workflow-library:reg-personal-data-quality-deidentification"},"lineOfDefense":"operate","mappingStatus":"mapped","risks":[],"slug":"reg-personal-data-quality-deidentification","source":"coworkcanvas-gallery","standards":["gdpr","ccpa","hipaa","nist-800-53"],"teams":["privacy"]},"name":"Personal Data Quality & De-identification","nodes":[{"data":{"description":"Execute the approved dispositions on the authoritative records — correct, delete, or retain-with-justification — consistently across every copy, and capture the corrected-and-deleted set that drives the downstream recipient notices.","instructions":"**Objective**\nExecute the approved dispositions on the authoritative records — correct, delete, or retain-with-justification — consistently across every copy, and capture the corrected-and-deleted set that drives the downstream recipient notices.\n\n**Inputs**\nThe in-scope personal-data assets from the data map and records of processing (RoPA), uploaded at this step as the RoPA / data-map extract (XLSX/CSV): each system and dataset holding PII, the purpose it serves, its legal basis and retention clock, and which checks fall due this period (interval re-checks vs. at-collection validations for new intakes). There is no Data Asset item type in the tenant, so each asset is a row in that extract, not an item. An asset with no recorded purpose cannot be quality-checked — log it as a finding for the RoPA owner rather than silently skipping it, since accuracy, relevance, timeliness, and completeness are all judged against a stated purpose (GDPR Art. 5(1)(d); NIST 800-53 SI-18).\n- The data-quality ruleset — per-field accuracy rules, staleness thresholds by category, required-attribute lists — held as the data-quality standard Policy item (`policy_type: standard`, `framework` gdpr/nist-800-53) with the current ruleset document attached. A ruleset older than the last processing change (new system, field, purpose, or sharing arrangement) is presumptively stale — proceed on the current version and flag the update for close-out.\n- Source-system access or period extracts uploaded at this step; the prior cycle's exception register for recurrence analysis — the still-open exception Issue items (`issue_type: exception`) on the anchor Control plus the prior workflow instance's archived close-and-archive package.\n\nThe approved exception register with per-record dispositions — the exception Issue items (`issue_type: exception`) from the preceding procedure plus the register document attached there.\n- The system-of-record map per dataset (authoritative source plus replicas, caches, warehouse and analytics copies, and backup behavior), uploaded at this step.\n- The retention schedule (held as a Policy item, `policy_type: procedure`) and the legal-hold register, uploaded/checked at this step before any deletion.\n\n**Procedure**\n*Agent retrieval, preparation and filing absorb “Run data-quality checks”; the responsible roles retain their judgments and all independent sign-offs within this checkpoint.*\n\n1. Assessment scope for Run data-quality checks: Test every in-scope personal-data asset for accuracy, relevance, timeliness, and completeness, and produce an exception register with a defensible proposed disposition for each failing record.\n\n2. Accuracy — validate against an authoritative source wherever one exists: the HR system for workforce data, postal reference data for addresses, checksum and format rules for national identifiers, syntax and domain checks for emails and phone numbers. Separate verifiably wrong (fails the authoritative check) from unverifiable (no source to test against): only the former is an accuracy exception; the latter is handled through timeliness and re-confirmation.\n3. Relevance — confirm each field still serves the stated purpose (GDPR Art. 5(1)(c) minimisation): a field collected for a discontinued feature or purpose is no-longer-relevant however accurate it is. Fields added since the last cycle must show a recorded purpose or they are relevance exceptions.\n4. Timeliness — measure each record's last-verified or last-updated date against the category's staleness threshold (typical: contact details 12–24 months; marketing preferences on the consent-refresh clock; workforce data at each HR sync). Past-threshold records are stale exceptions even when not provably wrong.\n5. Completeness — required attributes present and real: catch sentinel and placeholder values (\"N/A\", \"999-99-9999\", \"test@test.com\"), not just nulls.\n6. Apply at-collection validation at the point of entry for records intook this period, so inaccurate or incomplete data is caught before it propagates; run interval re-checks for records already held.\n7. Compile the exception register: record and field, rule failed, current vs. expected value where known, source system, purpose served, and a proposed disposition — correct (an authoritative value exists), delete (outdated or no longer relevant to any purpose — GDPR Art. 5(1)(e), Art. 17), or retain-with-justification.\n8. Produce the coverage summary — datasets scanned, rules run, pass and fail counts, and any dataset that could not be reached (an unreachable dataset is a scope failure to surface, never a silent skip). Cluster failures by field and source: one field failing across many records is an upstream feed or form defect — propose the systemic fix for the close-out backlog instead of perpetual record-by-record repair.\n9. Human checkpoint — the reviewer confirms coverage matches scope, re-performs a sample of flagged records against source (at least 25 exceptions or 10% per rule family, whichever is smaller) to screen false positives, and approves the dispositions.\n\n10. Assessment scope for Correct and purge failing records: Execute the approved dispositions on the authoritative records — correct, delete, or retain-with-justification — consistently across every copy, and capture the corrected-and-deleted set that drives the downstream recipient notices.\n\n11. Correct in the right order: authoritative source first, then propagate to replicas, caches, and analytical copies — a correction landing only in a downstream copy is overwritten at the next sync. After the sync window, re-query at least one downstream copy per propagation path to confirm the corrected value took everywhere.\n12. Before any deletion, check the retention schedule and legal-hold register for that record. A record under hold or an unexpired retention obligation converts to retain-with-justification with the hold or obligation reference recorded — deleting held data is spoliation. Execute cleared deletions per the disposal standard (hard delete or crypto-erase per policy); where backups age out rather than being purged immediately, record the backup-expiry horizon as part of the disposal confirmation, with system and timestamp.\n13. Close retain-with-justification entries with the stated basis (pending accuracy dispute, statutory retention, legal hold) so no exception closes silently.\n14. Re-run the originally failed rule against each corrected record — the exception is closed by a passing re-test, not by the act of editing.\n15. Build the corrected-and-deleted set: identifiers, fields changed or removed, systems touched, action timestamps, and (where policy permits recording them) before-and-after values. This set is the sole input to the recipient-notice step — an item missing here silently escapes the GDPR Art. 19 notification duty.\n16. Under the reviewer-approved dispositions, automatically reconcile actions one-for-one, verify no retention obligation or legal hold was overridden, and verify the corrected-and-deleted set before recipient-notice review.\n\n**Record in AssureSwarm**\nItem create — one exception Issue per failing record or cluster: `issue_type: exception`, `source: compliance_review`, `severity` per exposure, `description` (record and field, rule failed, current vs. expected value, source system, purpose served, proposed disposition), `identified_date`.\n- Item relationship — link each exception Issue to the anchor Control (Issue ↔ Control) so the cycle's exceptions read against the control they operate.\n- Step document — attach the exception register and coverage summary (XLSX) to this step: datasets scanned, rules run, pass/fail counts, and any unreachable dataset. There is no Data Asset item type, so per-dataset pass/fail counts live as rows in this document, not on items; flag systemic-defect candidates for close-out here.\n\nItem field update — close each exception Issue: status closed, `remediation_plan` = the action taken (correct / delete / retain-with-justification and its basis), `actual_remediation_date`, and `verified_date` set only when the originally-failed rule re-tests clean.\n- Step document — attach the disposal confirmations and the corrected-and-deleted set (CSV/XLSX) to this step. There is no Data Asset item type, so the affected datasets and per-record actions (identifiers, fields changed/removed, systems touched, timestamps) are rows in that set, reconciled one-for-one to the exception register.\n\n**Exit criteria**\nEvery in-scope asset scanned or explicitly listed unreachable-with-reason; every exception carries a proposed disposition; the false-positive sample is documented; dispositions approved by the reviewer. Every register entry closed with a recorded action; corrections verified by rule re-test; disposals confirmed with system and timestamp (or backup-expiry noted); zero hold or retention overrides; the corrected-and-deleted set attached and reconciled to the register.","label":"Correct and purge failing records","performedBy":{"note":"","primitives":["coach-query-data","coach-items-link","coach-item-update","coach-document-upload","coach-item-create"]}},"id":"correct-and-purge-failing-records"},{"data":{"decisionField":"request_disposition","description":"Agent works each individual correction or amendment request into a per-request recommendation with its evidence and deadline; human grants or formally denies each within the statutory window","formData":{"fields":[{"key":"request_disposition","label":"Correction request disposition","options":[{"label":"Grant — execute the correction or amendment","value":"grant"},{"label":"Deny — issue formal denial with stated reasons","value":"deny"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Decide every individual correction or amendment request in the queue — grant or deny — inside its statutory window, on verified identity and weighed evidence. The privacy or data-quality owner named on the cycle owns the call.\n\n**Decision criteria**\n\nThe correction-request queue arrives as the request-register upload at this step (XLSX/CSV) with per-request intake and statutory due dates — there is no Privacy Request item type, so each request is a row in that register, not an item; upstream, this queue is typically fed by a DSAR / privacy-rights-intake process.\n\nBefore branching, verify for each request: (1) standing — requester identity verified proportionate to the data's sensitivity, or a personal representative/authorized agent with documented authority; (2) the record at issue is positively matched to the verified requester, not a namesake; (3) the statutory due date computed at intake still holds — GDPR Art. 12(3) one month (+2 with notice), CCPA 45 days (+45 with notice), HIPAA §164.526 60 days (+30 with written notice). A decision issued after the window is a recordable compliance miss even when substantively right.\n\nThen weigh the merits per request: the question is whether the data is inaccurate, incomplete, or not up to date for its purpose. Documentary evidence (government ID, court order, HR record) outweighs the stored value; a bare self-assertion suffices where the individual is the authoritative source (their own phone number, their own preferences). Under HIPAA, also test the §164.526(a) preconditions: the record was created by the entity (or the originator is no longer available to act) and sits in the designated record set.\n\n- **Grant — execute the correction or amendment (`grant`)** — the evidence supports the asserted inaccuracy or incompleteness for one or more requests, in full or in part. Partial grants take this branch: state the granted scope, and give the denied remainder full deny-quality reasoning in its letter. Granting routes to amendment execution; denial letters for any denied requests in the same queue are still issued from this step within their windows.\n- **Deny — issue formal denial with stated reasons (`deny`)** — every request in the queue fails, on permitted grounds only: the record is accurate and complete as evidenced against the authoritative source; the request is manifestly unfounded or excessive (GDPR Art. 12(5) — document why; the burden is the controller's); or a HIPAA §164.526(a)(2) ground applies (not created by the entity, not part of the designated record set, not available for inspection under §164.524, or accurate and complete). \"Too burdensome to fix\" is not a lawful ground. Every denial letter must state the specific reason; the appeal and complaint routes (supervisory authority and judicial remedy under GDPR Art. 12(4); the CCPA complaint route); and, where the regime provides it, the right to file a statement of disagreement (HIPAA §164.526(d)) that then travels with future disclosures of the disputed record. An empty request queue also takes this branch — record \"no requests received this cycle\" as the rationale. Denying rejoins the notice step so the period's proactive corrections still propagate.\n\n**Record in AssureSwarm**\n- Submit the decision form: `request_disposition` (grant/deny); the step result listing each request identifier with its outcome (grant, partial, or deny), legal basis, evidence relied on, and decision date vs. due date; the step's approver record.\n- Step document — attach the issued denial letters, the per-request evidence set, and the updated request register carrying each request's outcome. There is no Privacy Request item type, so per-request outcomes are rows in that register (and mirrored in the step result), not item updates.\n\n**Exit criteria** — Form submitted; every queued request has a recorded outcome with basis and evidence pointers; denial letters issued with reasons, appeal routes, and statement-of-disagreement rights where applicable; all decisions inside their statutory windows or under a noticed extension; the unused branch is prunable.","kind":"decision","label":"Adjudicate correction requests","performedBy":{"primitives":["coach-query-data","coach-document-upload"]}},"id":"adjudicate-correction-requests"},{"data":{"description":"Automatically execute and verify only the granted amendments, send the authorized confirmations and carry disclosed changes into recipient notices.","instructions":"**Objective** — Apply every granted correction or amendment to the authoritative record and all of its copies, confirm completion to the requester inside the statutory window, and queue any previously disclosed amendment for recipient notices.\n\n**Inputs**\n- The granted requests with approved amendment instructions, including partial grants with their recorded granted scope.\n- The system-of-record map used for the proactive corrections: authoritative source, replicas, caches, downstream copies.\n- The disclosure log entries for each affected record.\n- Each request's statutory due date and any noticed extension.\n\n**Procedure**\n1. Apply each amendment to the authoritative source and propagate to every replica, cache, and downstream copy — identical treatment to the proactive corrections, so the individual's record is consistent everywhere it lives. Verify by re-query after the sync window.\n2. Honor the granted scope exactly on partial grants: amend what was granted and nothing more — the denied remainder is already answered by its denial letter.\n3. For PHI under HIPAA §164.526(c): amend by appending or linking — the amendment attaches to the designated record set and the original entry is not obliterated. Identify the persons the individual named plus the business associates known to hold the PHI who may have relied on it to the individual's detriment, and add them to the recipient-notice set.\n4. Where the amended data was previously disclosed to any third party, add the record and its recipients to the corrected-and-deleted set driving the notice step (GDPR Art. 19).\n5. Issue the requester-facing confirmation that the correction or amendment was made, and log the completion date against the statutory due date. A completion after the window is recorded honestly as out-of-window with cause — not silently backdated.\n6. Capture before-and-after evidence per amended record (extract or screenshot) so a reviewer can reperform the change.\n7. Under the recorded grant decision, automatically verify authoritative and copied records, log actual completion against the statutory deadline, and carry every onward-disclosed amendment into recipient notices.\n\n**Record in AssureSwarm**\n- Step document — record each request's completion (completed, completion date, in-window vs. out-of-window result with cause) as rows in the request register on this step; there is no Privacy Request item type. Attach the before-and-after evidence and the requester confirmations here.\n- Step document — append the disclosed amendments to the corrected-and-deleted set document (there is no Data Asset item type, so amended records are rows there), carrying them into the recipient-notice step.\n\n**Exit criteria** — Every granted amendment applied and verified across copies; requester confirmations issued with dates logged against deadlines; before-and-after evidence attached per record; disclosed amendments present in the recipient-notice input.","label":"Execute approved amendments","performedBy":{"primitives":["coach-item-create","coach-items-link","coach-document-upload"]},"requiredApprovals":0},"id":"execute-approved-amendments"},{"data":{"description":"Agent maps every correction and deletion to the third parties and prior recipients it was disclosed to and dispatches the correction notices; human confirms recipient completeness","instructions":"**Objective** — Put a correction or deletion notice in front of every third party the affected data was disclosed to, and close every item with either a recipient acknowledgment or an explicit no-recipients determination — never silence.\n\n**Inputs**\n- The consolidated corrected-and-deleted set: proactive corrections and deletions plus granted amendments flagged as previously disclosed.\n- The disclosure log and RoPA recipient entries, and the recipient/processor Vendor register — Vendor items (`category: data_processing`, `business_owner` = contract owner, `data_classification`, `monitoring_status`) with the processor, service-provider, and data-sharing agreements attached (agreed channel and turnaround commitments).\n- The prior cycle's unacknowledged-recipient follow-ups.\n\n**Procedure**\n1. For each item in the set, enumerate every recipient from the disclosure log and the RoPA: processors and service providers, joint controllers, business associates, and other third parties. Reconcile both directions: every disclosed item has its recipients enumerated, and every never-disclosed item gets an explicit no-recipients marking.\n2. Know the legal trigger being satisfied: GDPR Art. 19 requires communicating each rectification or erasure to each recipient unless impossible or disproportionate effort — a disproportionate-effort claim is documented per item with the analysis, not asserted; CCPA regulations require instructing service providers and contractors to correct or delete their copies; HIPAA amendments go to the persons the individual identified and the business associates that may have relied on the PHI (§164.526(c)(3)). Note Art. 19's second limb: if the data subject asks who the recipients were, the controller must tell them — the recipient list built here is that answer.\n3. Draft each notice with the minimum the recipient needs: the record affected (a stable identifier, not a fresh copy of the full record), the corrected value or the deletion instruction to the extent the recipient needs it, the action requested of them, and a respond-by date. Do not over-disclose in the notice itself.\n4. Before dispatch, have the privacy notice approver judge recipient completeness, any disproportionate-effort determination and the minimum disclosed content, then dispatch through the agreed channel per contract (secure portal, API, encrypted mail); capture acknowledgments where the channel supports them; set a follow-up window (10 business days is a workable default) and chase; escalate a recipient that will not acknowledge to the vendor or contract owner — a repeat non-acknowledger is a systemic finding for close-out.\n5. Link every notice and acknowledgment to its source correction and to the cycle record so each item's notice trail reads end-to-end.\n6. Under the recorded notice approval, automatically reconcile onward-disclosed corrections to notices, retain no-recipient determinations, and record the approved follow-up list for unacknowledged recipients.\n\n**Record in AssureSwarm**\n- Step document — attach the notices, acknowledgments, per-item no-recipients and disproportionate-effort determinations, and the unacknowledged-recipient follow-up list (XLSX), linked back to their source exception Issue items and the anchor Control.\n- Item relationship — link each notice trail to the recipient's Vendor item (Issue ↔ Vendor) where the recipient sits on the vendor register.\n- Item create — a repeat non-acknowledger becomes an Issue (`issue_type: finding`, `source: compliance_review`, `issue_owner`, `target_remediation_date`) linked to that Vendor and the anchor Control, routed to close-out.\n\n**Exit criteria** — Every item in the corrected-and-deleted set carries notices to all its recipients, or a documented no-recipients or disproportionate-effort determination; acknowledgments captured or follow-ups open with named owners and dates; links to source corrections in place.\n\n> **⚡ Audit Artist accelerator:** `/coach-notify` dispatches the recipient notices, reminders, and escalations with a logged chase trail tied to each source correction.","label":"Notify downstream recipients","performedBy":{"primitives":["coach-items-link","coach-document-upload","coach-notify","coach-item-create"]}},"id":"notify-downstream-recipients"},{"data":{"decisionField":"deid_risk","description":"Decide whether each de-identified dataset's residual re-identification risk is acceptable for its intended use or sharing (release) or the treatment must be strengthened first (rework). The privacy owner decides on the residual-risk report.","formData":{"fields":[{"key":"deid_risk","label":"Residual re-identification risk","options":[{"label":"Release — residual risk acceptable for use or sharing","value":"release"},{"label":"Rework — strengthen de-identification before use","value":"rework"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective**\nDecide whether each de-identified dataset's residual re-identification risk is acceptable for its intended use or sharing (release) or the treatment must be strengthened first (rework). The privacy owner decides on the residual-risk report.\n\n**Decision criteria**\nInputs and preparation before selecting the branch:\nThe period's de-identification candidates identified from the data map and RoPA extract (analytics sets, test and development copies, datasets shared under agreement, reporting extracts — any dataset whose purpose does not require full direct identifiers); there is no Data Asset item type, so candidates are rows in that extract, not items.\n- The de-identification policy — held as a Policy item (`policy_type: standard`, `framework` hipaa/gdpr) with the technique catalog and the governing legal standard per purpose attached (HIPAA expert determination, safe harbor, limited data set; GDPR pseudonymization vs. anonymization).\n- Executed data-use agreements for shared sets (attached to their recipient Vendor items); the key-store custodian roster.\n\n*Agent retrieval, preparation and filing absorb “Apply de-identification and protect keys”; the responsible roles retain their judgments and all independent sign-offs within this checkpoint.*\n\n1. Assessment scope for Apply de-identification and protect keys: De-identify the period's flagged datasets with the technique the policy and governing legal standard call for, on working copies only, with every re-identification key segregated and access-restricted.\n\n2. Confirm per dataset that the purpose is achievable without direct identifiers. If the purpose genuinely requires identity (individual-level outreach, case handling), the dataset is out of scope — record why and keep it under full-identifier controls. Test and development copies almost never need real identifiers; default them to de-identified or synthetic data.\n3. Select the technique against the governing standard, and record which standard governs each dataset:\n   - Masking or suppression of direct identifiers for low-exposure internal uses.\n   - Pseudonymization (GDPR Art. 4(5)): identifiers replaced by tokens, with the additional information held separately under technical and organisational measures. Pseudonymized data is still personal data — full GDPR obligations continue to apply to it.\n   - HIPAA safe harbor (§164.514(b)(2)): remove all 18 identifier categories — names; geography below state (3-digit ZIP only where the rule permits); all date elements except year, with ages over 89 aggregated; phone and fax; email; SSN; medical record and health-plan/account numbers; certificate and license numbers; vehicle and device identifiers; URLs; IP addresses; biometrics; full-face photos; any other unique identifying attribute — plus no actual knowledge the residual information could identify.\n   - HIPAA expert determination (§164.514(b)(1)): a qualified expert's documented determination that re-identification risk is very small, with methods and assumptions recorded.\n   - Limited data set (§164.514(e)): the 16 direct identifiers removed; dates and city/state/ZIP may remain; only under an executed data-use agreement, and the field set must match the agreement exactly.\n4. Apply the technique to a working copy only — the source of truth stays untouched. Sweep the quasi-identifier and leak paths the method calls for: generalize dates, coarsen geography, and scrub free-text and notes fields plus metadata (file properties, embedded identifiers) — free text is the classic leak path.\n5. Tokenize with a keyed method (secret key or salt), never a bare hash of the identifier: an unsalted hash of an SSN or email is dictionary-reversible and is not de-identified. Per §164.514(c), a re-identification code must not be derived from information about the individual, and the mechanism must not be disclosed.\n6. Move every re-identification key and crosswalk into the protected key store: access limited to the named custodians, held in a separate system or ACL domain from the de-identified data (not a sibling folder), access logged. Record the standing prohibition on re-identification attempts — the policy clause and, for shared sets, the agreement clause.\n7. Human checkpoint — approve the technique against the stated purpose and governing legal standard for each dataset, confirm the keys and mappings are separated and access-restricted per the custodian roster, and confirm the re-identification prohibition is recorded before any dataset moves to effectiveness verification.\n\n8. Assessment scope for Verify de-identification and residual risk: Decide whether each de-identified dataset's residual re-identification risk is acceptable for its intended use or sharing (release) or the treatment must be strengthened first (rework). The privacy owner decides on the residual-risk report.\n\n\n\nBuild the evidence before branching:\n1. Direct-identifier check — none survive; for safe-harbor sets, walk the full 18-category checklist: any single surviving category is an automatic fail.\n2. Quasi-identifier testing for pseudonymized and expert-determination sets — equivalence-class (k-anonymity) analysis on the released quasi-identifier set (common floors: k ≥ 5 general-purpose; k ≥ 11 where CMS-style cell-size rules apply); sample- and population-uniqueness counts; and a linkage trial against a plausible auxiliary dataset (voter rolls, breach corpora, public profiles) — the motivated-intruder test. GDPR Recital 26 frames the bar: means reasonably likely to be used, considering cost, time, and available technology.\n3. Leak sweep — free text, metadata, and joined attributes carry no direct or indirect identifiers; the re-identification keys remain segregated from the de-identified copy (a non-custodian access attempt fails).\n4. Standard conformance — safe harbor: checklist complete plus no actual knowledge; expert determination: the determination document exists and its assumptions still hold (a determination predating a schema or recipient change is stale); limited data set: fields match the data-use agreement's permitted list exactly.\n\n- **Release — residual risk acceptable for use or sharing (`release`)** — every dataset in the batch passes its governing standard and measures within the policy threshold for its intended use and recipient: all equivalence classes at or above the k floor, no population uniques on the shared quasi-identifier set, the linkage trial produced no confident matches, determinations current. Release is scoped: clearing an internal analytics use does not clear public release — the more exposed the destination, the lower the tolerable residual risk. Name the cleared uses per dataset in the rationale.\n- **Rework — strengthen de-identification before use (`rework`)** — any dataset fails any check: a surviving direct identifier or safe-harbor category, equivalence classes below the floor, population uniques, a successful linkage match, a free-text or metadata leak, a stale or missing expert determination, a data-use-agreement field mismatch, or keys not verifiably segregated. Rework routes the failing datasets to strengthening; record per dataset which failed on what and which passed — nothing in the batch is used or shared until a release decision covers it.\n\n**Record in AssureSwarm**\nStep document — attach the per-dataset technique-and-standard register (technique applied, governing legal standard, working-copy location reference — one row per dataset, since there is no Data Asset item type) together with the transformation specification or configuration.\n- Step document — record the key-store location reference and custodian roster (never key material itself); link the executed data-use agreements (attached as documents / on their recipient Vendor items).\n\nSubmit the decision form: `deid_risk` (release/rework); the step result with per-dataset results — k values, uniqueness counts, linkage outcome, governing standard, and the cleared uses or the failure mode; the step's approver record.\n- Step document — attach the residual-risk report (PDF/XLSX) to this step; per-dataset k values, uniqueness counts, linkage outcomes, governing standard, and cleared-uses-or-failure-mode are rows in that report, since there is no Data Asset item type.\n\n**Exit criteria**\nEvery candidate dataset is either de-identified on a working copy with recorded technique and standard, or documented out-of-scope with reason; keys segregated with restricted, logged access; the re-identification prohibition recorded; sources verified untouched. Form submitted; residual-risk report attached with per-dataset scores and recommendations; each dataset's status — cleared for named uses, or routed to strengthening — is explicit; no above-threshold dataset in use; the unused branch is prunable.","kind":"decision","label":"Verify de-identification and residual risk","performedBy":{"note":"","primitives":["coach-query-data","coach-document-upload"]}},"id":"verify-deidentification-and-risk"},{"data":{"description":"Agent applies the additional de-identification treatment the risk assessment called for and re-tests until residual risk is acceptable; human confirms the dataset is cleared before use","instructions":"**Objective** — Bring every dataset routed back within the acceptable residual-risk threshold through targeted additional treatment and a full re-test, with nothing used or shared while above threshold.\n\n**Inputs**\n- The residual-risk report with per-dataset failure modes: which quasi-identifiers drove the risk, equivalence-class sizes, uniqueness counts, linkage results.\n- The de-identification policy's technique ladder; each dataset's governing standard and data-use agreement.\n\n**Procedure**\n1. Match the treatment to the failure mode: population uniques on combinations like {ZIP, birth date, sex} — coarsen geography (3-digit ZIP or state) and dates (year or age band); small equivalence classes — generalize or suppress the rare values (top- and bottom-code ages, collapse rare categories into \"other\"); free-text or metadata leaks — redact or drop the field; a rich shared field set that linked — cut the shared fields to the minimum the purpose needs; masking that failed outright — move up the ladder to keyed pseudonymization or, under HIPAA, to safe harbor or expert determination.\n2. Prefer the transformation that preserves the analytic purpose: generalization beats suppression when the analysis needs the field. Record the utility impact so the data consumer learns of the coarsening from the record, not by surprise.\n3. Hold every routed-back dataset out of any use or sharing while it is being strengthened, and check the staging location's access log to verify no interim access occurred — no dataset above the risk threshold is released in the interim.\n4. Re-run the full verification battery, not just the failed check — uniqueness, k-anonymity, and linkage tests, or the complete safe-harbor identifier checklist — because a treatment can close one vector while opening another (generalizing dates while adding a newly joined attribute, for example). Confirm the strengthened dataset now meets its governing standard.\n5. If a dataset cannot reach threshold without destroying its purpose, escalate honestly: the outcomes are use under full-identifier safeguards with a documented decision, or no release — never threshold-shopping the test until it passes.\n6. Update the residual-risk report with the additional treatment applied per dataset, the re-test results, and the uses now cleared.\n7. Human checkpoint — confirm the additional treatment brought residual risk within the acceptable threshold under the governing standard, that no dataset was used or shared while above threshold, and clear the strengthened datasets for their intended uses.\n\n**Record in AssureSwarm**\n- Step document — attach the updated residual-risk report to this step; the additional treatment applied, re-test results, cleared status, and permitted uses per dataset are rows in that report (no Data Asset item type), linked to the anchor Control.\n\n**Exit criteria** — Every routed-back dataset re-tested with documented results and either cleared within threshold or escalated with a recorded decision; the no-interim-use check is documented; the updated report is attached.","label":"Strengthen de-identification","performedBy":{"primitives":["coach-query-data","coach-document-upload"]}},"id":"strengthen-deidentification"},{"data":{"description":"Automatically reconcile and archive completed privacy operations under their existing dispositions, preserving all open obligations.","instructions":"**Objective** — Assemble a self-contained, regulator-ready cycle record, compute the cycle metrics, archive to retention, and route systemic findings to the privacy backlog before formal close.\n\n**Inputs**\n- Every cycle artifact: the closed exception register; correction and deletion evidence with disposal confirmations; the request register with outcomes, letters, and deadline results; recipient notices and acknowledgments; the de-identification and residual-risk reports with final cleared statuses.\n- The retention schedule entry for privacy-operations records; the privacy program backlog.\n\n**Procedure**\n1. Run the completeness pass against the registers: every exception closed with an action; every request decided and communicated with its deadline result; every notice acknowledged or on the follow-up list with a named owner and date; every dataset at a final cleared-or-held status. Anything genuinely open either blocks close or transfers to a named owner with a due date recorded in the cycle record — no orphaned tails.\n2. Compute the cycle metrics: records checked and the exception rate; corrected vs. deleted vs. retained-with-justification; requests granted and denied, in-window vs. out-of-window (out-of-window results are recorded honestly with cause — they are the accountability signal, not an embarrassment to bury); recipients notified and acknowledged; datasets de-identified with their residual-risk outcomes; trend vs. the prior cycle. This is the operating evidence for GDPR Art. 5(2) accountability and NIST 800-53 SI-18/SI-19.\n3. Archive the cycle record to the retention location with the retention date that applies to data-quality and de-identification operations records. Then securely dispose of the transient working copies of personal data the cycle itself created — staging extracts, comparison files — and record the disposal: the hygiene cycle must not become its own data-hoarding exception.\n4. Route systemic findings into the privacy backlog with proposed owners: a field failing across consecutive cycles (upstream feed or form defect), a processor that will not acknowledge correction notices (contract or vendor action), a de-identification technique that keeps failing its risk test (technique-catalog change), staleness thresholds that generate noise or miss real decay (ruleset tuning).\n5. Record the archive confirmation; post-archive corrections are new dated addenda, never edits to the archived record.\n6. After both streams reach their authorized outcomes, automatically verify that each exception, request, notice and dataset has its recorded outcome and that the evidence is self-contained, then record closure.\n\n**Record in AssureSwarm**\n- Workflow instance — this run is the archived cycle record (the audit trail); export the workflow record for the archive package. Dashboard — refresh the cycle dashboard with the metrics.\n- Item create — one Issue per systemic finding (`issue_type: finding` or `observation`, `source: compliance_review`, `issue_owner`, `target_remediation_date`), linked (Item relationship) to the anchor Control and routed to the privacy backlog.\n- Step document — attach the archive confirmation with location and retention date.\n\n**Exit criteria** — Cycle record archived with a retention date; metrics computed and on the dashboard; zero unresolved items without a named transferee; systemic findings on the backlog with owners; automatic closure recorded under the prior dispositions.\n\n> **⚡ Audit Artist accelerator:** `/coach-render-package` assembles the registers, evidence, notices, and reports into the archive-ready cycle package.","label":"Close and archive","performedBy":{"primitives":["coach-dashboard-create","coach-workflow-export","coach-render-package","coach-item-create","coach-items-link"]},"requiredApprovals":0},"id":"close-and-archive"}],"sourceTemplateId":"workflow-library:reg-personal-data-quality-deidentification"}