The Hidden Problem of Managing Technology Change in Regulated Industries

Why Shipping Software Is About More Than Just Code

In most industries, deploying software is a seamless, automated process. Developers write code, push it through a CI/CD pipeline, and it’s live. However, for regulated industries, the process is far more complex.

Shipping software in finance, healthcare, and government isn’t just about engineering — it’s about proving compliance. The result? A tangled web of non-engineering tasks that often take longer than writing the code itself.

‍

What’s Really Required to Ship Software?

For organizations in regulated industries, shipping isn’t just about deploying features. It involves layers of governance designed to ensure the change is compliant, secure, and audit-ready.

The steps required to ship often take on different names, but they all serve the same purpose: 

• Change Approval Process
• Path to Production (Path to Prod)
• Production Readiness Review (PRR)
• Deployable Go-Live Criteria

These are all synonyms for the same thing — gathering evidence to prove compliance before deployment.

While the names differ, the goal is the same: to show that you’ve done what you’re supposed to do.

‍

Engineering vs. Administrative Tasks: The Bottleneck

If you break down the software lifecycle, from planning and coding through to release, you’ll find that engineering tasks are only part of the picture.

• Engineering Tasks (Blue): Automated, fast, and efficient (e.g., coding, testing, deployment).
• Administrative Tasks (White): Manual, slow, and resource-intensive (e.g., documentation, approvals, compliance checks).

In a typical month-long release cycle, the majority of tasks that delay shipping are non-engineering tasks.

“Automation accelerates development. But shipping is slowed by layers of manual, administrative work.”

The Hidden Process Behind Every Release

Let’s break it down:

1. Engineering Moves Fast: Thanks to modern DevOps tools, developers can code, test, and deploy changes quickly.
2. Governance Slows Everything Down: Before anything can go live, it must pass through a series of manual checkpoints — change approvals, audits, and risk assessments.
3. The Imbalance Becomes Clear: Developers wait on compliance teams to approve their work, leading to frustrating delays and bloated release cycles.

‍

The True Burden of Governance

Here’s what this looks like in practice:

• A Single Release Could Take Weeks — not because the code isn’t ready, but because administrative processes lag behind.
• Developers Spend More Time Waiting than coding, while compliance teams are overwhelmed by manual reviews.
• Leaders Face Pressure to speed up releases without compromising security or regulatory standards.

The result is a vicious cycle: Engineering accelerates, but governance drags behind, creating bottlenecks that slow innovation.

‍

How Did We Get Here?

The root of the problem lies in how regulations are interpreted and enforced. Most regulatory frameworks require organizations to manage the risks associated with technology change — but they rarely prescribe exactly how to do it.

This ambiguity leads to overly cautious processes:

• Company: “What does that mean?”
• Regulator: “Make sure you don’t allow vulnerabilities in prod.”

‍

• Company: “How do I do that?”
• Regulator: “That’s up to you.”

‍

• Company: “Should I do SAST, DAST, IAST, SCA, and container scans?”
• Regulator: “We don’t tell you how to do your job.”

‍

• Company: “How will I know if I’m successful?”
• Regulator: “Your auditor will tell you.”

Faced with such vague guidance, companies default to doing everything, resulting in governance processes that are both exhaustive and exhausting. The lack of clear criteria not only fosters inefficiency but also pushes organizations to focus on checking boxes for compliance rather than achieving meaningful security outcomes.

To avoid penalties, organizations err on the side of caution, layering on manual checks, approvals, and redundant processes.

“Compliance isn’t about doing the work — it’s about proving you did it. And proving it takes time.”

What Needs to Change?

The challenge isn’t the regulation itself — it’s the manual processes that exist to enforce it. To ship faster, organizations need to rethink the governance process:

1. Automate Compliance Tasks: Replace manual approvals and documentation with automated evidence collection.
2. Integrate Governance into CI/CD Pipelines: Build compliance checks directly into the development process, ensuring evidence is gathered as part of the workflow.
3. Shift Left on Risk Management: Identify risks early and embed controls throughout the development lifecycle, reducing the need for last-minute approvals.

‍

The Future of Governance in DevOps

Regulated industries don’t have to choose between speed and compliance. By modernizing governance workflows, organizations can:

• Reduce Release Cycles without sacrificing security.
• Eliminate Bottlenecks by automating evidence collection and approvals.
• Scale Compliance Efficiently as development accelerates.

The real challenge of managing technology change isn’t engineering — it’s governance. Until organizations address the imbalance between engineering and administrative tasks, they’ll continue to face long delays, high costs, and mounting frustration.

In the next part of this series, we’ll explore how regulatory frameworks contribute to this problem and what organizations can do to interpret and implement these requirements more effectively.