{"description":"Regulatory Compliance Attestation Cycle: runs on and enriches the existing Audit item created for this authority and reporting period (audit_type = compliance or regulatory_exam; scope = certification boundary; period_start/period_end = the reporting period) — that Audit item is the attestation record the cycle updates throughout, never a duplicate. Over the cycle: compile evidence for the authority source across the reporting period, validate and resolve evidence gaps, produce the five-section regulatory attestation package, route certifying-officer certification, and archive the package. In scope: the legal entities, products, geographies, and systems named in the certification boundary for that authority and period. Consumes the implemented, owned, control-mapped obligation baseline as the handoff package from the Regulatory Obligation Implementation workflow (the implementations themselves are the Control items whose framework multiselect includes this authority, linked to the anchor Audit). Out of scope: obligations under other authorities, entities outside the certification boundary, and the obligation-to-control implementation itself. Hands the certification outcome, exception register, action plans, and accepted risks off to Quarterly Board & Audit-Committee GRC Reporting.","edges":[{"id":"e-lock-executable-workplan-validate-current-evidence","source":"lock-executable-workplan","target":"validate-current-evidence"},{"id":"e-validate-current-evidence-obtain-officer-certification","source":"validate-current-evidence","target":"obtain-officer-certification"},{"id":"e-obtain-officer-certification-approve-or-revise-package","source":"obtain-officer-certification","target":"approve-or-revise-package"},{"id":"e-obtain-officer-certification-classify-disposition","source":"obtain-officer-certification","target":"classify-disposition"},{"id":"e-classify-disposition-create-action-plan","label":"Action","source":"classify-disposition","target":"create-action-plan","whenValue":"gaps"},{"id":"e-classify-disposition-approve-or-revise-package","label":"Clear","source":"classify-disposition","target":"approve-or-revise-package","whenValue":"complete"},{"id":"e-classify-disposition-escalate-or-accept-risk","label":"Escalate","source":"classify-disposition","target":"escalate-or-accept-risk","whenValue":"monitor"},{"id":"e-create-action-plan-approve-or-revise-package","source":"create-action-plan","target":"approve-or-revise-package"},{"id":"e-escalate-or-accept-risk-approve-or-revise-package","source":"escalate-or-accept-risk","target":"approve-or-revise-package"},{"id":"e-approve-or-revise-package-reapprove-revised-package","label":"Revise","source":"approve-or-revise-package","target":"reapprove-revised-package","whenValue":"revise"},{"id":"e-approve-or-revise-package-handoff-to-related-workflow","label":"Approved","source":"approve-or-revise-package","target":"handoff-to-related-workflow","whenValue":"approved"},{"id":"e-reapprove-revised-package-handoff-to-related-workflow","label":"Re-approved","source":"reapprove-revised-package","target":"handoff-to-related-workflow","whenValue":"reapproved"},{"id":"e-reapprove-revised-package-close-and-archive","label":"Withhold","source":"reapprove-revised-package","target":"close-and-archive","whenValue":"withdraw"},{"id":"e-handoff-to-related-workflow-close-and-archive","source":"handoff-to-related-workflow","target":"close-and-archive"}],"isPublic":true,"metadata":{"capabilities":[],"controlVerbs":{},"controls":["UC-AUDIT-24","UC-GOV-24","UC-AUDIT-25"],"department":"compliance-legal","domains":["reg"],"library":{"aliases":[],"canonicalUrl":"https://workflow-library.com/all/?w=reg-compliance-attestation-cycle","contentDigest":"sha256:ec89107ef3b241534c7ed1153a3b71287baa28fce8a8fba6b41647569cd08291","prerequisites":{"status":"undeclared"},"provenance":[],"releaseId":"sha256:ec89107ef3b241534c7ed1153a3b71287baa28fce8a8fba6b41647569cd08291","schemaVersion":1,"sourceTemplateId":"workflow-library:reg-compliance-attestation-cycle"},"lineOfDefense":"monitor","mappingStatus":"mapped","risks":[],"slug":"reg-compliance-attestation-cycle","source":"coworkcanvas-gallery","standards":["gdpr","dora","nydfs-500","eu-ai-act","nis2","pci-dss","hipaa","ccpa"],"teams":["compliance-legal","executive"]},"name":"Regulatory Compliance Attestation Cycle","nodes":[{"data":{"description":"Freeze scope, owners, due dates, evidence standards, and review expectations into a versioned workplan the team executes without renegotiation, sized backward from the filing deadline.","instructions":"**Objective**\nFreeze scope, owners, due dates, evidence standards, and review expectations into a versioned workplan the team executes without renegotiation, sized backward from the filing deadline.\n\n**Inputs**\nThe obligation baseline (the citing Control items linked to the anchor Audit) and the locked workplan document.\n- The authority text, for tracing (the authority source recorded in the anchor Audit's scope).\n- The prior cycle's obligation set — the prior cycle's Audit item and the obligation-set register document on its archived workflow instance — for delta analysis.\n- Regulator findings or commitments that make specific obligations certification-material: open Issue items with source: regulatory_exam (or external_audit) linked to the citing Controls.\n\nThe obligation baseline for this authority — the implemented, owned, control-mapped obligation set — consumed as the handoff package (a document on the Regulatory Obligation Implementation workflow's handoff step); the implementations themselves are the citing Control items (framework multiselect includes this authority: gdpr | dora | nydfs-500 | eu-ai-act | nis2 | pci-dss | hipaa | ccpa), linked to the anchor Audit.\n- The cycle boundary from the anchor Audit item (existing): scope (certification boundary, authority source/URL/version), period_start and period_end (the reporting period), and audit_type — plus the filing deadline and the certifying officer's calendar hold.\n- The organization's evidence-quality conventions, if documented; otherwise the defaults below.\n\n**Procedure**\n*Agent retrieval, preparation and filing absorb “Select obligation set”; the responsible roles retain their judgments and all independent sign-offs within this checkpoint.*\n\n1. Assessment scope for Select obligation set: Freeze the exact list of obligations this certification will cover, classified by how each will be evidenced, so \"what are we attesting to\" has one versioned answer everyone works from.\n\n2. Enumerate every obligation citing this authority from the baseline. Treat archived policies carefully: retiring a policy does not retire the legal duty — if the obligation persists without a citing policy, that is a mapping gap to flag, not a reason to drop the obligation from scope.\n3. Classify each obligation by evidencing type: (a) continuous-control-backed — proven by control operation (encryption, access reviews, logging); (b) event-driven — proven by handling records (breach notifications, DSARs, incident reports), where zero events requires a population query proving zero, not silence; (c) point-in-time — documents current at cutoff (policies, records of processing, registers, training completion); (d) third-party-reliant — proven through a vendor's attestation plus our complementary controls.\n4. Run the delta against the prior cycle: obligations added (why), removed (why — removal takes the same rigor as an exclusion), reclassified (why). An obligation silently missing versus last year's filing is the first thing an examiner cross-checking filings finds.\n5. Mark certification-material obligations — those whose failure would flip the officer's statement from clean to qualified: anything named in prior findings, prior acknowledgments of noncompliance, or active remediation commitments. These take evidence priority and, for the highest-risk among them, independent validation.\n6. Freeze the set: count it, version it, and publish it — later additions or removals are logged scope changes.\n\n7. Assessment scope for Lock executable workplan: Freeze scope, owners, due dates, evidence standards, and review expectations into a versioned workplan the team executes without renegotiation, sized backward from the filing deadline.\n\n8. Fix the evidence cutoff and state the freshness rule: operating evidence must be dated inside the reporting period; point-in-time artifacts (configurations, access lists, registers) are pulled as late in the period as practicable; anything predating the period fails validation and becomes a gap, not a footnote.\n9. Set the quality bar per artifact type: system-generated output over screenshots; screenshots carry source URL and timestamp; population-based evidence names the population source, extraction date, and row count. An owner's assertion is never evidence — it is an input to a gap.\n10. Assign every obligation an evidence owner and a separate reviewer. The reviewer's standard: could a regulator's examiner reperform the conclusion from what is attached, with no one in the room to explain it?\n11. Build the calendar backward: evidence collection, then validation, then a gap-remediation buffer of at least 20% of the collection window (gaps always surface), then digest assembly, two weeks of officer review, certification, filing. If the arithmetic does not close, cut scope consciously and record it; never compress officer review to make the math work.\n12. Lock and publish: version the workplan, notify owners of their assignments and dates, and treat every subsequent change as a logged scope change with compliance-officer concurrence. Silent scope drift is how obligations vanish from certifications.\n\n**Record in AssureSwarm**\nConfirm the citing Control items (framework includes this authority) are linked to the anchor Audit — there is no per-obligation item, so the frozen obligation set itself is the obligation-set register document attached to this step.\n- Record each obligation's evidencing class and certification-material flag as columns in that register document (no native per-obligation field holds them).\n- Attach the delta memo and the versioned obligation-set register as documents on this step; note the set version and count on the step.\n\nAttach the versioned, locked workplan as a document on this step (version and lock date in the filename).\n- There is no per-obligation item type, so the per-obligation evidence owner, independent reviewer, and due date live as a table inside the workplan document — not native fields; link the citing Control items (the obligation implementations, framework includes this authority) to the anchor Audit so the in-scope set is traceable from the attestation record.\n- The anchor Audit item is the attestation record: confirm audit_type (compliance or regulatory_exam), scope (certification boundary and authority source), period_start, and period_end are set. A native per-obligation watchlist has no home; due-date movement is tracked from the workplan document.\n\n**Exit criteria**\nA frozen, versioned obligation set with a count; every obligation carries an evidencing class and materiality flag; every add, removal, and reclassification versus the prior cycle is explained. Workplan locked and versioned; every in-scope obligation has an evidence owner, an independent reviewer, and a due date; cutoff and freshness rules published to owners; the timeline closes with the officer-review window intact.","label":"Lock executable workplan"},"id":"lock-executable-workplan"},{"data":{"description":"Test the evidence held for every in-scope obligation against the workplan's quality bar and issue a per-obligation verdict — sufficient, stale, incomplete, or missing — with a severity-rated gap list.","instructions":"**Objective**\nTest the evidence held for every in-scope obligation against the workplan's quality bar and issue a per-obligation verdict — sufficient, stale, incomplete, or missing — with a severity-rated gap list.\n\n**Inputs**\nThe frozen obligation set with evidencing classes and materiality flags.\n- Evidence documents captured on the citing controls' workflow steps during the reporting period.\n- The freshness and quality rules from the locked workplan.\n- Third-party attestations on file (SOC 2 reports, ISO certificates, vendor AOCs) with their coverage periods — the relied-on third parties are Vendor items (tier, data_classification, monitoring_status, last_assessment_date, next_reassessment_date, contract_end_date); the attestation reports and CUEC schedules are uploads on this step.\n\nThe gap list with severities, owners, and deadlines.\n- The remediation window and evidence-quality rules from the workplan.\n- The regime's exception conventions: what a qualified statement or acknowledgment of noncompliance must contain, where one exists.\n\n**Procedure**\n*Agent retrieval, preparation and filing absorb “Resolve evidence gaps”; the responsible roles retain their judgments and all independent sign-offs within this checkpoint.*\n\n1. Assessment scope for Validate current evidence: Test the evidence held for every in-scope obligation against the workplan's quality bar and issue a per-obligation verdict — sufficient, stale, incomplete, or missing — with a severity-rated gap list.\n\n2. Pull the evidence inventory per obligation: walk obligation to citing controls to the evidence documents on their related workflow steps, bounded to the reporting period. Query the records rather than survey the owners — \"we have that somewhere\" is where certifications die.\n3. Apply four tests to every artifact: (a) period — dated inside the reporting period, or at cutoff for point-in-time items; (b) provenance — system-generated, or attributable to a named person and source with a timestamp; (c) pertinence — it demonstrates this obligation, not a neighbor (a firewall ruleset does not evidence encryption-in-transit); (d) reperformability — a reviewer reaches the same conclusion from the artifact alone.\n4. For event-driven obligations with zero events, require the population proof: the query or report showing zero reportable breaches, zero overdue DSARs — with source and extraction date. Absence of records is not evidence of absence.\n5. For third-party reliance: the vendor report's period overlaps ours, the relied-on services are in that report's scope, and the complementary user-entity controls assigned to us are themselves evidenced. An expired or wrong-scope attestation is a gap, not a technicality.\n6. Verdict each obligation — sufficient, stale (exists but pre-period), incomplete (partial coverage), or missing — and rate severity: certification-material obligations with stale or missing evidence are red; they threaten the statement itself, not just the file.\n7. Publish the gap list with an owner and the remediation window per gap.\n\n8. Assessment scope for Resolve evidence gaps: Close every validation gap — refresh, complete, or obtain the missing proof — or convert what cannot close in-window into an explicit, owned exception, so the digest is built over verdicts, not hopes.\n\n9. Triage each gap by closability: (a) refreshable now — re-run the report, pull the current configuration, obtain the renewed vendor attestation; (b) closable only by performing the underlying activity — the access review that never ran this period gets run now and dated honestly; backdating converts an evidence gap into misconduct; (c) not closable in-window — becomes a candidate exception, decided deliberately rather than drifted into.\n10. Chase with deadline discipline: each owner gets the gap, the exact artifact required with its quality tests, and the drop-dead date; escalate to the owner's manager at 50% of the window elapsed with no movement.\n11. Re-validate every artifact received against the same four tests (period, provenance, pertinence, reperformability). Gap-closure evidence gets no quality discount for arriving late.\n12. Draft each unresolvable gap as an honest exception: what the obligation requires, what evidence exists, what is missing, the interim risk, and the remediation plan with a date. Word it to map onto what the regime would require disclosed — under NYDFS, the exceptions drive the choice between certifying material compliance and filing the acknowledgment. The digest's posture rating for these is in-progress or gap, never compliant.\n13. Reconcile the ledger: gaps closed plus gaps converted to exceptions equals gaps opened. Zero silently dropped.\n\n**Record in AssureSwarm**\nRecord each obligation's verdict (sufficient / stale / incomplete / missing) in the validation worksheet — there is no per-obligation item or evidence-status field, so the worksheet document carries the verdict column, keyed to the citing Control items.\n- For each third party whose attestation you rely on, record the reliance against its Vendor item — do not leave it as a step upload only: set last_assessment_date to the report's period-end (or receipt date), next_reassessment_date to when the next report is due, and monitoring_status (enrolled / not_enrolled / exited), and relate the Vendor ↔ the anchor Audit so the reliance is traceable from the vendor register; the SOC 2 / ISO / AOC report and its CUEC schedule stay as the upload on this step.\n- Attach the validation worksheet (four-test results per artifact) as a document on this step.\n- Attach the severity-rated gap list (severity, owner, remediation deadline per gap) as a document on this step.\n\nUpdate each affected obligation's verdict in the validation worksheet (no per-obligation item exists to hold an evidence-status field).\n- For every gap that cannot close in-window, create one Issue item (issue_type: exception, source: compliance_review, severity, root_cause, identified_date) and relate it Issue ↔ anchor Audit and Issue ↔ its citing Control; the exception register is those Issue items plus a register summary document on this step.\n- Attach closure artifacts to the relevant steps; note the chase-and-escalation trail in step comments.\n\n**Exit criteria**\nEvery in-scope obligation carries a four-test-backed verdict; zero-event obligations have population proof; the gap list is published with severities, owners, and deadlines inside the remediation window. Every gap is either closed with re-validated evidence or written up as an exception with owner, interim risk, and remediation date; the ledger reconciles; evidence-status fields are current for digest assembly.\n\n> **⚡ Audit Artist accelerator:** `/coach-query-data` pulls the per-obligation evidence inventory — citing controls plus period-bounded step documents — as one query instead of a manual walk.","label":"Validate current evidence","performedBy":{"note":"","primitives":["coach-query-data","coach-item-update","coach-items-link"]}},"id":"validate-current-evidence"},{"data":{"description":"Put the anchored attestation package in front of the certifying officer(s), support their challenge of it, and capture an executed certification whose wording matches what the evidence supports — or a documented decline that the disposition step will route.","instructions":"**Objective**\nPut the anchored attestation package in front of the certifying officer(s), support their challenge of it, and capture an executed certification whose wording matches what the evidence supports — or a documented decline that the disposition step will route.\n\n**Inputs**\nThe authority source: regulator, region, source URL, version, and publication date.\n- The attestation target — the anchor Audit item for this authority and reporting period (the attestation record) — and its reporting period.\n- The in-scope Policy items whose framework multiselect includes this authority (gdpr | dora | nydfs-500 | eu-ai-act | nis2 | pci-dss | hipaa | ccpa), with their obligation language — carrying policy_owner, version, effective_date, and next_review_date.\n- The Control items implementing those policies: status, owner, last-tested date.\n- The step evidence captured on those controls' related workflow steps within the reporting period, as validated and gap-resolved upstream.\n\nThe anchored attestation package from the digest step (source sections plus rendered files).\n- The exception register and remediation plans.\n- The regime's certification instrument: the NYDFS Certification of Material Compliance versus the Acknowledgment of Noncompliance, the PCI AOC signature blocks, a management-body approval minute for NIS2 or DORA.\n- The officer-review calendar hold from the workplan.\n\n**Procedure**\n*Agent retrieval, preparation and filing absorb “Generate attestation digest”; the responsible roles retain their judgments and all independent sign-offs within this checkpoint.*\n\n1. Assessment scope for Generate attestation digest: Assemble the regulator-facing compliance attestation package for one authority source and one reporting period — five sections, evidence-cited, clean of internal notes — ready for officer certification and for rendering into the distribution package.\n\n2. Resolve the authority source and confirm the attestation target — the anchor Audit item — and the reporting period the attestation covers.\n3. Compile the in-scope obligations: gather every Policy item whose framework multiselect includes this authority source, skipping any policy that is archived; for each, capture title, obligation excerpt, status, policy_owner, and next_review_date.\n4. Walk the citing controls and, for each control, the evidence documents captured on its related workflow steps within the reporting period; note each control's status, owner, and last-tested date.\n5. Build the five attestation sections: (a) cover — our identity, the regulator, region, reporting period, authority title and source URL; (b) authority summary — a one-paragraph description of the authority; (c) obligations-in-scope table — policy title, obligation excerpt, status, owner; (d) per-obligation compliance posture — rate each obligation compliant, in-progress, or gap, with its citing controls and recent evidence references; (e) officer sign-off declaration — the certification language the compliance officer or general counsel will attest to.\n6. Cite, do not reproduce: reference control text and evidence files by title and location rather than copying their contents into the package, so the regulator can request specific evidence as follow-up instead of receiving an uncontrolled evidence dump.\n7. Strip internal review notes before anything leaves: no review markers, coaching notes, or reviewer commentary may survive into regulator-facing text. Treat any unresolved marker as a blocker that halts packaging until resolved — this is high-stakes output, and a clean package beats a fast one.\n8. Render the assembled sections into the distribution formats (.docx and .pdf), re-sweep the rendered output for internal notes under the same blocking discipline, and produce the distribution package with its distribution list: compliance officer, general counsel, and the external regulator liaison.\n9. Enrich the anchor Audit item — the attestation record for this cycle — with the posture counts, and record the assembled package back on this attestation step, so the downstream certification and archive steps act on a single anchored artifact.\n10. Human checkpoint: the compliance officer or general counsel reviews the assembled posture and evidence citations before the package advances to certification — every posture rating must be defensible from the cited evidence, and every obligation must trace to the authority text. They review and sign offline; this step produces the package, not the signature.\n\n11. Assessment scope for Obtain officer certification: Put the anchored attestation package in front of the certifying officer(s), support their challenge of it, and capture an executed certification whose wording matches what the evidence supports — or a documented decline that the disposition step will route.\n\n12. Deliver the package with a certification brief, never a bare signature page: what the officer is asked to sign, posture counts (compliant / in-progress / gap), the exception register, and what changed since the prior certification. Retain the officer’s own statement of certified scope, decision, exceptions and reliance basis in the native result and executed instrument, with native approval identifying the exact package.\n13. Staff the challenge session: expect \"show me the basis\" on every gap and on every posture that improved since last cycle. The officer's standard — and the regulator's — is that the certification rests on data and documentation, not on the compliance team's assurance.\n14. Handle wording changes through the record, not around it: a material qualification (compliant to materially-compliant-with-enumerated-exceptions, or the regime's noncompliance acknowledgment with a remediation timeline) is legitimate, and it goes back through the digest so the signed statement and the anchored package stay identical in substance. A statement that diverges from its package is a false-certification risk.\n15. The signature itself happens offline on the regime's instrument. This step captures the executed artifact and the decision: the signed document, signatory name and title, date, and statement type — clean, qualified, or acknowledgment — and reconciles them against the officer’s recorded decision, qualifications and reliance basis before recording.\n16. If the officer declines to sign in time, that is a disposition, not a delay: record the reason, engage legal on regulator-deadline options (extension request, qualified filing), and let the disposition decision route the escalation.\n\n**Record in AssureSwarm**\nAttach the assembled five-section package — source sections plus rendered .docx and .pdf — as documents on this step.\n- The anchor Audit item is the attestation record — enrich it, do not create a second one: set description to the posture counts (compliant / in-progress / gap) and confirm scope carries the authority source, region, and reporting period.\n- The obligations-in-scope layer is the Policy items whose framework multiselect includes this authority (gdpr | dora | nydfs-500 | eu-ai-act | nis2 | pci-dss | hipaa | ccpa) — do not leave this in prose only: confirm each carries policy_owner, version, effective_date, and next_review_date, and relate the in-scope Policy items ↔ the anchor Audit so the certified obligation set is traceable from the attestation record; each policy's implementing Control items stay linked as the control layer.\n- Residual per-obligation posture columns (applicability rationale, evidence status, gap rating, attestation status) have no native per-row field, so the obligations-in-scope and per-obligation-posture sections of the package document carry them, keyed to the in-scope Policy items and their implementing Control items.\n\nUpload the executed certification (or the documented decline with its reason) as a document on this step.\n- Retain certified scope, decision, exceptions and compensating measures, reliance evidence/personnel, signatory name/title and actual signing date in the native result and executed certification. Bind native approval to that exact artifact; do not collect a duplicate questionnaire.\n- Record the certification as a step approval by or on behalf of the certifying officer.\n- On the anchor Audit item (the attestation record) set opinion (unqualified = certified-clean, qualified = certified-qualified, adverse/disclaimer = acknowledgment or decline), rating, and report_date (the certification date); the signatory name and title live in the uploaded instrument and the step approval.\n\n**Exit criteria**\nThe five-section package is assembled and recorded on this step; every obligation traces to the authority source text and to at least one citing control; every posture rating is backed by cited (not reproduced) evidence within the period; no internal review notes remain in any text destined for the regulator, source or rendered; the distribution list stands; the digest is ready for officer certification and downstream archival. An executed certification (or documented decline) is attached; the officer’s native decision record reconciles with the instrument; the statement's substance is identical to the anchored package; the approval is recorded; attestation status, date, and signatory are set.\n\n> **⚡ Audit Artist accelerator:** `/coach-render-package` renders the assembled sections into the distribution formats, enforces the block-on-unresolved-review-notes sweep, and produces the distribution package and its distribution list.","label":"Obtain officer certification","performedBy":{"agent":"reg-artist","note":"assembles the five-section regulator attestation package (obligations, citing controls, evidence citations) for officer certification","primitives":["coach-query-data","coach-document-upload","coach-item-create","coach-item-update","coach-items-link","coach-render-package"]}},"id":"obtain-officer-certification"},{"data":{"decisionField":"disposition_path","description":"Classify the result of Regulatory Compliance Attestation Cycle so the agent keeps only the relevant closure path","formData":{"fields":[{"key":"disposition_path","label":"Classify disposition","options":[{"label":"Complete","value":"complete"},{"label":"Gaps require action","value":"gaps"},{"label":"Monitor without immediate action","value":"monitor"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Classify the cycle's outcome so closure follows the right path — clean completion, gap remediation, or an escalation and risk-acceptance decision — with the compliance officer making the call against the exception register, not the mood of the meeting.\n\n**Decision criteria**\n- `complete` (Complete) — the officer signed a clean certification; the exception register is empty; no remediation commitments were made to the regulator; nothing remains but routine next-cycle scheduling. A signed-but-qualified certification is never \"complete\".\n- `gaps` (Gaps require action) — the certification is qualified, an acknowledgment of noncompliance was filed, or the exception register holds items with remediation plans — anything where a named fix with a date must demonstrably happen. Pick this whenever a regulator could later ask \"you identified this — what did you do about it?\" and the answer must be a tracked plan.\n- `monitor` (Monitor without immediate action) — no remediable gap, but a risk decision above the compliance team is required: exceptions the business proposes to accept rather than fix, near-threshold applicability calls awaiting facts, third-party weaknesses awaiting the vendor's next report, or an officer decline whose filing posture needs senior direction. This routes to the escalate-or-accept-risk step for a signed decision — an accepted risk without a written acceptance is not \"monitor\", it is an unmanaged gap.\n\n**Record in AssureSwarm** — Submit `disposition_path`; the rationale cites the certification type and the exception-register counts it was judged against; name the decision owner.\n\n**Exit criteria** — Form submitted with a rationale tied to the certification type and exceptions; unused branches are prunable because edge values match the selected form value.","kind":"decision","label":"Classify disposition"},"id":"classify-disposition"},{"data":{"description":"Create an owned action plan for gaps","instructions":"**Objective** — Convert every open gap and qualification into an owned, dated, verifiable remediation action — the record that shows the regulator the organization acted on what it disclosed.\n\n**Inputs**\n- The exception register with severities and interim risks.\n- The qualified certification or acknowledgment wording — any remediation timeline stated there is a commitment, not an aspiration.\n- Root-cause notes from the gap-resolution step.\n\n**Procedure**\n1. Cut one action item per gap — never bundles; bundles hide the one item that slips. Each carries: root cause (evidence never generated, control never operated, or obligation never implemented — three different fixes), a named person as owner, a due date, an interim mitigation, and the closure evidence that will prove remediation.\n2. Honor committed dates: any date stated in the certification, the acknowledgment, or regulator correspondence is a hard ceiling — plan dates land at or before it, with buffer for validation.\n3. Define closure evidence now, to the same four quality tests the cycle used (period, provenance, pertinence, reperformability). \"Owner says fixed\" does not close a disclosed gap.\n4. Set the reporting cadence: certification-material actions report monthly to the compliance officer and roll into Quarterly Board & Audit-Committee GRC Reporting; the rest at least quarterly until closed.\n5. Wire the follow-through: link each action item to its obligation and to this workflow, put the set on a watchlist, and schedule the check-ins — an action plan nobody re-opens is disclosure theater.\n\n**Record in AssureSwarm**\n- The action plan enriches the exception Issue items raised at gap resolution (and adds one Issue per qualification not yet captured): relate each Issue ↔ its citing Control and ↔ the anchor Audit.\n- On each Issue set issue_owner (USER), target_remediation_date (at or before any regulator-committed date), remediation_plan (the interim mitigation and the closure-evidence definition), and management_response.\n- Attach the plan summary as a document on this step; a native action-item watchlist has no home, so track the open Issues by target_remediation_date.\n\n**Exit criteria** — Every open gap has exactly one action item with a named owner, a date at or before any regulator-committed date, an interim mitigation, defined closure evidence, and a reporting cadence.","label":"Create action plan"},"id":"create-action-plan"},{"data":{"description":"Escalate to compliance officer, legal owner, obligation owner, or governance delegate or document risk acceptance","instructions":"**Objective** — Obtain an explicit, signed decision from the right authority on every monitor-path item — escalate for direction or accept the risk with conditions — so no known exposure is carried silently into the filed record.\n\n**Inputs**\n- The monitor-path items with their exposure analyses.\n- The risk-acceptance policy: who may accept what magnitude, and the prohibition on open-ended acceptances.\n- The filed or pending certification wording, to check for contradictions.\n\n**Procedure**\n1. Write a decision memo per item: the obligation; the exposure — what the regulator could find, the plausible enforcement range and business impact, quantified where the regime allows it (GDPR's up-to-4%-of-worldwide-turnover upper tier and published NYDFS penalty practice make \"low impact\" a claim that needs support); the options (fix now, accept with conditions, escalate); and a recommendation.\n2. Route to the level the acceptance policy names. Regulatory-compliance risk typically sits above the compliance team: the obligation owner's executive, the risk committee, or the certifying officer — it is their signature that carries the exposure.\n3. Capture each decision with its conditions: an acceptance term with an expiry date (open-ended acceptances are prohibited), compensating measures, the re-review trigger, and the named accepting owner.\n4. Check the filing consequence: an accepted risk that contradicts the certification's wording must be resolved before filing — reconcile the statement or reverse the acceptance; never file the contradiction.\n5. Feed accepted risks to the risk register and flag them for Quarterly Board & Audit-Committee GRC Reporting — an acceptance the board never sees is a governance gap of its own.\n\n**Record in AssureSwarm**\n- Attach the decision memo(s) as documents on this step; capture each acceptance term and expiry date in the memo (a Risk item has no native expiry field).\n- For each accepted risk, create or update a Risk item with treatment: accept, risk_owner = the accepting authority, and residual_rating, related to the anchor Audit; capture the accepting authority's sign-off as a step approval.\n- Link the accepted Risk items so the downstream board-reporting workflow tracks the live records, and note the board-reporting flag on this step.\n\n**Exit criteria** — Every monitor item has a signed decision memo with conditions, expiry, and a named owner; no acceptance contradicts the certification wording; risk-register and board-reporting feeds are linked.","label":"Escalate or accept risk"},"id":"escalate-or-accept-risk"},{"data":{"decisionField":"approval_path","description":"Capture the accountable approval of the final package from the compliance officer, legal owner, obligation owner, or governance delegate — or return it with itemized revision conditions. The approver attests to the internal record's integrity, distinct from the officer's regulator-facing certification; both must hold independently.","formData":{"fields":[{"key":"approval_path","label":"Approve or revise package","options":[{"label":"Approved","value":"approved"},{"label":"Revision required","value":"revise"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective**\nCapture the accountable approval of the final package from the compliance officer, legal owner, obligation owner, or governance delegate — or return it with itemized revision conditions. The approver attests to the internal record's integrity, distinct from the officer's regulator-facing certification; both must hold independently.\n\n**Decision criteria**\nInputs and preparation before selecting the branch:\nThe anchored package (source plus rendered files) and the executed certification.\n- The exception register, validation worksheet, and gap-resolution trail.\n- Decision rationales from the cycle's decision steps.\n- The filing receipt or submission confirmation, if already filed.\n\nThe archived attestation package and the executed certification.\n- The action plan (gaps path) or signed escalation and acceptance memos (monitor path), where those branches ran.\n- The assumption log and the cycle's decision rationales.\n\n*Agent retrieval, preparation and filing absorb “Archive package”, “Prepare final package”; the responsible roles retain their judgments and all independent sign-offs within this checkpoint.*\n\n1. Assessment scope for Archive package: Preserve the complete attestation record — package, executed certification, evidence citation index, and decision trail — retrievable for the regime's full retention horizon.\n\n2. Assemble the archive manifest: the five-section package, the executed certification, the evidence citation index (titles and locations — the archive must let a future responder retrieve every cited artifact), the exception register, decision rationales, and any regulator submission receipts.\n3. Verify citation resolvability: sample 5–10 evidence citations and confirm each resolves to a retrievable document. An artifact cited in a filed attestation but unretrievable at exam time is indistinguishable from evidence that never existed.\n4. Apply the longest applicable retention rule: NYDFS requires the records supporting the certification for five years; PCI evidence conventions run at least 12 months, with the AOC retained per assessor and card-brand rules; GDPR accountability documentation lives as long as the processing does. Overlapping regimes take the longest clock.\n5. Record the archive confirmation — date, archivist, and package version identifier (a file hash serves). Post-archive corrections are new dated addenda linked to the attestation record, never edits to archived artifacts.\n6. Record the filing status: submitted (date, channel, receipt) or pending with owner and deadline — an archived-but-unfiled certification still misses the deadline.\n\n7. Assessment scope for Prepare final package: Compile the cycle's complete decision package — certification outcome, evidence basis, exceptions and their dispositions, and the proposed conclusion — so the approver reviews one reconciled record rather than a trail of fragments.\n\n8. Assemble in review order: (a) a one-page conclusion — authority, period, certification type, posture counts, and the delta versus the prior cycle; (b) the executed certification and its filing status; (c) the exception register with each item's disposition — fixed, action-planned, or risk-accepted; (d) the action plan or acceptance memos; (e) the assumptions and third-party reliance carried through the cycle; (f) links into the archived evidence base rather than re-copied artifacts — the archive stays the single source.\n9. Reconcile the counts across documents: obligations in the frozen set equal rows in the posture table; compliant plus in-progress plus gap ratings equal the frozen count; exceptions in the register equal the non-compliant ratings. A package whose own numbers disagree fails review before anyone reads a sentence.\n10. State the proposed conclusion explicitly, including what the approver is being asked to accept: the residual exceptions, the monitoring items and their expiries, and the next-cycle date.\n11. Flag open constraints honestly — a pending regulator response, a vendor report still awaited — as open items with owners. Approvers approve packages, not surprises discovered after signature.\n\n12. Assessment scope for Approve or revise package: Capture the accountable approval of the final package from the compliance officer, legal owner, obligation owner, or governance delegate — or return it with itemized revision conditions. The approver attests to the internal record's integrity, distinct from the officer's regulator-facing certification; both must hold independently.\n\n\n\n`approved` (Approved) — the package's counts reconcile (frozen obligation set equals posture rows; exceptions equal non-compliant ratings); every exception carries a disposition — fixed, action-planned with owner and date, or risk-accepted with a signed memo; the executed certification matches the archived package in substance; action dates honor every regulator-committed date; and the approver accepts the residual position as stated, including the open constraints.\n- `revise` (Revision required) — any of: unreconciled numbers; an exception without a disposition; certification wording diverging from package substance; a missing acceptance signature; an action date later than a regulator commitment; an open constraint presented as resolved. Revision conditions must be itemized and answerable — \"tighten it up\" is not a reviewable condition; \"exception 3 lacks an interim mitigation\" is.\n\n**Record in AssureSwarm**\nAttach the archive manifest and the evidence-citation index as documents on this step.\n- Record the archive confirmation, package version identifier, and the retention-until date on this step (there is no native retention field).\n- On the anchor Audit item (the attestation record) confirm report_date; filing status and the archive-location link have no native Audit field, so note them on this step and in the manifest.\n\nAttach the final package; record the conclusion summary on this step.\n- Verify the links to the attestation record, action items, acceptance memos, and archive all resolve.\n\nSubmit `approval_path`; the rationale lists the checks performed for an approval, or the itemized conditions for a revision; name the decision owner.\n\n**Exit criteria**\nManifest complete and attached; the citation spot-check is documented; retention-until date recorded; archive confirmation logged; filing status current. Package complete with reconciled counts, an explicit proposed conclusion, and an honest open-constraints list; every referenced record link resolves; ready for the approval decision. Form submitted; on approval, conditions are empty or explicitly tracked as follow-ups; on revision, itemized conditions are recorded; the unused branch is prunable because edge values match the selected form value.","kind":"decision","label":"Approve or revise package"},"id":"approve-or-revise-package"},{"data":{"decisionField":"reapproval_path","description":"Gate the revise path: confirm the itemized revision conditions were genuinely resolved at the source records and that the reworked package now warrants the accountable approval, or withhold approval and close the cycle with the deficiency documented. This is the re-approval the revise path requires — a revised package is never recorded as approved without passing back through this checkpoint, and the recorded approval always corresponds to an approval that actually happened here.","formData":{"fields":[{"key":"reapproval_path","label":"Re-approve revised package","options":[{"label":"Re-approved","value":"reapproved"},{"label":"Withhold approval and close","value":"withdraw"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective**\nGate the revise path: confirm the itemized revision conditions were genuinely resolved at the source records and that the reworked package now warrants the accountable approval, or withhold approval and close the cycle with the deficiency documented. This is the re-approval the revise path requires — a revised package is never recorded as approved without passing back through this checkpoint, and the recorded approval always corresponds to an approval that actually happened here.\n\n**Decision criteria**\nInputs and preparation before selecting the branch:\nThe itemized conditions from the approval decision.\n- The final package and its underlying records: exception register, action plan, acceptance memos, attestation record.\n\n*Agent retrieval, preparation and filing absorb “Resolve approval conditions”; the responsible roles retain their judgments and all independent sign-offs within this checkpoint.*\n\n1. Assessment scope for Resolve approval conditions: Close every itemized revision condition at the source records and document what changed, so re-approval reviews deltas instead of re-reading the package.\n\n2. Log each condition with a resolution type: evidence added, conclusion revised, action plan changed, wording corrected — or pushback with rationale. A reviewer can be wrong; resolve disagreements by argument on the record, never by silent compliance or silent omission.\n3. Make every change at the source record first (the exception register, the action item, the attestation record), then regenerate the affected package sections. Editing the package alone divorces it from the records it summarizes — the exact defect approvals exist to catch.\n4. Gate on substance: if any change alters the certified statement's substance — a posture rating moves, an exception is added or removed — the certifying officer sees it again before re-approval. A package that shifted under an executed signature is a false-certification risk, not an editorial matter.\n5. Produce the change log: condition, change made, where, by whom; date it and increment the package version.\n6. Route the revised package to the re-approval decision — the revise path yields a recorded approval only after that re-decision approves the incremented package version; it does not shortcut straight to the approval record.\n\n7. Assessment scope for Re-approve revised package: Gate the revise path: confirm the itemized revision conditions were genuinely resolved at the source records and that the reworked package now warrants the accountable approval, or withhold approval and close the cycle with the deficiency documented. This is the re-approval the revise path requires — a revised package is never recorded as approved without passing back through this checkpoint, and the recorded approval always corresponds to an approval that actually happened here.\n\n\n\n`reapproved` (Re-approved) — every itemized condition from the first approval decision is closed at its source record (or resolved by documented pushback); the change log reconciles to the incremented package version; any substantive change was re-reviewed by the certifying officer so the signed statement and the package stay identical in substance; and the approver accepts the revised residual position. The approval facts — approver, role, date, package version, any residual follow-up conditions — are captured here for the record step to bind.\n- `withdraw` (Withhold approval and close) — the conditions could not be resolved to the approver's satisfaction within the cycle, or resolving them would reopen the certified statement's substance beyond what this cycle can absorb. The internal-record approval is withheld rather than looping indefinitely; the cycle routes straight to closure with the unresolved conditions and the reason documented, and no board-reporting handoff occurs on this outcome.\n\n**Record in AssureSwarm**\nAttach the change log and the revised package version.\n- Mark each condition closed (or resolved by documented pushback) on this step.\n- Note the officer re-review wherever substance changed.\n\nSubmit `reapproval_path`; the rationale names the conditions checked and the resolution evidence for a re-approval, or the reason approval is withheld; name the decision owner and the package version judged.\n\n**Exit criteria**\nAll conditions closed or resolved by documented pushback; the change log is complete; the package version is incremented; the officer re-reviewed any substantive change. Form submitted with a rationale tied to the itemized conditions; on re-approval the approval facts (approver, date, version, residual conditions) are captured for binding; on withhold the reason is recorded and the cycle routes to closure; the unused branch is prunable because edge values match the selected form value.","kind":"decision","label":"Re-approve revised package"},"id":"reapprove-revised-package"},{"data":{"description":"Deliver a handoff package to Quarterly Board & Audit-Committee GRC Reporting that lets it report this certification accurately — outcome, exceptions, actions, accepted risks — without redoing or second-guessing any of the cycle's work.","instructions":"**Objective**\nDeliver a handoff package to Quarterly Board & Audit-Committee GRC Reporting that lets it report this certification accurately — outcome, exceptions, actions, accepted risks — without redoing or second-guessing any of the cycle's work.\n\n**Inputs**\nThe approval decision output — approver, date, any conditions — from either the first-round approval decision (clean approval of the prepared package) or the re-approval decision on the revise path (approval of the incremented package version after conditions were resolved). Exactly one of these approvals reaches this step; bind that one.\n- The approved package version and the archive record.\n- Follow-up items generated during approval.\n\nThe approved final package and the certification outcome (statement type, filing date).\n- The action plan and accepted-risk decisions with expiries.\n- The archive location and the citation index.\n\n**Procedure**\n*Agent retrieval, preparation and filing absorb “Record approval decision”; the responsible roles retain their judgments and all independent sign-offs within this checkpoint.*\n\n1. Assessment scope for Record approval decision: Bind the final approval to the exact package version as a durable record — who approved, when, under what conditions, and who owns each follow-up — so no later edit can claim the approval.\n\n2. Bind approval to version: record the approver's name and role, the decision date, and the package version identifier approved. An approval that floats free of a version approves nothing.\n3. Convert every condition attached to the approval into a tracked follow-up with a named owner and date — a condition without an owner is a condition that will not happen.\n4. Verify the authority chain: the approver matches the role the workplan named; a delegate's approval cites the delegation it acted under.\n5. Cross-check the archive: the approved version equals the archived version. If final revisions postdate the archive, file the approved version as a dated addendum to the archive — never overwrite the archived artifact.\n6. Set the next-cycle anchors while the facts are fresh: the next certification due date, the evidence-cutoff date, and the trigger that starts the next cycle (regulatory calendar or scheduled cadence).\n\n7. Assessment scope for Handoff to related workflow: Deliver a handoff package to Quarterly Board & Audit-Committee GRC Reporting that lets it report this certification accurately — outcome, exceptions, actions, accepted risks — without redoing or second-guessing any of the cycle's work.\n\n8. Compose the handoff package: the certification outcome line (authority, period, statement type, filing date and channel), posture counts with the delta versus the prior cycle, the exception register with dispositions, action items with owners and dates, accepted risks with expiries, and the archive pointer.\n9. State what downstream must not redo: the evidence basis is validated, approved, and archived — board reporting cites the certification and its exceptions and routes any challenge to the archived citation index; it does not re-open evidence questions.\n10. State what downstream must carry: certification-material action items and accepted risks stay in the board and audit-committee view until closed or expired; a qualified certification or an acknowledgment filing is reportable this quarter, not when convenient.\n11. Create or link the Quarterly Board & Audit-Committee GRC Reporting workflow for the period, attach the handoff package to its intake step, and obtain receipt — an acknowledging comment from that workflow's owner on the intake step.\n12. Transfer the inherited assumptions explicitly: third-party attestation windows that lapse before the next board cycle, acceptance expiries, and monitoring triggers the downstream owner must watch.\n\n**Record in AssureSwarm**\nCapture the approval as a step approval; record approver, role, decision date, and the approved package version in the approval note.\n- Convert each approval condition into a tracked follow-up Issue with a named issue_owner and target_remediation_date.\n- The next-cycle anchors (next certification due date, evidence cutoff) would overwrite this cycle's Audit period fields, so record them in the closure note and next workplan rather than on this Audit — they seed the next cycle's own Audit item.\n\nAttach the handoff package; link the downstream workflow.\n- Note the receipt acknowledgment and the owner who gave it.\n- Link the carried items (actions, accepted risks) so the downstream view tracks the same records.\n\n**Exit criteria**\nApproval bound to a named package version with approver identity and date; every condition tracked with an owner; archive consistency confirmed or the addendum filed; next-cycle dates recorded. Handoff package delivered and acknowledged by the downstream owner; the do-not-redo and must-carry boundaries are explicit; inherited assumptions are transferred with owners.","label":"Handoff to related workflow"},"id":"handoff-to-related-workflow"},{"data":{"description":"Automatically archive the selected approved or withheld outcome and preserve continuing obligations after the authorized decision.","instructions":"**Objective** — Close the cycle with a complete audit trail and the next cycle armed, so the record answers an examiner years from now without the people who ran it in the room.\n\n**Inputs**\n- The archived attestation record and actual decision record. Include the approval and reporting handoff only on approved/reapproved outcomes; on withdraw include the withheld-approval rationale and unresolved conditions.\n- The surviving open items: action items, accepted-risk expiries, and any monitoring triggers set during the cycle.\n- The workplan, for lessons and next-cycle anchors.\n\n**Procedure**\n1. After the authorized decision, automatically sweep the selected path: executed steps carry outputs, selected decisions carry rationale, and skipped branches retain their recorded disposition. One empty step is a hole in the trail an examiner will ask about.\n2. Verify the archive holds the actual final state: the approved version and reporting handoff where authorized, or the withheld approval with unresolved conditions where withdrawn, plus the executed certification and filing receipt where they exist. Anything that postdates the archive confirmation goes in as a dated addendum linked to the attestation record; archived artifacts are never edited.\n3. Confirm the survivors live outside this workflow before it closes: action items on their watchlist with owners and check-ins, accepted risks with expiry re-reviews scheduled. The workflow ends; the obligations do not.\n4. Schedule the next cycle from the recorded anchors — due date, evidence cutoff, officer calendar hold — and write down the lessons that change the next workplan: which evidence was hardest to obtain, which owners slipped, where the timeline pinched.\n5. Communicate closure to participants and stakeholders: the outcome, the filing status, and where the record lives.\n6. Close and archive the workflow. Post-closure corrections are new dated addenda linked to the attestation record — never edits to the closed record.\n\n**Record in AssureSwarm**\n- Record the closure note on this step: date, outcome summary, archive pointer.\n- Confirm the next-cycle schedule and lesson notes are on the attestation record.\n- Note the closure communication (who was told, when).\n\n**Exit criteria** — Selected-path steps carry outputs and decision records; withheld approval remains explicit and has no reporting handoff; archive verified final; surviving trackers live independently with owners; next cycle scheduled with lessons recorded; closure communicated.","label":"Close and archive","requiredApprovals":0},"id":"close-and-archive"}],"sourceTemplateId":"workflow-library:reg-compliance-attestation-cycle"}