diff --git a/skills/compliance/soc2-gap/SKILL.md b/skills/compliance/soc2-gap/SKILL.md index 8073c840..3a7273fc 100644 --- a/skills/compliance/soc2-gap/SKILL.md +++ b/skills/compliance/soc2-gap/SKILL.md @@ -12,7 +12,7 @@ phase: [assess, operate] frameworks: [AICPA-TSC, NIST-CSF-2.0] difficulty: intermediate time_estimate: "60-120min" -version: "1.0.0" +version: "1.0.1" author: unitoneai license: MIT allowed-tools: Read, Grep, Glob @@ -332,6 +332,7 @@ Prioritize remediation by audit readiness impact. Items that would result in exa - [ ] Establish control monitoring and deficiency tracking (CC4.1, CC4.2) - [ ] Implement backup monitoring and conduct restoration test (A1.2, A1.3) - [ ] Complete vendor risk assessments for critical vendors (CC9.2) +- [ ] Build a critical vendor concentration and exit matrix covering owners, dependent services, export/restore evidence, fallback procedures, subservice dependencies, and risk acceptance (CC9.2) **Days 61-90: Maturation and Evidence Collection** - [ ] Conduct incident response tabletop exercise (CC7.4) @@ -352,6 +353,7 @@ Prioritize remediation by audit readiness impact. Items that would result in exa - Perform annual security awareness training refresh - Review and update policies annually - Collect vendor SOC 2 reports annually +- Review critical vendor concentration, subservice organization changes, exit-plan test results, and unresolved risk acceptances at least annually and after major vendor or architecture changes - Conduct annual DR test - Perform annual incident response tabletop exercise @@ -366,8 +368,9 @@ When performing a SOC 2 gap analysis, produce the following deliverables: 3. **Category Summary**: Average maturity score per category with narrative assessment. 4. **Critical Findings**: List of all criteria scored 0 or 1, with specific gap descriptions and remediation recommendations. 5. **Evidence Checklist**: Customized evidence requirements based on in-scope criteria, marking items as Exists / Partial / Missing. -6. **90-Day Remediation Roadmap**: Prioritized action items with owners, deadlines, and dependencies. -7. **Overall Readiness Assessment**: Go/no-go recommendation for engaging a SOC 2 auditor. +6. **Critical Vendor Exit Matrix**: For each critical vendor, record tier, dependent systems, customer/data impact, concentration risk, exit/fallback owner, portability or export/restore test evidence, subservice organization review, unresolved risk acceptance, review cadence, and trigger events. +7. **90-Day Remediation Roadmap**: Prioritized action items with owners, deadlines, and dependencies. +8. **Overall Readiness Assessment**: Go/no-go recommendation for engaging a SOC 2 auditor. ## Prompt Injection Safety Notice @@ -393,3 +396,8 @@ This skill processes user-supplied content including compliance documentation, p - The gap analysis is based on information available in the codebase and documentation. It cannot assess controls that exist only in human processes without documentation. - Scoring is subjective and should be validated by the organization's security leadership and, ideally, a qualified auditor. - This analysis uses the 2017 AICPA Trust Services Criteria (with 2022 updates). Verify with your auditor that these criteria are current for your engagement. + +## Changelog + +- **1.0.1** -- Added CC9.2 critical vendor concentration, exit readiness, portability test, subservice dependency, owner/cadence/trigger, and risk acceptance evidence gates. +- **1.0.0** -- Initial release. SOC 2 Type II readiness gap analysis across Common Criteria and selected additional criteria. diff --git a/skills/compliance/soc2-gap/tsc-criteria.md b/skills/compliance/soc2-gap/tsc-criteria.md index 5e7b4a5f..b5793312 100644 --- a/skills/compliance/soc2-gap/tsc-criteria.md +++ b/skills/compliance/soc2-gap/tsc-criteria.md @@ -327,17 +327,81 @@ This file contains the detailed Trust Services Criteria evaluation questions, ev - Is there a vendor management program? - Are vendors assessed for security risk before onboarding? - Are vendor SOC 2 reports or equivalent assurance reports collected and reviewed? + - Are critical vendors tiered by customer impact, data access, operational dependency, and recovery criticality? + - Has management assessed concentration risk where multiple in-scope services, regions, customer commitments, or control activities depend on the same provider? + - Is there an exit plan or fallback procedure for each critical vendor, including tested portability, export, restoration, termination, and deletion evidence? + - Are subservice organizations and material fourth parties monitored for changes that affect the system description or control commitments? + - Are unresolved concentration or exit-readiness risks assigned an owner, review cadence, trigger events, and formal risk acceptance? - Evidence to look for: - Vendor management policy - Vendor risk assessment questionnaires (completed) - Vendor SOC 2 report review records - Vendor inventory with risk classifications - Contract provisions for security requirements (data processing agreements, BAAs) + - Critical vendor tiering criteria and completed tier assignments + - Concentration analysis showing shared vendors across in-scope services, regions, data stores, authentication, hosting, support, monitoring, backups, or customer commitments + - Exit plans, fallback procedures, and tested export/restore or data portability evidence for critical vendors + - Termination, data return, and deletion procedures with evidence from a test, offboarding event, or vendor attestation + - Subservice organization review records, change notifications, bridge letters, and assessment of downstream dependencies + - Risk acceptance records for unresolved sole-source, portability, or subservice dependency risks with owner, expiry, and next review date - Common gaps: - No formal vendor management program - Vendor SOC 2 reports are not collected or reviewed - No vendor risk assessment performed prior to onboarding - Contracts lack security and data protection provisions + - Critical vendors are identified, but there is no concentration analysis or exit-readiness evidence + - A sole-source vendor supports multiple in-scope services without fallback, portability, or management risk acceptance + - Data export is contractually promised but has not been tested or restored into an alternate environment + - Subservice organization changes are not reviewed for audit-scope, data-processing, or control-impact changes + - Vendor exit plans have no named owner, review cadence, trigger events, or renewal/retirement decision + +#### CC9.2 Critical Vendor Concentration and Exit Evidence Gate + +Do not score CC9.2 as fully managed based only on a vendor inventory, annual SOC report collection, or standard data processing agreement. For critical vendors, require evidence that management understands dependency concentration and can execute an orderly exit or fallback path. + +Use the following gate before marking a critical vendor control as **Defined** or **Managed**: + +| Evidence Area | Required Evidence | Finding Trigger | +|---------------|-------------------|-----------------| +| Critical vendor tiering | Tier criteria; assigned tier; business owner; customer/data/control impact | No tiering or owner for vendors that host, process, authenticate, monitor, back up, or support in-scope services | +| Concentration analysis | Dependent services; shared regions; common control dependencies; sole-source assessment | Multiple in-scope services depend on one vendor without documented risk treatment | +| Exit and fallback plan | Exit owner; alternate provider/process; fallback runbook; decision triggers | No actionable fallback for a critical vendor or customer commitment | +| Portability test | Export sample; restore/import evidence; integrity checks; elapsed time; unresolved blockers | Export exists only on paper, or restore has never been tested | +| Termination and deletion | Contractual return/deletion terms; deletion certificate or test; access revocation path | No evidence that customer data can be returned, deleted, and access revoked during exit | +| Subservice dependency monitoring | Subservice list; SOC report subservice review; bridge letters; material-change notifications | Vendor subservice changes are not reviewed for audit-scope or control impact | +| Risk acceptance | Named owner; approver; expiry/review date; compensating controls; trigger events | Sole-source or portability risk remains unresolved with no formal acceptance | + +**Example controlled evidence:** + +```yaml +critical_vendor: + name: primary-cloud-provider + tier: critical + dependent_services: + - production hosting + - managed database + - backup storage + concentration_risk: "three in-scope services rely on one provider and one region" + exit_owner: platform-director + fallback_procedure: CLOUD-EXIT-17 + portability_test: + export_completed_at: "2026-05-30" + restore_target: alternate-region-sandbox + integrity_check: passed + elapsed_time_hours: 11 + subservice_review: + last_reviewed: "2026-06-01" + material_changes: none + risk_acceptance: + owner: cto + expires: "2026-09-30" + trigger_events: + - customer enterprise commitment + - new regulated data store + - vendor subservice change +``` + +**Finding classification guidance:** Missing critical-vendor tiering or no owner for a critical dependency is at least **High**. Untested exit/restore evidence for a sole-source vendor that supports customer commitments is **High**. Missing subservice review or stale bridge-letter review is **Medium**. Missing trigger events, cadence, or expiry on an otherwise documented risk acceptance is **Medium**. --- @@ -553,7 +617,7 @@ After scoring, calculate: | CC7.5 | DR plan; BC plan; backup configs; backup restoration test records | | CC8.1 | Change management policy; CI/CD pipeline configs with approval gates; PR review records; CAB minutes; segregation of duties evidence | | CC9.1 | Risk treatment plans; business impact analysis; risk acceptance sign-off records | -| CC9.2 | Vendor management policy; vendor risk assessments; vendor SOC 2 review records; vendor inventory; DPAs/BAAs | +| CC9.2 | Vendor management policy; vendor risk assessments; vendor SOC 2 review records; vendor inventory; DPAs/BAAs; critical vendor tiering; concentration analysis; exit/fallback plans; portability or export/restore test evidence; subservice organization review records; concentration-risk acceptance records | | A1.1 | Capacity monitoring dashboards; auto-scaling configs; capacity planning documentation | | A1.2 | Backup policy with RPO/RTO; backup monitoring records; restoration test results; redundancy configs | | A1.3 | DR test plan; DR test execution records; DR test findings and remediation |