Most enterprise software projects that get into trouble in regulated industries don't fail on the technical side. They fail on the readiness side: a control was assumed instead of documented, an access path was scoped without the auditor, a data flow crossed a boundary that nobody flagged. By the time it surfaces, you're six months into the build and a re-architecture is on the table.
Below is the 21-point checklist we run on every regulated-industry engagement before we write code. It's not exhaustive — every regime has its own corners — but if you can't check off these 21 items with confidence, you're not ready to start.
Data classification & lineage
- Every data element classified. PHI, PII, PCI, FERPA-protected, “ordinary”. Down to the field. Not at the table or service level.
- Lineage mapped end-to-end. Every system that touches each class of data — including logs, backups, and analytics pipelines.
- Cross-border data flows identified. If data crosses a jurisdiction boundary, name it. Document the legal basis.
- Retention policy defined per class. Including how deletion is verified and on what cadence.
- De-identification strategy. If non-prod environments touch real data, document the masking. If they don't, document the synthetic-data source.
Access & identity
- Identity provider chosen and integrated. SSO, MFA, lifecycle, deprovisioning — all working before code is written, not after.
- Role model documented. Roles, permissions, and the matrix of who-can-do-what. Reviewed by the compliance owner, not just engineering.
- Audit logging architected. Tamper-evident, queryable, retained per policy. Auditing isn't an afterthought; it's a primary system.
- Break-glass procedure defined. Emergency access, who authorizes it, what gets logged, how it's reviewed.
Compliance posture
- Target framework named. HIPAA, HITRUST, SOC 2 Type II, PCI-DSS, ISO 27001, FedRAMP. With a target audit date.
- Gap assessment completed. Against the named framework, before the build starts. Don't discover gaps in audit prep.
- Vendor / sub-processor inventory. Every third party touching regulated data, with contract status, BAA / DPA, and last review date.
- Incident response plan. Written, drilled, with named owners and notification timelines.
- Compliance owner identified. A single named person on the client side. Not “legal” or “the security team” — a name.
Operational readiness
- Environment separation enforced. Prod, staging, dev — different accounts, different credentials, no production data in non-prod by default.
- Deployment audit trail. Every change to production has an approver, a ticket, and a record. Not just for code — for config and infra.
- Backup & recovery tested. Not just configured. RTO and RPO documented and proven on a real recovery exercise.
- Disaster recovery scenario tested. At least once. With evidence.
The political layer
- Regulator-facing narrative aligned. If you're in a sector where the regulator may ask, you have a one-page summary your CIO is comfortable presenting.
- Internal audit briefed early. Not the day before the external audit. Six months before — so they help you instead of fight you.
- Sponsor knows what they signed up for. The executive sponsor understands that regulated builds cost 30–60% more in time and money than non-regulated equivalents — and budgeted accordingly.
How we use this
On every engagement in a regulated industry, we walk this list with the client during the inquiry-brief phase. Items we can't check off go into the risk register. Items that can't be checked off in the first 8 weeks of the build go to the executive sponsor as scope decisions: do we slow down, do we de-scope, do we accept the risk?
The 21-item list isn't the work. The work is the conversation it forces.
If you'd like the printable version of this checklist (with audit-evidence columns and a maturity score sheet), get in touch — we'll send the PDF.