Compliance is not a slide deck for auditors. Done right, every control becomes an automated piece of the pipeline — and evidence is produced as a side effect of shipping software.
Four common frameworks — what they really are
| Framework | Goal | When it applies |
|---|---|---|
| ISO/IEC 27001:2022 | Information Security Management System (ISMS) — overall governance | Any organisation seeking an international cert in InfoSec governance |
| SOC 2 (AICPA) | Trust Service Criteria (Security, Availability, Confidentiality, Processing Integrity, Privacy) | B2B SaaS in the US; often required by enterprise customers in RFPs |
| PCI DSS v4.0 | Protecting cardholder data | Anyone storing/processing/transmitting payment cards |
| Vietnam Decree 13/2023/NĐ-CP | Personal data protection in Vietnam | Any organisation processing PII of Vietnamese citizens |
ISO 27001:2022 — what engineers should know
The 2022 edition has 93 Annex A controls grouped into four themes: Organizational, People, Physical, Technological. Most "Technological" controls map directly to the DevSecOps pipeline:
- A.8.8 Management of technical vulnerabilities → SCA + SBOM + Dependency-Track + fix SLA.
- A.8.25 Secure development life cycle → SDLC documentation, threat models, code review.
- A.8.28 Secure coding → SAST + linters + secure coding training.
- A.8.29 Security testing → DAST, periodic pentests, IR drills.
- A.8.32 Change management → branch protection, ticket-driven deploys, audit logs.
You don't need to memorise control numbers, but you should know which of your tools serves which control so when an auditor asks, you can point straight at the dashboard or log.
SOC 2 Type II
SOC 2 is not a "cert"; it is a CPA report. Type II matters more than Type I because it tests control effectiveness over a window (typically 6-12 months). Engineers must produce recurring evidence:
- Quarterly access reviews: who has what, for how long.
- Change tickets tied to PRs/deploys: every production change is traceable to a request.
- Real backup tests (not just running backups).
- Vulnerability management report against SLAs.
- IR drill report (tabletop, post-mortem).
Tip: use compliance automation (Vanta, Drata, Secureframe) to pull evidence from AWS/GCP, GitHub, Okta, MDM automatically — cutting manual collection effort by ~80%.
PCI DSS v4.0 — common engineer blind spots
- Scope minimization: tokenize and outsource to payment processors to shrink the Cardholder Data Environment (CDE), thereby reducing applicable controls.
- Customised approach in v4: design your own controls if you meet the objectives — fits cloud-native, but requires detailed documentation.
- MFA everywhere: required for all access to the CDE from 2025.
- Targeted Risk Analysis: many v4 controls require a risk analysis to set review/test frequency.
- Software security: Req 6 expands to require an inventory of bespoke + custom software (≈ SBOM for internal code).
Vietnam Decree 13/2023/NĐ-CP and the Personal Data Law
Engineer essentials:
- Classification: basic personal data and sensitive data (health, biometrics, political views, religion, finance, location, criminal history…). Different controls apply.
- Data Processing Impact Assessment (analogous to DPIA): mandatory for high-scale/high-sensitivity systems, must be filed.
- Consent must be explicit, revocable, not bundled with other terms.
- 72-hour breach notification from the moment you become aware, sent to A05 (Ministry of Public Security).
- Cross-border transfer: requires assessment dossier; certain data classes must be stored in Vietnam for the regulated period.
Mapping to engineering:
- Data classification tags in the database and data catalog.
- Pseudonymization/encryption on sensitive columns + key management via KMS.
- Audit logs for sensitive data access, retention per policy.
- 72h breach runbook: detect → triage → notify → record.
- DPIA template triggered by a feature toggle when new PII is introduced.
Compliance-as-code: evidence from the pipeline
Instead of collecting evidence manually at audit time, generate it as pipeline artifacts:
- Branch protection screenshots → exported via the GitHub API monthly into an evidence bucket.
- Each deploy carries a change ticket id and sign-off → query Loki/CloudTrail to auto-build the report.
- Access reviews automatically dump IAM, Okta groups, K8s RBAC → diff against HRIS to find orphan accounts.
- Backup verification jobs actually restore into ephemeral environments and compare checksums weekly.
- Vulnerability dashboards from Dependency-Track + DefectDojo are direct "exhibits".
Sample control mapping — one row of evidence
| Control | Tool | Evidence file | Cadence |
|---|---|---|---|
| ISO A.8.8 / SOC2 CC7.1 | Trivy + Dependency-Track | monthly-vuln-report.pdf | Monthly |
| ISO A.8.32 / SOC2 CC8.1 | GitHub branch protection | branch-protection.json | Quarterly |
| PCI Req 8 / SOC2 CC6.1 | Okta + IdP report | access-review-Q<n>.csv | Quarterly |
| Decree 13 Art.25 | Audit log query | pii-access-log-monthly.json | Monthly |
Conclusion
Compliance is an opportunity to invest in systems, not a once-a-year event. When you know which framework applies, map it to technical controls, and generate evidence automatically, audit season becomes mostly report exports. More importantly: the system actually becomes safer — which is the goal DevSecOps was set up to pursue.