Why compliance keeps slowing your releases (and what to change first)

A team ships at a steady pace for most of the year. Then an audit approaches, and delivery slows. Engineers get pulled off feature work to support the audit, producing the configuration exports, logs, and environment checks that the evidence depends on. The slowdown lasts as long as the audit does.

It is tempting to read this as a team that needs to move faster or be bigger. It is usually neither. The delay comes from manual compliance work wrapped around each release, and adding people to that work only produces more of it.

The scale is easy to underestimate. First-year SOC 2 efforts commonly pull between 100 and 500 hours of engineering time onto compliance tasks and off the product roadmap, a cost that never appears as an invoice but is paid in features that ship later. The work itself is the problem, not the people doing it, and most of it exists only because compliance is proven by hand, one release at a time.

The bottleneck is not your team's speed

Key takeaway: Delivery slows near audits because engineers are diverted into manual evidence work, not because they are shipping code too slowly.

When release cycles slow around PCI DSS or SOC 2 obligations, the constraint is rarely how fast engineers write code. It is the work required to prove the code was shipped under control.

In practice, an audit window functions as a feature freeze. Your senior engineers stop shipping and start assembling evidence: exporting pull request histories to show that changes were reviewed, pulling access logs to prove who could reach production, screenshotting configuration to demonstrate a control was in place, and confirming that the staging environment an auditor is looking at actually matches what shipped. None of that work moves a feature forward. It is produced by the same people you count on to deliver the roadmap, and it comes due every audit cycle.

This is why the slowdown feels like a team problem when it is actually a process problem. The team is not underperforming. It is being pulled off delivery to do compliance work by hand.

Why audit preparation slows down releases

Key takeaway: The delay comes from manual, repeated evidence work and environment reconciliation, all of which are process costs rather than engineering failures.

For most organizations, this is not a once-a-year event. In A-LIGN's 2026 Compliance Benchmark Report, 97% of organizations reported conducting at least two audits or assessments a year, and the firm's earlier benchmark found that nearly two-thirds spend at least three months a year preparing for them. The delay comes from a handful of specific, repeatable tasks, and each is a process artifact rather than a sign of a weak team.

• Evidence gathering is manual and repeated. The auditor asks for a sample of changes from the period and proof that each was reviewed before it shipped. Someone reassembles that from pull request history, ticket exports, and screenshots, because no single system recorded it as it happened. Next cycle, the same reassembly starts over.
• Environments drift, so proving parity is hard. The auditor asks you to show that what you tested is what you shipped. If staging and production have quietly diverged, a library version here, a config flag there, answering that turns into a day of investigation before you can even respond.
• Controls are proven by hand. When you build on raw infrastructure, you are responsible for operating system hardening, patching, and network isolation, and you have to produce the evidence for all of it yourself.
• Change traceability is reconstructed after the fact. Who changed what, when, and why gets pieced together from memory and scattered tickets rather than read from a single, reliable history.
• Audit scope is larger than it needs to be. Without a clear line between what the platform is responsible for and what your application is responsible for, controls a platform could own under a shared-responsibility model, network segmentation, infrastructure hardening, physical security, stay inside your audit scope.

They are all consequences of compliance work living in the wrong place: attached to people and manual routines rather than to the platform the software runs on.

What to change first: move controls into the platform layer

Key takeaway: Moving controls into the platform lets you inherit verified infrastructure evidence and an automatic audit trail, so the infrastructure share of evidence becomes a byproduct of shipping rather than a separate project.

The first change is to move compliance controls and evidence out of manual routines and into the platform your software runs on. On a secure-by-default platform, the infrastructure-level controls are owned and evidenced by the platform, so you inherit that share of the audit rather than rebuilding it.

This works through a shared responsibility split. The platform secures the infrastructure and records every change. Your team secures its own application code and access. Using Upsun Cloud as the example of this model, the practical effects are:

• Infrastructure controls arrive already verified. Deploying on certified infrastructure means you start an audit with the infrastructure-level controls already verified and documented by the platform, so you inherit the evidence rather than reconstructing it. Upsun Cloud maintains PCI DSS v4.0.1 Level 1, SOC 2 Type 2, and ISO/IEC 27001:2022 certifications, and supports HIPAA-regulated workloads under a signed BAA. Current scope and conditions are listed in the Trust Center.
• Every change is logged automatically. Each deployment and configuration change is recorded as an activity, giving you a built-in audit trail instead of one assembled after the fact.
• Configuration is version-controlled code. Your environment is defined in the .upsun/config.yaml file and in any other YAML files at the top level of the .upsun directory. The Git history shows when each change was made and what the commit recorded, rather than requiring a walkthrough of a console.
• Preview environments are built from the same definition as their parent. Because each environment is created from the same definition, proving that what you tested matches what you shipped is no longer an investigation. Environments also inherit their parent data, so sanitize any database holding personal data before opening a preview environment more widely.

This is what let Qombo, an EU fintech selling verification APIs to banks, lead with credibility in banking conversations: inheriting Upsun Cloud's compliance posture and EU data residency shortened the due diligence and compliance reviews its banking customers ran on it, and a two-person team met bank-grade expectations without hiring for DevOps.

The practical result is consistent evidence across environments without manually reconciling separate consoles. It does not mean evidence appears at the press of a button, and it does not remove your responsibility for your own code. It means the infrastructure half of the work is inherited rather than rebuilt each cycle.

Two conditions are worth confirming early. Upsun Cloud's PCI certification currently excludes the FR-1 and FR-3 regions, so verify your region's status before starting a PCI-scoped workload. HIPAA workloads run only in the US-4 region and require a signed BAA.

What a compliance-ready release cycle looks like

Key takeaway: When evidence and environment parity are produced automatically, audit windows stop forcing a delivery freeze.

The change is easiest to see in the shape of a release near an audit.

Before, a release approaching an audit window triggers a scramble. Engineers stop feature work to assemble evidence, reconcile environments that have drifted, and reconstruct a record of what changed. Delivery stalls, and the stall lasts as long as the audit does.

Afterward, the infrastructure evidence already exists because the platform recorded each change as it happened. The environments already match because they are built from the same definition. The audit draws on what is already there for that share of the work, and the release cadence stops bending around the audit calendar.

The same pattern shows up in the pre-release checks a regulated team runs on every deploy. ROLLIN, an agency building for government and healthcare clients, replaced slow, manual, error-prone validation with an automated pipeline tied to version-controlled Upsun Cloud environments and moved to faster, safer, and more confident releases without adding delivery risk.

Where to start: move compliance into the platform

Compliance slowing your releases is a signal that compliance work is sitting in the wrong layer, not that your team is too slow. The first change is to move the infrastructure controls and their evidence into the platform, so that share of compliance is inherited and produced automatically rather than rebuilt by hand every cycle.

Audits are the most visible way compliance slows delivery, but not the only one. Regulated teams face a related version under obligations like the EU's DORA, where the constraint is architectural: you have to prove you could move off a provider without redesigning the system. The same fix applies, since portable, version-controlled configuration gives that exit strategy something concrete to point to. 

Our DORA exit strategy post covers it in depth.

Frequently asked questions (FAQ)

Does compliance have to slow down software releases?
No. Releases slow when compliance evidence is gathered manually and repeated every audit cycle. When infrastructure controls live in the platform and evidence is recorded automatically as changes happen, that share of audit preparation stops forcing a pause in delivery.

Why do audits slow down engineering teams?
Because audits pull engineers off feature work to produce evidence by hand: gathering screenshots, verifying configuration, and proving that staging matches production. The delay comes from manual evidence work, not from how fast the team writes code.

What is inherited compliance?
It is a model where a secure-by-default platform manages and evidences the infrastructure-level controls, so your team is responsible for its own application code, access control, and data handling. You start an audit with that share of the control set already verified and documented rather than reconstructed.

Can you meet PCI DSS or SOC 2 requirements without slowing delivery?
You can remove the infrastructure-evidence portion of the audit work by deploying on already-certified infrastructure and letting the platform produce the audit trail. This shrinks the manual evidence burden and narrows audit scope, though your application code, access controls, and data handling remain your responsibility.

How does DORA affect how financial services teams build?
Under Article 28(8), DORA requires financial entities to put in place documented exit strategies for ICT services that support critical or important functions, tested and reviewed periodically. That is hard to prove when deployments are tied to provider-specific services. Portable, version-controlled configuration gives teams a concrete exit blueprint, though a full exit strategy also needs migration planning.