12 - Compliance Framework - GDPR, SOC2, ISO27001 Mapping and Automation

Compliance Framework: Automating Conformity

Compliance in the DevSecOps context is not a bureaucratic exercise, but a set of technical controls that can be automated and continuously verified. Frameworks like GDPR, SOC2, ISO27001, and PCI-DSS define security requirements that translate directly into implementable DevSecOps controls as code.

The compliance-as-code approach transforms compliance requirements into automated policies, continuous evidence collection, and verifiable audit trails. This reduces audit effort, eliminates gaps between audits, and provides demonstrable real-time compliance.

Mapping Compliance to DevSecOps Controls

Each compliance framework defines requirements that can be satisfied through the DevSecOps controls we've explored in this series:

SOC2: Trust Service Criteria

SOC2 (Service Organization Control Type 2) is the most requested compliance standard for SaaS companies. It's based on five Trust Service Criteria: Security, Availability, Processing Integrity, Confidentiality, and Privacy.

For DevSecOps, the most relevant criterion is Security (Common Criteria), which requires controls to protect systems from unauthorized access:

• CC6 - Logical Access: RBAC, MFA, least privilege, periodic access reviews
• CC7 - System Operations: monitoring, vulnerability management, incident response
• CC8 - Change Management: code review, approval workflows, testing

ISO27001: Information Security Management

ISO27001 is the international standard for information security management. It defines an ISMS (Information Security Management System) with 93 controls in Annex A, many of which map directly to DevSecOps practices.

Compliance-as-Code: Implementation

The compliance-as-code concept is implemented at three levels:

1. Automatic Policy Enforcement

Compliance policies are implemented as code (OPA/Rego, Kyverno) and automatically applied in the pipeline and infrastructure.

2. Continuous Evidence Collection

Compliance evidence is automatically collected from every pipeline execution, deploy, and security operation. This eliminates manual pre-audit collection.

# .github/workflows/compliance-evidence.yml
name: Compliance Evidence Collection
on:
  push:
    branches: [main]

jobs:
  collect-evidence:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: SAST Evidence (CC7.1)
        run: |
          semgrep scan --config auto --sarif > evidence/sast-results.sarif
          echo "SAST scan completed at $(date -u)" >> evidence/audit-log.txt

      - name: SCA Evidence (CC7.1)
        run: |
          npm audit --json > evidence/sca-results.json
          echo "SCA scan completed at $(date -u)" >> evidence/audit-log.txt

      - name: Container Scan Evidence (CC7.1)
        run: |
          trivy image --format json myapp:latest > evidence/container-scan.json
          echo "Container scan completed at $(date -u)" >> evidence/audit-log.txt

      - name: SBOM Generation (Supply Chain)
        run: |
          syft myapp:latest -o cyclonedx-json > evidence/sbom.json
          echo "SBOM generated at $(date -u)" >> evidence/audit-log.txt

      - name: Store Evidence
        uses: actions/upload-artifact@v4
        with:
          name: compliance-evidence-${{ github.sha }}
          path: evidence/
          retention-days: 365
      

3. Immutable Audit Trail

Every compliance-relevant action is recorded in an immutable audit trail that includes who did what, when, and with what result:

# Audit log structure
audit_entry:
  timestamp: "2026-01-15T10:30:00Z"
  actor: "github-actions[bot]"
  action: "security-scan"
  resource: "myapp:v1.5.0"
  result: "PASS"
  details:
    sast_findings: 0
    sca_critical: 0
    container_vulnerabilities: 2
    container_vulnerabilities_severity: "LOW"
  evidence_ref: "artifact/compliance-evidence-abc123"
  pipeline_run: "https://github.com/org/repo/actions/runs/12345"
      

Compliance Automation Tools

Continuous Compliance Monitoring

Compliance is not a point-in-time event (the annual audit), but a continuous process. Continuous compliance monitoring constantly verifies that all controls are in place and alerts when a deviation occurs:

• Real-time dashboard: compliance status updated in real-time for each control
• Deviation alerts: immediate notification when a control fails
• Trend analysis: compliance trend analysis over time to identify improvement areas
• Evidence repository: centralized archive of all automatically collected evidence

Audit Preparation

Compliance Best Practices

1. Automation first: automate 90%+ of compliance controls
2. Continuous evidence collection: collect evidence on every pipeline execution
3. Single source of truth: one centralized platform for all evidence
4. Explicit mapping: document the mapping between controls and compliance requirements
5. Periodic reviews: quarterly review of controls and policies
6. Team training: continuous training on framework updates

Conclusions

Automated compliance is a natural result of a good DevSecOps implementation. When security controls are integrated into the pipeline and evidence collection is automatic, audit preparation becomes a verification exercise rather than a frantic documentation gathering.

In the next article, we'll explore European regulations in detail: GDPR for developers, NIS2 directive, and the new Cyber Resilience Act, with focus on technical implementation of requirements.

Related deep dive: 10 - Infrastructure as Code Scanning - IaC Security e Terraform Policy.

Related deep dive: 11 - Runtime Security - Monitoraggio e Rilevamento di Anomalie.