Compliance: SOC 2, ISO 27001 & audits

Sooner or later a large customer's security questionnaire asks: "Do you have a SOC 2 Type II report?" Without one, the deal stalls. Compliance frameworks are how companies prove to customers, regulators and auditors that they run security deliberately rather than by luck, and DevSecOps engineers end up doing much of the work: designing controls, wiring them into pipelines and producing evidence. This lesson explains the main frameworks, how an audit works, how to map controls to things you already do, and how to automate evidence so compliance stops being a scramble once a year.

#Compliance is not security, but it overlaps

Security is about actually preventing and detecting attacks. Compliance is about meeting a defined set of requirements and being able to prove it to someone else.

They overlap heavily, because most framework requirements are sensible security practices: least-privilege access, reviewed changes, encryption, logging, tested backups, incident response. But they're not the same thing:

• You can be compliant and insecure: a control can be "in place" on paper and useless in practice, such as an access review where a manager approves everything without reading it.
• You can be secure and non-compliant: excellent practices with no written policy or evidence don't pass an audit.

The goal for an engineering team is to do the security work properly and make the evidence a by-product of how you already work, not a separate theatre.

#The frameworks you'll meet

Two SOC 2 terms matter: a Type I report checks that controls were designed properly at a point in time; a Type II report checks they operated effectively over a period, typically 3 to 12 months. Customers want Type II, which means your controls must run continuously, and you must be able to show they did for every week of the period.

ISO 27001 is more about the management system: you identify risks, choose controls to treat them, document them in a Statement of Applicability, measure, review and improve. Certification audits happen once, then surveillance audits each year and recertification every three years.

EU regulation now reaches engineering teams directly, too. NIS2 sets security and incident-reporting duties for medium and large organisations in critical sectors, including cloud and digital infrastructure providers. DORA has applied to EU financial firms and their critical technology suppliers since January 2025. The Cyber Resilience Act covers anyone selling software or connected products in the EU: since 11 September 2026, manufacturers must report actively exploited vulnerabilities within 24 hours, and from December 2027 they must also meet secure-development requirements such as handling vulnerabilities throughout a product's support period. None of these gives you a certificate, but SBOMs, vulnerability management and incident runbooks are how you meet them.

A practical tip: reduce scope. If card numbers never touch your systems because you use a payment provider's hosted fields, most of PCI DSS doesn't apply to you. Isolating sensitive data into a small, well-guarded part of the system shrinks what auditors look at.

#How an audit works

1. Scoping: decide which systems, teams and locations are in scope (for example "the production SaaS platform and the people who operate it").
2. Controls: write policies (what you commit to) and controls (specific practices that implement them). Frameworks say what to achieve; you decide how.
3. Readiness assessment: a gap analysis before the real audit, by a consultant or by the audit firm within its independence rules.
4. Audit period (Type II): controls run, and evidence accumulates.
5. Fieldwork: the auditor selects samples ("show me 25 production changes from this period and their approvals", "show me the offboarding of these 5 leavers") and checks each one.
6. Report: any exceptions (samples that failed) are listed in the report, usually with management's response. Enough of them, or one serious one, and the auditor issues a qualified opinion, which customers' security teams read as a red flag.

Sampling is why consistency matters. If 24 of 25 sampled changes had a reviewed pull request and one was a hot-fix pushed directly to main, that's an exception in a document every prospective customer reads.

#Turning controls into engineering practice

Most controls map onto practices covered elsewhere in this roadmap. Here's how common SOC 2 and ISO 27001 requirements translate:

Notice the pattern: controls you enforce in code and configuration (branch protection, IaC modules, policy checks) are reliable and their evidence is easy to collect. Controls that depend on people remembering (a manual checklist before each deploy) produce exceptions.

#Compliance as code

Instead of collecting screenshots once a year, make controls checkable by machines, continuously:

• Policy as code in the pipeline: the Conftest/OPA policies from the IaC security lesson block unencrypted storage or public buckets before they exist. Each blocked pull request is evidence the control operates.
• Cloud configuration monitoring: services such as AWS Config, Security Hub, Azure Policy or Google Cloud's Security Command Center continuously evaluate resources against benchmark rules (for example the CIS benchmarks) and record history.
• Repository settings as code: manage branch protection and required checks with Terraform's GitHub provider, so a change to the control itself is reviewed.
• Scheduled evidence collection: a pipeline that exports evidence on a schedule into an append-only store.

A small example: a scheduled GitHub Actions job that exports the AWS IAM credential report and the rules protecting main monthly, using OIDC (no stored AWS keys):

name: evidence-collection
on:
  schedule:
    - cron: "0 6 1 * *"   # 06:00 UTC on the 1st of each month
  workflow_dispatch:

permissions:
  id-token: write   # for OIDC to AWS
  contents: read

jobs:
  collect:
    runs-on: ubuntu-latest
    steps:
      - uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123456789012:role/evidence-collector   # read-only, plus s3:PutObject on the evidence bucket
          aws-region: eu-west-1

      - name: IAM credential report
        run: |
          until [ "$(aws iam generate-credential-report --query State --output text)" = COMPLETE ]; do
            sleep 5
          done
          aws iam get-credential-report --query Content --output text | base64 -d > iam-credential-report.csv

      - name: Rules protecting main
        env:
          GH_TOKEN: ${{ secrets.EVIDENCE_READ_TOKEN }}   # fine-grained, read-only administration access
        run: |
          gh api "repos/$GITHUB_REPOSITORY/branches/main/protection" > branch-protection.json   # classic branch protection
          gh api "repos/$GITHUB_REPOSITORY/rules/branches/main" > branch-rules.json             # rulesets

      - name: Upload to the evidence bucket
        run: |
          month=$(date -u +%Y-%m)
          aws s3 cp iam-credential-report.csv "s3://acme-compliance-evidence/$month/"
          aws s3 cp branch-protection.json "s3://acme-compliance-evidence/$month/"
          aws s3 cp branch-rules.json "s3://acme-compliance-evidence/$month/"

Store evidence in a bucket with versioning and object lock (write once, read many), so nobody can quietly alter it later. Compliance automation platforms (Vanta, Drata, Secureframe and others) do this at scale: they connect to your cloud, identity provider, HR system and code host, test controls continuously, and show auditors the history directly.

#Access reviews, done properly

Access reviews are a classic source of exceptions, and a good example of doing a control well:

1. Export who has access to each in-scope system (cloud accounts, production databases, CI admin, the identity provider's admin role) from the source of truth, not from memory.
2. Send each manager or system owner the list for their people and systems, with last-used data, so "has admin but hasn't used it in 90 days" stands out.
3. Require an explicit keep or remove decision per entry. Revoke what's removed, and record the ticket.
4. Keep the export, the decisions and the revocation tickets as evidence.

The security value comes from step 2: reviewers who see last-used data actually remove access. A spreadsheet of names approved in bulk satisfies the letter of the control and protects nothing.

#Practice

Your company needs SOC 2 Type II within 12 months. You run a SaaS product on AWS with code on GitHub, deploys through GitHub Actions, and Google Workspace as the identity provider. Pick these five controls and, for each, describe (a) how you'd implement it, (b) how you'd enforce it technically rather than by policy alone, and (c) what evidence an auditor would sample and how you'd collect it automatically:

1. Production changes are peer-reviewed before deployment.
2. Employees' access is removed within 24 hours of leaving.
3. Production data is encrypted at rest.
4. Critical vulnerabilities are remediated within 14 days.
5. Production database backups are restored successfully at least quarterly.

#Key takeaways

• Compliance proves security practices to others; aim for real security with evidence as a by-product, not paperwork alone.
• SOC 2 Type II tests that controls operated over a period; ISO 27001 certifies a risk-driven management system; PCI DSS, HIPAA and GDPR apply by data type and jurisdiction.
• Auditors sample: every exception appears in the report, so controls must run consistently.
• Enforce controls in code and configuration (branch protection, SSO, IaC modules, policy as code) rather than by people remembering.
• Collect evidence automatically on a schedule into versioned, object-locked storage, and keep scope small by isolating sensitive data.