Compliance for engineers

The frameworks and what they are for

Each framework serves a different audience and question. Knowing which one applies tells you what evidence matters.

Others appear by sector: HIPAA for US health data, FedRAMP for US government cloud, DORA and NIS2 in the EU for financial and critical services, CIS Controls and NIST CSF as general-purpose baselines. They overlap heavily. A control like "MFA for all administrative access" satisfies a requirement in every one of them, which is why a single well-maintained control set with a mapping to each framework is the sustainable approach.

From requirement to control to evidence

A framework requirement is abstract ("logical access is restricted to authorised users"). A control is what you actually do ("all production access goes through SSO with phishing-resistant MFA; access is reviewed quarterly; leavers are removed within one business day"). Evidence is what proves the control operated during the period (identity provider configuration export, the quarterly review records, the leaver tickets with timestamps). Auditors sample: they will ask for evidence for five random leavers in the period, not for a policy document.

CONTROL AC-03  Production access requires SSO + phishing-resistant MFA
  Owner:        platform lead
  Frequency:    continuous (enforced), reviewed quarterly
  Implemented:  IdP policy "prod-admins": require WebAuthn; cloud roles trust only the IdP
  Evidence:     - IdP policy export (automated, weekly, S3 evidence bucket)
                - cloud IAM trust policies (Terraform in repo, tagged release)
                - quarterly access review ticket with approvals
  Tests:        - scheduled check: no IAM user has console password or long-lived keys
  Maps to:      SOC 2 CC6.1, CC6.2 | ISO 27001 A.5.15, A.8.5 | PCI DSS 8.4 | NIST CSF PR.AA

The controls this track has covered already form most of a control set: threat modelling (risk assessment), cryptography and TLS (encryption), identity and MFA (access), hardening and patching (vulnerability management), secrets, supply chain (change management and integrity), logging and detection (monitoring), incident response, and network segmentation. Compliance work is largely writing them down in the auditor's vocabulary and proving they run.

Automate the evidence

The difference between a two-week audit and a two-month one is whether evidence is generated by systems or assembled by people from memory. Every control should have a script, a query or a pipeline that produces its evidence on a schedule into a write-once evidence store: configuration exports, scan reports, access lists, change records, backup test results, training completions. Compliance automation platforms do this against common SaaS and cloud APIs; a folder of dated exports produced by scheduled jobs works too.

STAMP=$(date -u +%Y-%m-%d)
OUT="evidence/access/$STAMP"; mkdir -p "$OUT"

# every IAM user, their MFA status and key age: the auditor's first question
aws iam generate-credential-report >/dev/null && sleep 5
aws iam get-credential-report --query Content --output text | base64 -d > "$OUT/credential-report.csv"

# who can assume the production admin role
aws iam get-role --role-name prod-admin --query 'Role.AssumeRolePolicyDocument' > "$OUT/prod-admin-trust.json"

# members of the admin group in the identity provider (example: Okta API)
curl -s -H "Authorization: SSWS $OKTA_TOKEN" \
  "https://acme.okta.com/api/v1/groups/$PROD_ADMINS_GROUP_ID/users" \
  | jq '[.[] | {id, login: .profile.login, status}]' > "$OUT/prod-admins-group.json"

sha256sum "$OUT"/* > "$OUT/SHA256SUMS"
aws s3 cp --recursive "$OUT" "s3://acme-audit-evidence/access/$STAMP/"

Tie changes to tickets and pull requests: an auditor sampling ten production changes wants to see the request, the review, the approval, the test result and the deploy record for each. If every deploy is a merged pull request with required review and a green pipeline, that evidence already exists in the repository; the DevOps track's practices are, from this angle, change management controls with automatic evidence.

GDPR for engineers

GDPR is different from the certifications: it is law, it applies to any personal data about EU residents wherever you are, and its principles translate directly into engineering decisions. Lawful basis and purpose: collect data for a stated reason and use it for that reason. Minimisation: do not collect or keep what you do not need; a field you never store is a field you never leak. Security: appropriate technical measures, which is this track. Retention: define how long each data class lives and delete it on schedule, including from backups and logs within a reasonable window. Rights: individuals can ask what you hold, get a copy, correct it, or have it erased, usually within a month; you need a way to find every copy of one person's data and act on it.

• Keep a record of processing: which systems hold personal data, what kind, why, for how long, who it is shared with. This is also your data inventory for incident response.
• Pseudonymise where you can: analytics on user ids that map to identities only in one protected system.
• Design deletion as a feature: a job that removes or anonymises a user across services, with a report of what it did.
• Log access to personal data at the application level; the logging module's data.export.requested event is exactly this.
• Check the transfer rules before sending data to another region or vendor, and have data processing agreements with processors.
• Report breaches within 72 hours; the incident module covers the clock.

-- retention policy: support tickets 24 months, then anonymise; run nightly
BEGIN;
UPDATE support_tickets
   SET requester_email = NULL,
       requester_name  = 'anonymised',
       body            = regexp_replace(body, '[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+', '[email removed]', 'g')
 WHERE created_at < now() - interval '24 months'
   AND requester_email IS NOT NULL;
INSERT INTO retention_runs (policy, rows_affected, ran_at) VALUES ('support_tickets_24m', 0, now());
COMMIT;

Working with auditors

An audit is a structured conversation with sampling. Agree the scope first (which systems, which period, which trust criteria); everything out of scope is out of the report, so be deliberate. Provide evidence that answers the question asked, no more: volunteering unrelated material creates new questions. When a control did not operate as described, say so and show the remediation; auditors expect findings, and a candid exception with a fix looks far better than a discovered inconsistency. Never fabricate or backdate evidence; that converts a finding into a much bigger problem.

Findings come in grades: an observation (improvement suggested), a deficiency (control not operating effectively) or, for SOC 2, an exception noted in the report. Most are fixable within the period if caught early, which is why an internal readiness assessment before the real audit is worth the time. After the audit, the report becomes a sales asset; before the next one, the automation you built means the evidence is already waiting.