{"description":"GDPR Article 35 data protection impact assessment as a decision-aware workflow, run on the existing Process item (process_type=business_process) that represents the processing activity under assessment — the Process item doubles as the AssureSwarm proxy for the activity's records-of-processing (RoPA) entry, and the instance enriches it rather than creating a duplicate. It draws on upstream evidence — the RoPA extract, the data inventory and data-flow map, the Article 28 processor arrangements and transfer impact assessment from vendor due diligence, and the security risk assessment for the hosting systems — and moves the activity from screening, through necessity and proportionality and privacy-risk treatment, to a residual-risk decision with Article 36 prior consultation where needed and DPO sign-off. The named deliverable is the signed, versioned DPIA package (or, on the screened-out path, a defensible screening memo), registered against the Process item with tracked mitigation actions; close-and-archive hands that package off to records-of-processing maintenance. In scope: one processing activity (or a set of similar operations with comparable risks per Article 35(1)) from screening through sign-off; out of scope: the related workflows it draws on or feeds — vendor due diligence for new processors, transfer impact assessment for third-country transfers, security risk assessment for the hosting systems, and the records-of-processing maintenance that absorbs the outcome.","edges":[{"id":"e-screen-for-dpia-document-screening-outcome","label":"No DPIA required","source":"screen-for-dpia","target":"document-screening-outcome","whenValue":"not_required"},{"id":"e-screen-for-dpia-describe-and-assess","label":"Run full DPIA","source":"screen-for-dpia","target":"describe-and-assess","whenValue":"required"},{"id":"e-document-screening-outcome-close-and-archive","source":"document-screening-outcome","target":"close-and-archive"},{"id":"e-describe-and-assess-evaluate-residual-risk","source":"describe-and-assess","target":"evaluate-residual-risk"},{"id":"e-evaluate-residual-risk-consult-authority","label":"Consult authority","source":"evaluate-residual-risk","target":"consult-authority","whenValue":"consult_authority"},{"id":"e-evaluate-residual-risk-signoff-and-register","label":"Risk acceptable","source":"evaluate-residual-risk","target":"signoff-and-register","whenValue":"acceptable"},{"id":"e-consult-authority-signoff-and-register","source":"consult-authority","target":"signoff-and-register"},{"id":"e-signoff-and-register-close-and-archive","source":"signoff-and-register","target":"close-and-archive"}],"isPublic":true,"metadata":{"capabilities":[],"controlVerbs":{},"controls":["UC-RISK-16"],"department":"privacy","domains":["reg"],"library":{"aliases":[],"canonicalUrl":"https://workflow-library.com/all/?w=reg-dpia-privacy-impact-assessment","contentDigest":"sha256:067c568dd4441d2e2af151c0e54d600bf0756560cae3f64ccce9b450523a9e04","prerequisites":{"status":"undeclared"},"provenance":[],"releaseId":"sha256:067c568dd4441d2e2af151c0e54d600bf0756560cae3f64ccce9b450523a9e04","schemaVersion":1,"sourceTemplateId":"workflow-library:reg-dpia-privacy-impact-assessment"},"lineOfDefense":"operate","mappingStatus":"mapped","risks":[],"slug":"reg-dpia-privacy-impact-assessment","source":"coworkcanvas-gallery","standards":["gdpr"],"teams":["privacy"]},"name":"DPIA / Privacy Impact Assessment","nodes":[{"data":{"decisionField":"dpia_required","description":"Agent screens the activity against Article 35 criteria and drafts the screening memo; the DPO decides whether a full DPIA is required","formData":{"fields":[{"key":"dpia_required","label":"Screen for DPIA","options":[{"label":"Full DPIA required","value":"required"},{"label":"No DPIA required","value":"not_required"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Decide whether Article 35 requires a full DPIA for this processing activity. The DPO owns the decision, made on a screening memo that dispositions every criterion with evidence.\n\n**Inputs**\n- The processing activity under assessment — the anchor Process item (process_type=business_process, process_owner set); this workflow instance attaches to it, and the item stands in for the activity's records-of-processing (RoPA) entry.\n- The RoPA extract (lawful basis, data categories, retention) and the data inventory / data map with approximate data-subject and volume figures — uploaded to this step (PBC/external); no native RoPA or data-inventory item type exists, so both enter as step documents.\n- GDPR Article 35 criteria, the WP248 nine-criteria list, and the applicable authority's Article 35(4)/(5) screening lists — external regulator publications; the AssureSwarm copy is the edition and date cited inside the screening memo attached here.\n\n**Decision criteria**\n\nScreen the processing activity against three layers before picking a branch: (1) the Article 35(3) examples — systematic and extensive profiling with legal or similarly significant effects, large-scale processing of special-category or criminal-offence data, systematic large-scale monitoring of publicly accessible areas; (2) the applicable supervisory authority's screening lists — the Article 35(4) mandatory list and any Article 35(5) exemption list, citing the list edition used; (3) the WP248 nine criteria — evaluation or scoring, automated decisions with legal or similar effect, systematic monitoring, sensitive or highly personal data, large scale, matching or combining datasets, vulnerable data subjects (including employees), innovative technology, and processing that blocks a right or service — plus internal thresholds such as new technologies or vulnerable groups. Mark every criterion met or not met with an evidence reference to the records of processing and the data inventory; draft the screening memo with the recommended outcome.\n\n- **Full DPIA required (`required`)** — the activity appears on the authority's Article 35(4) list; or matches an Article 35(3) example; or meets two or more WP248 criteria; or meets one criterion and the team cannot demonstrate the impact is limited. Doubt resolves toward `required` — WP248's own recommendation, and the cost asymmetry supports it.\n- **No DPIA required (`not_required`)** — no mandatory-list entry applies, and at most one WP248 criterion is met with demonstrably limited impact, or an exemption list or a still-valid DPIA covering a materially similar set of operations applies. This branch is defensible only when every criterion is individually dispositioned with evidence — \"we do not consider it high risk\" is not a screening record.\n\n**Record in AssureSwarm**\n- Submit the decision form: `dpia_required` (the branch), the step result with the criterion-by-criterion outcome and evidence references, and the step's approver record — the DPO. The form may arrive pre-filled with the memo's recommendation; the DPO's submission is the decision.\n- Attach the screening memo to this step.\n\n**Exit criteria** — Form submitted with every criterion dispositioned and evidence-referenced; DPO recorded as decision owner; the not-taken branch is prunable because the memo fully supports the taken one.","kind":"decision","label":"Screen for DPIA","performedBy":{"primitives":["coach-form-fill","coach-document-upload"]}},"id":"screen-for-dpia"},{"data":{"description":"Agent files the screening memo with justification and reopening triggers; the privacy team confirms the negative decision is defensible","instructions":"**Objective** — Leave a defensible, criterion-by-criterion record of the decision that no full DPIA is required, with concrete reopening triggers and a review date — Article 5(2) accountability applies even where Article 35 does not.\n\n**Inputs**\n- The submitted screening decision form and its rationale.\n- The screening memo draft and the evidence it cites: records-of-processing entry, data inventory extracts, authority list references.\n- The records-of-processing entry for the activity.\n\n**Procedure**\n1. Finalize the memo so each criterion applied states *why* its threshold was not met — e.g. \"not large scale: ~1,200 subjects in one member state, one data category, 12-month retention\" — citing the WP248 scale factors (number of subjects, volume and range of data, duration, geographic extent) wherever scale was the discriminator. A bare \"not met\" will not survive a regulator's or auditor's second look.\n2. Cite the authority screening lists checked, with version or publication date — the lists change, and the memo must show which edition the decision relied on.\n3. Record the reopening triggers as checkable conditions: change of scope or purpose, new data categories or subject populations, new technology, new vendor or transfer, a relevant incident or breach, or new regulator guidance touching this activity type.\n4. Record the review date and name the re-screen owner — annual is typical for screened-out activities, shorter where the product roadmap makes change likely.\n5. Obtain DPO concurrence on the memo. The negative decision is the one most likely to be challenged later, so it carries the same sign-off discipline as a positive one.\n\n**Record in AssureSwarm**\n- Attach the final screening memo (DOCX/PDF) and the supporting evidence documents to this step.\n- Link the memo document to the anchor Process item (the RoPA proxy) and note the screening reference and its version in Process.description. Process has no review-date or reopening-trigger fields, so record the review date, the named re-screen owner, and the reopening triggers as a checklist on this step record (honest RoPA gap — the true register is not a native type).\n- Flag the Process item on the privacy team's saved item view so scope or purpose changes surface for re-screening (no native watchlist field — the open-item view is the tracker).\n\n**Exit criteria** — Memo filed with per-criterion justification and list editions cited; DPO concurrence recorded; reopening triggers and review date set with a named re-screen owner; the memo linked to the Process item.","label":"Document screening outcome","performedBy":{"primitives":["coach-document-upload"]}},"id":"document-screening-outcome"},{"data":{"description":"Agent drafts the processing description, data-flow map, and necessity and proportionality analysis; the privacy team reviews accuracy","formData":{"fields":[{"key":"groups_represented","label":"The people or groups you speak for in this consultation","required":true,"type":"text"},{"helperText":"What you expected, what surprised you, and whether the described purpose seems reasonable.","key":"views_on_intended_processing","label":"Your views on the intended processing as described to you","required":true,"type":"textarea"},{"helperText":"Concrete effects on the people affected — not organisational risk.","key":"main_concerns","label":"The specific harms or consequences you are most concerned about","required":true,"type":"textarea"},{"key":"proportionality_view","label":"Is the processing proportionate to its stated purpose, in your view?","options":[{"label":"Proportionate as described","value":"proportionate"},{"label":"Proportionate only with the changes described below","value":"proportionate_with_changes"},{"label":"Not proportionate","value":"not_proportionate"}],"required":true,"type":"select"},{"key":"suggested_safeguards","label":"Safeguards, limits, or alternatives you would want in place","required":false,"type":"textarea"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Build the DPIA's factual foundation: the systematic description of the processing (Article 35(7)(a)) and the necessity-and-proportionality assessment (Article 35(7)(b)), validated against how the systems actually behave rather than how the spec says they should.\n\n**Inputs**\n- The records-of-processing entry for the activity, plus the screening decision and memo that required this DPIA.\n- System documentation: architecture diagrams, data dictionaries, integration specs, retention configuration.\n- Contracts and the Vendor register: Article 28 processor agreements with sub-processor disclosures, transfer mechanisms (adequacy decisions, SCCs plus transfer risk assessments), any joint-controller arrangement — processors already in the register arrive as Vendor items; new ones are added here.\n- The privacy notices and consent flows shown to the affected data subjects.\n\n**Procedure**\n1. Draft the systematic description: nature, scope, context, and purposes of the processing; categories of personal data and of data subjects with approximate volumes; collection sources (direct, third party, observed, inferred); storage locations and retention periods per category; and recipients, processors, and every international transfer with its Article 46 safeguard named.\n2. Draft the end-to-end data-flow map, collection through deletion, across the named systems and vendors. Every arrow names the data categories it carries and the mechanism (API, file transfer, manual). Walk it with the system owner — the gap between designed and actual flows is where DPIAs fail.\n3. Test necessity purpose by purpose: identify the Article 6 lawful basis (plus an Article 9(2) condition for special categories; reference the balancing test where the basis is legitimate interests), then ask the minimisation question concretely — could this purpose be met with fewer fields, aggregated or pseudonymised data, shorter retention, or less intrusive means? Record the alternatives considered and why they were rejected; \"we might need it later\" fails Article 5(1)(c).\n4. Test proportionality: retention per category evidenced by configured deletion, not policy prose; transparency — where and when data subjects are informed per Articles 13/14; and the actual mechanism by which each right (access, rectification, erasure, restriction, portability, objection, and Article 22 safeguards for automated decisions) will be honoured in these systems.\n5. Verify processor arrangements: Article 28 clauses in place for every processor in the flow, sub-processor chains disclosed, and transfer safeguards valid — for third-country transfers post-Schrems II, SCCs plus a documented transfer risk assessment.\n6. Decide and document data-subject consultation: Article 35(9) requires seeking the views of data subjects or their representatives where appropriate — plan it (user research, survey, works council) or record the specific justification for not consulting; the DPIA must state one or the other. Where consultation runs, send this step's form to each representative or participant so their views arrive in a comparable, citable shape rather than as meeting recollections.\n7. Review with the privacy team and system owners; correct the description against real practice before it becomes the basis for the risk assessment.\n\n**Record in AssureSwarm**\n- Attach the processing description, data-flow map, and necessity-and-proportionality analysis to this step (DOCX/PDF plus the flow diagram).\n- For each processor in the flow, link the anchor Process item to its Vendor item (category=data_processing, data_classification, tier, business_owner, risk_owner); create the Vendor item where the processor is not yet in the register. The Article 28 agreement, sub-processor disclosures, and transfer mechanism (adequacy decision or SCCs plus the transfer impact assessment) attach as evidence documents on this step — there is no Contract field, so each agreement lives as an attached document.\n- Link the privacy notices and consent flows as evidence documents on this step.\n- Record the consultation decision (done or not, with justification) and the system-owner review sign-off on this step. Where consultation ran, the form on this step, answered by the data subjects or their representatives, captures the groups respondents speak for, their views on the intended processing, their main concerns, their proportionality view and desired safeguards; bind the invited role and native response timestamp to the assignment — carry those responses into the risk table's affected-group and severity reasoning, and record any view the assessment departs from with the reason.\n\n**Exit criteria** — Description and flow map validated by system owners against actual behaviour; every purpose has a lawful basis and a documented minimisation test; retention, rights-handling, and transfer safeguards evidenced; consultation decision recorded; privacy team approves the package as the risk-assessment basis.\n\n**Form recipient** — this step's form is answered by *the data subjects or their representatives consulted under Article 35(9)*, not by the step owner. Send it with a form assignment; the owner's own work goes in the step result.","label":"Describe and assess","performedBy":{"primitives":["coach-document-upload","coach-item-create","coach-items-link"]}},"id":"describe-and-assess"},{"data":{"decisionField":"residual_risk","description":"Decide whether residual risk after planned mitigations is acceptable or requires prior consultation with the supervisory authority under Article 36. The DPO and the accountable owner decide together, on an assembled draft DPIA.","formData":{"fields":[{"key":"residual_risk","label":"Evaluate residual risk","options":[{"label":"Residual risk acceptable","value":"acceptable"},{"label":"Consult supervisory authority","value":"consult_authority"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective**\nDecide whether residual risk after planned mitigations is acceptable or requires prior consultation with the supervisory authority under Article 36. The DPO and the accountable owner decide together, on an assembled draft DPIA.\n\n**Decision criteria**\nInputs and preparation before selecting the branch:\nThe approved processing description and data-flow map from the previous step.\n- The privacy risk taxonomy and existing risk register items for related systems.\n- Incident and breach history for the same data or systems; security assessment results for the hosting systems and vendors.\n\n*Agent retrieval, preparation and filing absorb “Identify risks and mitigations”; the responsible roles retain their judgments and all independent sign-offs within this checkpoint.*\n\n1. Assessment scope for Identify risks and mitigations: Produce a validated risk table — risks to data subjects' rights and freedoms, proportionate mitigations with owners, and residual ratings — satisfying Article 35(7)(c) and (d) and feeding the residual-risk decision.\n\n2. Enumerate risks by walking every node and arrow of the data-flow map against the risk register and the privacy risk taxonomy, asking what could harm the data subject — not the organisation. Cover at minimum: unlawful or illegitimate access (breach, insider, third-country government access), unwanted modification, data loss, re-identification of pseudonymised or aggregated data, function creep beyond stated purposes, inaccurate data driving decisions, discriminatory or unfair outcomes from profiling or automated decisions, and chilling effects from monitoring. Tie each risk to its source — a specific flow, system, vendor, or practice — and the affected data subject groups.\n3. Rate inherent likelihood and severity from the data subject's perspective; the CNIL PIA scales are the common reference. Severity weighs identifiability, data sensitivity, and the reversibility of physical, material, and non-material harms (Recital 75); likelihood weighs threat sources, vulnerabilities, and existing controls. A small file of health data on vulnerable people can be maximum severity; a large file of business contact emails may be limited.\n4. Propose proportionate technical and organisational mitigations per risk: pseudonymisation or tokenisation at collection, encryption in transit and at rest with key separation, role-based access controls with recertification, retention automation, enhanced transparency, human review of automated decisions with real override authority. Each mitigation gets a suggested owner and due date — an unowned mitigation is a wish, not a measure.\n5. Compute residual likelihood and severity assuming the mitigations are implemented as designed, and be honest about partial coverage — encryption does not mitigate authorised-user misuse. Flag every risk whose residual rating remains high; those flags drive the Article 36 decision at the following procedure.\n6. Have the privacy team validate the table: adjust any rating they disagree with (recording why), confirm each mitigation's fit and feasibility with its proposed owner, and lock the version that feeds the residual-risk decision.\n\n7. Assessment scope for Evaluate residual risk: Decide whether residual risk after planned mitigations is acceptable or requires prior consultation with the supervisory authority under Article 36. The DPO and the accountable owner decide together, on an assembled draft DPIA.\n\n\n\nBefore picking a branch, assemble the draft DPIA record — processing description, data-flow map, necessity-and-proportionality analysis, and the validated risk table with residual ratings — and compare every residual rating against the organisation's risk appetite and the Article 36(1) test: consultation is mandatory where the processing would still result in a high risk absent further mitigating measures, i.e. where residual risk remains high after all identified, feasible mitigations.\n\n- **Residual risk acceptable (`acceptable`)** — no risk's residual rating remains high; every high inherent risk has mitigations that demonstrably reduce it, each owned and scheduled before processing begins (or covered by a compensating interim measure); and remaining medium and low residuals sit inside documented risk appetite. Each accepted residual names its acceptor — acceptance is the accountable owner's act, not the assessor's.\n- **Consult supervisory authority (`consult_authority`)** — at least one residual risk remains high and no further proportionate mitigation is available, or the mitigations that would reduce it cannot be in place before processing must begin, or the authority's guidance mandates consultation for this processing type. In-scope processing must not begin until the consultation concludes.\n\nDo not stretch `acceptable` to dodge the consultation clock: an unconsulted high residual risk is an Article 36 breach and strips the DPIA of its protective value in any later enforcement.\n\n**Record in AssureSwarm**\nCreate a Risk item per identified risk (category=privacy, taxonomies=data_privacy, domains=data_protection_privacy, likelihood, impact, inherent_rating, treatment=mitigate, risk_owner; residual_rating set once the mitigations are agreed). The risk's source (the specific flow, system, or vendor), the affected data-subject groups, and the proposed mitigation with its owner and due date have no native Risk fields — capture them in Risk.description and in the consolidated risk table, never as invented fields.\n- Relationship: link each Risk item to the anchor Process item.\n- Attach the consolidated risk table to this step (XLSX).\n- Record the validation — who reviewed, which ratings were adjusted and why — as comments on the adjusted Risk items.\n\nSubmit the decision form: `residual_risk` (the branch), the step result naming each flagged risk item and its residual rating with evidence references, and the step's approver record — the DPO plus the accountable owner. The form may arrive pre-filled with the recommended outcome; the submission is the decision.\n- Link the draft DPIA and the version-locked risk table to this step.\n\n**Exit criteria**\nEvery data-flow element considered; each risk carries source, affected groups, inherent and residual ratings, and an owned, dated mitigation; high-residual risks explicitly flagged; table validated and version-locked for the decision step. Form submitted; every high-residual risk explicitly dispositioned in the rationale; draft DPIA assembled and linked; the not-taken branch is prunable.","kind":"decision","label":"Evaluate residual risk","performedBy":{"note":"","primitives":["coach-form-fill","coach-document-upload","coach-item-create","coach-items-link"]}},"id":"evaluate-residual-risk"},{"data":{"description":"Agent assembles the Article 36 consultation file and tracks the exchange; the DPO conducts the consultation and folds in feedback","instructions":"**Objective** — Run Article 36 prior consultation to conclusion: submit a complete consultation file, hold in-scope processing through the statutory window, and fold every element of the authority's advice into the mitigation plan with DPO approval.\n\n**Inputs**\n- The draft DPIA with the high residual risks flagged, and the version-locked risk table.\n- Controller and processor responsibility documentation: Article 28 agreements, any joint-controller arrangement.\n- DPO contact details and the authority's designated submission channel and format requirements.\n\n**Procedure**\n1. Assemble the Article 36(3) file — the statute lists its contents: (a) the respective responsibilities of controller, joint controllers, and processors; (b) the purposes and means of the intended processing; (c) the measures and safeguards protecting data subjects; (d) the DPO's contact details; (e) the DPIA itself; (f) any other information the authority requests. Cross-check the authority's published submission requirements — several require a specific form or portal.\n2. Check internal consistency before submitting: the high residual risks in the table must match what the cover letter says the consultation is about. A file that undersells the risk invites a longer inquiry, not a shorter one.\n3. Submit through the designated channel and start the clock: written advice within up to eight weeks, extensible by six further weeks for complexity (Article 36(2)), with the clock able to pause while the authority awaits requested information. Track the initial window, the possible extension, and each information request separately.\n4. Hold all launch-dependent activities within the consulted scope until advice is received; record the hold and its exact scope so product teams cannot drift into a partial launch.\n5. Log every exchange — information requests, meetings, interim communications — with dates and content. Answer requests promptly: response time is in your control; the paused clock is not.\n6. Map the advice item by item to concrete changes: every recommendation, condition, or warning — and any Article 58 measure such as a limitation or ban on the processing — gets a mitigation-plan change with a refreshed risk rating, or a documented organisational response with rationale. No item is dispositioned as merely \"noted\" without the DPO's explicit sign-off.\n\n**Record in AssureSwarm**\n- Attach the submitted consultation file and the authority's written advice to this step (PDF).\n- Log the exchange trail as dated comments or documents on this step.\n- Update the linked Risk items with refreshed ratings (Risk.residual_rating) and, where the advice changes the response, Risk.treatment; the feedback-driven mitigation changes go in Risk.description and the risk table. Record the launch hold and its exact release scope on this step (no native hold field).\n\n**Exit criteria** — Consultation concluded with written advice (or the statutory window elapsed and the documented position on proceeding approved by the DPO and legal); every advice item mapped to a change or a DPO-approved response; risk table refreshed; the hold released only for what the outcome permits.","label":"Consult supervisory authority","performedBy":{"primitives":["coach-document-upload","coach-item-update"]}},"id":"consult-authority"},{"data":{"description":"Agent finalizes and registers the DPIA with a review date; the DPO signs and the accountable executive approves","instructions":"**Objective** — Finalize the versioned DPIA, capture the DPO's documented opinion and the accountable executive's approval, and register it with live mitigation tracking and a review date so the approval conditions cannot silently drift.\n\n**Inputs**\n- All DPIA components: processing description, data-flow map, necessity-and-proportionality analysis, validated risk table, and both decision forms — plus, on the consultation path, the authority's advice and its incorporation record.\n- The open mitigation list with owners and due dates.\n\n**Procedure**\n1. Assemble the final versioned DPIA and reconcile inconsistencies across sections: data categories in the description match the flow map, every risk in the narrative appears in the table, and mitigation owners in the table match the actions to be tracked.\n2. Verify the accountability chain closes: every risk carries either a scheduled mitigation with owner and due date or an explicit acceptance signed by the accountable owner with rationale. No orphan risks.\n3. Where the authority imposed conditions, incorporate them verbatim — conditions are part of the approval, and the processing is approved only as conditioned.\n4. Route for signature: the DPO records a documented opinion (the Article 35(2) advice), including any point where the organisation departs from that advice and the justification — an unjustified departure converts the DPO's advice into a governance finding. The accountable executive then approves proceeding under the documented conditions.\n5. Register the signed DPIA against the records-of-processing entry and create every open mitigation as an action item with owner and due date — post-sign-off mitigation slippage is the most common DPIA failure mode, and a row in a PDF is not tracking.\n6. Set the review date and reopening triggers. Article 35(11) requires review at least when the risk changes; three years is common practice, shorter for high-risk or fast-evolving processing. Triggers: change of scope or purpose, new data categories, new vendors or transfers, a relevant incident, or new regulator guidance.\n\n**Record in AssureSwarm**\n- Attach the signed, versioned DPIA package (PDF) to this step and link the document to the anchor Process item (the RoPA proxy); note the DPIA version and review date in Process.description. Process has no register or date fields, so the review date and reopening triggers also live on this step record (honest RoPA gap).\n- For each accepted residual risk, set Risk.treatment=accept and record the named acceptor (the accountable owner) in Risk.description; risks carried on active mitigation stay Risk.treatment=mitigate.\n- Create one Issue item per open mitigation (issue_type=observation, source=self_assessment, issue_owner, target_remediation_date, remediation_plan) and link each Issue to its Risk item, so slippage surfaces on the Issue's remediation date (no native watchlist field — the open-Issue view is the tracker).\n- Record the DPO opinion (with any departures justified), the executive approval, the review date, and the reopening triggers on this step.\n\n**Exit criteria** — Signed DPIA registered against the Process item; every open mitigation is a tracked, owned, dated action item; DPO opinion and executive approval recorded with any departures justified; review date and reopening triggers set.\n\n> **⚡ Audit Artist accelerator:** `/coach-render-package` assembles the description, data-flow map, necessity analysis, risk table, and decision trail into the versioned DPIA package ready for signature.","label":"Sign off and register","performedBy":{"primitives":["coach-document-upload","coach-item-create","coach-items-link","coach-item-update","coach-render-package"]}},"id":"signoff-and-register"},{"data":{"description":"Automatically preserve the screening or DPIA outcome and its owned obligations after the authorized path completes.","instructions":"**Objective** — Close the assessment with a complete, retrievable audit trail — whether the outcome was a documented screening exclusion or a signed DPIA — and hand every live obligation (mitigations, review date) to a named owner before the workflow ends.\n\n**Inputs**\n- Screening path: the screening memo, decision form, and reopening triggers.\n- Full-DPIA path: the signed DPIA, both decision forms, the risk items and mitigation actions, and any Article 36 correspondence.\n- The stakeholder list recorded for the activity (privacy, legal, security, and product owners).\n\n**Procedure**\n1. Verify the archive set is complete for the path taken: every decision form submitted with rationale, the memo or signed DPIA in final version with its evidence set, and — on the consultation path — the full authority exchange trail.\n2. Confirm the live obligations survive the close: each open mitigation exists as a tracked item with owner and due date, and the review date with its reopening triggers sits on the processing-activity item. Closing the workflow must not close the obligations.\n3. Update the linked records and registers: the records-of-processing entry references the DPIA or memo with version and date, and related workflow records — vendor due diligence, transfer impact assessment — link back to the outcome that affects them.\n4. Export the workflow record for the audit file so the full step, decision, and approval trail is preserved outside the live workflow.\n5. Notify the activity's stakeholders of the final outcome and any attached conditions — the product owner needs the conditions, not just the approval flag.\n6. Record the archive confirmation on this step; post-archive corrections are new dated addenda, never edits to the archived record.\n\n**Record in AssureSwarm**\n- Attach the workflow export and an archive index to this step, stating what is in the record and where each artifact lives.\n- Assemble the records-of-processing handoff package — the archive index plus the signed DPIA (or the screening memo) and its evidence set — and link it to the anchor Process item so the records-of-processing maintenance workflow consumes it from there; back-link the outcome to any related vendor due-diligence or transfer-impact-assessment records it affects. (The template has no formal handoff node, so this close-and-archive step doubles as the handoff step.)\n- Record the stakeholder notification list with dates on this step; the archived workflow instance on the Process item is the durable audit trail, and post-archive corrections are new dated addenda, never edits.\n- Record the archive confirmation automatically after the selected path’s DPO concurrence or executive approval.\n\n**Exit criteria** — Archive verified complete for the path taken; every open mitigation and the review reminder live with named owners; workflow export attached; stakeholders notified with the conditions; completion is recorded automatically after the selected authorized outcome.\n\n> **⚡ Audit Artist accelerator:** `/coach-workflow-export` captures the full step, decision, and approval trail for the audit file; `/coach-notify` sends the outcome notice with its conditions to the stakeholder list.","label":"Close and archive","performedBy":{"primitives":["coach-workflow-export","coach-document-upload","coach-notify"]},"requiredApprovals":0},"id":"close-and-archive"}],"sourceTemplateId":"workflow-library:reg-dpia-privacy-impact-assessment"}