{"description":"SOC 2 Readiness & Evidence Collection runs ON an already-opened Audit item — the SOC examination engagement record (audit_type readiness, or external_attestation) whose scope (report type and Type 1/Type 2), examination period (period_start/period_end), and CPA firm (external_firm) are already set. That Audit item is an INPUT: this workflow enriches it and attaches its run to it, never creating a duplicate engagement. It consumes the organization's own Control library — the Control items, framework tagged soc2/soc1 — and no upstream workflow feeds it. In scope: one SOC examination cycle end to end — map the Control library to each in-scope Trust Services criterion (Security always; Availability, Confidentiality, Processing Integrity, or Privacy only where a customer commitment requires it) and SOC 1 control objective, close readiness gaps, run the provided-by-client (PBC) evidence request list with QA, and coordinate the CPA firm through fieldwork and follow-ups. Named deliverables: the criteria-to-control mapping matrix and graded gap matrix, the owned PBC evidence request list, the QA'd evidence set, and the cross-referenced PBC response package — all attached to the anchor Audit and its workflow instance. Out of scope: the SOC report the CPA firm drafts and continuous control monitoring between examinations. No downstream workflow is declared; this run's next-cycle seed artifacts (the PBC list and control calendar) stay on the close step as the de facto handoff to the next examination.","edges":[{"id":"e-map-and-assess-collect-and-qa-evidence","label":"Audit ready","source":"map-and-assess","target":"collect-and-qa-evidence","whenValue":"audit_ready"},{"id":"e-map-and-assess-remediate-gaps","label":"Close gaps","source":"map-and-assess","target":"remediate-gaps","whenValue":"gaps_found"},{"id":"e-remediate-gaps-collect-and-qa-evidence","source":"remediate-gaps","target":"collect-and-qa-evidence"},{"id":"e-collect-and-qa-evidence-package-and-coordinate-auditor","label":"QA passed","source":"collect-and-qa-evidence","target":"package-and-coordinate-auditor","whenValue":"complete"},{"id":"e-collect-and-qa-evidence-rework-evidence","label":"Rework","source":"collect-and-qa-evidence","target":"rework-evidence","whenValue":"rework_needed"},{"id":"e-rework-evidence-package-and-coordinate-auditor","source":"rework-evidence","target":"package-and-coordinate-auditor"}],"isPublic":true,"metadata":{"capabilities":[],"controlVerbs":{},"controls":["UC-AUDIT-21","UC-AUDIT-23","UC-AUDIT-25","UC-RISK-14"],"department":"it","domains":["controls"],"library":{"aliases":[],"canonicalUrl":"https://workflow-library.com/all/?w=controls-soc2-readiness-evidence-cycle","contentDigest":"sha256:a75a8829641f824e14de4a3ac834eb857327b7536a5954b8f5b887df61305df4","prerequisites":{"status":"undeclared"},"provenance":[],"releaseId":"sha256:a75a8829641f824e14de4a3ac834eb857327b7536a5954b8f5b887df61305df4","schemaVersion":1,"sourceTemplateId":"workflow-library:controls-soc2-readiness-evidence-cycle"},"lineOfDefense":"monitor","mappingStatus":"mapped","risks":[],"slug":"controls-soc2-readiness-evidence-cycle","source":"coworkcanvas-gallery","standards":["soc2","soc1"],"teams":["it","compliance-legal"]},"name":"SOC 2 Readiness & Evidence Collection","nodes":[{"data":{"decisionField":"readiness_state","description":"Agent maps the control library to each in-scope criterion and drafts the gap matrix; human decides audit ready or gaps found","formData":{"fields":[{"key":"readiness_state","label":"Readiness state","options":[{"label":"Audit ready","value":"audit_ready"},{"label":"Gaps found, remediate first","value":"gaps_found"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Decide whether the program enters evidence collection now (audit_ready) or must remediate first (gaps_found), grounded in a complete criteria-to-control map and a graded gap matrix. Owned by the compliance lead.\n\n**Decision criteria**\n\nBuild the map and grade the gaps first, then pick the branch:\n1. Pull the Control library (the Control items — control_id, control_type, automation, frequency, control_owner, framework tagged soc2/soc1) and read the anchor Audit item's confirmed scope (audit_type, and the scope text stating report type and Type 1/Type 2) and examination period (period_start/period_end). Map every in-scope Trust Services criterion — and every SOC 1 control objective where that report is in scope — to one or more specific Control items, capturing control type (preventive/detective, manual/automated), operating frequency, owner, and source system.\n2. Flag every criterion with no mapped control or only thin coverage; flag every orphan control that maps to nothing for retirement or re-scoping.\n3. For each flagged criterion, assess design against the criterion wording and spot-check one operating instance. Draft the gap matrix: gap description, affected criteria, severity, proposed remediation, candidate owner, and a target date inside the examination period.\n4. Summarize coverage by criteria category so the reviewer sees where the program is thin.\n\nBranch conditions:\n- `audit_ready` — every in-scope criterion maps to at least one adequately designed control, no criterion is uncovered, and no material gap remains. Thin-but-adequate coverage backed by a documented compensating control qualifies.\n- `gaps_found` — any criterion is uncovered or only thinly covered, a spot-checked control fails on design or its single operating instance, or any gap is rated material; the affected control needs clean operating history inside the period before evidence is pulled.\n\n**Record in AssureSwarm**\n- Query the Control library and its coverage with coach-query-data; link each in-scope Control item to the anchor Audit item with coach-items-link. There is no Criterion/Requirement item type, so the criterion-to-control mapping itself is not stored as item links — it lives inside the mapping-matrix document.\n- Attach the criteria-to-control mapping matrix and the graded gap matrix (both XLSX) to this step with coach-document-upload.\n- Submit the `readiness_state` SELECT (`audit_ready` | `gaps_found`) on this step's form; record the decision rationale with evidence references in the step result and the decision owner in native approval.\n\n**Exit criteria** — Every in-scope criterion is mapped or flagged; the gap matrix is attached with severities and owners; the `readiness_state` routing selector is submitted and the step result contains a rationale, and the unchosen branch is prunable.","kind":"decision","label":"Map controls and assess readiness","performedBy":{"primitives":["coach-query-data","coach-items-link","coach-document-upload"]}},"id":"map-and-assess"},{"data":{"description":"Agent drafts remediation plans, tracks execution, and validates fix artifacts exist; human approves each gap closure","instructions":"**Objective** — Close or formally accept every material gap from the readiness gap matrix so each affected control accumulates clean operating history before evidence is pulled.\n\n**Inputs**\n- The gap matrix attached to the readiness decision: each line's gap description, affected criteria, severity, proposed remediation, candidate owner, and target date.\n- The mapping matrix, so new or changed controls can be reflected back into coverage.\n- Control ownership records and the examination period boundaries.\n\n**Procedure**\n1. Create a remediation Issue per gap-matrix line with coach-item-create — issue_type: deficiency, source: self_assessment, severity per the gap grade, the fix actions in remediation_plan, issue_owner, identified_date, and a target_remediation_date early enough for the changed control to build operating history inside the period — and link it with coach-items-link to the affected Control item and the anchor Audit. (There is no Criterion item type; the criterion each gap affects is carried in the gap matrix and the Issue description, not as a link.)\n2. Track execution status with coach-query-data; chase owners as target dates approach and keep each Issue current as fixes land.\n3. Validate each claimed fix by confirming the proving artifact exists on file: for a policy fix, capture the new or updated policy as a Policy item with coach-item-create (policy_type, policy_owner, version, effective_date, next_review_date + review_frequency), attach the governed document to it, and link it to the affected Control; for other fixes, confirm the configuration evidence or a post-fix operating instance dated after implementation. Update the mapping matrix for any new or changed control.\n4. For any gap that will not be fixed this cycle, record the acceptance structurally rather than letting it stand implied: create an Issue with issue_type: policy_exception carrying exception_approver (the signing executive) and exception_expiry_date (the re-review date), linked to the affected Control and — where one exists in the register — the related Risk item, and set treatment: accept on that Risk. Obtain the executive signature and attach it to the Issue.\n\n**Record in AssureSwarm**\n- Create remediation Issues (coach-item-create — issue_type: deficiency, source: self_assessment, severity, remediation_plan, issue_owner, identified_date, target_remediation_date) and link each to its affected Control and the anchor Audit (coach-items-link); set actual_remediation_date once the fix is validated and track status with coach-query-data.\n- For accepted gaps: a policy_exception Issue (exception_approver, exception_expiry_date) linked to the affected Control and the related Risk, with treatment: accept set on that Risk.\n- Capture each validated policy fix as a Policy item (coach-item-create — policy_type, policy_owner, version, next_review_date) with its governed document attached (coach-document-upload) and linked to the affected Control (coach-items-link); attach each other per-gap validation artifact and each executive-signed acceptance document with coach-document-upload.\n\n**Exit criteria** — Every material gap is either closed with a validated artifact on file or covered by an executive-signed policy_exception Issue (treatment: accept on its Risk); the mapping matrix reflects all changed controls; the program is released to evidence planning.","label":"Remediate gaps","performedBy":{"primitives":["coach-item-create","coach-items-link","coach-query-data","coach-document-upload"]}},"id":"remediate-gaps"},{"data":{"decisionField":"evidence_quality","description":"Approve owned evidence requests and resolve QA defects before choosing complete evidence or rework.","formData":{"fields":[{"key":"evidence_quality","label":"Evidence quality","options":[{"label":"Evidence complete","value":"complete"},{"label":"Rework needed","value":"rework_needed"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Approve owned evidence requests and resolve QA defects before choosing complete evidence or rework.\n\n**Inputs**\n- The final mapping matrix — post-remediation on the gaps path, as-mapped on the audit-ready path — with every in-scope control and its criteria links.\n- Control ownership records (owner + backup, source-system access).\n- The confirmed examination period and the auditor's standard request list, if available.\n\n**Procedure**\n_This checkpoint absorbs “Build the evidence request list”. The agent runs the preparation, evidence assembly and record updates below; the named owners retain the substantive decisions and approvals stated in the procedure._\n1. Build the evidence request list: Turn the final control set into an owned, scheduled provided-by-client (PBC) request list, issued to control owners as the evidence request they answer, and backed by an evidence workspace the team can execute item by item.\n2. Generate the PBC list from the final mapping matrix: for each control, the artifacts that demonstrate design and operation — policies, system configurations, system-generated reports, tickets, approvals, and full population files for sampled controls — each with source system, period coverage, format, and completeness expectations. Deduplicate so a single artifact serves every criterion it can.\n3. Record each PBC request as a row in the request-list document. There is no Request/Task item type, so a PBC request is not stored as an item — the request-list document plus the progress dashboard are the per-request tracking surface. Link each in-scope Control item to the anchor Audit with coach-items-link where not already linked, so control coverage stays queryable even though the requests live in the list.\n4. Assign each request an accountable owner and backup from ownership records, set due dates that leave a QA and rework buffer before fieldwork, and flag any owner lacking access to the source system they need.\n5. Issue the request list through the existing evidence workspace. Retrieve existing artifacts first and attach them as documents. Obtain only unresolved generation parameters, period limits or population caveats from the named source owner outside the complete executor and approver roster; participants record their own findings in native results. Verify population completeness from source evidence and use native approval for required attestation.\n6. Stand up the evidence workspace with a naming convention and per-request status tracking, and build a PBC progress dashboard with coach-dashboard-create.\n7. Collect and QA evidence: Decide whether the collected evidence set is audit-ready (complete) or needs correction (rework_needed), after chasing owners and QA-ing every item. Owned by the compliance lead.\n\n**Decision criteria**\nCollect and QA first, then pick the branch:\n1. Chase each owner against the due dates with coach-workflow-scan; send reminders ahead of deadlines and escalate blockers the day they surface.\n2. File each submission against its PBC request in the evidence workspace with coach-document-upload, preferring system-generated output with visible timestamps, report parameters, and system identifiers, named to the workspace convention.\n3. QA every item on three checks: period coverage (dates span the requested window), completeness (full unfiltered populations, all requested fields, generation parameters visible), and legibility (timestamps and system context readable, no manual alterations or unexplained edits).\n4. Flag each failing item with the precise defect and an exact fix instruction, capturing them in the QA pass/fail defect log (XLSX/CSV); summarize pass/fail counts by criterion with coach-query-data.\n\nBranch conditions:\n- `complete` — every item passes all three QA checks, or carries an accepted known-limitation note, so the set meets audit standards.\n- `rework_needed` — any item fails period coverage, completeness, or legibility and can be regenerated correctly.\n\n**Record in AssureSwarm**\n- The PBC evidence request list is an XLSX document attached to this step with coach-document-upload — one row per request (artifact, source system, period coverage, format, owner, backup, due date). No Request/Task item type exists, so requests are not created as items; the list document and the dashboard are their tracking home.\n- The request-list row supplies request reference, control, owner and expected period. Attach evidence documents, record actual period and completeness checks with caveats in native results, and preserve authenticated source attribution. Link each response to its row for the progress dashboard.\n- Link the in-scope Control items to the anchor Audit with coach-items-link where coverage is not already recorded.\n- Build the PBC progress dashboard (status by criterion/owner) with coach-dashboard-create.\n- Scan and chase owners with coach-workflow-scan; file each submission against its PBC request with coach-document-upload; attach the QA pass/fail defect log (XLSX/CSV) to this step and tally pass/fail by criterion with coach-query-data.\n- Submit the `evidence_quality` SELECT (`complete` | `rework_needed`) on this step's form; record the rationale with evidence references in the step result and the decision owner in native approval.\n\n**Exit criteria**\n- Every in-scope control has at least one owned, dated PBC request row with the evidence request issued through the existing workspace; access and capacity conflicts are flagged; the evidence workspace and progress dashboard exist; the list reconciles to the auditor's standard request list.\n- Every PBC item is filed and QA-checked; flags carry precise defects; the `evidence_quality` routing selector is submitted and the step result contains a rationale, and the unchosen branch is prunable.","kind":"decision","label":"Collect and QA evidence","performedBy":{"primitives":["coach-item-create","coach-items-link","coach-dashboard-create","coach-document-upload","coach-workflow-scan","coach-query-data"]}},"id":"collect-and-qa-evidence"},{"data":{"description":"Agent re-requests each flagged item with the precise gap noted and re-checks resubmissions; human validates before packaging","instructions":"**Objective** — Correct every evidence item flagged in QA so the set meets audit standards, without restarting collection.\n\n**Inputs**\n- The QA defect log and the rework rationale from the collection decision: each failing item with its specific gap (wrong date range, filtered population, missing system context, illegible capture).\n- The evidence workspace and its naming convention.\n- Owner and source-system records for re-requests.\n\n**Procedure**\n1. List each failing item with its precise defect and re-request it from its owner with the exact regeneration instruction — correct date range, unfiltered population, visible generation parameters, clean capture.\n2. Track resubmissions with coach-workflow-scan and re-run the same period, completeness, and legibility checks on each returned item, marking it cleared or still defective until the defect log is fully dispositioned.\n3. For anything that genuinely cannot be produced, draft a known-limitation note with a written explanation an auditor could weigh.\n\n**Record in AssureSwarm**\n- Re-file corrected artifacts against their PBC requests with coach-document-upload; track resubmissions with coach-workflow-scan.\n- Attach each known-limitation note (one per unproducible item) to its PBC request on this step.\n\n**Exit criteria** — Every flagged item is re-checked and marked cleared or covered by an accepted known-limitation note; the tracker shows a clean or explained status on every item before packaging.","label":"Rework flagged evidence","performedBy":{"primitives":["coach-workflow-scan","coach-document-upload"]}},"id":"rework-evidence"},{"data":{"description":"Agent packages and indexes PBC responses, schedules walkthroughs, tracks auditor requests to closure, then archives the cycle and seeds the next one; human leads walkthroughs, approves responses and formally closes the cycle","instructions":"**Objective** — Deliver a complete, navigable evidence package, drive fieldwork to a clean finish with every auditor request answered, and close the cycle so the next examination reuses what this one built — the sponsor's approval recorded here *is* the closure.\n\n**Inputs**\n- The QA'd evidence set — passed items plus accepted known-limitation notes — and the PBC tracker/manifest.\n- The mapping matrix and the in-scope criteria, for the cross-reference index.\n- The auditor's request portal or agreed secure channel and the walkthrough schedule.\n- The org's retention labels and retention periods, governed by the records-management/retention Policy item.\n- The gap and defect logs, walkthrough notes, and the exceptions and accepted risks carried out of fieldwork and remediation.\n\n**Procedure**\n_Items 1–4 run fieldwork; items 5–9 close the workflow (folded from the former \"Close and archive\" step); the approval recorded here is the closure, with no separate confirmation step._\n\n1. Assemble the PBC response package organized by request item, with an index that cross-references every artifact to its controls and criteria using coach-document-link, and with the mapping matrix and known-limitation notes stated up front.\n2. Verify the manifest matches the tracker one-for-one with nothing out of scope or over-exposed, export the package with coach-item-export, and stage delivery through the auditor's portal or secure channel with written receipt confirmation requested.\n3. Schedule each walkthrough with the correct control owner plus a compliance chaperone and prepare per-owner briefs so verbal answers match the delivered evidence.\n4. Set fieldwork_start on the anchor Audit when walkthroughs begin and fieldwork_end when the auditor closes fieldwork. Log every auditor question, commitment, and follow-up request the day it is raised: routine Q&A and evidence requests go into a fieldwork request tracker document (there is no Request item type), each with an owner and due date chased to closure with supplemental evidence delivered promptly; any exception the auditor intends to report becomes an Issue with coach-item-create — issue_type: exception, source: external_audit, severity, a factual remediation-oriented management_response, and issue_owner — linked to the anchor Audit.\n5. Record the engagement outcome on the anchor Audit item: rating, opinion (opinion: na for a readiness-only cycle), and report_date. Then export the full workflow record with coach-workflow-export; the archived workflow instance attached to the anchor Audit is the durable cycle record.\n6. Archive every artifact under the org's retention labels, recording the archive location and retention period. The records-management/retention policy is a Policy item (policy_type: policy or standard) in the org's Policy library — reference it as the governing source of the labels. The retention labels themselves have no native field, so attach the exported record and artifacts as documents on this step under those labels, referencing that Policy item.\n7. Draft lessons learned — which items caused rework, which controls drew exceptions, where the timeline slipped — and seed the next cycle by exporting this run's PBC list and control calendar as starting artifacts with coach-item-export. With no downstream workflow declared, these seed documents on this step are the de facto handoff package for the next examination.\n8. Create a carry-forward Issue with coach-item-create for every open exception and accepted risk — issue_owner and target_remediation_date — linked to the anchor Audit, and re-confirm treatment: accept on each accepted Risk item, so nothing waits for the next cycle to be rediscovered.\n9. Draft and send the closure communication to the executive sponsor and customer-facing teams; the executive sponsor's approval of the delivered package and the recorded outcome closes the cycle.\n\n**Record in AssureSwarm**\n- Build the cross-reference index (XLSX) with coach-document-link, linking each package artifact to its Control items and the anchor Audit; export the package with coach-item-export.\n- Set Audit.fieldwork_start and Audit.fieldwork_end as fieldwork opens and closes, and the engagement outcome — rating, opinion (na for a readiness-only cycle), report_date — on the anchor Audit.\n- Log auditor exceptions as Issue items (coach-item-create — issue_type: exception, source: external_audit, management_response, issue_owner, linked to the anchor Audit); keep routine Q&A requests in the fieldwork request tracker document, driving each to closure.\n- Export the workflow record and next-cycle seed artifacts (coach-workflow-export, coach-item-export); the archived workflow instance on the anchor Audit is the durable cycle record.\n- Create carry-forward Issue items (coach-item-create — issue_owner, target_remediation_date, linked to the anchor Audit) for every open exception and accepted risk; re-confirm treatment: accept on each accepted Risk.\n- Attach the closure record, lessons learned, and the exported cycle record under retention labels with coach-document-upload (the labels derive from the records-management/retention Policy item; the labels themselves have no native field, so the artifacts attach as documents referencing that Policy item).\n\n**Exit criteria** — The package is delivered with confirmed receipt and a complete cross-reference index; every walkthrough is held; every auditor exception is an owned, closed Issue and every routine request is logged and closed; fieldwork dates and the engagement outcome are recorded on the anchor Audit; the archive can answer auditor or customer questions without relying on the people who ran the cycle; every exception and accepted risk has an owned follow-up; the closure communication is sent and the executive sponsor's approval on this step closes the workflow.","label":"Package and coordinate the auditor","performedBy":{"primitives":["coach-document-upload","coach-export-package","coach-item-create","coach-workflow-export"]}},"id":"package-and-coordinate-auditor"}],"sourceTemplateId":"workflow-library:controls-soc2-readiness-evidence-cycle"}