In January 2025, the EU's Digital Operational Resilience Act (DORA) went live. Within six months, multiple financial institutions faced enforcement actions — not because they weren't trying to comply, but because their software architectures were fundamentally incompatible with the regulation's requirements. They had built first, then tried to bolt compliance on afterwards.
I've spent 12+ years building software for financial services, healthcare, insurance, and energy — all heavily regulated sectors. The single most expensive mistake I see organizations make is treating compliance as a feature to be added later, rather than a foundational constraint that shapes the architecture from day one.
This article is for CTOs, CIOs, and engineering leaders in regulated industries who are about to build (or rebuild) critical software. I want to show you why compliance-first is not just safer — it's actually faster and cheaper than the alternative.
The Regulatory Landscape in 2026: What You're Up Against
The volume and complexity of regulatory requirements has increased dramatically over the past three years. Here's the landscape that enterprises in regulated industries are navigating right now.
| Framework | Sector | Key Requirements | Penalties |
|---|---|---|---|
| DORA (EU) | Financial Services | ICT risk management, incident reporting, resilience testing, third-party risk | Up to 1% of avg daily global turnover |
| NIS2 (EU) | Critical Infrastructure | Risk management, incident reporting, supply chain security, board accountability | Up to €10M or 2% of global turnover |
| HIPAA (US) | Healthcare | Data privacy, security safeguards, breach notification, audit trails | Up to $1.5M per violation category/year |
| PCI DSS 4.0 | Payment Processing | Encryption, access controls, vulnerability management, continuous monitoring | Fines $5K-100K/month + loss of processing rights |
| PSD3 / PSR (EU) | Payments | Strong customer authentication, open banking APIs, fraud prevention | Varies by member state |
| AI Act (EU) | All (AI systems) | Risk classification, transparency, human oversight, data governance | Up to €35M or 7% of global turnover |
Michele's Take
What's changed isn't just the number of regulations — it's the enforcement posture. Regulators in 2026 are not issuing warnings. They're issuing fines. The DORA enforcement actions in H1 2025 sent a clear signal: if your systems aren't built for compliance, you will pay — literally.
Why "Compliance-Later" Fails: The 5 Patterns I Keep Seeing
After working on compliance remediation projects across dozens of organizations, I've identified five recurring patterns that explain why retrofit compliance almost always fails.
1. Audit Trails Can't Be Retrofitted
Every major regulatory framework requires comprehensive audit trails — who did what, when, and why. If your system wasn't built with immutable event logging from the start, adding it later means either rewriting your data layer or building a parallel logging system that's always slightly out of sync with reality.
I've seen teams spend 6-12 months trying to retrofit audit trails onto existing systems. The result is usually a fragile overlay that passes the first audit but creates ongoing maintenance headaches. The cost? Typically 3-5x more than building it in from the start.
2. Data Residency Is an Architectural Decision
GDPR, DORA, and sector-specific regulations often require that certain data stays within specific geographic boundaries. If your architecture wasn't designed for data partitioning and residency controls, you may need to re-architect your entire data layer — or worse, run parallel infrastructure in multiple regions with custom synchronization logic.
3. Access Control Requires Design-Time Thinking
Role-based access control (RBAC) or attribute-based access control (ABAC) that satisfies regulatory requirements needs to be woven into every API endpoint, every database query, and every UI component. Bolting it on after the fact means auditing every single code path — an exercise that's both expensive and error-prone.
4. Encryption at Rest and in Transit Is Not a Switch You Flip
Moving from unencrypted to encrypted data at rest requires migrating every database, every backup, every cache layer. It requires key management infrastructure. And it requires verifying that every component in your system can handle encrypted data without performance degradation. This is a project, not a configuration change.
5. Incident Response Needs Built-In Telemetry
DORA and NIS2 require organizations to detect, report, and respond to ICT incidents within strict timeframes (often 24-72 hours for initial reporting). This is only possible if your software is built with comprehensive observability — structured logging, distributed tracing, health checks, and automated alerting. Systems built without these capabilities can't even detect incidents reliably, let alone report them within regulatory timeframes.
Warning
The retrofit cost multiplier: In my experience, every compliance requirement that's retrofitted costs 3-8x more than the same requirement built in from the architecture phase. For a system handling €100M+ in transactions, a failed audit can cost more than the entire development budget. Compliance-first is not gold-plating — it's risk management.
The Compliance-First Architecture: 8 Pillars
Here's the architectural framework I use when building software for regulated industries. These eight pillars apply whether you're building a core banking platform, a claims management system, a healthcare data platform, or an energy trading application.
Pillar 1: Immutable Audit Log
Every state change in the system is recorded in an append-only, cryptographically signed event log. This isn't just a database table with timestamps — it's an event store that captures the full context: who performed the action, what authorization they had, what the system state was before and after, and why the action was triggered. Think event sourcing, not activity logs.
Pillar 2: Data Classification & Residency
Every data entity is tagged with a classification level (public, internal, confidential, restricted) and a residency requirement. The infrastructure enforces these constraints automatically — restricted data physically cannot leave the designated region. This is implemented at the database, API, and network layer, not at the application layer.
Pillar 3: Zero-Trust Access Control
Every request is authenticated, authorized, and logged — regardless of whether it comes from an external user, an internal service, or an automated process. No implicit trust based on network location. Fine-grained ABAC policies that can express rules like "doctors can view patient records only for patients assigned to their department, during business hours, from approved devices."
Pillar 4: Encryption Everywhere
TLS 1.3 for all communication. AES-256 encryption at rest for all persistent data. Dedicated key management (AWS KMS, Azure Key Vault, or HashiCorp Vault) with automated key rotation. Field-level encryption for the most sensitive data — so that even database administrators can't read credit card numbers or health records in plain text.
Pillar 5: Observability & Incident Detection
Structured JSON logging with correlation IDs across all services. Distributed tracing (OpenTelemetry). Real-time anomaly detection for security events. Automated alerting that can escalate to incident response teams within minutes. Dashboards that regulators can understand — not just DevOps dashboards.
Pillar 6: Automated Compliance Testing
Compliance requirements are encoded as automated tests that run in CI/CD. Every deployment verifies that access control policies are correctly enforced, that audit logs capture the required fields, that encryption is active, and that data residency constraints are respected. If a compliance test fails, the deployment is blocked. This transforms compliance from a periodic audit into a continuous guarantee.
Pillar 7: Third-Party Risk Management
DORA and NIS2 explicitly require organizations to manage the risk of their ICT suppliers. The architecture must include dependency inventory (SBOMs), automated vulnerability scanning of all third-party components, and the ability to quickly replace any third-party service without system-wide disruption. This is why I advocate for hexagonal architecture — your business logic should never be tightly coupled to any specific vendor.
Pillar 8: Disaster Recovery & Resilience Testing
DORA requires financial institutions to conduct regular resilience testing, including threat-led penetration testing (TLPT). The architecture must be designed for graceful degradation, automated failover, and rapid recovery. This means infrastructure as code, blue-green deployments, and regular chaos engineering exercises — not just a DR plan in a binder that no one has tested.
Framework-by-Framework: What Each Regulation Actually Demands
DORA — For Financial Services
DORA is the most comprehensive ICT regulation in financial services. It requires: an ICT risk management framework covering all digital systems, major incident classification and reporting within 4 hours of detection, annual digital operational resilience testing, and a register of all ICT third-party dependencies. For software teams, this means every system must be observable, auditable, and testable from day one.
HIPAA — For Healthcare
HIPAA's technical safeguards require: unique user identification, emergency access procedures, automatic logoff, encryption, and audit controls. The critical nuance most teams miss: HIPAA applies not just to healthcare providers, but to any "business associate" that handles Protected Health Information (PHI). If you're building software that touches patient data — even if you're a SaaS vendor — HIPAA applies to you.
PCI DSS 4.0 — For Payment Processing
PCI DSS 4.0 introduced a significant shift: the "customized approach" allows organizations to meet security objectives through alternative methods. But the trade-off is that you must demonstrate the effectiveness of your custom controls with evidence. For development teams, this means you need continuous compliance monitoring, not annual scans.
The Business Case: What Compliance-First Actually Costs (And Saves)
Let me be transparent about costs. Building compliance into the architecture from day one adds 15-25% to the initial development cost. That's real money. But here's what you save:
| Factor | Compliance-Later | Compliance-First |
|---|---|---|
| Initial development | 100% (baseline) | 115-125% |
| First audit preparation | +30-50% of dev cost | Minimal (automated) |
| Compliance remediation | +40-80% of dev cost | Near zero |
| Time to first audit pass | 6-12 months after launch | Day one |
| Ongoing compliance cost | 15-20% of annual budget | 5-8% of annual budget |
| Regulatory fine risk | High | Very low |
| Total 3-year cost | 2.5-3.5x initial dev cost | 1.3-1.5x initial dev cost |
The math is clear: compliance-first is cheaper over any time horizon longer than 12 months. And that's before you factor in the cost of regulatory fines, reputational damage, and lost deals from failing audits.
Michele's Take
I've had clients push back on compliance-first architecture because it "costs too much upfront." Then I show them the remediation costs from their last audit cycle. The conversation usually ends quickly. One client spent $2.4M on DORA remediation that would have cost $380K if built into the original architecture. That's not an outlier — that's the median case.
Implementation Checklist: Making Compliance-First Practical
Here's the practical checklist I use when starting a compliance-first project. This applies regardless of the specific regulatory framework.
- Map regulations to technical requirements — Before writing any code, create a matrix that maps every applicable regulation to specific technical controls. This becomes your compliance backlog.
- Choose your compliance architecture patterns — Event sourcing for audit trails. ABAC for access control. Envelope encryption for data protection. These aren't gold-plating — they're the minimum viable architecture for regulated software.
- Encode compliance as automated tests — Every compliance requirement should have at least one automated test. These tests run in CI/CD and block non-compliant deployments.
- Build observability from day one — Structured logging, distributed tracing, health checks. Don't wait until you need them for an incident report.
- Design for auditability — Every deployment should produce an audit package: what changed, who approved it, what tests passed, what the rollback plan is.
- Document continuously — Regulatory auditors don't read code. They read documentation. Generate compliance documentation from your code and tests, not as a separate artifact.
- Test your incident response — Run tabletop exercises quarterly. Simulate incidents and measure your detection-to-report time against regulatory SLAs.
The Bottom Line
The regulatory environment for enterprise software is not going to get simpler. The EU alone has introduced more regulatory frameworks in the last 3 years than in the previous 15. The US is following suit with sector-specific requirements. And AI regulation is adding an entirely new layer of compliance obligations.
In this environment, treating compliance as an afterthought is not just risky — it's economically irrational. The organizations that build compliance into their architecture from day one don't just avoid fines. They move faster because they don't have to pause for remediation. They win more deals because they can pass vendor assessments on the first try. And they sleep better because they know their systems are built to withstand scrutiny.
Compliance-first isn't a tax on innovation. It's the foundation that makes sustainable innovation possible in regulated industries.
“The cheapest audit is the one you pass without scrambling. Build compliance in, or pay to bolt it on — the math always favors building it in.”
— Michele Cimmino