securitybusiness
Compliance Assessment
Conduct regulatory compliance assessments — mapping controls to frameworks (SOC 2, GDPR, HIPAA, ISO 27001), identifying gaps, and producing remediation roadmaps with evidence requirements.
complianceSOC2GDPRHIPAAISO-27001audit
Works well with agents
Works well with skills
compliance-assessment/
SKILL.md
Markdown| 1 | |
| 2 | # Compliance Assessment |
| 3 | |
| 4 | ## Before you start |
| 5 | |
| 6 | Gather the following from the user. If anything is missing, ask before proceeding: |
| 7 | |
| 8 | 1. **Which frameworks apply?** — SOC 2, GDPR, HIPAA, ISO 27001, PCI DSS, or others |
| 9 | 2. **What is the scope?** — Which systems, services, data types, and teams are in scope |
| 10 | 3. **What is the driver?** — Customer requirement, regulatory obligation, funding milestone, or internal initiative |
| 11 | 4. **What is the timeline?** — Audit date, certification deadline, or customer commitment |
| 12 | 5. **What exists today?** — Current policies, controls, prior audit reports, known gaps |
| 13 | 6. **Who are the stakeholders?** — Engineering, legal, security, executive sponsor |
| 14 | |
| 15 | ## Assessment template |
| 16 | |
| 17 | ### 1. Define Scope Boundary |
| 18 | |
| 19 | Document exactly what is in and out of scope: |
| 20 | |
| 21 | ``` |
| 22 | In Scope: |
| 23 | - Systems: [List every system, service, and data store] |
| 24 | - Data types: [PII, PHI, financial data, credentials, logs] |
| 25 | - Teams: [Engineering, DevOps, support, HR] |
| 26 | - Environments: [Production, staging, CI/CD pipelines] |
| 27 | - Third parties: [Cloud providers, SaaS tools, subprocessors] |
| 28 | |
| 29 | Out of Scope: |
| 30 | - [System/area]: [Reason] |
| 31 | ``` |
| 32 | |
| 33 | Rules: if a third-party processes in-scope data, they are in scope. If staging has production data copies, staging is in scope. CI/CD pipelines deploying to production are in scope. |
| 34 | |
| 35 | ### 2. Map Controls to Framework Requirements |
| 36 | |
| 37 | For each framework, map existing controls to requirements per control area: |
| 38 | |
| 39 | | Requirement | Framework Ref | Current Control | Status | Gap | |
| 40 | |-------------|--------------|-----------------|--------|-----| |
| 41 | | Unique user IDs | SOC 2 CC6.1, ISO A.9.2.1 | SSO via Okta | Compliant | None | |
| 42 | | MFA for privileged access | SOC 2 CC6.1, ISO A.9.4.2 | MFA for admin roles | Compliant | None | |
| 43 | | Access reviews | SOC 2 CC6.2, ISO A.9.2.5 | None | Gap | Quarterly review needed | |
| 44 | |
| 45 | Cover at minimum: Access Control, Data Protection (encryption, key management, retention), Logging and Monitoring, Incident Response, Change Management, Business Continuity, Vendor Management, HR Security (training, onboarding/offboarding). |
| 46 | |
| 47 | ### 3. Evidence Inventory |
| 48 | |
| 49 | For every "Compliant" or "Partial" control, document: the control name, evidence type (policy document, configuration screenshot, logs/reports, process records, or third-party certification), evidence location, last verified date, and refresh cadence. |
| 50 | |
| 51 | If evidence does not exist for a control marked "Compliant," it is not compliant. Undocumented controls fail audits. |
| 52 | |
| 53 | ### 4. Gap Analysis |
| 54 | |
| 55 | For each gap, document using this format: |
| 56 | |
| 57 | ``` |
| 58 | Gap ID: GAP-001 |
| 59 | Control Area: Access Control |
| 60 | Requirement: Quarterly access reviews (SOC 2 CC6.2) |
| 61 | Current State: No regular access reviews performed |
| 62 | Risk Level: High |
| 63 | Remediation: Implement quarterly review with automated user listing |
| 64 | Evidence Needed: Review records, revocation tickets |
| 65 | Estimated Effort: 2 weeks to implement, 4 hours/quarter ongoing |
| 66 | ``` |
| 67 | |
| 68 | Risk levels: **Critical** (regulatory violation, active exposure), **High** (control missing entirely), **Medium** (partially implemented), **Low** (exists but evidence incomplete). |
| 69 | |
| 70 | ### 5. Remediation Roadmap |
| 71 | |
| 72 | Prioritize gaps into phases. Each item must have a single owner, deadline, and evidence deliverable: |
| 73 | |
| 74 | - **Phase 1 (0-30 days)**: Critical and High gaps |
| 75 | - **Phase 2 (30-90 days)**: Medium gaps |
| 76 | - **Phase 3 (90-180 days)**: Low gaps and documentation |
| 77 | |
| 78 | ### 6. Framework-Specific Considerations |
| 79 | |
| 80 | **SOC 2**: Type II requires a period of observation (3-12 months). Controls implemented one week before the audit window provide insufficient evidence. |
| 81 | |
| 82 | **GDPR**: Requires data processing records (Article 30), DPIAs for high-risk processing (Article 35), and documented lawful basis for each processing activity. |
| 83 | |
| 84 | **HIPAA**: Requires formal risk analysis, Business Associate Agreements with all PHI vendors, and minimum necessary access. Breach notification within 60 days. |
| 85 | |
| 86 | **ISO 27001**: Requires a formal ISMS with Statement of Applicability, risk treatment plan, and management review. Certification requires accredited external audit. |
| 87 | |
| 88 | ## Quality checklist |
| 89 | |
| 90 | Before delivering a compliance assessment, verify: |
| 91 | |
| 92 | - [ ] Scope boundary is documented with explicit in/out decisions |
| 93 | - [ ] Every control area has been assessed against each applicable framework |
| 94 | - [ ] Each compliant control has evidence with location and verification date |
| 95 | - [ ] Gaps include risk level, remediation steps, and evidence requirements |
| 96 | - [ ] Remediation roadmap is phased with owners, deadlines, and deliverables |
| 97 | - [ ] Framework-specific requirements (observation periods, mandatory documents) are addressed |
| 98 | - [ ] Third-party/vendor controls are assessed, not assumed compliant |
| 99 | |
| 100 | ## Common mistakes |
| 101 | |
| 102 | - **Treating compliance as point-in-time.** Controls must remain effective after the audit. Build ongoing processes, not one-time fixes. |
| 103 | - **Assuming vendor compliance covers you.** Your cloud provider's SOC 2 does not make you SOC 2 compliant. You own your configuration. |
| 104 | - **Documenting controls that do not exist.** Auditors verify operation, not just policy documents. A policy without an implemented process is a finding. |
| 105 | - **Ignoring evidence requirements.** A control without evidence is a gap. Every control must produce verifiable proof of operation. |
| 106 | - **Scoping too narrowly.** Excluding systems that process in-scope data creates unassessed risk. Auditors will question exclusions. |
| 107 | - **No single owner for remediation.** "The team will handle it" means no one will. Every gap needs one person accountable by a specific date. |
| 108 |