Add SOC 2 emergency change evidence gates

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
@@ -319,6 +319,7 @@ Prioritize remediation by audit readiness impact. Items that would result in exa
 - [ ] Conduct initial quarterly access review (CC6.1)
 - [ ] Deploy centralized logging and SIEM or log aggregation (CC7.1, CC7.2)
 - [ ] Implement change management controls in CI/CD pipeline (CC8.1)
+- [ ] Define emergency-change rollback, post-implementation review, and segregation-of-duties evidence gates (CC8.1)
 - [ ] Document and publish incident response plan (CC7.3, CC7.4)
 - [ ] Initiate vendor inventory and begin collecting vendor SOC 2 reports (CC9.2)
 - [ ] Conduct initial risk assessment (CC3.2)

skills/compliance/soc2-gap/tests/benign/emergency-change-with-post-implementation-review.md

@@ -0,0 +1,34 @@
+# Benign: Emergency change with traceable rollback and post-implementation review
+
+This fixture should satisfy the CC8.1 emergency-change evidence gate because the emergency path is expedited while preserving authorization, segregation, validation, rollback, and after-the-fact review evidence.
+
+```yaml
+change_id: CHG-2026-0522
+type: emergency
+production_deployment: true
+reason: "patch exploited dependency in public API image"
+incident_link: SEC-INC-2026-2214
+requester: appsec-oncall
+approver: engineering-manager
+deployer: platform-release-engineer
+verifier: sre-oncall
+approval:
+  status: retroactive_approved
+  retroactive_approval_due: "2026-05-23T10:00:00Z"
+  retroactive_approval_completed: "2026-05-22T22:40:00Z"
+ci_result: "passed"
+smoke_test: "api-healthcheck-run-1942"
+rollback_plan: "redeploy image digest sha256:previous-known-good and disable feature flag api.v2.cache"
+abort_criteria: "5xx rate above 2 percent for 5 minutes or auth latency above 500 ms p95"
+post_implementation_review:
+  reviewer: security-engineering-manager
+  completed_at: "2026-05-23T15:30:00Z"
+  follow_up_actions:
+    - "add dependency alert auto-ticket routing"
+    - "add emergency-change evidence checklist to release template"
+```
+
+Expected result:
+
+- No emergency-change finding if the evidence is complete and timestamps fall within the policy-defined approval SLA.
+- Record `CHG-2026-0522` in the CC8.1 emergency-change evidence checklist with approval, SoD, test, rollback, and review evidence present.

skills/compliance/soc2-gap/tests/vulnerable/emergency-change-missing-rollback-review.md

@@ -0,0 +1,31 @@
+# Vulnerable: Emergency change without rollback or post-implementation review
+
+This fixture should be treated as incomplete CC8.1 evidence because the emergency path bypasses the controls needed for SOC 2 operating-effectiveness testing.
+
+```yaml
+change_id: CHG-2026-0418
+type: emergency
+production_deployment: true
+reason: "hotfix login failures"
+incident_link: INC-2026-8871
+requester: api-team-lead
+approver: api-team-lead
+deployer: api-team-lead
+verifier: api-team-lead
+approval:
+  status: missing
+  retroactive_approval_due: "2026-04-19T18:00:00Z"
+  retroactive_approval_completed: null
+ci_result: "passed"
+smoke_test: null
+rollback_plan: null
+abort_criteria: null
+post_implementation_review: null
+```
+
+Expected result:
+
+- `SOC2-CC8-EMERG-03` because approval evidence is missing.
+- `SOC2-CC8-EMERG-04` because one actor requested, approved, deployed, and verified the emergency change.
+- `SOC2-CC8-EMERG-05` because rollback and abort criteria are missing.
+- `SOC2-CC8-EMERG-06` because there is no post-implementation review.

skills/compliance/soc2-gap/tsc-criteria.md

@@ -291,18 +291,61 @@ This file contains the detailed Trust Services Criteria evaluation questions, ev
   - Are changes tested before deployment to production?
   - Is there segregation of duties between development, testing, and deployment?
   - Are emergency change procedures defined?
+  - Do emergency changes retain a ticket, risk reason, approver, rollback path, and post-implementation review?
+  - Are requester, approver, and production deployer identities separated or formally exception-approved?
 - Evidence to look for:
   - Change management policy
   - CI/CD pipeline configurations showing approval gates, automated testing, and deployment controls
   - Pull request records with code review approvals
   - Change advisory board (CAB) meeting minutes (for infrastructure changes)
   - Emergency change request records
   - Segregation of duties evidence (separate roles for code authoring and production deployment)
+  - Emergency-change tickets linked to incidents, outages, vulnerability fixes, or customer-impact records
+  - Rollback plans, abort criteria, smoke-test evidence, and post-implementation review sign-off
+  - Deployment audit logs showing who requested, approved, executed, and verified the production change
 - Common gaps:
   - Developers can push directly to production without review
   - No automated testing in CI/CD pipeline
   - Emergency changes bypass all controls with no after-the-fact review
   - No segregation of duties between development and deployment
+  - Emergency changes are tracked only in chat messages, not in the formal change system
+  - Rollback plans exist generically but are not tied to the specific production change
+  - The same individual requests, approves, deploys, and closes emergency changes without compensating review
+
+#### CC8.1 Emergency Change Evidence Gate
+
+Treat emergency changes as expedited, not exempt. A SOC 2-ready emergency-change path should preserve enough evidence for an auditor to verify authorization, risk rationale, implementation control, and after-the-fact review.
+
+Require these fields for every emergency production change:
+
+| Field | Required Evidence | Audit Concern if Missing |
+|-------|-------------------|--------------------------|
+| Change identifier | Ticket ID, PR, deployment run, or CAB record | Change cannot be traced through the evidence chain |
+| Emergency reason | Incident, outage, vulnerability, customer-impact, or risk record | Emergency path may be used to bypass normal controls |
+| Approval path | Pre-approval or documented retroactive approval within policy SLA | Authorization cannot be tested |
+| Segregation of duties | Requester, approver, deployer, and verifier identities | One person can bypass or conceal control failures |
+| Test and validation evidence | CI result, smoke test, production health check, or monitoring screenshot reference | Operating effectiveness cannot be verified |
+| Rollback plan | Change-specific rollback steps, abort threshold, and rollback owner | Failed changes may not be recoverable |
+| Post-implementation review | Closure notes, root cause, follow-up actions, and reviewer sign-off | Emergency changes bypass normal learning and control improvement |
+
+Flag these findings when evidence is incomplete:
+
+```
+SOC2-CC8-EMERG-01: Emergency change lacks a formal ticket or traceable change identifier.
+SOC2-CC8-EMERG-02: Emergency reason is missing or not tied to incident, vulnerability, outage, or customer-impact evidence.
+SOC2-CC8-EMERG-03: Approval is missing, undocumented, or not completed within the policy-defined retroactive approval SLA.
+SOC2-CC8-EMERG-04: Requester, approver, deployer, and verifier are the same person without documented compensating review.
+SOC2-CC8-EMERG-05: Change-specific rollback plan or abort criteria are missing.
+SOC2-CC8-EMERG-06: Post-implementation review is missing, unsigned, or does not record follow-up control actions.
+```
+
+Add this table to the evidence checklist when emergency changes occurred during the audit period:
+
+```markdown
+| Change ID | Emergency Reason | Approval Evidence | SoD Evidence | Test Evidence | Rollback Evidence | Post-Implementation Review | CC8.1 Finding |
+|-----------|------------------|-------------------|--------------|---------------|-------------------|-----------------------------|---------------|
+|           |                  |                   |              |               |                   |                             |               |
+```
 
 ---
 
@@ -551,7 +594,7 @@ After scoring, calculate:
 | CC7.3 | Incident response plan; severity classification matrix; triage procedures |
 | CC7.4 | Tabletop exercise records; IR team roster; communication templates; post-incident review records |
 | 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 |
+| CC8.1 | Change management policy; CI/CD pipeline configs with approval gates; PR review records; CAB minutes; segregation of duties evidence; emergency-change tickets; rollback plans; post-implementation review sign-offs |
 | 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 |
 | A1.1 | Capacity monitoring dashboards; auto-scaling configs; capacity planning documentation |