Compliance for Engineers: SOC 2, ISO 27001, PCI DSS, GDPR

Why this lands on your desk

Compliance feels like a tax invented by people who have never deployed anything. But it is usually the thing standing between your company and a six-figure enterprise contract, big customers will not sign until you can prove you handle their data responsibly. The good news: most of what an auditor wants, you are *already doing*. The work is making it provable, not inventing it from scratch.

We will demystify the four frameworks engineers hit most, SOC 2, ISO 27001, PCI DSS, and GDPR, separate compliance from security (they are not the same thing), and walk the audit loop so you know exactly what "collect evidence" means in code.

Compliance is a promise you can prove

Security is whether your system actually resists attack. Compliance is whether you can prove, to an outsider, with evidence, that you do the things you claim to do.

Read that twice. A system can be secure but non-compliant (you encrypt everything and enforce least privilege, but you have no audit trail to prove it). And a system can be compliant but insecure (every box is ticked, every policy documented, and a default password sits on the admin panel). Compliance raises the floor and forces consistency; it does not guarantee you are safe. Treat a clean audit report as a starting line, never a finish line.

A mental model: the restaurant health inspection

If the words still feel abstract, borrow this picture. Walk into any restaurant and look for the framed certificate near the door.

The certificate is not what makes the food safe, the cooking practices do that. But your customers cannot inspect your kitchen, so the certificate is how a stranger trusts you. That is exactly what a SOC 2 report does for a prospect who will never see your production environment.

The four frameworks, side by side

These get lumped together but they answer different questions and are driven by different forces. Two are voluntary trust signals you pursue to win deals (SOC 2, ISO 27001), one is mandatory if you touch a specific kind of data (PCI DSS), and one is the law (GDPR).

The audit loop: how a report gets made

Every framework runs the same cycle. You define what you promise to do, you do it, you keep proof, an independent auditor inspects the proof, and they issue the paper. Understanding this loop tells you exactly where engineering plugs in.

1. 1

   Define controls

   Security/GRC writes policies: 'access is granted on least privilege', 'changes are reviewed before merge'. Each becomes a testable control.

2. 2

   Implement

   Engineering makes the control real, IAM policies, branch protection, encrypted buckets. This is your day job, formalized.

3. 3

   Collect evidence

   Capture proof the control operated over time: access-review exports, PR approvals, KMS configs, log retention settings.

4. 4

   Auditor reviews

   An independent firm samples your evidence (e.g. picks 25 changes and checks each had an approval). They cannot test what you cannot prove.

5. 5

   Report / attestation

   The auditor issues the SOC 2 report or ISO certificate. You hand it to prospects; then the period resets and the loop runs again.

Controls, evidence, and audits, the vocabulary

Three words carry the whole field. A control is the thing you promise to do. Evidence is the artifact proving you did it. An audit is someone independent checking the evidence against the control. The auditor's mantra: *if it is not written down, it did not happen.* A perfectly enforced rule with no exported proof fails the audit.

Here is how abstract controls map to artifacts you can generate from systems you already run. This table is the Rosetta Stone between the GRC team and your terminal.

If you want the deeper mechanics behind these, see cloud IAM from first principles, security logging and monitoring, and key management and encryption (KMS).

SOC 2 Type I vs Type II & the Trust Services Criteria

SOC 2 is built on five Trust Services Criteria (TSC): Security (the only mandatory one, often called the Common Criteria), Availability, Processing Integrity, Confidentiality, and Privacy. You scope which apply, almost everyone starts with Security alone and adds Availability and Confidentiality as customers demand them.

The practical consequence: for Type II you cannot cram. If the period is six months, you need six months of access reviews, approvals, and logs. Wiring evidence collection in *before* the observation window opens is the single highest-leverage thing engineering can do.

How compliance shows up in your day job

You will rarely 'do compliance' as a separate task. It hides inside routines you already own:

• Access reviews, every quarter, confirm each person's permissions still match their role. Revoke what is stale. Export the result; that export *is* the evidence.
• Change management, every production change goes through a reviewed, approved PR. Branch protection and required reviewers turn this from a habit into provable evidence automatically.
• Encryption, data encrypted at rest and in transit, keys managed in a KMS with rotation. The config is the control; the config export is the evidence.
• Logging & monitoring, audit logs capturing who did what, retained long enough (often 1 year), with alerting on suspicious events.
• Vendor risk, before adopting a new SaaS that touches customer data, collect its SOC 2 report and sign a Data Processing Agreement. Their compliance becomes part of yours.

On the data-privacy side, GDPR adds duties that are squarely engineering problems. You need a lawful basis for processing personal data (consent, contract, legitimate interest, pick and record one per use). You must handle DSARs (Data Subject Access Requests): a person can ask what data you hold on them, and you have ~30 days to produce it, which means your data must be *findable* by subject. The right to erasure ('right to be forgotten') means you must be able to fully delete a person on request, including from backups and downstream systems. And data residency rules may require EU personal data to stay in EU regions, a deployment-topology decision, not a legal footnote.

Compliance as code: prove it automatically

Screenshot-driven audits do not scale and rot the moment someone changes a setting. Compliance as code turns controls into automated policy checks that run in CI and produce evidence on every change, the foundation of *continuous compliance*. This is the same engine behind cloud security posture management (CSPM).

Here is a policy-as-code check (OPA/Rego, runnable via Conftest) that fails any Terraform plan creating an S3 bucket without encryption at rest, a hard guardrail for the 'data encrypted at rest' control:

# policy/encryption.rego  (run: conftest test plan.json)
package main

# Deny any S3 bucket created without server-side encryption.
deny[msg] {
  resource := input.resource_changes[_]
  resource.type == "aws_s3_bucket"
  not has_encryption(resource.address)
  msg := sprintf("S3 bucket '%v' must enable encryption at rest (control SC-28)", [resource.address])
}

has_encryption(addr) {
  sse := input.resource_changes[_]
  sse.type == "aws_s3_bucket_server_side_encryption_configuration"
  startswith(sse.address, trim_suffix(addr, "_bucket"))
}

Wire it into CI so non-compliant infra never merges, the failed/passed check itself becomes timestamped evidence:

#!/usr/bin/env bash
# ci/check-compliance.sh, runs on every PR, output archived as evidence
set -euo pipefail

terraform plan -out=tfplan.bin
terraform show -json tfplan.bin > plan.json

# Fail the build if any control is violated
conftest test plan.json --policy policy/ \
  --output json | tee evidence/conftest-$(date +%F).json

echo "Encryption-at-rest control enforced for commit ${GITHUB_SHA}"

And the other half of continuous compliance, automate the recurring access review so the export is generated, not hand-assembled the night before the auditor calls:

#!/usr/bin/env bash
# scripts/access-review.sh, scheduled quarterly; output is the evidence artifact
set -euo pipefail
OUT="evidence/access-review-$(date +%Y-Q%q).json"

# Snapshot every IAM user and their attached policies
aws iam list-users --query 'Users[].UserName' --output text \
| tr '\t' '\n' | while read -r user; do
    policies=$(aws iam list-attached-user-policies \
      --user-name "$user" --query 'AttachedPolicies[].PolicyName' --output json)
    last=$(aws iam get-user --user-name "$user" \
      --query 'User.PasswordLastUsed' --output text)
    printf '{"user":"%s","policies":%s,"last_used":"%s"}\n' \
      "$user" "$policies" "$last"
  done | jq -s '.' > "$OUT"

echo "Access review written to $OUT, route to managers for sign-off."

Common mistakes that cost hours (or deals)

1. Treating the audit as a one-week sprint. Type II watches a *period*. If you start collecting evidence the week before, you have nothing for the prior five months. Instrument early.
2. Confusing compliance with security. A clean report is not a secure system. Keep doing real threat modeling, pen tests, and patching, the framework is a floor, not a ceiling.
3. Boiling the PCI ocean. Letting card data flow through your own servers drags your entire stack into PCI scope. Tokenize and use a hosted payment provider so card data never touches you, slash the scope.
4. Manual, screenshot-based evidence. It rots instantly and does not scale. Anything you screenshot twice should be a script or a policy-as-code check.
5. Scattering personal data everywhere. Makes DSARs and the right to erasure nearly impossible under GDPR. Centralize personal data behind a clear boundary.
6. Ignoring vendor risk. Your compliance is only as strong as the SaaS tools handling your data. Collect their reports and sign DPAs before you onboard them, not after the auditor asks.
7. Forgetting offboarding. Access that lingers after someone leaves is the single most common audit finding. Tie deprovisioning to the HR termination event.

Takeaways

Where to go next

Compliance sits on top of security primitives, strengthen those and the controls largely take care of themselves. Start with the building blocks each framework leans on:

• cloud IAM from first principles, least privilege is the most-audited control there is.
• security logging and monitoring, your audit trail is the evidence behind half your controls.
• key management and encryption (KMS), encryption at rest and in transit, provably configured.
• cloud security posture management (CSPM), the engine for continuous, automated compliance checks.

Pick one framework your business actually needs, usually SOC 2 Type II for B2B SaaS, and reverse-engineer its controls into automated checks. Make the evidence a byproduct of how you already build, and compliance stops being a tax and becomes a feature you can sell.