Compliance Architecture: HIPAA, PCI-DSS, SOC 2, GDPR and the EU AI Act
Technical controls designed into the system, so the audit is a formality
Compliance is an architecture property
Retrofitting controls after launch costs many times more than designing them in, and it rarely passes the first audit. Row-level security, audit trails, encryption and access control are not paperwork. They are structural decisions about where data lives, who can reach it and how every access is recorded.
I make those decisions with your team, document them the way an auditor reads them, and leave a checklist the team can apply to every change afterwards.
The controls I design
- Row-level security. PostgreSQL policies that enforce tenant and role isolation in the database, not only in application code.
- Audit logging. Request-level trails that record who accessed what, when and why, retained and queryable for the auditor.
- Encryption and key management. At rest and in transit, with keys managed where the framework expects them.
- Access control. Role-based access with least privilege, short-lived credentials and separation of duties in the deployment pipeline.
- Data lifecycle. Retention, deletion, export and minimization implemented as system behaviour.
- Evidence. Logs, diagrams and control descriptions produced by the system itself, so the audit does not depend on someone's memory.
Frameworks
| Framework | What the engagement covers |
|---|---|
| HIPAA | Technical safeguards for PHI: access control, audit controls, integrity, transmission security. Healthcare platforms, clinical trials, EHR integrations, HL7 and FHIR interfaces. |
| PCI-DSS | Level 1 requirements for payment paths: cardholder data environment isolation, logging, encryption, segmentation. |
| SOC 2 | Type II control design and evidence for enterprise SaaS: change management, access, availability, confidentiality. |
| GDPR | Lawful basis, minimization, retention, subject rights and processor relationships reflected in the data model. |
| EU AI Act | Risk classification, technical documentation, logging, human oversight, robustness and data governance for AI systems in scope. Most obligations apply from 2 August 2026 as of this writing; the current timeline is confirmed at the start of every engagement. |
Two audits, first attempt
A payment processing platform needed PCI-DSS Level 1 while growing tenfold. The architecture isolated the cardholder data environment, set the audit logging and encryption rules per service, and documented the controls for the QSA. The audit passed on the first attempt. A clinical trial platform for US laboratories reached HIPAA and 21 CFR Part 11 readiness in six to eight months on the same principle: controls designed in, evidence generated by the system.
What you receive
- Gap analysis report. Current state mapped against the target framework, control by control.
- Control mapping matrix. Every required control mapped to a specific component, with status and remediation.
- Remediation roadmap. Ordered by risk, with effort estimates.
- Auditor-ready documentation. Technical safeguard descriptions, data flow diagrams and access control documentation formatted for the auditor or QSA.
- Architecture review checklist. The reusable list your team applies to future changes.
Questions
Are you an auditor?
We already have a product. Is it too late?
What does the EU AI Act change for a software team?
Do you cover GDPR as well?
What clients said
“Dan's deep knowledge of Go and PCI-DSS compliance saved us from a costly rewrite. He showed us how to architect our payment processing to handle 10x the volume while meeting Level 1 requirements. We passed our QSA audit on the first attempt, which almost never happens.”
“Our customer portal was sluggish: 3 second page loads, frustrated users. Dan designed a GraphQL layer that eliminated years of technical debt in 5 months. Page loads dropped to under 400ms. The technical approach was brilliant, but what really stood out was how he trained our team along the way.”