<![CDATA[
TLDR: The dominant failure mode in regulated-industry digital transformation is structural: compliance enters the programme after architecture decisions lock in, generating irreversible technical debt that standard programme frameworks such as PRINCE2, SAFe, and PMI were built to overlook.
Digital transformation carries a promise: modernised systems, faster delivery, lower cost of regulatory compliance. For organisations outside regulated sectors, that promise proves achievable at scale. For pharmaceutical companies, financial services firms, and public healthcare bodies, the failure rate tells a different story, and the reason for that divergence sits inside the programme structure, independent of the ambition of the change.
The National Audit Office (NAO) traced twenty-five years of consistent underperformance in UK government digital programmes to a single root cause: decisions on technology being taken too early, before the business problem is properly understood. In regulated industries, the equivalent formulation is more precise: architecture decisions get taken before compliance requirements enter the design. The sequence matters more than any individual technology choice.
This article sets out the structural cause of that failure, the regulatory frameworks that now demand a different approach, and the operating model that organisations can implement from sprint zero to close the gap permanently.
Seventy Percent of Digital Transformations Miss Their Targets, and Regulated Industries Face a Steeper Curve
Seventy percent of digital transformations fail to meet their objectives, according to a Boston Consulting Group (BCG) survey of 825 executives published in 2020. The figure captures programmes across sectors. For regulated industries, the structural challenge compounds the general failure rate with an additional layer: programmes that succeed on a technical level still expose the organisation to regulatory rejection, enforcement action, and mandatory remediation that reverses cost savings already counted.
The scale of the exposure is quantifiable. The National Programme for IT (NPfIT) in the National Health Service (NHS), initiated in 2002 and abandoned in 2011, consumed £9.8 billion before its termination. Technology contracts were signed before clinical workflows, data governance obligations, and information governance requirements were mapped. In financial services, TSB Bank’s 2018 IT migration transferred 5.2 million customer accounts to a new platform, Proteo4UK. The platform failed on go-live day. The result: 225,000 customer complaints, £32.7 million in customer redress, eight months of disruption, and a £48,650,000 fine from the Financial Conduct Authority (FCA) and the Prudential Regulation Authority (PRA) in December 2022.
These are losses at the scale of entire transformation budgets. The question they raise is structural rather than operational: what in the programme model generates this outcome, and what model replaces it?
The Structural Defect: Compliance as a Review Gate, Architecture as a Given
Every large digital transformation programme in a regulated industry reaches the same crossroads in its first weeks: the moment when the technology architecture gets fixed and the vendor contracts get signed. In the dominant programme model, that moment happens before the compliance and regulatory team engages substantively with the design. Compliance enters as a review gate: the design is presented to the compliance function, the compliance function identifies gaps, and the programme returns to earlier stages to remediate.
The problem with this sequence is economic and architectural. By the time a compliance review gate runs, the fundamental technology choices, data model decisions, and integration contracts are locked. Remediation at that stage redesigns decisions already embedded in vendor deliverables. The result is technical debt by design: a programme paying twice for every compliance requirement that entered late.
The Senior Managers and Certification Regime (SMCR) makes this pattern a personal accountability matter. SMCR assigns named senior managers direct accountability for all significant activities, including digital change programmes and the compliance gaps those programmes generate. Technology delivery sits inside that accountability perimeter with full force. A programme that produces a compliance gap is, under SMCR, a governance failure attributed to a specific individual.
Standard programme management frameworks offer limited structural protection against this pattern. PRINCE2 treats compliance as a “consideration” inside stage plans, keeping it below the level of a first-class constraint on architecture selection. Scaled Agile Framework (SAFe) treats compliance as an additive overlay, with checkpoints built into the Definition of Done. The Project Management Institute (PMI) body of knowledge treats compliance similarly. A February 2026 peer-reviewed analysis of the Agile V framework, published on arXiv (arXiv:2602.20684), names this gap directly: “regulatory compliance remains external to the task cycle rather than intrinsic to it.”
Two Programme Post-Mortems That Tell the Same Story
The NPfIT and TSB cases share a structural signature that explains their outcomes.
In the NPfIT, technology contracts were awarded through a centralised procurement model before the clinical communities who would use the systems had specified their data governance or information governance requirements. The relevant architecture decisions (which systems, which data models, which integration contracts) were locked before the compliance environment was characterised. The NAO described it as one of the worst and most expensive contracting fiascos in the history of the public sector. Remediation exceeded the scope of contractual correction, and the programme terminated with £9.8 billion expended.
In the TSB case, the FCA’s Final Notice records that TSB failed to adequately organise and control the IT migration programme and failed to manage the operational risks arising from its IT outsourcing arrangements with its critical third-party supplier. Internal Audit raised concerns during delivery. Those concerns arrived after the architectural decisions on the migration approach were already locked. The FCA’s requirement under Policy Statement PS21/3 (Operational Resilience) is that firms map technology dependencies of important business services before go-live: the dependency map is an architectural requirement, and producing it post-facto converts a compliance obligation into a remediation exercise.
Both cases follow the same sequence: architecture first, compliance review second, remediation third. The sequence is the failure mode.
Regulatory Frameworks Are Already Mandating the Compliance-First Model
The regulatory environment across pharmaceutical and financial services sectors has moved to encode the compliance-first operating model in law.
In pharmaceutical manufacturing, the US Food and Drug Administration (FDA) regulation 21 CFR Part 11 requires electronic records and electronic signatures to carry validated audit trails, access controls, and record retention from system inception. When an audit trail module arrives after the data architecture is set, the underlying data model already records only the fields the original design considered. The original design brief omitted every field FDA 21 CFR Part 11 specifies, as the FDA’s own Part 11 scope and application guidance makes plain, so the retroactively installed module operates against a data schema built for a different purpose. Between 2016 and 2017, data integrity violations featured in 43 to 60 percent of FDA warning letters issued to pharmaceutical manufacturers, a pattern that regulators and industry bodies attribute directly to systems designed without the required audit trail architecture. The European Medicines Agency (EMA) Annex 11, governing computerised systems in pharmaceutical manufacturing, is under a complete revision with a July 2025 draft revision that adds cybersecurity, artificial intelligence and machine learning (AI/ML) lifecycle validation, and cloud and software-as-a-service (SaaS) requirements. Validation designed in from the start of the system lifecycle is the requirement; bolt-on validation of a deployed system is a scope violation.
In financial services, the FCA’s Policy Statement PS21/3 on Operational Resilience requires firms to map the technology dependencies of important business services before disruption. The full compliance deadline passed on 31 March 2025. That dependency map is an architectural artefact: it describes which technology components underlie which business services, at what tolerance for disruption. A firm that builds the map retrospectively conducts remediation on a completed design, treating an embedded architectural requirement as a post-go-live item.
The EU AI Act, Regulation (EU) 2024/1689, raises the stakes further for high-risk AI systems in healthcare, employment, credit, infrastructure, and law enforcement. Articles 8 through 15 require risk management throughout the lifecycle (Article 9), data governance built into the data architecture (Article 10), technical documentation from design (Article 11), automatic logging designed in from the start (Article 12), human oversight designed in (Article 14), and accuracy and cybersecurity designed in (Article 15). For high-risk AI system non-compliance under Articles 8 to 15, penalties reach €15 million or 3% of global annual turnover; for violations of the Act’s prohibited-use provisions, that ceiling rises to €35 million or 7%. The Act applies from 2 August 2026. Article 12 carries the most direct architectural implication: a data architecture with logging capabilities below the required granularity requires redesign, and that redesign costs orders of magnitude more on a deployed system than when the logging requirement was a first-class input to the initial data model.
The frameworks converge on a single architectural requirement: compliance requirements are design inputs, specified before architecture decisions are made.
Figure 1. Operating Model Comparison: Compliance-Afterthought vs Compliance-First in Regulated-Industry Digital Transformation
| Factor | Compliance-Afterthought | Compliance-First |
|---|---|---|
| Compliance entry point | Post-architecture review gate; compliance team reviews a finished design after technology decisions are locked. | Sprint 0 design constraint; regulatory requirements enter as NFRs before any architecture decisions are made. |
| Risk discovery timing | Late and costly; compliance gaps surface during testing or post-go-live, requiring redesign of locked decisions. | Early and cheap; gaps surface during requirements elaboration, before any architecture is committed. |
| Time-to-market impact | Remediation cycles add months or years; programmes stall awaiting architectural correction. | Regulatory clearance embedded in delivery velocity; compliance addressed incrementally, sprint by sprint. |
| Technical debt profile | High; retrofitted audit trails and access controls break data flows and create structural debt. | Low; audit trails and access controls are first-class data architecture elements, built once. |
| Programme failure mode | Regulatory rejection, enforcement fine, or cost overrun as remediation balloons beyond budget. | Iterative course correction within the sprint cadence, with compliance gaps resolved as standard items. |
| Stakeholder alignment | Compliance team as late-stage blocker, raising objections after design is committed. | Compliance team as co-designer from sprint 0, translating requirements into backlog items. |
The Operating Model That Closes the Gap
The pharmaceutical industry’s answer to this problem has been operating at scale since the publication of Good Automated Manufacturing Practice (GAMP) 5 by the International Society for Pharmaceutical Engineering (ISPE). GAMP 5 mandates a V-model of lifecycle validation in which compliance requirements traced from User Requirements Specifications flow through functional design, detailed design, and into validation testing. The V-model was created precisely because pharmaceutical companies that built first and validated later consistently generated FDA inspection failures. The structural solution inverted the sequence: regulatory requirements become the starting point of the design process, and the validation test plan derives from those requirements, replacing the old sequence of appending compliance to a completed system.
The compliance-first operating model generalises the GAMP 5 principle across pharmaceutical, financial services, and public sector programmes. Its structural elements are four.
First, regulatory requirements are translated into nonfunctional requirements (NFRs) before the architecture design sprint. FDA 21 CFR Part 11 audit trail requirements, EMA Annex 11 validation obligations, FCA PS21/3 resilience mapping requirements, and EU AI Act Article 12 logging requirements each become concrete, testable NFRs in the sprint backlog before a single architecture decision is made.
Second, NFRs carry the same sprint-level priority as functional requirements. The standard practice of placing compliance requirements in a separate workstream, governed by a separate compliance review gate, gives way to a single integrated backlog in which a logging requirement carries the same sprint-level obligation as a user story for a business feature.
Third, the compliance team operates as a co-designing partner from the opening sprint, distinct from the review function model. This is a staffing and governance change: a compliance architect moves out of the downstream approval committee and into the delivery team. The compliance function becomes a source of sprint backlog items, raising requirements at the point where the cost of addressing them is lowest.
Fourth, the architecture decision record (ADR) carries a compliance mapping section. Every significant architecture decision records the regulatory requirement it satisfies or the risk it accepts, with the acceptance formally governed. This creates a traceable chain from regulatory requirement to design to code to test, which is precisely the traceability that FDA inspectors, EMA auditors, and FCA supervisors examine during review.
Kainjoo’s work with regulated organisations across pharmaceutical, financial services, and public sector clients reflects this structural reading: the compliance-first operating model is an architectural choice, made once at programme inception, with compounding returns throughout delivery. The consistent pattern across Kainjoo’s regulated-sector programmes is that organisations which engage compliance as a co-designing partner from sprint zero deliver faster regulatory clearance, smaller remediation budgets, and audit-ready traceability from day one of the programme. The four-element framework outlined here (regulatory requirements as NFRs before architecture, equal sprint priority with functional requirements, compliance as co-designer from sprint zero, and ADR compliance mapping) is the structural model Kainjoo applies to close the gap between programme ambition and regulatory reality in regulated industries.
What the Evidence Shows About Speed and Cost
The claim that compliance-first slows delivery is the most consistent objection from programme sponsors. The evidence from the banking sector runs in the opposite direction.
A McKinsey study of a banking transformation examined the outcome of embedding technology-risk NFRs in Jira backlogs at sprint start, ahead of any review gate. The results: an 85% reduction in compliance overhead, a 90% increase in the speed of code deployment, and a 50% reduction in defects. These are delivery acceleration numbers, produced by a compliance-first approach. Compliance review gates are the brake; compliance as a sprint input is the accelerant.
ING Bank’s agile transformation provides a second data point. After embedding compliance as an architectural guardrail from the start of its transformation programme, ING reduced its product development cycle from 18 months to between 3 and 6 months. The compliance function transitioned from a review gate operating at the end of an 18-month development cycle to a co-designing partner operating at sprint cadence. The cycle time reduction followed directly from that structural change.
The economics of the comparison are straightforward: a compliance requirement addressed in sprint one costs a fraction of the same requirement addressed in the remediation phase of a deployed system. Every week a compliance gap persists in a deployed system accumulates remediation cost and regulatory risk. The compliance-first operating model eliminates that accumulation by converting regulatory requirements into sprint-zero inputs.
The regulatory environment that applies to digital transformation in 2026 is categorical on this point. FDA 21 CFR Part 11, EMA Annex 11 in its July 2025 draft revision, FCA PS21/3, and EU AI Act Articles 8 through 15 each treat compliance obligations as properties of the system architecture, specified before go-live. The compliance-first operating model is already the regulatory requirement. Programmes that treat it as optional innovation carry a structural deficit that the enforcement data (£48.65 million in banking fines, €15 million penalty ceilings for high-risk AI) converts into measurable financial exposure.
The operating model that resolves the failure rate is architecturally simple: compliance requirements enter as NFRs at sprint zero. Every compliance gate that currently operates at the end of the programme belongs at the beginning. The evidence from pharmaceutical manufacturing, from banking transformation, and from the regulatory frameworks themselves converges on the same structural conclusion. Programmes that make this architectural choice once, at inception, spend less on remediation, deliver faster against regulatory milestones, and face regulators with a traceable record built incrementally across delivery, meeting the audit standard from day one.
References
- BCG. “Increasing the Odds of Success in Digital Transformation.” 2020. https://www.bcg.com/publications/2020/increasing-odds-of-success-in-digital-transformation
- National Audit Office. “The Challenges in Implementing Digital Change.” NAO HC 575, July 2021. https://www.nao.org.uk/insights/the-challenges-in-implementing-digital-change/
- National Audit Office. “The National Programme for IT in the NHS.” NAO HC 888, May 2011. https://www.nao.org.uk/reports/the-national-programme-for-it-in-the-nhs-an-update-on-the-delivery-of-detailed-care-records-systems/
- FCA. “TSB Fined £48m for Operational Resilience Failings.” December 2022. https://www.fca.org.uk/news/press-releases/tsb-fined-48m-operational-resilience-failings
- FCA/PRA. “Final Notice: TSB Bank PLC.” December 2022. https://www.fca.org.uk/publication/final-notices/tsb-bank-plc-2022.pdf
- US FDA. “21 CFR Part 11.” eCFR. https://www.ecfr.gov/current/title-21/chapter-I/subchapter-A/part-11
- US FDA. “Part 11 Scope and Application Guidance.” https://www.fda.gov/regulatory-information/search-fda-guidance-documents/part-11-electronic-records-electronic-signatures-scope-and-application
- European Commission. “EudraLex Volume 4 Annex 11 Consultation.” July 2025. https://health.ec.europa.eu/consultations/stakeholders-consultation-eudralex-volume-4-good-manufacturing-practice-guidelines-chapter-4-annex_en
- EMA. “Annex 11: Computerised Systems.” 2011. https://health.ec.europa.eu/system/files/2016-11/annex11_01-2011_en_0.pdf
- FCA. “PS21/3: Building Operational Resilience.” March 2021. https://www.fca.org.uk/publications/policy-statements/ps21-3-building-operational-resilience
- European Parliament. “Regulation (EU) 2024/1689 (EU AI Act).” 2024. https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32024R1689
- FCA. “Senior Managers and Certification Regime.” https://www.fca.org.uk/firms/senior-managers-certification-regime
- ISPE. “GAMP 5.” Second Edition. https://ispe.org/publications/guidance-documents/gamp-5-guide
- McKinsey. “Lessons from Banking to Improve Risk and Compliance.” https://www.mckinsey.com/capabilities/tech-and-ai/our-insights/lessons-from-banking-to-improve-risk-and-compliance-and-speed-up-digital-transformations
- McKinsey. “ING’s Agile Transformation.” https://www.mckinsey.com/industries/financial-services/our-insights/ings-agile-transformation
- arXiv. “Agile V Framework.” arXiv:2602.20684, 2026. https://arxiv.org/html/2602.20684
- Ofni Systems. “FDA Warning Letter Archive.” https://www.ofnisystems.com/fda-warning-letters/
]]>
