{"description":"DSAR Fulfillment (Access & Deletion Requests) as a modular, decision-aware workflow that verifies identity, locates and reviews personal data, applies exemptions, and delivers the response inside the statutory deadline. The workflow runs against the EXISTING \"DSAR / Data-Subject Request Handling\" Process item (process_type: business_process) — enrich it, never recreate it: one workflow instance per inbound request, and the instance itself is the DSAR register entry (there is no native DSAR/privacy-request item type; the register is the set of these instances). In scope: a single inbound data-subject access or deletion request under GDPR, CCPA/CPRA, or HIPAA, with the statutory clock started at receipt, carried from identity verification through data compilation, exemption review, delivery, and archival, with any correction or portability elements handled inline. It consumes the inbound request and identity artifacts uploaded at the first step, the data map / record of processing activities, the exemption playbook and retention schedule (Policy items with the governing documents attached), and the processor register (Vendor items, category: data_processing). Named deliverables: the access disclosure set or deletion certificate, the exemption log and redlined package, the reasoned rejection notice on the failed-verification path, the delivery evidence and completion-metrics record, systemic-finding Issue items routed to the privacy program, and the archived DSAR case file — the exported workflow record. Out of scope: unrelated privacy processes such as breach notification and privacy impact assessments, which run as their own workflows; this workflow takes no upstream handoff and produces no downstream workflow handoff.","edges":[{"id":"e-verify-identity-apply-exemptions-and-redactions","label":"Verified","source":"verify-identity","target":"apply-exemptions-and-redactions","whenValue":"verified"},{"id":"e-verify-identity-notify-rejection","label":"Rejected","source":"verify-identity","target":"notify-rejection","whenValue":"rejected"},{"id":"e-apply-exemptions-and-redactions-legal-release-review","source":"apply-exemptions-and-redactions","target":"legal-release-review"},{"id":"e-legal-release-review-deliver-and-record","label":"Full release","source":"legal-release-review","target":"deliver-and-record","whenValue":"approve_full"},{"id":"e-legal-release-review-document-exemption-basis","label":"Partial release","source":"legal-release-review","target":"document-exemption-basis","whenValue":"approve_partial"},{"id":"e-document-exemption-basis-deliver-and-record","source":"document-exemption-basis","target":"deliver-and-record"}],"isPublic":true,"metadata":{"capabilities":[],"controlVerbs":{},"controls":["UC-DATA-06","UC-DATA-08","UC-DATA-14"],"department":"privacy","domains":["reg"],"library":{"aliases":[],"canonicalUrl":"https://workflow-library.com/all/?w=reg-dsar-fulfillment","contentDigest":"sha256:8226ebb5176ad52f52c7a5ab46e65466771eac32bed5bc7d88069b47d6aaef39","prerequisites":{"status":"undeclared"},"provenance":[],"releaseId":"sha256:8226ebb5176ad52f52c7a5ab46e65466771eac32bed5bc7d88069b47d6aaef39","schemaVersion":1,"sourceTemplateId":"workflow-library:reg-dsar-fulfillment"},"lineOfDefense":"operate","mappingStatus":"mapped","risks":[],"slug":"reg-dsar-fulfillment","source":"coworkcanvas-gallery","standards":["gdpr","ccpa","hipaa"],"teams":["privacy"]},"name":"DSAR Fulfillment (Access & Deletion Requests)","nodes":[{"data":{"decisionField":"identity_check","description":"Agent gathers identity artifacts and drafts a match assessment against records on file; human makes the verification decision","formData":{"fields":[{"key":"identity_check","label":"Verify identity","options":[{"label":"Identity verified","value":"verified"},{"label":"Identity cannot be verified","value":"rejected"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Decide whether the requester — or their authorized agent — is who they claim to be, at a standard of proof proportionate to the sensitivity of the data at stake, before a single record is disclosed or deleted. The response owner decides on the documented match assessment.\n\n**Decision criteria**\n\nBuild the assessment first, from inputs that live in known places: the original request (channel, receipt date, scope) and every identity artifact submitted with it — identity documents, account identifiers, contact details, agent authorization papers — are uploaded to this step (external/requester-supplied uploads); the records to match against — account email, registered address, phone number, recent activity markers — live in the production customer/account systems, with the AssureSwarm copy of the comparison being the match assessment attached here; and the already-received request itself is the workflow's subject — this workflow instance IS the DSAR register entry, anchored to the existing DSAR-handling Process item, with the statutory clock already running from receipt. Log every identity artifact against the DSAR identifier and match it to the records on file. Verify with what the organization already holds rather than over-collecting: a request made from inside an authenticated account is largely self-verifying (require re-authentication, not a passport). Calibrate the bar to the stakes — the CCPA regulations give the working scale: a reasonable degree of certainty (two matched data points) for category-level access; a reasonably high degree of certainty (three matched points plus a signed declaration under penalty of perjury) for specific pieces of personal information or deletion of sensitive data (11 CCR §§ 7060–7062). Never verify using data you would then have to disclose (security answers), and use verification artifacts for verification only, then dispose of them. If the first pass is inconclusive, issue at most one documented follow-up naming the specific evidence required, and record the clock effect: under GDPR practice the response period runs from receipt of the identity evidence reasonably required (Art. 12(6)); under the CCPA the 45-day clock keeps running regardless of verification time. Score each artifact matched, partially matched, or failed, and flag every discrepancy.\n\n- **Identity verified (`verified`)** — every artifact the proportionate standard requires is matched: account re-authentication succeeded, or the two- or three-point match (with declaration where required) holds; for agent requests, signed authority is on file and the subject's own identity was verified or directly confirmed; discrepancies are resolved in writing, not waved through.\n- **Identity cannot be verified (`rejected`)** — after the single follow-up, the evidence still falls short of the standard; the agent cannot show authority; or affirmative fraud markers exist (artifacts internally inconsistent, contact details matching nothing on file, pressure to skip verification, a request aimed at another person's account). Rejection is never silence — the rejection branch owes the requester a reasoned notice inside the window, and a CCPA deletion request that fails verification is denied but processed as an opt-out of sale or sharing.\n\n**Record in AssureSwarm**\n- Attach the artifact log (XLSX) and the match assessment (DOCX/PDF) to this step (document upload); the uploaded request and identity artifacts also live on this step.\n- Record any follow-up evidence request and its clock effect in the match assessment on this step — there is no native DSAR item type, so the workflow instance is the register entry and carries the clock trail in its step documents.\n- Submit the decision form: `identity_check` (the branch), the step result citing the specific artifacts relied on or found lacking, and the step's approver record.\n\n**Exit criteria** — Form submitted with a rationale that names its evidence; no personal data disclosed before the decision; verification artifacts marked for disposal after use; the branch not selected is prunable.","kind":"decision","label":"Verify identity","performedBy":{"primitives":["coach-query-data","coach-document-upload"]}},"id":"verify-identity"},{"data":{"description":"Agent drafts the rejection letter with its legal basis and reopen conditions; human approves and sends it","instructions":"**Objective** — Tell the requester, inside the statutory window, that the request cannot be actioned because identity or agent authority could not be verified — with the legal basis, the exact evidence that would reopen the case, and their complaint routes — while disclosing nothing an impostor could use.\n\n**Inputs**\n- The rejected verification decision: the submitted `identity_check` form (branch, rationale, owner) plus the match assessment and follow-up trail documents on the verify-identity step.\n- The approved rejection template for the applicable regime — attached to the privacy notice-templates Policy item (policy_type: procedure) or, absent one, uploaded as a reference document at this step.\n- The register entry — this workflow instance: the channel and receipt date from the original request uploaded at verify-identity, and the remaining statutory window.\n\n**Procedure**\n1. Draft the letter from the approved template: the request cannot be actioned because identity (or agent authority) could not be verified, citing the basis — under GDPR, the controller is not in a position to identify the data subject (Arts. 11(2), 12(2)) and must, under Art. 12(4), state the reasons plus the right to lodge a complaint with the supervisory authority and to seek a judicial remedy; under the CCPA, explain the verification failure and the complaint routes to the California AG or the CPPA.\n2. State the reopen conditions concretely: name the artifact classes that would meet the proportionate standard (for example, a signed declaration plus two account data points) — never a bare \"additional information\".\n3. For a CCPA deletion request that failed verification, state that the request is being treated as an opt-out of sale or sharing, and confirm the opt-out was actually applied.\n4. Screen the letter for leakage: no personal data beyond what the requester themselves supplied, and no confirmation or denial of what the organization holds about the named subject — an unverified requester may be probing for exactly that.\n5. Compile the rejection memo — what was requested, what evidence was sought and when, why verification failed against the stated standard, who decided, and the reopen conditions — and link it to the DSAR identifier.\n6. Route for human approval of the legal basis and letter text, confirm the send lands inside the statutory window, send through the channel the requester used, and capture the delivery evidence.\n\n**Record in AssureSwarm**\n- Attach the approved rejection letter (PDF) and the rejection memo (DOCX/PDF) to this step (document upload).\n- Record the send date, channel, delivery evidence, and remaining statutory window in the rejection memo on this step — the workflow instance is the register entry; the rejected outcome is already carried by the `identity_check: rejected` branch, since no DSAR item type exists to hold a status field.\n- Link the anchor \"DSAR / Data-Subject Request Handling\" Process item to the workflow if not already linked (item link).\n\n**Exit criteria** — Letter approved and sent inside the statutory window through the requester's channel; delivery evidence attached; the memo states the standard applied, the evidence gap, the decision owner, and concrete reopen conditions; the opt-out is applied and noted where a CCPA deletion request failed verification.","label":"Notify rejection","performedBy":{"primitives":["coach-document-upload","coach-items-link"]}},"id":"notify-rejection"},{"data":{"description":"Convert the raw working set into a releasable (or deletable) set: every flagged record carries a proposed disposition with a specific legal citation, redactions are applied to working copies as a reviewable redlined package, and the privacy officer has ruled on each proposal individually.","instructions":"**Objective**\nConvert the raw working set into a releasable (or deletable) set: every flagged record carries a proposed disposition with a specific legal citation, redactions are applied to working copies as a reviewable redlined package, and the privacy officer has ruled on each proposal individually.\n\n**Inputs**\nThe verified identity package from the verify-identity step (the submitted `identity_check` form plus the match assessment document there): confirmed identifiers plus reasonable variants — every known email, prior names, customer and account IDs, normalized phone numbers, device and cookie IDs where they link back to the subject. Pseudonymized data that can be re-linked is in scope.\n- The data map / record of processing activities (GDPR Art. 30) as the search authority — attached as a reference document at this step (there is no native system/data-asset item type); the processing activities themselves may exist as Process items. Coverage: production databases, analytics stores, logs, backups, unstructured stores (shared drives, ticketing tools, email), and third-party processors.\n- The processor register — Vendor items (category: data_processing, with tier, data_classification, business_owner, risk_owner, monitoring_status) — with processor contacts and the assistance clause in each DPA (extracts attached to the Vendor item or to this step). Art. 28(3)(e) obliges processors to act on the controller's instructions for rights requests.\n- The regime's temporal scope: CCPA look-back is 12 months minimum, and beyond that on request for data collected after January 1, 2022 unless impossible or disproportionate.\n\nThe released working set (in its access-controlled external store) with the source index and the third-party, privilege, and trade-secret flags — documents on the apply-exemptions-and-redactions step.\n- The exemption playbook mapped to the regime(s) — a Policy item (policy_type: procedure, framework spanning gdpr | ccpa | hipaa) with the playbook document attached: third-party rights, legal professional privilege, trade secrets, ongoing investigations.\n- The retention schedule — a Policy item (policy_type: standard) with the schedule document attached — and any active legal holds that constrain a deletion scope, cited by hold identifier (there is no native legal-hold item type).\n\n**Procedure**\n*Agent retrieval, preparation and filing absorb “Locate and compile data”; the responsible roles retain their judgments and all independent sign-offs within this checkpoint.*\n\n1. Assessment scope for Locate and compile data: Produce a complete, deduplicated, access-controlled working set of everything the organization and its processors hold on the verified subject, with a source index proving where each record came from and an affirmative nil from every system that holds nothing.\n\n2. Enumerate every system in the data map and run the searches with the verified identifiers and variants. The data map is the completeness yardstick a regulator applies: a system listed there with no recorded search result is the finding.\n3. Issue processor instructions with internal due dates that leave margin — no later than half the remaining statutory window — and chase owners and processors before, not after, those dates lapse.\n4. Capture per-system results: exact search parameters, result counts, locations. Any system that returns nothing gets an explicit, attributed nil return — silence is not none.\n5. Decide the backup position and write it down: disclose what is reasonably retrievable; for a deletion scope, the standard treatment is delete from live systems now and let backup copies age out on the rotation cycle, with a documented safeguard that restored data is re-deleted (the \"beyond use\" position).\n6. Compile the located records into a single access-controlled working set restricted to the case team — the compilation is itself a new high-sensitivity store. Deduplicate, and verify each record genuinely relates to the verified subject: an identifier collision puts a stranger's data one step from disclosure.\n7. Alter and delete nothing during collection — early deletion destroys the ability to respond accurately, and under a litigation hold it is spoliation.\n8. Build the source index mapping every compiled record to its originating system, and flag records containing other people's personal data or privileged, confidential, or trade-secret material for the exemption step.\n9. Route for the human completeness review: every data-map system reported results or an affirmative nil, no known source is unaccounted for, and the third-party and privilege flags look plausible — then release the working set to exemption and redaction analysis.\n\n10. Assessment scope for Apply exemptions and redactions: Convert the raw working set into a releasable (or deletable) set: every flagged record carries a proposed disposition with a specific legal citation, redactions are applied to working copies as a reviewable redlined package, and the privacy officer has ruled on each proposal individually.\n\n11. Screen every record and flag against the playbook. For access requests the operative law: GDPR Art. 15(4) — the copy must not adversely affect the rights and freedoms of others, so mixed records (emails, complaints, shared documents) get third-party identities redacted while the subject's own data is still released; Recital 63 — trade secrets and IP may shape the copy but never justify refusing all information; Art. 23 national-law restrictions for matters like ongoing investigations.\n12. Apply the CCPA never-disclose rule regardless of verification strength: no response may reproduce SSNs, government ID numbers, financial account numbers, health insurance or medical IDs, account passwords, security questions and answers, or unique biometric data — state with particularity that the category is held, without the value.\n13. For deletion requests, screen against the exception grounds: CCPA §1798.105(d) (completing the transaction, security-incident detection, debugging, legal compliance, compatible internal uses) and GDPR Art. 17(3) (freedom of expression, legal obligation, legal claims). Statutory retention (tax, AML/KYC) and litigation holds override deletion — cite the specific statute or hold identifier, never \"legal reasons\".\n14. Propose a disposition per flagged item with a written justification citing the provision: release, redact, or withhold on an access request; delete, anonymize, or retain-with-basis on a deletion request. Anonymization counts as deletion only when re-identification is no longer reasonably possible — name the technique and what happens to the linkage keys.\n15. Apply the proposed redactions to working copies and produce the redlined package showing every mark-up in context. Redactions must be irreversible in the artifact: no text layer under black boxes, document metadata and hidden content stripped, spreadsheet hidden rows, columns, and formulas checked.\n16. Assemble the exemption log — every proposed exemption, redaction, and retention conflict with its citation — plus per-system deletion plans (method, backup treatment, processor instructions and certificates due) for the proposed deletion scope.\n17. The privacy officer reviews the redlined package and rules on each proposal individually — approve or overrule, never in bulk — confirms every withheld or retained item cites a specific provision rather than a generic concern, and initials the log entries that stand.\n\n**Record in AssureSwarm**\nAttach the search log (XLSX/CSV: per-system parameters, counts, nil returns) and the source index (XLSX) to this step (document upload). The compiled working set itself stays in the access-controlled external store — it is never uploaded to AssureSwarm.\n- Attach the processor instruction-and-response trail to this step and link each engaged processor's Vendor item to the workflow (item link).\n- Attach the backup-treatment decision memo, noting the human completeness-review release, as a document on this step — neither has a native item field.\n\nAttach the redlined package (PDF/ZIP) and the exemption log with the privacy officer's per-item rulings (XLSX) to this step (document upload).\n- Attach the per-system deletion plans as a document on this step — there is no native DSAR item to carry them; query the source index to confirm every flag received a disposition.\n\n**Exit criteria**\nEvery system in the data map shows results or an affirmative nil; processor returns are in or escalated; the source index covers every compiled record; third-party and privilege flags recorded; the working set is access-controlled and released by the human reviewer. Every flagged record has a ruled disposition with a specific citation; the redlined package shows each redaction in context and passes the irreversibility check; deletion plans exist for every in-scope system; the exemption log carries the privacy officer's initials on every standing entry.\n\n> **⚡ Audit Artist accelerator:** `/coach-redact` applies the proposed redactions to the working copies and produces the redlined package with irreversible marks.","label":"Apply exemptions and redactions","performedBy":{"note":"","primitives":["coach-query-data","coach-document-upload","coach-redact","coach-items-link"]}},"id":"apply-exemptions-and-redactions"},{"data":{"decisionField":"release_decision","description":"Agent assembles the final package and exemption log for counsel; human counsel decides between full and partial release","formData":{"fields":[{"key":"release_decision","label":"Legal release review","options":[{"label":"Approve full release","value":"approve_full"},{"label":"Approve partial release with exemptions","value":"approve_partial"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Counsel's gate before anything leaves the building: decide whether the assembled response package goes out in full or with the approved exemptions and redactions standing, with enough margin left to deliver on time.\n\n**Decision criteria**\n\nAssemble the review materials first. The final package matches the request type: an access disclosure set carrying every regime particular — under GDPR Art. 15(1)(a)–(h) and 15(3), the purposes, categories, recipients (named recipients when the subject asks, per CJEU C-154/21), retention period or criteria, the subject's further rights, the source where data was not collected from the subject, automated decision-making with meaningful logic, and the copy itself; under CCPA, categories, sources, purposes, third parties, and the specific pieces in a portable, readily usable format — or a deletion certificate with per-system confirmations, method, backup treatment, processor certificates, and the stated basis for anything retained. Attach the ruled exemption log and the redlined package so every withheld or retained item traces to its citation. Verify the redactions are irreversible in the final artifacts — burned in, not visual overlays — and that nothing exempt leaks through metadata, hidden text, embedded objects, or attachments. Summarize the deadline position, exemptions applied, and open conditions in a one-page brief. Counsel then tests each exemption against one question — would we defend this citation to the supervisory authority or the AG? — and spot-checks the redactions, remembering that over-redaction is itself a failure: Art. 15(4) narrows the copy, it never swallows the right. Whichever branch, the decision must leave delivery margin (as a working rule, at least five business days of the window); if the operative date cannot be met, the extension notice with reasons goes out before the original due date — decided here, not discovered at delivery.\n\n- **Approve full release (`approve_full`)** — no exemption or redaction survives counsel's challenge (all proposals withdrawn, or none were made): the deliverable is the complete compiled set with every regime particular, and withdrawn redactions are removed from the final artifacts before delivery.\n- **Approve partial release with exemptions (`approve_partial`)** — at least one exemption, redaction, or retention basis stands, each traced to a specific provision; the requester-facing explanation still has to be drafted and approved in the next step; counsel's conditions (items to unredact, citations to tighten) are recorded and must be resolved before the package is resealed.\n\n**Record in AssureSwarm**\n- Attach the one-page review brief (PDF) and the assembled final package version — the access disclosure set or deletion certificate — to this step (document upload); the ruled exemption log stays on the apply-exemptions step where it was produced.\n- Submit the decision form: `release_decision` (the branch), the step result naming the citations tested and any conditions attached, and the step's approver record.\n\n**Exit criteria** — Form submitted; every withheld or retained item traceable to a citation counsel accepted; the redaction-irreversibility check documented; the remaining margin to the operative due date stated in the rationale; the branch not selected is prunable.\n\n> **⚡ Audit Artist accelerator:** `/coach-render-package` assembles the disclosure set or deletion certificate with the exemption log and flattened redactions into the counsel-review package.","kind":"decision","label":"Legal release review","performedBy":{"primitives":["coach-document-upload","coach-items-link","coach-render-package"]}},"id":"legal-release-review"},{"data":{"description":"Agent finalizes per-item citations and the requester-facing exemption explanation; human privacy officer approves the final text","instructions":"**Objective** — Turn counsel's partial-release decision into the final legal record: per-item citations locked exactly as approved, a requester-facing explanation that acknowledges what the law requires while revealing nothing exempt, and the package resealed as the sole release candidate.\n\n**Inputs**\n- Counsel's decision record: the submitted `release_decision` form (branch, rationale, owner) on the legal-release-review step, the ruled exemption log, and the conditions attached to the partial-release decision.\n- The current package version (document on the legal-release-review step) and the redlined artifacts (documents on the apply-exemptions step).\n- The regime's notice duties: GDPR Art. 12(4) reasons plus complaint and judicial-remedy routes; CCPA denial-explanation rules for deletion — delete what is deletable, name the exception for the rest.\n\n**Procedure**\n1. Resolve every condition counsel attached — unredact the named items, tighten the named citations — then finalize the per-item citations in the exemption log exactly as approved. Nothing enters the log that counsel did not rule on.\n2. Draft the requester-facing explanation: state that material was withheld or retained and on what grounds, to the degree the regime requires — a named exception category under CCPA; reasons plus the supervisory-authority complaint route and judicial remedy under GDPR — without reproducing or describing the exempt content itself.\n3. Where acknowledging an exemption would defeat it (an ongoing-investigation restriction under Art. 23 national law), a neither-confirm-nor-deny posture is its own logged decision with its own justification — never a silent omission.\n4. Cross-check the explanation against the exemption log both ways: every standing log entry is acknowledged in the explanation or carries a documented reason it cannot be; nothing appears in the explanation without a log entry behind it.\n5. Merge the explanation and the final exemption memo into the response package and reseal it as a new approved version that supersedes — never overwrites — the prior one, referencing counsel's decision.\n6. The privacy officer approves the explanation and the final memo — confirming the text acknowledges withholding where the law requires acknowledgment yet reveals nothing exempt — and releases the resealed package for delivery.\n\n**Record in AssureSwarm**\n- Attach the final exemption memo (DOCX/PDF), the requester-facing explanation, and the resealed package version — superseding, never overwriting, the prior version — to this step (document upload).\n- Record the privacy officer's approval on this step (step approval).\n\n**Exit criteria** — Per-item citations final and condition-free; the two-way log-to-explanation cross-check documented; the resealed version identified as the sole release candidate; the privacy officer's approval recorded.","label":"Document exemption basis","performedBy":{"primitives":["coach-document-upload","coach-items-link"]}},"id":"document-exemption-basis"},{"data":{"description":"Agent delivers the sealed package through the secure channel inside the deadline, records completion metrics, routes systemic findings and archives the case file with working copies disposed of; human confirms the delivery and closes the case","instructions":"**Objective** — Get the sealed, approved package to the verified requester through a channel bound to their verified identity on or before the operative due date, then close the case: metrics and systemic findings routed, the file archived to retention, and every working copy of the subject's data disposed of.\n\n**Inputs**\n- The sealed approved package — the full-release version on the legal-release-review step or the resealed partial-release version on the document-exemption-basis step — the only artifact authorized to leave.\n- The identity-channel binding from the verify-identity step (its form and match assessment), and the requester's original channel and format preference from the request uploaded there.\n- The operative due date: the statutory date as adjusted by any extension already noticed.\n- The case's accumulated completion data across this instance's prior steps (forms and documents): checkpoint dates, systems searched, records located, exemptions applied, rework causes — and, for the archive, the full case trail for the branch that closed the case (request and verification evidence on verify-identity, source index on apply-exemptions-and-redactions, exemption log on apply-exemptions-and-redactions, package version and manifest on the release steps).\n- The retention rule for DSAR records themselves: CCPA regulations require records of requests and responses for at least 24 months (11 CCR § 7101); GDPR accountability (Art. 5(2)) aligns retention to the program schedule and limitation periods.\n- The inventory of working copies created during the case: the compiled working set, redline intermediates, verification artifacts.\n\n**Procedure**\n_The response owner authorizes the sealed version and identity-bound delivery channel in procedure item 3 before transmission. Subsequent delivery reconciliation, filing and closure run under that recorded authorization._\n1. Choose the channel by identity binding, strongest first: the authenticated account portal; otherwise an encrypted package with credentials passed over a separate channel. Never the data set as a plain email attachment. Match the regime's format duty — a commonly used electronic form when the request came in electronically (GDPR Arts. 12(3), 15(3)); through the account or, absent one, by mail or electronically in a portable, readily usable format under CCPA.\n2. If the operative date is at risk, do not deliver late — issue the permitted extension notice with reasons, approved before the original due date: GDPR two further months noticed within the first month; CCPA one additional 45 days noticed within the first 45; HIPAA one 30-day extension on written notice. Recompute and record the new operative date.\n3. Obtain the response owner’s native authorization of the sealed approved version and verified identity-bound channel, then transmit on or before the operative date and capture the delivery evidence the channel allows — transmission log, download or portal-access receipt, tracking number — each tied to the verified identity.\n4. For a deletion request, the deliverable is the deletion confirmation with the explanation of anything retained; confirm the processor and third-party deletion notifications the regime requires went out and their certificates are in or being chased.\n5. Record the completion metrics: elapsed days against the deadline, extension usage, systems searched, records located, exemptions applied, and the causes of any rework.\n6. File the case: the delivery evidence, package manifest, decision rationales, and metrics all sit on this instance's steps under the DSAR identifier — the workflow instance is the register entry.\n7. Flag systemic findings — a system missing from the data map, a processor that responded late, a verification gap — as Issue items (issue_type: observation, source: compliance_review) with proposed owners, each linked to the Process, Control, or Vendor item it concerns.\n8. Verify closability against the branch checklist before archiving — a hole in the archive is the finding a regulator writes up. On the fulfilled path every artifact from intake through delivery proof must be present and internally consistent, the manifest matching the delivered version.\n9. Export the full workflow record and archive the case file to the retention location; set the retention date per the DSAR-records schedule. Verify retrievability by opening the archived copy.\n10. Securely dispose of every working copy recordkeeping does not require — the compiled working set is a new store of the subject's data and must not outlive the case; on a deletion case, retaining it would quietly undo the deletion just performed. Keep the request, the response and the decision trail, not the data trove, and record the disposal confirmations.\n11. Record the archive confirmation; post-archive corrections are new dated addenda, never edits to archived artifacts.\n12. Assemble the closure record — archive reference, closure timestamp, retention date — and notify the response owner and privacy officer; completing this instance closes the register entry (the register is the set of these workflow instances).\n13. After the authorized delivery, record completion by checking that the delivery went to the verified requester through the bound channel; the delivered artifact is the sealed approved version (version identifier match); the delivery date beats the operative deadline; the metrics and finding routing stand; the archive is self-contained and no working copies remain outside it.\n\n**Record in AssureSwarm**\n- Attach the delivery evidence (transmission log, portal receipt, or tracking record), the package manifest, the disposal confirmations and the closure record — carrying the archive reference, closure timestamp and retention date — to this step; there is no native DSAR item to hold these as fields, so the closure record on this step is authoritative.\n- Export the completion-metrics record (CSV) and attach it here — the workflow instance is the register entry, so the case metrics live on the run.\n- Create one Issue item per systemic finding — issue_type: observation (deficiency where a control failed), source: compliance_review, severity, issue_owner, identified_date, description — and link each Issue to the affected Process, Control, or processor Vendor item (item relationship).\n- Refresh the DSAR metrics dashboard (cycle time, extension rate, exemption mix) from the register of workflow instances.\n- Export the full workflow record as the archive package (workflow export); the archived instance, anchored to the DSAR-handling Process item, is the audit trail and the register entry's closed state.\n\n**Exit criteria** — Delivery evidence shows the sealed approved version reached the identity-bound channel on or before the operative date; any extension was noticed before the original deadline with reasons; metrics recorded and systemic findings routed with owners; the archive is verified retrievable and complete against the branch checklist; disposal confirmations cover every working copy outside the archive; the register shows the case closed with its archive reference, under the response owner’s recorded release authorization with the privacy officer notified.\n\n> **⚡ Audit Artist accelerator:** `/coach-notify` sends the delivery and any extension notice through the recorded channel and logs the transmission evidence; `/coach-workflow-export` assembles the complete workflow record with its attachments as the archive package.","label":"Deliver and record","performedBy":{"primitives":["coach-export-package","coach-item-create","coach-dashboard-create","coach-items-link","coach-notify","coach-workflow-export","coach-document-upload"]}},"id":"deliver-and-record"}],"sourceTemplateId":"workflow-library:reg-dsar-fulfillment"}