{"description":"Privacy Safeguards & Notice Management as a decision-aware cycle that runs as a workflow instance attached to the standing \"Privacy Program\" Process item (process_type: business_process, process_owner: the privacy officer) — one archived instance per period is the cycle file. Each run refreshes the privacy requirements inventory, confirms PII-protection accountability over the PII stores (modeled as processing-activity Process items), verifies administrative, technical, and physical safeguards against data volume and sensitivity (the safeguard set is the Control items with control_category administrative|technical|physical and framework gdpr|ccpa|hipaa protecting each store), remediates gaps as tracked Issues, and authors, publishes, and version-retains the privacy notices and registrations (modeled as Policy items) kept accurate to actual processing. In scope: the periodic privacy program cycle over the confirmed PII stores, their safeguard control set, and the published notice and registration population; every run reconciles the affected notices to actual processing — a cycle that skips notice reconciliation is a different workflow. No upstream or downstream workflow feeds or consumes this cycle; its inputs are the organization's own privacy program records, and open remediation, treatment expiries, and deferred drift carry forward as open Issues that seed the next cycle's intake.","edges":[{"id":"e-refresh-requirements-inventory-verify-safeguards","source":"refresh-requirements-inventory","target":"verify-safeguards"},{"id":"e-refresh-requirements-inventory-author-and-refresh-notices","source":"refresh-requirements-inventory","target":"author-and-refresh-notices"},{"id":"e-refresh-requirements-inventory-remediate-safeguard-gaps","source":"refresh-requirements-inventory","target":"remediate-safeguard-gaps"},{"id":"e-verify-safeguards-remediate-safeguard-gaps","label":"Remediation required","source":"verify-safeguards","target":"remediate-safeguard-gaps","whenValue":"remediation_required"},{"id":"e-verify-safeguards-close-and-archive","label":"Adequate","source":"verify-safeguards","target":"close-and-archive","whenValue":"adequate"},{"id":"e-remediate-safeguard-gaps-close-and-archive","source":"remediate-safeguard-gaps","target":"close-and-archive"},{"id":"e-author-and-refresh-notices-resolve-notice-with-counsel","label":"Counsel review required","source":"author-and-refresh-notices","target":"resolve-notice-with-counsel","whenValue":"counsel_review_required"},{"id":"e-author-and-refresh-notices-publish-and-deliver-notices","label":"Approved to publish","source":"author-and-refresh-notices","target":"publish-and-deliver-notices","whenValue":"approved_to_publish"},{"id":"e-resolve-notice-with-counsel-publish-and-deliver-notices","source":"resolve-notice-with-counsel","target":"publish-and-deliver-notices"},{"id":"e-publish-and-deliver-notices-close-and-archive","source":"publish-and-deliver-notices","target":"close-and-archive"}],"isPublic":true,"metadata":{"capabilities":[],"controlVerbs":{},"controls":["UC-DATA-05","UC-DATA-13","UC-GOV-25","UC-GOV-26","UC-DATA-04"],"department":"privacy","domains":["reg"],"library":{"aliases":[],"canonicalUrl":"https://workflow-library.com/all/?w=reg-privacy-safeguards-notice-management","contentDigest":"sha256:9fc1ed573a4e68d5331016375524eaf9c4bcf19c6c6de67ae968a3a474effd42","prerequisites":{"status":"undeclared"},"provenance":[],"releaseId":"sha256:9fc1ed573a4e68d5331016375524eaf9c4bcf19c6c6de67ae968a3a474effd42","schemaVersion":1,"sourceTemplateId":"workflow-library:reg-privacy-safeguards-notice-management"},"lineOfDefense":"operate","mappingStatus":"mapped","risks":[],"slug":"reg-privacy-safeguards-notice-management","source":"coworkcanvas-gallery","standards":["gdpr","ccpa","hipaa"],"teams":["privacy"]},"name":"Privacy Safeguards & Notice Management","nodes":[{"data":{"description":"Rebuild the authoritative inventory of statutory, regulatory, and contractual privacy obligations, mapped to the specific personal-information stores each one governs, with a defensible diff from the prior cycle.","instructions":"**Objective**\nRebuild the authoritative inventory of statutory, regulatory, and contractual privacy obligations, mapped to the specific personal-information stores each one governs, with a defensible diff from the prior cycle.\n\n**Inputs**\nThis cycle runs as a workflow instance attached to the standing \"Privacy Program\" Process item; it enriches the program's requirements inventory rather than starting one from scratch.\n- The legal and regulatory register for every jurisdiction where the organization collects or processes personal information — uploaded to this step (there is no native Obligation/Requirement item type; see Record in AssureSwarm).\n- The contracts register: data processing agreements (GDPR Art. 28), business associate agreements, joint-controller arrangements (Art. 26), vendor terms, and customer MSA privacy commitments — uploaded to this step; the processors themselves are the Vendor items confirmed in the following procedure.\n- The prior cycle's requirements inventory memo — the document on the prior cycle instance's close-and-archive step.\n- The data inventory and record of processing activities — the processing activities are Process items (process_type: business_process) carrying store jurisdictions and data categories; store-level detail rides as an upload here (no native DataStore/Asset type).\n\nThe current accountability model: data owners, system owners, control owners, the privacy officer, the DPO, and the per-store RACI assignments — the system-of-record owner is Process.process_owner on each store/activity Process item; the full RACI model rides as a document on this step.\n- The HR roster or movers-and-leavers list as of period start, for owner-currency checks — uploaded to this step.\n- The data inventory (the store/activity Process items) and the processor and business-associate list — the processors are Vendor items (category: data_processing), each needing a named internal relationship owner in Vendor.business_owner / Vendor.risk_owner.\n\n**Procedure**\n*Agent retrieval, preparation and filing absorb “Confirm PII-protection responsibilities”; the responsible roles retain their judgments and all independent sign-offs within this checkpoint.*\n\n1. Assessment scope for Refresh privacy requirements inventory: Rebuild the authoritative inventory of statutory, regulatory, and contractual privacy obligations, mapped to the specific personal-information stores each one governs, with a defensible diff from the prior cycle.\n\n2. Determine jurisdictions by where data subjects are, not where offices are: GDPR reaches organizations outside the EU that target or monitor EU residents (Art. 3(2)); CCPA applies by California residency plus the business thresholds (the inflation-adjusted $25M revenue mark, 100,000 or more consumers or households, or half of revenue from selling or sharing personal information). Run the scoping test per regime and record the conclusion — \"we assumed\" is not a scoping analysis.\n3. Confirm HIPAA posture per store: covered entity, business associate, or out of scope. PHI held as a business associate carries the Security Rule and the BAA's terms but not the Notice of Privacy Practices duty — the obligation set differs by posture, not just by data type.\n4. Pull the contractual obligations and capture the stricter-of terms: DPAs (processing instructions, sub-processor approval, breach-notice SLAs shorter than statute, audit rights), BAAs (permitted uses, safeguard duties), and customer commitments such as \"no data outside the EU\" or deletion within a stated window. Contractual duties routinely exceed statute; the inventory records the binding term, not the statutory floor.\n5. Map every requirement to the stores and data categories it governs so each store carries its full obligation set — GDPR to EU personal data; CCPA to California consumer and household data, including HR and B2B data since those exemptions sunset in 2023; HIPAA to PHI; state comprehensive laws and sectoral regimes (GLBA, COPPA, FERPA) where the inventory shows their data. A store with zero mapped obligations is either out-of-scope data or a mapping error — rule which, in writing.\n6. Diff against the prior cycle: new laws and amendments now in force, requirements expired or superseded, newly executed contracts adding obligations, and stores whose obligation set changed because the data or processing changed. Separate \"in force now\" from \"enacted, effective later\" — the latter go to a forward log with a compliance lead time, not into this cycle's obligation set.\n7. Draft the requirements inventory memo: the per-store obligation map, the change list with effective dates, each ambiguous applicability framed as a question with its scoping analysis attached, and a proposed owner for every new or changed requirement.\n\n8. Assessment scope for Confirm PII-protection responsibilities: Verify that a named, current owner is accountable for protecting every PII store in scope across all three safeguard classes, and that the privacy officer and data protection officer roles are filled, current, and conflict-free.\n\n9. Confirm the mandated roles first: HIPAA requires a designated privacy official (§164.530(a)); GDPR requires a DPO where core activities involve regular and systematic monitoring at large scale or large-scale special-category processing (Art. 37). A vacant mandated role is a finding in its own right, not a footnote to the owner map.\n10. Check DPO independence per EDPB guidance: the DPO must not also hold a role that determines the purposes and means of processing — head of IT, HR, or marketing are the classic conflicts — and should not carry KPIs tied to processing outcomes.\n11. Reconcile per store: exactly one named accountable owner for the store's administrative, technical, and physical safeguards. Accountability split across two names with no tiebreak is an exception, not a nuance. Verify currency against HR — an owner who left or transferred means the store has been orphaned since their exit date, and the memo says so.\n12. Sweep the processor list: every processor and business associate has a named internal relationship owner accountable for oversight — reviewing attestations, tracking sub-processors, receiving breach notices. A processor with a sound contract and no internal owner is still an orphan.\n13. Flag the exceptions: orphaned stores, stale owners, split accountability, vacant or conflicted officer roles, each with its aging. For each, propose a reassignment naming the manager who must confirm it — a proposed owner who has not accepted is still a vacancy.\n14. Draft the accountability memo: the per-store owner map, the exception list with aging, and the proposed reassignments.\n\n**Record in AssureSwarm**\nAttach the requirements inventory memo — the per-store obligation map, the change list with effective dates, and the proposed owner per new or changed requirement (step document, DOCX/PDF). Obligations have no native item type, so this memo is the authoritative record of the obligation set; the per-store detail is expressed against each store's Process item.\n- Where a governing statute or framework is already a Control item (framework: gdpr|ccpa|hipaa), link that Control to the processing-activity Process items it governs (item relationship) so the obligation-to-store map is queryable.\n- Carry the proposed owner for each new or changed requirement in the memo; confirmed accountable owners land on Process.process_owner in the following procedure.\n\nUpdate Process.process_owner on each store/activity Process item to the confirmed accountable owner; set Vendor.business_owner (or Vendor.risk_owner) on each processor/business-associate Vendor item to its internal relationship owner (item field update).\n- Create an Issue per accountability gap — orphaned store, stale owner, split accountability, or a vacant/conflicted officer role — issue_type: observation (deficiency for a vacant mandated role), source: compliance_review, issue_owner, identified_date, target_remediation_date, with the aging and reassignment proposal in the description; link each Issue to the affected Process (or Vendor) item (item create + item relationship).\n- Attach the accountability memo — the per-store owner map and the exception list with aging (step document, DOCX/PDF).\n- Record each confirming manager's acceptance in Issue.management_response on the gap Issue.\n\n**Exit criteria**\nEvery in-scope store carries at least one mapped obligation or a written out-of-scope ruling; the change list carries effective dates; ambiguities are resolved or assigned to counsel with a date; the privacy officer has approved the memo as the cycle's authoritative obligation set. Zero stores without a confirmed accountable owner; privacy officer and DPO roles filled, current, and conflict-checked; every reassignment accepted by the named manager rather than merely proposed; the accountability memo approved for the cycle.","label":"Refresh privacy requirements inventory","performedBy":{"note":"","primitives":["coach-query-data","coach-item-create","coach-items-link","coach-document-upload","coach-item-update"]}},"id":"refresh-requirements-inventory"},{"data":{"decisionField":"safeguards_status","description":"Agent tests the safeguard evidence across all three classes against each store's volume and sensitivity and drafts findings; human decides whether safeguards remain adequate","formData":{"fields":[{"key":"safeguards_status","label":"Verify administrative, technical, and physical safeguards","options":[{"label":"Adequate","value":"adequate"},{"label":"Remediation required","value":"remediation_required"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Decide whether the administrative, technical, and physical safeguards protecting each in-scope store remain appropriate to that store's data volume and sensitivity, or whether any gap requires a tracked remediation plan before the cycle can close. The privacy officer decides on the verification evidence, with the security owner concurring.\n\n**Decision criteria**\n\nThe branch rests on evidence produced in this step, per store and per class. Pull and test: administrative safeguards — policies, access authorization, workforce training, sanction records (HIPAA §164.308); physical safeguards — facility access, workstation, device and media controls (§164.310); technical safeguards — access control, encryption at rest and in transit, audit logging, transmission security (§164.312). Judge them against the applicable bar: GDPR Art. 32's risk-appropriateness test (state of the art, implementation cost, and the nature, scope, context, and purposes of processing weighed against the risk), ISO 27001 A.5.34, and the CCPA reasonable-security duty under §1798.150, where the California AG's data-breach guidance treats the CIS Controls as the floor. Score each class for fit to the store's tier — a high-sensitivity, high-volume store demands stronger controls than a small low-sensitivity one — and test a sample for operating effectiveness through the period: completed access reviews, encryption configuration exports, log retention, facility logs. A control that exists on paper but did not run is a gap, not a pass. For any HIPAA addressable implementation specification not implemented, require the documented §164.306(d) assessment and equivalent alternative; skipping the specification without the analysis is a gap even where the compensating measure is sound.\n\n- **Adequate (`adequate`)** — every store's three classes score appropriate to its tier; operating-effectiveness samples show the controls ran through the period; and residual exceptions are immaterial: confined to low-sensitivity stores, covered by a compensating control, and involving no missing regulatory-required specification. Immaterial items are recorded and tracked as routine maintenance, but nothing here needs a remediation plan.\n- **Remediation required (`remediation_required`)** — any safeguard is missing outright; any high-sensitivity store's control is degraded, untested, or under-scaled for its tier (shared credentials on a PHI store, unencrypted special-category data, log retention shorter than the duty); or an exception maps to a specific regulatory requirement. When the call is genuinely close, take this branch — the cost is a tracked plan; the alternative is an undocumented exposure.\n\n**Record in AssureSwarm**\n- Submit the decision form: `safeguards_status` (the branch), the step result citing the per-store, per-class results and an evidence pointer for every exception, and the step's approver record (step form).\n- Attach the safeguard verification report — appropriateness scores, sample results, and the exception list with proposed owners and due dates (step document, XLSX/PDF). The three classes tested are the Control items with control_category administrative|technical|physical protecting each store's Process item.\n\n**Exit criteria** — Form submitted with a rationale that disposes every store and class; verification report attached with evidence pointers a reviewer can follow without asking; the not-taken branch prunable because the exception list fully states what remediation, if any, must handle.","kind":"decision","label":"Verify administrative, technical, and physical safeguards","performedBy":{"primitives":["coach-query-data","coach-document-upload"]}},"id":"verify-safeguards"},{"data":{"description":"Agent opens and tracks remediation items with interim risk treatments for each safeguard gap; human security and control owners approve the plan and treatments","instructions":"**Objective** — Convert every safeguard exception from the verification into a remediation item with an owner, an exposure-scaled due date, and pre-defined closure evidence — or an approved interim risk treatment — so no store, and especially no high-sensitivity store, sits exposed without a decision while the cycle proceeds.\n\n**Inputs**\n- The safeguard verification report's exception list with evidence pointers, from verify-safeguards.\n- Store sensitivity tiers from the data inventory and the per-store owners (Process.process_owner) confirmed in refresh-requirements-inventory.\n- The risk-acceptance policy — who may accept what exposure and the maximum acceptance duration — a Policy item (policy_type: policy) or, absent one, an upload to this step.\n\n**Procedure**\n1. Open a remediation item per gap carrying the store, the safeguard class, the specific shortfall (missing, degraded, or under-scaled), the accountable owner from the accountability memo — the store's named owner, not \"security\" generically — and a due date scaled to exposure: a high-sensitivity store with an exploitable gap gets a fix or an interim treatment within 30 days; moderate exposure 60–90 days; low-sensitivity gaps may run to next cycle with a written reason.\n2. For any gap not closable by its due date, draft the interim treatment now: compensating controls (tightened access, added monitoring and alerting, network segmentation), or a documented risk acceptance with an explicit expiry and a signer scaled to the exposure — a high-sensitivity acceptance takes the privacy officer and the security owner, not the store owner alone. No acceptance is open-ended; every expiry lands in a future cycle's intake for re-decision.\n3. Define closure evidence per item before work starts: the artifact that will prove the fix — a re-run access review, an encryption configuration export, the revised policy with training completion records. An item whose closure can only be asserted, not evidenced, is not yet specified.\n4. Link each remediation item to its verification finding, the affected store, and the owner, so the chain finding → item → store → owner survives staff turnover.\n5. Run the coverage check: every exception in the verification report maps to a remediation item or an approved treatment. Any residual with no plan goes back to the decision owner by name — it does not get dropped into a miscellaneous list.\n\n**Record in AssureSwarm**\n- Create a remediation Issue per gap — issue_type: deficiency, source: compliance_review, severity scaled to exposure, issue_owner (the store's named owner), identified_date, target_remediation_date (the exposure-scaled due date), and the specific shortfall plus the closure-evidence definition in remediation_plan (item create).\n- Link each remediation Issue to the failed safeguard Control (Issue ↔ Control) and the affected store's Process item (Issue ↔ Process), so the chain finding → Issue → Control → store survives turnover (item relationship).\n- For a documented risk acceptance, record it as an Issue with issue_type: policy_exception, exception_approver (the signer scaled to exposure), and exception_expiry_date (the filterable expiry index), linked to the affected Risk item (category: privacy) with treatment: accept set on that Risk; compensating-control treatments that are not acceptances ride as a step document with their expiries (item create + item relationship + item field update + step document).\n- Record the security and control owners' approval of the plan and every treatment (step approval).\n\n**Exit criteria** — 100% of verification exceptions map to a remediation item or an approved treatment; every item carries an owner, an exposure-scaled due date, and defined closure evidence; every acceptance carries an expiry and the right signer; the security and control owners have approved the plan with no high-sensitivity gap left untreated.","label":"Remediate safeguard gaps","performedBy":{"primitives":["coach-item-create","coach-item-update","coach-items-link","coach-document-upload"]}},"id":"remediate-safeguard-gaps"},{"data":{"decisionField":"notice_review","description":"Agent compares every published notice against actual processing, flags the drift and redrafts the notice and registration text in plain language with version stamps; human decides whether the drafts can publish or need counsel review","formData":{"fields":[{"key":"notice_review","label":"Author and refresh privacy notices","options":[{"label":"Approved to publish","value":"approved_to_publish"},{"label":"Counsel review required","value":"counsel_review_required"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Reconcile every published notice and registration against actual processing, redraft what has drifted, and decide whether the refreshed drafts are accurate, plain-language, and within the routine editorial mandate to publish, or whether any change requires privacy counsel before it goes live. The privacy officer decides on the compiled review pack.\n\n**Inputs**\n- The notice and registration population — Policy items (policy_type: policy/standard, framework: gdpr|ccpa|hipaa) carrying version and effective_date, with the published text attached and the covered collection points named; the prior dated versions are the documents on the prior cycle's publish-and-deliver-notices step.\n- The record of processing activities and data inventory as approved this cycle — the store/activity Process items.\n- The retention schedule (a Policy item or an upload to this step) and the requirements inventory memo for regime refresh intervals.\n- The collection-point register: web forms, application flows, call scripts, paper intake, in-person and device collection — uploaded to this step.\n\n**Procedure**\n_Items 1–8 are agent-run (items 1–6 folded from the former \"Reconcile notices to actual processing\" step); the human moment is the branch call in item 9._\n1. Extract each notice's stated content into the same taxonomy the processing record uses: categories collected, purposes, lawful bases, recipients and disclosures (including sale or share for CCPA), retention periods, data-subject rights, and any transfer or automated-decision disclosures. Field-by-field structure is what makes the comparison decidable; prose-versus-prose comparison finds nothing.\n2. Compare stated against actual in both directions. Processing the notice omits or misstates is the serious direction — a live misrepresentation to data subjects, with deception exposure under FTC Act §5 and a fairness breach under GDPR Art. 5(1)(a). A notice claiming practices that stopped is the other direction: overdisclosure to trim. Recipients are where drift concentrates — analytics, ad-tech, and AI vendors added since the last publication.\n3. Tie every retention statement to the retention schedule. CCPA requires the notice at collection to state the retention period, or the criteria used to determine it, per category (§1798.100(a)(3)) — a bare \"as long as necessary\" with no criteria fails.\n4. Sweep the collection-point register: every point delivers a notice at or before collection (CCPA §1798.100(a)–(b); GDPR Art. 13 at the time the data are obtained, Art. 14 within one month where the data come from elsewhere). Test the live surfaces from a clean session: links resolve to the current version, mobile flows included, call scripts actually read the notice language, paper intake stocks the current form.\n5. Check the mandated refresh intervals: the CCPA privacy policy updated within the last 12 months (§1798.130(a)(5)); the Notice of Privacy Practices reflecting current practices; each system-of-records notice matching the system's current uses — a significantly modified system operating ahead of its SORN update is a finding, not a backlog item.\n6. Draft the reconciliation report: per-notice drift items classified as misstatement, omission, stale interval, or uncovered collection point; the registrations needing update; and a proposed owner per item, with misstatements flagged for priority — they are live representations to data subjects.\n7. Redraft each affected notice to correct every drift item in clear and plain language (GDPR Art. 12(1) — concise, transparent, intelligible, easily accessible; the EDPB-endorsed transparency guidelines' layered-notice pattern keeps the first layer to what a reader needs before proceeding). Align each draft to its regime template: GDPR Arts. 13–14 content elements; the CCPA notice at collection — categories, purposes, sale or share status, retention, and the link to the full policy; the HIPAA Notice of Privacy Practices with its required header and elements (§164.520). Draft or update the registrations — NPPs, Privacy Act system-of-records notices, regulator filings — so the external artifacts match the refreshed processing description.\n8. Version-stamp every draft: new version number, effective date, and a change log stating what changed and why, with the prior dated version preserved untouched in the history. Compile the review pack: redlines, registration drafts, change logs, and the reconciliation finding each draft resolves.\n9. Confirm each reconciliation finding is a genuine discrepancy rather than wording taste, then pick the branch below.\n\n**Decision criteria**\n- **Approved to publish (`approved_to_publish`)** — every draft resolves its drift items one-for-one; the changes correct accuracy, recipients, retention statements, or clarity within existing lawful bases; no new purpose or basis, no new international-transfer or automated-decision disclosure, no regulated registration touched; plain-language and regime-template checks pass. The routine editorial mandate covers exactly this and nothing more.\n- **Counsel review required (`counsel_review_required`)** — any draft alters or adds a lawful basis (a switch to legitimate interests needs its assessment on file), re-represents a material practice change to data subjects, introduces sale or share (which triggers the CCPA opt-out link duties under §1798.135), adds a transfer or automated-decision disclosure, materially revises an NPP, or changes a system-of-records notice in a way that requires a Federal Register filing. A single flagged draft takes this branch for the cycle: the counsel step packages only the flagged drafts, and cleared and unflagged drafts publish together downstream.\n\n**Record in AssureSwarm**\n- Create a drift Issue per discrepancy — issue_type: observation (misstatements, being live misrepresentations to data subjects, take severity: high or critical), source: compliance_review, issue_owner, identified_date — and link each to the Policy item for the affected notice (Issue ↔ Policy) and the store/activity Process item it concerns (Issue ↔ Process) (item create + item relationship).\n- Attach the notice reconciliation report — the per-notice field-by-field comparison, the collection-point test results, and the registrations needing update (step document, XLSX/PDF).\n- Attach the review pack — redlined, version-stamped drafts, change logs, and the drift Issue each resolves (step document, DOCX/PDF); link each draft to the Policy item for the notice it revises (item relationship). The published version and next_review_date land on that Policy item at the publish step.\n- Submit the decision form: `notice_review` (the branch), the step result naming which drafts triggered counsel review and why — or confirming the editorial-mandate check per draft — and the step's approver record (step form).\n\n**Exit criteria** — Every notice compared field-by-field against the processing record and every collection point tested on its live surface; drift items classified with proposed owners; form submitted; every flagged reconciliation item resolved by a draft or explicitly deferred with a reason; version numbers and change logs present on every draft; the not-taken branch prunable because the rationale states per draft whether counsel must see it.","kind":"decision","label":"Author and refresh privacy notices","performedBy":{"primitives":["coach-document-upload","coach-items-link","coach-query-data","coach-item-create"]}},"id":"author-and-refresh-notices"},{"data":{"description":"Agent packages the flagged notice drafts with the legal questions framed; human counsel clears the text and required registrations","instructions":"**Objective** — Obtain privacy counsel's clearance on every flagged notice and registration draft, capture counsel's instructions traceably into the final text, and surface any filing or timing obligation counsel identifies — so publication proceeds on cleared language and a known regulatory calendar.\n\n**Inputs**\n- The flagged drafts with redlines and change logs from the review pack.\n- The reconciliation findings behind each draft and the collection points each governs.\n- The affected lawful bases, disclosures, and registrations, with the regime citations counsel will need.\n\n**Procedure**\n1. Package per draft: the redline, the change log, the findings it resolves, the affected bases and disclosures, and the collection points it governs. Frame a specific legal question for each — not \"please review\" but \"does moving this purpose from consent to legitimate interests survive the balancing assessment,\" \"does this NPP change constitute a material revision,\" \"does this system change require a new or modified system-of-records notice and its comment period.\" Counsel answering a framed question is faster and leaves a cleaner record than counsel hunting for the issue.\n2. Have reviewing counsel record the package determination in the native result and capture counsel’s instructions verbatim — as comments on the draft's item or a memo attached to this step. Paraphrase is where cleared language drifts.\n3. Revise each draft to match exactly. Counsel's wording on lawful bases, rights descriptions, and required elements is not editable for style afterward without re-clearance.\n4. Record every additional obligation counsel identifies as its own item with an owner and a date: a regulator submission, a public comment period (new or modified Privacy Act routine uses take a 30-day comment period plus OMB and congressional review before the practice operates), or an effective-date rule (health plans provide a materially revised NPP within 60 days, §164.520(c)(1)(v)).\n5. Re-version each revised draft, update its change log, and run the traceability check — every counsel instruction maps to an edit or to a recorded counsel-approved exception — before the drafts rejoin the publication path.\n\n**Record in AssureSwarm**\n- The native result and attached counsel review record capture per draft the clearance status, any verbatim required wording, the effect on lawful basis or purpose, whether the change is a material revision, any filing or comment-period obligation it triggers, and the earliest date the text may publish.\n- Attach the counsel review record and the instruction-to-edit trace, and upload the re-versioned drafts (step document).\n- Create a filing/effective-date obligation Issue per item counsel identifies — issue_type: observation, source: compliance_review, issue_owner, target_remediation_date (the filing or effective date) — and link each to the Policy item for the affected notice (item create + item relationship).\n- Record counsel's sign-off on this step (step approval).\n\n**Exit criteria** — Every flagged draft carries counsel's documented clearance; instructions trace to edits with none outstanding; filing and effective-date obligations exist as owned, dated items; nothing is queued to publish ahead of a counsel-ordered comment period or filing.\n\n","label":"Resolve notices with privacy counsel","performedBy":{"primitives":["coach-item-create","coach-document-upload","coach-items-link"]}},"id":"resolve-notice-with-counsel"},{"data":{"description":"Agent publishes the approved notices, wires delivery at each collection point, re-communicates material changes, and retains the dated versions as evidence; human approves the release","instructions":"**Objective** — Put every approved notice and registration live at its correct version, delivering at or before each point of collection, with material changes re-communicated on the regime's timeline and the dated version history preserved as transparency evidence.\n\n**Inputs**\n- The approved, version-stamped drafts with effective dates, from the approved_to_publish branch or from counsel clearance — each tied to its notice Policy item.\n- The collection-point register and the delivery mechanism at each point.\n- The materiality determinations and any counsel-ordered filings or effective-date rules (the filing/effective-date obligation Issues from resolve-notice-with-counsel).\n- The prior published versions — the documents on the prior cycle's publish step.\n\n**Procedure**\n1. Publish each notice to its live locations on its effective date — the website and application privacy centers, and the regulator or Federal Register channel for a system-of-records notice, which must complete before the changed practice operates. Retire the superseded version from live surfaces while preserving it in the dated history: the prior version is the evidence of what data subjects were told before the change.\n2. Wire delivery at or before collection at every register point, and verify from a clean session that each just-in-time link resolves to the new current version — stale CDN caches and hard-coded PDF links are the classic failures. Confirm the mobile flows, call scripts, and paper intake switched over, not just the website.\n3. Re-communicate material changes to existing data subjects on the regime timeline: a new purpose or changed lawful basis is communicated before the new processing starts (GDPR Arts. 13(3)/14(4)); health plans provide the materially revised NPP within 60 days; a new sale or share turns on the CCPA opt-out links at the same moment the practice starts (§1798.135). Capture the evidence — send logs with date ranges, in-product banner screenshots with display windows, filing confirmations.\n4. Assemble the transparency evidence set — dated versions, change logs, delivery confirmations, re-communication records — linked to each notice and its collection points, retained per the program schedule (where HIPAA applies, six years, §164.530(j)).\n5. Spot-check the end state the way a data subject meets it: open a collection surface fresh, follow the notice link, and confirm the version and effective date on screen match the approved draft.\n\n**Record in AssureSwarm**\n- Upload the published dated versions, delivery confirmations, and re-communication evidence, and link each to the Policy item for its notice (item relationship / step document); stamp the published version and effective_date on that Policy item and set next_review_date to the mandated refresh interval (item field update). Live publication to the website or regulator channel is the external system; the dated AssureSwarm copy is the retained transparency evidence.\n- Record the release approval on this step (step approval).\n\n**Exit criteria** — Every approved notice live at the correct version and effective date; every collection point verified delivering; material-change re-communications evidenced on time; the version history complete and traceable from notice item to evidence; release approved.","label":"Publish, deliver, and retain notices","performedBy":{"primitives":["coach-document-upload","coach-items-link","coach-item-update","coach-query-data"]}},"id":"publish-and-deliver-notices"},{"data":{"description":"Automatically archive the authorized safeguard and notice outcomes and carry forward every owned obligation.","instructions":"**Objective** — Close the cycle with a self-contained archive that would withstand regulator scrutiny without oral explanation, and seed the next cycle so every open thread survives with an owner and a date.\n\n**Inputs**\n- The cycle file: requirements inventory memo, accountability memo, safeguard verification report (with the remediation plan and treatments where that branch ran), the counsel review record where that branch ran, the notice reconciliation report, the published notices and registrations with dated versions and change logs, and the delivery and re-communication evidence.\n- The privacy program records-retention schedule.\n- The open items gathered during the cycle: unclosed remediation, treatments with expiries, pending filings and effective dates, deferred drift items.\n\n**Procedure**\n1. Verify closability first: every notice approved this cycle is published and delivered, every safeguard exception has a remediation item or an approved treatment, and counsel-ordered filings are complete or exist as owned, dated items. Missing artifacts block closure — an archive with holes is the finding a regulator writes up.\n2. Export the full workflow record and archive it with the cycle file to the retention location; set the retention date per the schedule (where HIPAA applies, six years is the floor; align the rest to the program schedule). Verify retrievability by opening the archived copy — the dated notice versions must remain retrievable as evidence of what data subjects were told and when.\n3. Record the archive confirmation; post-archive corrections are new dated addenda, never edits to archived artifacts.\n4. Carry the open items into the next cycle's intake with owners and due dates intact: remediation not yet closed; interim treatments due at their expiries for re-decision (a treatment that renews silently is how temporary exposure becomes permanent); notices awaiting a filing or effective date; and drift items deferred with their reasons.\n5. Mark the cycle closed in the privacy program register with the archive reference and closure timestamp, and send the closure notice to the privacy officer, the DPO, and the stream owners. Record closure automatically under the completed stream approvals.\n\n**Record in AssureSwarm**\n- Export the full workflow record and attach the closure record with the archive location and reference (workflow instance export + step document). The workflow instance attached to the \"Privacy Program\" Process item is the cycle's audit trail; the retention date is stated in the closure record, since Process carries no retention-date field.\n- Carry forward every open thread as an open Issue with its issue_owner and target_remediation_date intact — unclosed remediation Issues, policy_exception Issues due at their exception_expiry_date for re-decision, pending filing Issues, and deferred drift Issues — these open Issues are the next cycle's intake (item create / left open).\n- Record automatic closure under the existing stream approvals in the step result.\n\n**Exit criteria** — Archive verified retrievable and complete against the cycle checklist; every open thread exists as a carry-forward item with an owner and a date; the register shows the cycle closed with its archive reference; closure recorded under the existing stream approvals.\n\n> **⚡ Audit Artist accelerator:** `/coach-workflow-export` assembles the complete cycle record with its attachments as the archive package; `/coach-notify` sends the closure notice to the privacy officer, DPO, and stream owners.","label":"Close and archive","performedBy":{"primitives":["coach-workflow-export","coach-item-create","coach-document-upload","coach-notify"]},"requiredApprovals":0},"id":"close-and-archive"}],"sourceTemplateId":"workflow-library:reg-privacy-safeguards-notice-management"}