{"description":"Runs the standing **Privacy Program Operations** process — an existing operational Process item (process_type=operational, process_owner = the privacy officer) — on a recurring cycle: this workflow instance attaches to that Process and IS the cycle record. It enriches what already exists rather than recreating it: the anchor Process, the in-scope RoPA processing-activity Process items, the privacy Control and Policy items, and the still-open Issues carried forward from prior cycles. Three parallel streams run inside the cycle — reconcile consent and preferences against processing activities, resolve privacy complaints with an accounting of disclosures, and govern data-sharing agreements against actual flows — each consuming verifiable extracts (consent-platform events, the disclosure log, integration/transfer logs) and producing named deliverables: the consent reconciliation report, the complaint register (Issue items), executed agreement renewals with any legal-approved interim risk treatments, and the cycle metrics pack, before the cycle is archived to its retention schedule. Self-contained recurring cycle; the approved metrics pack informs downstream privacy governance / committee reporting.","edges":[{"id":"e-triage-privacy-complaints-resolve-and-respond","label":"Standard resolution","source":"triage-privacy-complaints","target":"resolve-and-respond","whenValue":"standard_resolution"},{"id":"e-triage-privacy-complaints-escalate-to-privacy-counsel","label":"Escalation required","source":"triage-privacy-complaints","target":"escalate-to-privacy-counsel","whenValue":"escalation_required"},{"id":"e-escalate-to-privacy-counsel-resolve-and-respond","source":"escalate-to-privacy-counsel","target":"resolve-and-respond"},{"id":"e-review-sharing-agreements-report-program-metrics","label":"Compliant","source":"review-sharing-agreements","target":"report-program-metrics","whenValue":"compliant"},{"id":"e-review-sharing-agreements-remediate-agreements","label":"Remediation needed","source":"review-sharing-agreements","target":"remediate-agreements","whenValue":"remediation_needed"},{"id":"e-remediate-agreements-report-program-metrics","source":"remediate-agreements","target":"report-program-metrics"},{"id":"e-resolve-and-respond-report-program-metrics","source":"resolve-and-respond","target":"report-program-metrics"}],"isPublic":true,"metadata":{"capabilities":[],"controlVerbs":{},"controls":["UC-DATA-02","UC-GOV-27","UC-DATA-18","UC-DATA-17","UC-DATA-01","UC-DATA-03"],"department":"privacy","domains":["reg"],"library":{"aliases":[],"canonicalUrl":"https://workflow-library.com/all/?w=reg-privacy-program-operations","contentDigest":"sha256:be27ffe0107fb0639209e9259a92dea5e56078e5fa8f797d331def91854a81fa","prerequisites":{"status":"undeclared"},"provenance":[],"releaseId":"sha256:be27ffe0107fb0639209e9259a92dea5e56078e5fa8f797d331def91854a81fa","schemaVersion":1,"sourceTemplateId":"workflow-library:reg-privacy-program-operations"},"lineOfDefense":"operate","mappingStatus":"mapped","risks":[],"slug":"reg-privacy-program-operations","source":"coworkcanvas-gallery","standards":["gdpr","ccpa","hipaa"],"teams":["privacy"]},"name":"Privacy Program Operations (Consent, Complaints & Sharing)","nodes":[{"data":{"decisionField":"complaint_path","description":"Agent logs and classifies each complaint and drafts responses with the accounting-of-disclosures extract; human decides the resolution path","formData":{"fields":[{"key":"complaint_path","label":"Triage privacy complaints","options":[{"label":"Standard resolution","value":"standard_resolution"},{"label":"Escalation required","value":"escalation_required"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Resolve whether the period's complaints proceed under the routine resolution playbook or any of them needs privacy counsel before a response goes out. The privacy officer or complaints lead owns the call; every downstream clock runs from what this step logs.\n\n**Decision criteria**\n\nThe branch rests on evidence produced in this step. Log each inbound complaint verbatim with a unique identifier, channel, receipt date, and complainant details, and start the applicable clocks on receipt: HIPAA requires documenting every complaint and its disposition (45 CFR § 164.530(d)); a GDPR complainant can go to the supervisory authority at any time (Art. 77), and any embedded data-subject request runs the one-month Art. 12(3) clock; CCPA request components run 45 days. Classify each complaint by type — consent or marketing, improper disclosure, data quality, security concern, request for an accounting of disclosures — and severity; check for repeat complainants and cross-complaint patterns (three complaints naming the same process in one cycle is one process defect, not three coincidences). For complaints implicating disclosures, extract the accounting of disclosures from the disclosure log for the regime lookback — up to six years under HIPAA § 164.528, excluding TPO, disclosures to the individual, and authorized disclosures — with date, recipient name and address, description of the information, and purpose per entry; the accounting itself is due within 60 days, one 30-day extension on written notice. Screen every draft response for intimidation or retaliation exposure (§ 164.530(g)) and waiver-of-rights language (§ 164.530(h)). Then draft a proposed response per complaint and a triage sheet recommending a path.\n\n- **Standard resolution (`standard_resolution`)** — every complaint fits the routine playbook: an established type with an approved response template, no allegation of unlawful processing, no regulator involved, no breach indicators, no litigation or media exposure, and complete disclosure extracts wherever promised. A repeat-complainant pattern whose root cause is already tracked as a remedial action still counts as standard.\n- **Escalation required (`escalation_required`)** — any single complaint: alleges unlawful processing or disclosure; is forwarded by or copies a regulator (OCR, a supervisory authority, a state attorney general); suggests a breach — route it to the incident-response process in parallel immediately, since breach clocks (GDPR Art. 33: 72 hours; HIPAA § 164.404: 60 days) do not wait for this cycle; carries litigation threat or media attention; contests the lawful basis itself; or needs a response that deviates in substance from the approved templates. Name each escalated complaint and the trigger it hit in the rationale — the escalation step works from that list, and non-escalated complaints ride through unchanged.\n\n**Record in AssureSwarm**\n- **Step form** — submit the decision form: `complaint_path` (the branch), the step result naming each escalated complaint identifier and its trigger, and the step's approver record.\n- **Item create** — one **Issue** per complaint: `issue_type: exception`, `source: compliance_review`, `severity`, `identified_date` = receipt date, `target_remediation_date` = the applicable regulatory clock date (Art. 12(3) month, CCPA 45 days, HIPAA accounting 60 days), `description` = verbatim complaint + channel + classification. There is no Complaint item type, so channel, complainant identity, and clock type ride the Issue `description` and date fields.\n- **Item relationship** — link related complaint Issues to each other where a pattern exists (repeat complainant, one process defect), and each to the anchor **Process** item.\n- **Step documents** — attach the triage sheet and the accounting-of-disclosures extracts to this step.\n\n**Exit criteria** — Every inbound complaint logged with running clocks; classification and severity set on each; disclosure extracts attached wherever implicated; the form submitted with a per-complaint rationale for the chosen path; the unused branch is prunable.","kind":"decision","label":"Triage privacy complaints","performedBy":{"primitives":["coach-item-create","coach-query-data","coach-document-upload","coach-items-link"]}},"id":"triage-privacy-complaints"},{"data":{"description":"Agent packages the escalated complaint files with the legal questions framed; human counsel resolves each escalation","instructions":"**Objective** — Put a complete, legally framed file in front of privacy counsel for each escalated complaint and capture counsel's instructions verbatim, so each case rejoins the standard resolution path with an approved response and ordered remedial actions.\n\n**Inputs**\n- The escalated complaint list and per-complaint triggers from the triage decision's the step result.\n- Per complaint: the complaint **Issue item** (classification, severity, clock dates) plus its attached verbatim original, triage sheet, accounting-of-disclosures extract, related consent records, prior complainant correspondence, and linked incident/request Issues.\n- The open complaint **Issue items** with their running clocks on `target_remediation_date`.\n\n**Procedure**\n1. Assemble each escalation package complete enough that counsel needs no system access: complaint, triage sheet, disclosure extract, consent records, correspondence, linked incidents and requests. Every missing artifact costs a round-trip against a running clock.\n2. Frame the legal questions per complaint specifically enough to be answerable: for alleged unlawful disclosure — which disclosure, and which permission or lawful basis it purportedly violates; for contested consent — which record and what defect is alleged; for a potential breach trigger — which facts suggest unauthorized acquisition or access, noting that breach analysis runs on its own clock (GDPR Art. 33: 72 hours to the supervisory authority where notifiable; HIPAA § 164.404: 60 days from discovery) and must not idle in this queue; for regulator involvement — who is asking, what they asked, and their response date. Attach the regime citations counsel will need.\n3. Log each escalation in the complaint register: date and counsel assignee. Pause a response clock only where the regime permits and only with the required notice — the HIPAA accounting extension is a single 30-day extension with a written statement of reasons and date (§ 164.528(c)(1)); a GDPR Art. 12(3) extension (up to two further months) requires informing the data subject within the first month with reasons. No silent pauses.\n4. Capture counsel's resolution verbatim: the approved or revised response text, each ordered remedial action — a disclosure log correction, an additional notification, a process change — with a proposed owner, and any direction to engage the regulator directly.\n5. Revise the draft responses to match counsel's instructions exactly; editorial drift between what counsel approved and what sends re-opens the exposure the escalation existed to close.\n6. Human checkpoint: privacy counsel resolves each escalated complaint — approving the response text, ordering remedial actions, or directing regulator engagement — and signs the escalation record so the case rejoins the standard path.\n\n**Record in AssureSwarm**\n- **Step documents** — attach each escalation package and counsel's signed resolution (PDF) to this step.\n- **Item field update** — on each escalated complaint **Issue**: `management_response` = counsel's approved/revised response text and `remediation_plan` = the ordered remedial actions; where a regime-permitted clock extension applies, reflect the new date on `target_remediation_date` and attach its written-notice evidence to this step (no native extension-notice field — it rides the attached document).\n- **Item relationship** — link each escalated complaint Issue to its remedial-action **Issue** items and any related incident/request Issues.\n\n**Exit criteria** — Every escalated complaint carries a counsel-signed resolution; revised responses match counsel's approved text; ordered remedial actions exist with owners; every clock extension has its required notice on file.","label":"Escalate to privacy counsel","performedBy":{"primitives":["coach-document-upload","coach-items-link","coach-item-update"]}},"id":"escalate-to-privacy-counsel"},{"data":{"description":"Automatically send the approved, identity-screened complaint responses and preserve clock, delivery, root-cause and remedy records.","instructions":"**Objective** — Send every approved response through the complainant's channel with delivery evidence against the clock, and close each complaint with a root cause and remedial actions that stay tracked after closure.\n\n**Inputs**\n- The approved response texts — routine-playbook drafts plus counsel-revised versions (`management_response` on the escalated Issues) where the escalation branch ran.\n- The complaint **Issue items** with their per-complaint clock dates on `target_remediation_date`.\n- Accounting-of-disclosures extracts (attached at the triage/counsel steps) wherever a response promises one.\n- The open remedial-action **Issue items** from this cycle and prior cycles (related to the anchor Process).\n\n**Procedure**\n1. Stage each response for the channel the complainant used, unless they asked for another. Pre-send screen per response: it reveals no personal data beyond the complainant's own; identity was verified proportionate to what the response reveals before any accounting or record extract goes out (an accounting sent to the wrong person is itself a reportable disclosure); the disclosure extract is attached wherever promised; nothing in the text waives rights (45 CFR § 164.530(h)) or reads as retaliatory (§ 164.530(g)).\n2. Send, and capture delivery evidence per complaint — sent timestamp, channel receipt or delivery status, returned-mail handling — and record the response date against each applicable clock. Fee discipline for accountings: the first in any 12-month period is free (§ 164.528(c)(2)); a fee for a repeat request requires advance notice and the chance to withdraw or modify.\n3. Update the complaint register per complaint: outcome, root cause from a stable taxonomy (training gap, system defect, process gap, third-party failure, unfounded) so patterns aggregate across cycles, and remedial actions with owners and due dates.\n4. Correct the disclosure log wherever resolution proved an entry wrong or found an unlogged disclosure — corrections are dated addenda stating what changed and why, never overwrites of the original entry.\n5. Sweep remedial actions from this and prior cycles: each must have a live owner and due date; flag overdue items for the metrics report, and escalate anything overdue two consecutive cycles to the privacy officer rather than letting it ride the report again.\n6. Under the triage-approved routine response or counsel-signed resolution, automatically verify each sent text matches its approval, delivery evidence and register entries are complete, and remedial actions remain tracked before marking the complaint closed.\n\n**Record in AssureSwarm**\n- **Step documents** — attach each sent response and its delivery evidence to the complaint **Issue** item; attach the dated disclosure-log addenda here (the AssureSwarm copy is the evidence; the disclosure log of record is external).\n- **Item field update** — on each complaint **Issue**: `status` → closed, `root_cause` (from the stable taxonomy: training gap, system defect, process gap, third-party failure, unfounded), `actual_remediation_date` = the response date (measured against `target_remediation_date`).\n- **Item create + relationship** — one **Issue** per remedial action (`issue_type: exception`, `issue_owner`, `target_remediation_date`), linked to the complaint Issue and the anchor Process.\n- Response-date-versus-clock results travel to the metrics step through these Issue dates (queryable), not a separate register.\n\n**Exit criteria** — Every complaint responded to inside its clock or the miss documented with reason and any required notice; delivery evidence filed per complaint; every closure carries a root cause; overdue remedial actions flagged and two-cycle stragglers escalated.","label":"Resolve and respond","performedBy":{"primitives":["coach-document-upload","coach-items-link","coach-query-data","coach-item-update"]},"requiredApprovals":0},"id":"resolve-and-respond"},{"data":{"decisionField":"agreements_status","description":"Agent inventories sharing instruments and checks recertification dates and terms against actual flows; human decides the compliance status","formData":{"fields":[{"key":"agreements_status","label":"Review sharing agreements","options":[{"label":"Compliant","value":"compliant"},{"label":"Remediation needed","value":"remediation_needed"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Decide whether every active data flow to a counterparty is covered by a current, accurate instrument (`compliant`) or renewals, amendments, or suspensions are required (`remediation_needed`). The privacy officer decides with legal; the paper-versus-reality check below is the evidence.\n\n**Decision criteria**\n\nBuild the evidence before choosing. The counterparty register IS the **Vendor items** — inventory every active instrument against its counterparty Vendor item (`next_reassessment_date` = the recertification date, `contract_end_date` = instrument expiry, `data_classification`, `monitoring_status`), capture data categories and permitted purpose on the instrument itself, and link each signed copy to its Vendor item: data use agreements (including HIPAA limited-data-set DUAs, 45 CFR § 164.514(e)), computer matching agreements (Privacy Act, 5 U.S.C. § 552a(o) — 18-month maximum term with a single 12-month renewal, Data Integrity Board approval), business associate agreements (§§ 164.502(e)/164.504(e) — verify the required elements: permitted uses, safeguards, subcontractor flow-down, breach reporting, return or destruction at termination), GDPR Art. 28 processor terms and Art. 26 joint-controller arrangements, and CCPA service-provider, contractor, and third-party contracts (regs §§ 7051/7053). Then check paper against reality: query the integration and transfer logs and confirm the data categories, volumes, and recipients actually flowing match what each instrument permits; for transfers out of the EEA, confirm a Chapter V mechanism is in place (adequacy, or SCCs with a transfer impact assessment on file) and onward-transfer limits are honored. Classify exceptions: instruments past recertification; live flows with no instrument on file; flows exceeding the instrument's permitted categories (treat as unauthorized-disclosure exposure, not paperwork); counterparties out of step with security or onward-transfer terms. Draft the review memo: per-instrument status, exceptions with evidence pointers, and remediation candidates with proposed owners.\n\n- **Compliant (`compliant`)** — every active flow is covered by a current instrument; no flow exceeds its permitted categories or purposes; recertifications are current, or inside a defined grace window with renewal already in motion; residual exceptions are immaterial and individually documented (e.g., an administrative date lapse on a flow with zero transfers in the period). Immaterial never covers an uncovered live flow, scope creep in the data actually moving, or a lapsed BAA or CMA with transfers occurring — any of those forces the other branch.\n- **Remediation needed (`remediation_needed`)** — any instrument needs renewal or amendment; any live flow lacks an instrument (a suspension candidate until papered); any flow exceeds its permitted scope; any counterparty fails security or onward-transfer terms. Name each instrument and its specific defect in the rationale — the remediation step executes from that list, and compliant instruments are not re-papered.\n\n**Record in AssureSwarm**\n- **Step form** — submit the decision form: `agreements_status`, the step result listing each defective instrument and where its evidence lives, and the step's approver record.\n- **Item (enrich)** — the counterparty register IS the **Vendor items**: enrich the existing Vendor item per counterparty (or create one where a live flow has no Vendor on file) with `next_reassessment_date` (recertification date), `contract_end_date` (instrument expiry), `data_classification`, and `monitoring_status`; the signed instrument attaches to its Vendor item via `coach-document-link`. Instrument-level terms (permitted purpose, data categories, onward-transfer limits) have no native Vendor field, so they ride the attached instrument document.\n- **Item create** — one **Issue** per defective instrument or uncovered flow (`issue_type: exception`, `source: compliance_review`, `description` = instrument + specific defect, `issue_owner`, `target_remediation_date`), linked to the anchor **Process**; the remediation step drives these to closure.\n- **Step documents** — attach the **agreement review memo** and the transfer-log evidence to this step.\n\n**Exit criteria** — Every register instrument has a per-instrument status; the paper-versus-flow check is evidenced from logs, not attestation; the form submitted with a per-instrument rationale; the unused branch is prunable.","kind":"decision","label":"Review sharing agreements","performedBy":{"primitives":["coach-query-data","coach-document-upload","coach-item-create","coach-item-update","coach-items-link"]}},"id":"review-sharing-agreements"},{"data":{"description":"Agent drafts renewals and amendments and tracks signatures; human legal approves each instrument and any interim risk treatment","instructions":"**Objective** — Drive every exception from the review memo to one of three end states — an executed instrument, a legal-approved interim risk treatment with an expiry, or a suspended-and-evidenced flow — with any residual gap explicitly owned.\n\n**Inputs**\n- The agreement-exception **Issue items** and the review memo from the review-sharing-agreements step.\n- The approved template library: BAA, DUA, Art. 28 addendum, SCC modules, CCPA contract clauses.\n- The counterparty **Vendor items** and their attached instruments, plus counterparty contract contacts.\n- Legal's standing direction on which flow types must stop pending execution.\n\n**Procedure**\n1. Draft the renewal or amendment per flagged instrument from the approved templates, carrying in the corrected data categories, purposes, retention, and onward-transfer terms the review identified — the amendment must fix the actual defect found in the flows, not merely re-date the instrument. Verify regime-required elements as you draft: BAA elements under 45 CFR § 164.504(e); GDPR Art. 28(3) processor obligations; computer-matching term limits (18 months plus a single 12-month Data Integrity Board renewal — a CMA past that is a new agreement, not an extension).\n2. Route the drafts to counterparties and track signatures with dated reminders and a defined escalation ladder — for example: unsigned at 30 days, the business relationship owner engages; at 60 days, legal decides continue-under-treatment or suspend.\n3. For any flow continuing under an expired or deficient instrument, log an interim risk treatment stating what continues, why, the compensating measures, and the treatment's expiry date — an interim treatment without an end date is silent risk acceptance. Where legal directs a stop: issue suspension instructions to the integration owner and evidence the stop from the transfer logs showing zero movement, not from the instruction email.\n4. Update the agreement register as each instrument executes: new effective and recertification dates, the linked signed copy, and the exception it closes.\n5. Verify closure coverage: every memo exception maps to an executed instrument, an approved interim treatment, or an evidenced suspension; report any residual gap with a named owner and target date.\n6. Human checkpoint: legal approves each renewal or amendment before it routes for signature, approves every interim risk treatment and every suspension, and confirms the register reflects the executed instruments before the cycle moves to reporting.\n\n**Record in AssureSwarm**\n- **Step documents** — attach executed instruments (PDF), interim-risk-treatment memos, and transfer-log zero-movement suspension evidence to this step; link each signed copy to its counterparty **Vendor** item via `coach-document-link`.\n- **Item field update** — on each counterparty **Vendor** item: new `contract_end_date` and `next_reassessment_date` as instruments execute, and `monitoring_status` where a flow is suspended.\n- **Item (risk acceptance) create** — for any flow continuing under an expired or deficient instrument, log the legal-approved interim risk treatment as an **Issue** with `issue_type: policy_exception`, `exception_approver` = the approving legal owner, `exception_expiry_date` = the treatment's expiry, linked to the affected Vendor (and to a Risk carrying `treatment: accept` where the acceptance is booked against the risk register). An interim treatment with no `exception_expiry_date` is silent risk acceptance.\n- **Item field update** — on each agreement-exception **Issue**: `status` → closed with `actual_remediation_date` where the instrument executed; link each closed exception to the artifact that resolved it.\n- Log the reminder and escalation trail per counterparty on this step.\n\n**Exit criteria** — Every exception in one of the three end states or reported as an owned residual gap; every interim treatment carries legal approval and an expiry date; every suspension evidenced from transfer logs; the register matches the executed paper.\n\n> **⚡ Audit Artist accelerator:** `/coach-notify` sends the counterparty routing, dated signature reminders, and escalation notices with a logged chase trail.","label":"Remediate agreements","performedBy":{"primitives":["coach-document-upload","coach-items-link","coach-item-create","coach-item-update","coach-notify"]}},"id":"remediate-agreements"},{"data":{"description":"Agent reconciles consent and preferences against processing activities and compiles the consent, complaint, and agreement KPIs into the cycle dashboard and summary; human approves distribution, and that approval closes and archives the cycle","instructions":"**Objective** — Reconcile consent and preferences against processing activities, compile the cycle's consent, complaint and agreement KPIs into a register-derived pack, and win approval to distribute — also the cycle's closure.\n\n**Inputs**\n- The cycle spine: the standing **Privacy Program Operations** Process item (process_type=operational), this cycle's workflow instance (which IS the cycle record), the in-scope RoPA processing-activity **Process items**, and the RoPA extract uploaded here.\n- Consent event extracts per platform for the period (grants, withdrawals, opt-outs, GPC signals; timestamp, source system, data-subject id) with completeness metadata; the per-activity downstream system map (analytics, ad platforms, suppression tables) rides as a step document.\n- Program parameters (propagation SLA, re-consent age, retention schedule) from the privacy **Policy items** (framework=gdpr|ccpa|hipaa) and **Control items** UC-DATA-02/17/18; defaults below where unset.\n- The other streams' outputs — complaint **Issues** with responses, delivery evidence and escalations; **Vendor items**, agreement review memo, executed instruments, interim policy_exception treatments, agreement-exception **Issues** — plus prior-cycle KPIs for trending (standing dashboard and archived cycles) and the distribution list: privacy officer, DPO, governance committee.\n\n**Procedure**\n_Items 1–6 are agent-run (folded from \"Reconcile consent and preferences\"); item 10 is the human moment; items 11–13 close the workflow (folded from \"Close and archive\") — the approval here is the closure._\n1. Verify each extract: event count ties to the platform's own reporting, timestamps sit inside the period, generation metadata (system, query, run date, row count) captured — an extract that cannot be re-run is not evidence.\n2. Sample consent records per platform: each must show who consented, when, the notice version shown, the capture mechanism and the scope granted (GDPR Art. 7(1)). Pre-ticked boxes, consent bundled into terms and inferred consent fail Art. 4(11) / Recital 32.\n3. Match activities to consent: a valid, unexpired record must cover the population actually processed; flag consents past the re-consent age (24 months with no refreshing interaction).\n4. Trace propagation end-to-end: every withdrawal, opt-out and GPC signal must reach every downstream system inside the SLA — CCPA honors an opt-out within 15 business days (11 CCR § 7026) and treats GPC as valid (§ 7025); GDPR Art. 7(3) requires withdrawal as easy as the grant. Anything live downstream past the SLA is an exception.\n5. Flag and disposition the rest: processing with no consent record; conflicting preference values across systems for one person (suppress to the most restrictive); consent under a superseded notice where the change was material. Re-query after the propagation window to separate failure from sync lag; for no-consent findings document any other lawful basis that covers it (legitimate interest with an LIA, contract necessity) — never backfill consent.\n6. Draft the reconciliation report: per-platform totals, SLA hit rate, exception list with evidence pointers, proposed owner and due date per exception.\n7. Compile the KPIs from register queries, not the prior deck — consent: grants, withdrawals, opt-outs (incl. GPC counts), SLA hit rate, open exceptions by age; complaints: received by channel and type, closed, median days to resolve, on-time rate, escalation rate, overdue remedial actions; agreements: active, recertified on time, past due, uncovered flows, suspended flows, treatments with days to expiry. Record the query and as-of date beside each number.\n8. Trend each KPI against prior cycles, annotating every deteriorating line with a cause naming the exceptions (\"SLA hit rate 94%→81%: ad-platform API defect, EXC-2031\"), not commentary. Thresholds (defaults where the program set none): hit rate under 95% or a withdrawal unpropagated past 30 days gets a named remediation escalation; a complaint past its regulatory clock is named individually, never aggregated; a remedial action overdue two cycles running is named with its owner.\n9. Build the cycle dashboard and one-page summary for the privacy officer, DPO and committee, leading with what needs their decision, and attach the evidence links (reconciliation report, complaint extract, agreement memo).\n10. **Human checkpoint** — review each consent exception (propagation failure real; no-consent finding not covered by another basis), approve its owner and due date, verify the metrics reconcile to the registers, approve or challenge each cause note, and approve distribution.\n11. Check the file against the path the cycle took: branch artifacts only where a branch ran (escalation records if `escalation_required`, instruments and treatments if `remediation_needed`); both decision forms with rationales regardless. Confirm it reads without explanation — each consent exception showing its disposition, each complaint tracing classification→response→delivery→closure, each agreement exception its resolving artifact — noting anything that does not.\n12. Archive the cycle file, retention date per artifact class: HIPAA records (complaints and dispositions, accountings, BAAs) six years minimum from creation or last effective date (45 CFR § 164.530(j)(2)); GDPR accountability records for the life of the processing plus limitation periods; longest period where classes overlap. Verify retrievability by opening the archived copy.\n13. Carry forward open items — unresolved remediation Issues, pending counterparty signatures, unpropagated-withdrawal exceptions, live interim treatments by `exception_expiry_date` — with owners, due dates and history intact (a due date moves only with the owner's documented reason), then mark the cycle closed in the register with the archive references and a closure timestamp and notify the privacy officer and stream owners; post-archive corrections are new dated addenda, never edits.\n\n**Record in AssureSwarm**\n- **Step documents** — the platform extracts with completeness metadata; the **consent reconciliation report** (totals, SLA hit rate, exceptions with evidence pointers); the one-page **metrics summary** plus the register extracts behind each KPI (`coach-item-export` CSVs of the exception/complaint/agreement Issues and Vendor items); the **cycle archive package** with retention date and reference.\n- **Item create** — one **Issue** per confirmed consent exception: `issue_type: exception`, `source: compliance_review`, `description` = exception class + affected systems, `issue_owner`, `identified_date`, `target_remediation_date`.\n- **Item relationship** — link each exception Issue to the anchor **Process** so cross-cycle patterns aggregate by query; at carry-forward unresolved Issues stay open with owner and date intact, linked to the next cycle's instance.\n- **Dashboard** — create or update the standing privacy operations dashboard; per-platform totals and SLA hit rate have no native metric field; they travel on the reconciliation report.\n- **Workflow instance** — export this run (`coach-workflow-export`) as the audit trail and mark it closed; the anchor **Process** stays active for the next cycle.\n- Record the distribution approval (approver, date, audience) and the closure notification on this step.\n\n**Exit criteria** — Every platform extracted with completeness evidence; every consent exception confirmed with owner and due date or cleared in writing; every KPI reconciling to an attached register extract, with cause notes naming exception identifiers; distribution approved and sent; the archive filed and referenced; every open item in the next cycle's intake with an unchanged-or-justified due date; the cycle closed with a timestamp under the approval recorded here.\n\n> **⚡ Audit Artist accelerator:** `/coach-dashboard-create` builds the KPI dashboard from the register queries; `/coach-render-package` renders the cycle file into one archive package.","label":"Report program metrics","performedBy":{"primitives":["coach-dashboard-create","coach-query-data","coach-export-package","coach-document-upload","coach-item-create","coach-items-link","coach-workflow-export","coach-render-package"]}},"id":"report-program-metrics"}],"sourceTemplateId":"workflow-library:reg-privacy-program-operations"}