compliance-and-audit

name	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.

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 | — |

Every vulnerability found by any agent must appear here with an owner, severity, and status. Risks do not disappear — they are mitigated, accepted, or transferred, with documentation.

Step 3 — Map controls to frameworks

Produce a control mapping table that connects ASVS requirements to applicable framework controls:

| ASVS Ref | Requirement | SOC 2 | ISO 27001 | NIST CSF | PCI DSS |
|----------|-------------|-------|-----------|----------|---------| 
| V6.2.1 | Password complexity ≥ 12 chars | CC6.1 | A.8.5 | PR.AC-1 | Req 8.3 |
| V14.1.1 | Encryption at rest (AES-256) | CC6.7 | A.8.24 | PR.DS-1 | Req 3.5 |
| V12.2.1 | TLS 1.2+ for all external comms | CC6.7 | A.8.20 | PR.DS-2 | Req 4.2 |

Step 4 — Collect audit evidence at time of implementation

For every control validated during Build or Test, create an evidence record immediately:

## Evidence Record: [Control ID]

**Control:** [Framework] — [Reference] — [Control Name]
**Evidence Type:** Test result / Configuration screenshot / Policy document / Log extract
**Date Collected:** YYYY-MM-DD
**Collected By:** [Who or which agent]
**Description:** [What this demonstrates — be specific enough for an auditor who wasn't there]
**Artefact:** [File path or link]
**Review Status:** Pending / Approved

Evidence must be collected at implementation time. Evidence reconstructed after the fact fails audit scrutiny.

Step 5 — Risk acceptance process

When a risk cannot be fully mitigated before release:

1. Document the risk in full (likelihood, impact, inherent score, existing controls)
2. Describe the residual risk after controls
3. Obtain a written business justification
4. Record the name and role of the approver (must be appropriate seniority for the risk level)
5. Set a mandatory review date — accepted risks expire

## Risk Acceptance: [Risk ID]

**Risk:** [Description]
**Inherent Risk:** [Score]
**Mitigating Controls:** [What's already in place]
**Residual Risk:** [Score after controls]
**Business Justification:** [Why this risk is being accepted rather than fixed]
**Accepted By:** [Name, Role]
**Acceptance Date:** YYYY-MM-DD
**Review Date:** YYYY-MM-DD

Step 6 — Produce the release compliance attestation

Before every release, write docs/audit-evidence/compliance-attestation-vX.Y.Z.md:

## Compliance Attestation — Release vX.Y.Z

**Date:** YYYY-MM-DD
**Frameworks in scope:** [List]

### Control Status Summary

| Framework | Total Controls | Compliant | Gap | Accepted Risk |
|-----------|---------------|-----------|-----|---------------|
| SOC 2 | 22 | 20 | 1 | 1 |

### Open Gaps
[List with owner and remediation timeline]

### Accepted Risks
[List with business justification and approver]

### Attestation
All in-scope controls reviewed. Gaps and accepted risks formally acknowledged.
Release is approved from a GRC perspective pending Release Manager sign-off.

Common Rationalizations

Excuse	Counter
"We'll document compliance after we launch"	Auditors require evidence contemporaneous with the control implementation. Retrospective documentation is a finding.
"We're too early-stage for formal compliance"	SOC 2 readiness takes 6–12 months. If you start when a customer requires it, you've already lost the deal.
"We've accepted this risk before"	Risk acceptance is time-bound and context-specific. Prior acceptance does not carry forward to a new feature or a changed threat landscape.
"The risk register is the security team's job, not mine"	Risk ownership belongs to the team generating the risk. Dev teams own application risks; Cloud teams own infrastructure risks.
"Our pentest report counts as audit evidence"	Pentest evidence is one artefact. Auditors require evidence for each control, not a single document.

Red Flags

• A risk register that hasn't been updated since the last audit
• Accepted risks with no expiry date — permanent acceptance is not a valid posture
• Compliance controls documented but no evidence they were actually implemented
• A feature handling PII with no GDPR Article 30 record of processing activity
• Audit evidence collected in a rush the week before an audit, not at time of implementation
• Framework mapping that lists "compliant" for controls that were never tested
• Risk acceptance signed off by an engineer rather than appropriate business authority

Verification

Do not close this phase until:

• All applicable compliance frameworks identified and documented
• Risk register is current — all findings from appsec-engineer and cloud-platform-engineer have entries
• Control mapping table exists in docs/ and reflects current ASVS requirements
• Audit evidence collected for every control claimed as implemented
• All accepted risks have a named approver, business justification, and review date
• Compliance attestation document written and reviewed before release
• grc-analyst has provided compliance context to release-manager for the go/no-go decision