Agile in Regulated Environments – Is That Even Possible?

February 2026 11 min read Opinion + Case Study

The most common objection to Agile in regulated industries – banking, pharmaceuticals, energy, medical devices – is that it is fundamentally incompatible with regulatory requirements. Documentation must be complete before development begins. Processes must be validated and locked down. Change must be controlled and audited. How can you iterate and adapt in an environment where the regulator expects predictability and traceability?

The objection is understandable. It is also, in most cases, based on a misreading of what regulators actually require. And in some cases, it is an organisational defence mechanism dressed in regulatory language.

The Hook: What Regulators Actually Require

Let us start with the uncomfortable truth for both sides of this debate. For Agile purists: regulated environments have genuine constraints that are not arbitrary bureaucracy. Patient safety, financial system stability, and energy grid reliability are real concerns that justify regulatory oversight. Those constraints deserve respect, not dismissal.

For regulated-industry traditionalists: most regulators do not prescribe waterfall. They prescribe documentation, traceability, validation, and control – all of which can be achieved through well-implemented Agile practices. The assumption that Agile is incompatible with regulation is frequently wrong, and defending that assumption costs organisations significantly in delivery speed, quality, and adaptability.

The FDA’s guidance on software development, for example, explicitly acknowledges iterative and Agile approaches as valid methodologies for developing medical device software. The EMA’s guidance on Good Manufacturing Practice does not mandate waterfall project management. The FCA’s operational resilience requirements specify outcomes, not methodologies. The regulation is often more flexible than the organisations operating under it.

The Reality: Three Regulated Environments, Three Different Challenges

Banking and Financial Services

The regulatory environment in banking is genuinely complex. MiFID II, Basel III, GDPR, PSD2, local capital requirements – the regulatory stack is deep and the consequences of non-compliance are severe. Change management in this environment is tightly controlled: systems that process regulated transactions must have documented change records, impact assessments, and rollback plans. The speed of traditional change advisory boards is often measured in weeks.

Where Agile works well in banking: product development where regulatory requirements are one input among many, not the primary driver of every decision. Internal tooling, customer-facing digital products, data analytics platforms. Where it is more challenging: core banking systems with regulatory reporting obligations, trading systems with market integrity implications, payment processing infrastructure with operational resilience requirements.

The mistake banks make most consistently: applying the governance model appropriate for core systems to all systems, regardless of their regulatory exposure. A marketing analytics platform does not need the same change governance as a regulatory reporting system. Treating them identically slows the former without making the latter safer.

Pharmaceuticals and Life Sciences

This is the regulated environment where the Agile-incompatibility argument is strongest and where it is most frequently wrong. The pharmaceutical industry operates under GxP requirements – Good Manufacturing Practice, Good Clinical Practice, Good Laboratory Practice – that mandate extensive documentation, validated systems, and controlled processes. The regulatory logic is sound: when a software error in a clinical trial data management system could affect patient safety or data integrity, the bar for validation is appropriately high.

What the GxP regulations do not mandate is that this validation be done in a single, upfront, waterfall sequence. Computer System Validation (CSV) frameworks have evolved significantly. The GAMP 5 guidance – the industry standard for pharmaceutical software validation – explicitly accommodates iterative and Agile development approaches when implemented with appropriate controls.

The practical implication: validation does not have to happen at the end of the project. It can happen iteratively, sprint by sprint, with validation artefacts produced alongside development artefacts. This is harder to implement than the traditional end-of-project validation approach. It is also faster, produces higher quality validation, and catches validation issues while they are still cheap to address.

I worked with a development team at a major pharmaceutical company that implemented this approach for a clinical data management system. The initial implementation was painful – building the validation framework iteratively, establishing the sprint-level validation practices, training the QA team to validate alongside development rather than after it. After three sprints, the rhythm was established. The validation artefacts were produced as part of the definition of done. The system was validated faster than any comparable system in the organisation’s history, with fewer validation findings.

Energy and Utilities

Operational technology in energy and utilities – systems that control physical infrastructure – has some of the most stringent safety requirements of any industry. IEC 61511 (functional safety for process industry), IEC 62443 (industrial cybersecurity), and various national grid operator standards create a regulatory environment where software change is tightly controlled and the consequences of failure can be catastrophic.

The honest position here: for safety-critical operational technology, the constraints on iterative development are genuinely more severe than in other regulated environments. When a software error in a gas turbine control system can cause physical harm, the validation requirements are appropriately demanding and the tolerance for iterative “we’ll fix it in the next sprint” development is low.

Where Agile has more room to operate in energy: business applications, customer management systems, data analytics, grid planning tools, and enterprise IT that does not interact directly with operational technology. These systems are not safety-critical in the direct sense, and applying the governance standards of operational technology to them is both unnecessary and expensive.

The classification question: Before deciding how much regulatory governance a system needs, classify it honestly. What is its regulatory exposure? What are the consequences of a failure? What specific regulatory requirements apply? Many organisations apply maximum governance to all systems because it is easier than classifying correctly. That decision has a cost – measured in delivery speed, team motivation, and competitive disadvantage.

The Checksum: Agile Practices That Work in Regulated Environments

The following Agile practices, with appropriate adaptation, are compatible with regulated environment requirements – and in many cases, improve on the traditional alternatives.

Agile Practice	Regulatory Concern	Compatible Approach
Iterative development	Requirement traceability and documentation	Maintain traceability matrix updated each sprint; user stories link to regulatory requirements
Continuous delivery	Change control and audit trail	Automated deployment pipelines with full audit logging; sprint-level change records
Evolving requirements	Validated system against fixed specification	Iterative validation; re-validation of changed components only; impact assessment per sprint
Self-organising teams	Defined roles and responsibilities for regulatory accountability	Clear regulatory roles within team; Scrum roles complementary to, not replacing, regulatory roles
Minimal documentation	Mandatory documentation requirements	Documentation produced as part of Definition of Done; automated where possible; right-sized, not maximal

The Definition of Done as a Regulatory Instrument

The most powerful Agile tool in a regulated environment is the Definition of Done. In a traditional regulated development process, documentation, testing, and validation happen after development – creating a separation between the people who built the system and the people who validated it, and producing a late-stage review process that is expensive and slow.

In an Agile regulated environment, the Definition of Done includes the documentation and validation artefacts required by regulation. A story is not done until the relevant validation evidence has been produced, the regulatory documentation has been updated, and the traceability records have been maintained. This shifts validation from a post-development activity to a concurrent activity – slower per sprint, significantly faster overall, and higher quality.

The prerequisite is that the QA and regulatory affairs functions are part of the team rather than external review bodies. This is a structural change that many regulated-industry organisations resist. It is also the change that makes the approach work.

“Regulation requires documentation, traceability, and control. It does not require waterfall. The organisations that conflate the two are protecting their existing processes, not the public.” Markus – agile-checksum.com

Real-World Examples

The Pharmaceutical Validation Win

The clinical data management example I described earlier deserves more detail. The team was building a system that would be used in Phase III clinical trials – a GxP-regulated environment where validation failures have significant regulatory and patient safety implications.

Traditional validation for a system of this complexity would have taken six to nine months as a post-development activity. The iterative approach – validation evidence produced sprint by sprint, integrated into the Definition of Done – took twelve weeks of concurrent development and validation. The overall project timeline was thirty percent shorter. The validation finding rate was lower than comparable traditional projects. The regulator’s inspection of the validation package found no critical findings.

The team’s QA lead had been the most sceptical about the approach at the outset. At the project retrospective, she said: “I thought this would be a compliance disaster. It was the most thorough validation we’ve ever done, because we caught things in sprint three that we would have found in week thirty-two of a traditional project.”

The Bank That Classified Its Systems

A mid-sized European bank undertook a systematic classification of its application portfolio by regulatory exposure. The result surprised its own leadership team: only 23% of applications had genuine regulatory requirements that constrained their development approach. The remaining 77% had been subject to the same heavy governance as the regulated systems, not because they required it, but because a single governance model had been applied to the entire portfolio.

The bank differentiated its governance model. Regulated systems maintained the full change advisory process. Non-regulated systems adopted a lightweight Agile-compatible governance approach. The result: delivery speed for non-regulated applications improved by over 60% within twelve months. Risk exposure did not increase – the regulated systems were unchanged. The 77% of applications that did not need heavy governance stopped paying its cost.

The Honest Constraints

I want to be clear about what Agile cannot do in regulated environments, because the honest answer matters more than the optimistic one.

Agile cannot eliminate regulatory documentation requirements. Where documentation is required, it must be produced. The question is when and how, not whether.
Agile cannot accelerate regulatory review timelines. Once work is submitted to a regulator, their review process operates on their timeline. Delivering faster to the regulator does not make the regulator faster.
Agile cannot resolve genuine safety-criticality constraints. For systems where iterative deployment carries real safety risk, the constraints on iteration are real and should be respected.
Agile cannot compensate for regulatory affairs teams that are not embedded in development. The iterative validation model requires QA and regulatory affairs to work alongside development. If those functions remain external review bodies, the model does not work.

The Takeaway: Possible, With Precision

Agile in regulated environments is possible. It is not easy. It requires a more careful and deliberate implementation than Agile in unregulated environments. It requires regulatory affairs professionals who understand Agile, and Agile practitioners who understand regulation. It requires organisational willingness to classify systems by their actual regulatory exposure rather than applying maximum governance to everything.

The organisations that have done this well have found that Agile and regulation are not just compatible – they are complementary. The short cycle times and continuous integration of Agile catch quality and compliance issues earlier than traditional approaches. The cross-functional team model reduces the handoff failures that cause many regulatory findings. The transparency and traceability that good Agile practice produces often exceeds what traditional waterfall projects generate.

Run the checksum on your regulated environment:

Which of your regulatory constraints have you actually read in the source regulation – and which have you inherited as organisational assumption without checking the primary source?
What percentage of your application portfolio genuinely has the regulatory exposure that justifies your current governance model?
Is your QA and regulatory affairs function embedded in development teams, or does it operate as a post-development review function? What would it take to change that?

The answers may be more encouraging than you expect. Or they may confirm that your constraints are genuine. Either way, you will have replaced assumption with evidence – which is, after all, what Agile is supposed to be about.

Glossary Terms Used in This Article

Definition of Done – The shared agreement on what “complete” means for a product increment.
Agile Transformation – The process by which an organisation attempts to adopt Agile values and practices at scale.
Sprint – A fixed time-box of 1-4 weeks in which a Scrum team delivers a potentially releasable increment.
Scrum – A lightweight framework for developing and delivering complex products.
Technical Debt – The implied cost of rework caused by choosing quick solutions over better ones.

"Agile in Regulated Environments – Is That Even Possible?"