SOC 2 and ISO evidence checklists

Before mapping SOC 2 and ISO evidence

Use this page when a customer needs SOC 2-style or ISO 27001-oriented checklist rows that cite WebRiskOps evidence. The checklist organizes source links, reviewer notes and open gaps; it does not replace an auditor, management-system owner or customer compliance decision.

• Review SOC 2 and ISO evidence checklist
• Start from customer-approved reports, diagnostics, remediation history, monitoring events and customer-supplied documents.
• Keep missing artifacts visible as gaps instead of converting them into unsupported assurance language.
• Stop when `SOC2_ISO_EVIDENCE_MISSING`, `ASSURANCE_CHECKLIST_INCOMPLETE` or `ASSURANCE_BOUNDARY_REQUIRED` applies.

Map evidence to checklist items

Follow the path `SaaS procurement pack → Source report → Checklist type → Control group → Evidence artifact → Open gap or customer review`.

1. Open `/saas-procurement-pack` and choose the SOC 2 or ISO evidence checklist output. Result: the customer sees checklist mapping as evidence support, not an audit, attestation or certification workflow.
2. Open `/reports/{report}` for the current customer-approved report that will feed the checklist. Result: checklist rows use the selected project, scan dates, findings, artifacts, diagnostics and customer-approved evidence.
3. Choose `soc2_evidence_checklist` or `iso27001_evidence_checklist`. Result: the checklist uses the right control reference set before evidence is mapped.
4. For SOC 2, map evidence to `security_posture`, `change_management`, `access_evidence`, `monitoring_incident_evidence` and `vendor_dependency_evidence`. Result: each SOC 2-style row has a named evidence group and source.
5. For ISO 27001, map evidence to `asset_risk_context`, `access_control_evidence`, `operations_monitoring_evidence`, `supplier_dependency_evidence` and `improvement_register`. Result: each ISO-oriented row has a named evidence group and source.
6. For each row, set `evidence_checklist_status`, `control_reference` and `evidence_artifact_path`. Result: reviewers can trace the row to a report, scan artifact, diagnostic handoff, remediation task, monitoring event or customer-supplied document.
7. When evidence is stale, missing or outside accepted scope, increase `checklist_gap_count` and add it to `open_gap_register`. Result: `SOC2_ISO_EVIDENCE_MISSING` stays visible instead of turning gaps into unsupported answers.
8. Set `customer_review_required` before any checklist leaves WebRiskOps. Result: answer wording remains customer-owned and editable before buyer, reviewer or auditor use.
9. Remove wording that claims audit readiness, control assurance, operating effectiveness, management-system maturity or buyer acceptance. Result: `ASSURANCE_BOUNDARY_REQUIRED` blocks unsupported assurance language.
10. Set `refresh_checklist_status` after scans, diagnostics, retests or customer documents change. Result: the checklist shows whether evidence is current enough to use or must be refreshed.

SOC 2 evidence groups

SOC 2-style checklist rows should map only to evidence WebRiskOps can support.

• `security_posture` can cite security-header findings, HTTPS and mixed-content observations, risk report summaries and accepted-scope artifacts.
• `change_management` can cite fix task status, pull request or ticket-only plans, retest results and change notes.
• `access_evidence` can cite accepted scan scope, account/project ownership context and scoped platform-access request status.
• `monitoring_incident_evidence` can cite monitoring subscription state, issue recurrence history and alert or notification routing notes.
• `vendor_dependency_evidence` can cite dependency inventory, advisory snapshots and customer-supplied vendor artifacts.

ISO 27001 evidence groups

ISO-oriented checklist rows should stay in technical evidence and open-gap language.

• `asset_risk_context` can cite project URL, accepted scan scope, report risk summary and unsupported-scope notes.
• `access_control_evidence` can cite account membership role context, scoped platform access request status and authorization terms accepted for scanning.
• `operations_monitoring_evidence` can cite monitoring state, issue recurrence history, retest status and alert routing notes.
• `supplier_dependency_evidence` can cite dependency inventory, advisory snapshots and supplier artifact gaps.
• `improvement_register` can cite remediation tasks, open risk registers, retest outcomes and change notes.

Ready and blocked checklist states

Use these states before a checklist is shared outside WebRiskOps.

• Checklist ready means `SOC2_ISO_CHECKLIST_READY`, `evidence_checklist_status`, `customer_review_required` and `refresh_checklist_status` show that mapped evidence is current and customer-reviewed.
• Checklist incomplete means `ASSURANCE_CHECKLIST_INCOMPLETE` or a nonzero `checklist_gap_count` leaves open rows for missing evidence or customer-owned documents.
• Evidence missing means `SOC2_ISO_EVIDENCE_MISSING` routes the customer to the report, diagnostic, retest, monitoring or document workflow that can produce the artifact.
• Boundary required means `ASSURANCE_BOUNDARY_REQUIRED` blocks unsupported wording about audit readiness, operating effectiveness, management-system maturity, certification or buyer acceptance.
• Refresh needed means `refresh_checklist_status` is stale after scans, diagnostics, retests, remediation or customer documents change.

Continue after checklist mapping

When checklist mapping is current, continue to Assurance and procurement packs for the buyer-facing evidence pack or Non-certification boundaries for external wording. Use Public reports only after publication is allowed, Artifact retention when evidence availability or retention is unclear, and Customer responsibilities plus Data collected and excluded before sharing evidence outside the customer-approved boundary.