A hands-on governance, risk and compliance (GRC) lab: three deliberately non-compliant environments to audit, each with an answer key mapped to real controls.
Reading about ISO 27001 or the DPDP Act doesn't teach you to audit a system. Auditable gives you systems to audit: a fintech startup, a legacy enterprise portal and a healthcare data broker, each a small Docker Compose stack with realistic configuration drift, leaky logs and shortcuts taken under deadline. You run one, collect evidence, rate the risks and write the findings up, then compare your work with the scenario's audit guide.
Every documented finding was reproduced end-to-end while building the lab (see How this was verified), so the answer key describes what the running system actually does.
| Scenario | Story | Stack | Frameworks | Findings |
|---|---|---|---|---|
| 01 Fintech startup | An employee portal that handles Aadhaar numbers | FastAPI, PostgreSQL, nginx | DPDP Act 2023, ISO 27001 | 7 |
| 02 Legacy enterprise | A banking ledger portal nobody wants to touch | Node.js, MySQL, nginx with TLS | SEBI CSCRF, PCI DSS, ISO 27001 | 7 |
| 03 Healthcare data broker | A telemetry broker feeding an ELK pipeline | FastAPI, Logstash, Elasticsearch | HIPAA, CERT-In, ISO 27001 | 5 |
Each scenario has a traffic simulator, so logs, indexes and dashboards fill with realistic (entirely fictional) records while you audit.
-
Pick a scenario and start it:
cd scenarios/01-fintech-startup docker compose up -d --buildEvery port is bound to
127.0.0.1, so the stack is only reachable from your own machine. The dashboard and API URLs are in the scenario's guide. -
Audit it without reading the guide. Review the code and the compose file, click through the dashboard, read the logs, query the datastores.
-
Record each finding in a copy of
templates/findings-register.csv: condition, control, evidence, likelihood, impact, recommendation. -
Write it up with
templates/audit-report.md, the standard condition / criteria / cause / effect structure. -
Compare with the Findings index at the top of the scenario's
audit_guide.md: every intentional flaw, its controls, and how to verify and fix it. -
Tear down:
docker compose down -v.
Auditable was built as a pair with TraceState, a policy-as-code scanner. After your manual audit, run it against the same files:
tracestate scan scenarios --onlineTraceState v2's rules are generic (none mention this lab), yet it reports 18 of the 19 findings in the three guides, plus 23 other real problems (49 findings in all), in about 25 ms. The one it misses is Scenario 03's disconnected breach-report webhook: every file is plausible on its own, and only an auditor asking "would anyone notice?" finds it. It also can't tell you that the Docker socket is exploitable, only that it's mounted. That gap is what the manual audit is for. The detailed comparison is in TraceState's benchmark.
This repository's CI runs the TraceState action on every push, and the findings appear in the Security tab and the job summary.
Control references use ISO/IEC 27001:2022 Annex A numbering (the 2013 edition's A.9 access control and A.10 cryptography became A.5.15 to A.5.18, A.8.2 to A.8.5, and A.8.24).
| Framework | Controls exercised | Scenarios |
|---|---|---|
| DPDP Act 2023 (India) | s.8(5) reasonable security safeguards for personal data | 01 |
| ISO/IEC 27001:2022 | A.5.17 authentication information, A.8.2 privileged access, A.8.5 secure authentication, A.8.8 technical vulnerabilities, A.8.11 data masking, A.8.15 logging, A.8.24 cryptography | all |
| PCI DSS v4.0 | 3.4.1 PAN masked when displayed, 3.5.1 stored PAN unreadable, 4.2.1 strong cryptography in transit | 02 |
| SEBI CSCRF (2024) | cryptographic hygiene, vulnerability management | 02 |
| HIPAA Security Rule | 164.308(a)(6) incident procedures, 164.312(a)(1) access control, 164.312(e)(1) transmission security | 03 |
| CERT-In Directions (2022) | incident reporting within 6 hours | 03 |
| CIS Docker Benchmark | non-root containers, no Docker socket, no secrets in environment | all |
| OWASP Top 10 (2021) | A07 identification and authentication failures (client-side secrets) | all |
- Each scenario was started with
docker compose up -d --buildand driven through its full flow (load data, trigger the flaw, inspect the resulting log or index), not just read. - The Docker socket finding in Scenario 03 was demonstrated from inside the broker container: the Docker Engine API answered with the host's full container list.
npm auditandpip-auditwere run on every pinned dependency. Advisories unrelated to the lesson were fixed (FastAPI, Uvicorn and Starlette in 01 and 03; Express's transitive dependencies in 02;requestsin 03 after four advisories were published in 2026). The one vulnerable dependency left,mysql2@3.11.2in Scenario 02, is a documented finding.- Scenario 02's TLS finding was tested with a real handshake: the nginx configuration declares TLS 1.0 and 1.1, but this image's OpenSSL refuses them. The guide explains why the declared policy is still the finding.
- Two claims in earlier versions of the guides turned out to be wrong (a
winstonversion that wasn't pinned, and a "weak cipher" that negotiates AES-256-GCM with forward secrecy) and were corrected.
These environments are insecure on purpose. Run them only on your own
machine. Keep the ports bound to 127.0.0.1 (CI enforces this), never deploy
them to a server, and tear them down when you're done. All names, Aadhaar
numbers, card numbers and medical records in the seed data are fictional.
New scenarios, better evidence steps and corrections are welcome. See CONTRIBUTING.md. Security reports about the lab's tooling (not its intentional flaws) go through SECURITY.md. MIT licensed.