DevOps Implementation Challenges

What are the main DevOps implementation challenges?

The main DevOps implementation challenges in regulated health teams are change approval processes built for quarterly releases, separation of duties rules written for manual deployment, validation expectations for pipeline tools, legacy interfaces that cannot be tested automatically, and standing production access. Each one needs a design answer, not only a new tool.

These problems share a cause. The controls a regulated organization relies on were written around people doing steps by hand. When a pipeline does the steps, the control still has to exist, but it has to be expressed in code, configuration and records instead of signatures on a form.

Teams that treat the rollout as a control redesign, not a tooling project, usually get through review faster. The rest of this guide takes each challenge in turn.

Why does a change approval board stall pipelines?

A change approval board stalls pipelines because it reviews every change the same way, on a fixed weekly or monthly cycle. A pipeline that can release daily ends up waiting for a meeting, and teams respond by batching changes, which makes each release riskier.

The fix is to tier changes by risk and let the pipeline handle the low tiers with recorded, automatic approval. The board then spends its time on the changes that deserve a human discussion.

• Standard changes: Pre-approved patterns, such as a dependency patch or a copy fix, that pass all automated checks and deploy with a peer review only.
• Normal changes: Feature work that touches patient data, permissions or clinical logic, which needs a named approver in the pull request and a release note.
• High-risk changes: Database migrations on clinical tables, identity provider changes or interface cutovers, which go to the board with a rollback plan and a clinical operations sign-off.
• Emergency changes: Fixes for live incidents, released through the same pipeline with approval recorded after the fact and reviewed at the next board.

Write the tier rules down and have the board approve them once. After that, the board is approving the system that classifies changes, not each change, and the pipeline log shows which rule applied to every release.

How do you keep separation of duties without manual gates?

Separation of duties survives automation when the pipeline enforces it: the author of a change cannot approve it, and nobody can push to production except through the pipeline. The control moves from who presses the deploy button to who can merge.

In practice that means branch protection with required reviewers who are not the author, deployment credentials held only by the pipeline's service identity, and no human role with write access to production infrastructure outside a logged emergency path.

Small teams worry that two-person rules are impossible with three engineers. They are not, as long as the second person is any qualified reviewer rather than a specific manager. What matters is that the record shows two different people.

Auditors used to manual processes may ask where the signature is. Show them the merge record with reviewer, timestamp and linked ticket, the pipeline run that deployed it and the access policy that stops anyone else from deploying. That chain is stronger than a signed form, because it cannot be skipped.

Do pipeline tools need validation?

For medical device makers, software used in production or the quality system needs risk-based assurance, and that can include CI and deployment tools. FDA's final Computer Software Assurance guidance, issued in February 2026, describes a risk-based approach for that software and applies to automation tools used as part of production or the quality management system.

The practical question is intended use. A pipeline that only builds a marketing site is not part of the quality system. A pipeline that runs the verification tests recorded in a device design history, or that generates release records, probably is, and the team should document what could go wrong if the tool failed and how that risk is covered.

Electronic approvals raise a second question. For records FDA rules require, 21 CFR Part 11 sets the criteria under which electronic records and electronic signatures are treated as trustworthy equivalents of paper and handwritten signatures. If pull request approvals stand in for signed release approvals, check with the quality team whether they fall under Part 11 and what identity and audit trail controls that implies.

For health software that is not a device and not used by an FDA-regulated maker, neither applies. Teams still benefit from a short record of each tool's purpose, version and configuration, because hospital reviewers ask how build integrity is protected.

Legacy systems and interfaces that resist automation

Some parts of a healthcare estate cannot move at pipeline speed, and pretending otherwise causes outages. The usual blockers are interfaces owned by another organization and systems with no test environment.

• Partner interfaces: An HL7 v2 feed to a hospital or lab is tested on the partner's calendar, often with a single shared test environment. Deploy the integration code often, but put interface behavior changes behind flags that are switched on only after the partner tests them.
• EHR upgrade windows: EHR vendors and their customers schedule upgrades and freeze periods. Keep a release calendar that blocks interface-affecting changes during those windows.
• Databases without migrations: Older clinical databases changed by hand-written scripts need a baseline schema in source control before any automated migration runs against them.
• No staging copy: Systems that exist only in production need a synthetic replica or a contract test against their API before changes around them can be tested.
• Vendor appliances: Interface engines or devices configured through a console need their configuration exported and versioned, even if deployment stays manual for now.

Treat these as a list of known exceptions, each with an owner and a plan. A rollout that claims to cover everything usually hides one of them, and that is where the first serious incident happens.

What happens to production access?

Standing production access has to shrink, and the access that remains has to be logged. Under 45 CFR 164.312(b), the HIPAA Security Rule requires audit controls: mechanisms that record and examine activity in systems that contain or use ePHI.

Before DevOps, many teams gave senior engineers permanent database and server access so they could fix problems. Once releases go through a pipeline, that access becomes the largest gap in the control set, because it bypasses every review the pipeline enforces.

• Just-in-time access: Engineers request time-limited production roles through a ticket, with approval and automatic expiry.
• Session recording: Interactive sessions on production hosts or databases are recorded and kept with the ticket.
• Read paths first: Most debugging needs logs and metrics, not database writes, so give engineers good observability and remove write access.
• Break-glass account: One emergency path for outages, with an alert on every use and a review within days.
• Regular review: Compare who holds production roles against the current team on a fixed schedule, and remove leftovers.

This is often the most resisted change, because it removes a habit people rely on during incidents. Make the replacement paths fast before removing the old ones, or engineers will find workarounds.

A rollout order that survives an audit

Sequence matters more than speed. This order changes controls before it changes habits, so there is never a gap where the old control is gone and the new one is not yet proven.

• 1. Map current controls: List every approval, signature and access rule in the current release process, and the rule or contract each one answers.
• 2. Design the replacement: For each control, write how the pipeline will enforce it and what record it will leave.
• 3. Agree the change tiers: Get the change board to approve risk tiers and the evidence each tier produces.
• 4. Pilot on one service: Choose a service with real users but no partner interface, and run old and new approval paths side by side for a few releases.
• 5. Close production access: Move the pilot team to just-in-time access once their observability is good enough.
• 6. Bring in the exceptions: Add legacy and partner-facing systems one at a time, each with its own release calendar and flags.
• 7. Retire the old forms: Stop the manual process only after an internal review confirms the new records answer every question the old ones did.

Two signals tell you the rollout is working. Release batches get smaller, and the time the team spends preparing for an audit goes down because the records already exist. If either moves the wrong way, revisit the tier rules before adding more automation.

How Agnotic can help

Most stalled rollouts need a control redesign more than new tooling. Agnotic Technologies maps the client's current release controls, designs the pipeline equivalents, builds the CI and deployment setup with branch protection, risk-tiered approvals and just-in-time production access, and handles the legacy interfaces as planned exceptions.

For device makers, Agnotic can also document intended use and risk for each pipeline tool so the quality team has a starting point for its assurance records.

Sources

• FDA: Computer Software Assurance for Production and Quality Management System Software (final guidance, February 2026)
• 21 CFR Part 11: Electronic records and electronic signatures
• 45 CFR 164.312: HIPAA Security Rule technical safeguards, including (b) audit controls