| name | compliance-and-audit |
| title | Compliance and Audit |
| description | Use when a project requires a compliance framework mapping, when risks need formal documentation, when audit evidence must be collected, or when producing a compliance attestation before release. Applies to SOC 2, ISO 27001, GDPR, PCI DSS, NIST CSF, and DORA. |
| author | Kaademos |
| author_url | https://github.com/Kaademos/secure-sdlc-agents/tree/main/skills/compliance-and-audit |
| license | MIT |
| version | 0.1.0 |
| execution_mode | open |
| jurisdiction | general |
| practice | cybersecurity |
| language | en |
Compliance and Audit
Overview
This skill maintains the governance, risk, and compliance (GRC) layer of the Secure SDLC.
It translates security work into auditable, framework-aligned documentation that survives
a real audit — not a self-assessment checklist filled in the night before.
The discipline: compliance is a continuous process. Every security control implemented
during Build and Test must be captured as evidence at the time it is implemented,
not reconstructed six months later.
When to Use
- A new project or feature processes regulated data (PII, payment data, health data)
- A compliance gap analysis is required
- Risks need to be formally accepted, transferred, or mitigated on record
- Audit evidence must be collected for a specific control
- Producing a compliance attestation before a release or audit
- Responding to a customer security questionnaire or due diligence request
Process
Step 1 — Determine applicable frameworks
Based on data classification and business context, identify which frameworks apply:
| Framework | Applies when… |
|---|
| SOC 2 Type II | You process customer data and need to demonstrate trust to enterprise buyers |
| ISO/IEC 27001:2022 | Formal ISMS certification is required (often for EU/UK contracts) |
| NIST CSF 2.0 | US federal contracts or voluntary alignment with US security standards |
| PCI DSS v4.0 | Any feature handling payment card data |
| GDPR / UK GDPR | Any processing of personal data of EU or UK residents |
| DORA | Financial services entities operating in the EU |
| HIPAA | Protected health information (PHI) in the US |
| OWASP ASVS | Always — this is the technical requirements anchor for all other frameworks |
Step 2 — Produce the risk register
Create or update docs/risk-register.md with every identified risk:
| Risk ID | Description | Category | Likelihood | Impact | Inherent Risk | Control(s) | Residual Risk | Owner | Status | Due Date |
|---------|-------------|----------|------------|--------|--------------|------------|--------------|-------|--------|----------|
| R-001 | SQL injection in search endpoint | Application | High | Critical | Critical | Input validation, WAF, SAST | Medium | Dev Lead | Open | YYYY-MM-DD |
| R-002 | Insider access to production DB | Access Control | Medium | High | High | RBAC, PAM, audit logs | Low | Cloud/Platform | Mitigated | — |
