Security and reliability review: 7 delivery model weak points to check first

Why your delivery model is a security and reliability question

Key takeaway: Security audits that focus only on application code often miss the delivery layer entirely. That is where the most common and most avoidable failures live.

Most teams treat security as a layer added on top of a working system. The problem is that the delivery model itself introduces risk before a single line of application code runs.

When deployments are manual, environments are inconsistent, or configuration drifts across stages, the system behaves unpredictably. That unpredictability makes incidents harder to detect and easier to compound.

The 7 weak points worth checking first

1. Inconsistent environments

When local, staging, and production are configured differently, you are not testing what you are shipping. Bugs that only appear in production are often environment bugs, not code bugs.

What to check: Can you spin up a new environment using the same data and configuration that runs in production?

2. Manual deployment steps

Any step that requires a human to run a command is a step that can be skipped, done out of order, or forgotten under pressure. The gap between teams that automate and teams that do not is measurable: according to DORA's 2024 research, elite performers recover from failed deployments 2,293 times faster than low performers and achieve an 8x lower change failure rate.

What to check: How many deployment steps are not in version control? If someone new needed to deploy today, what would they not find in the docs?

3. Unclear ownership

When no one is clearly responsible for an environment or configuration decision, things accumulate. Access persists after people leave. Debt gets deferred until it becomes an incident.

What to check: For each environment in your delivery pipeline, can you name the person accountable for its current state?

4. Weak rollback paths

Fast rollback is both a reliability mechanism and a security one. If reverting a bad deployment takes hours or requires reconstructing the state manually, your blast radius on any incident grows.

What to check: How long does a rollback actually take in your current setup? Has it been tested recently, or is it theoretical?

5. Configuration drift

Configuration drift occurs when environments that should match gradually diverge through ad hoc changes, often in a control panel that no one audits. It is one of the hardest failure modes to detect.

What to check: Is your infrastructure configuration versioned alongside application code?

6. Poor access control patterns

Broad permissions given for convenience rarely get walked back. Over time, more people have production access than need it. This matters beyond operational risk: the Verizon 2024 Data Breach Investigations Report found that stolen credentials appeared in 31% of all breaches over the past ten years, making excess access one of the most consistently exploited exposure points

What to check: Who has production access right now? Is that list reviewed regularly? Are permissions scoped to what each role requires?

7. Low deployment predictability

If developers are not confident that a deployment will go cleanly, they delay shipping. Larger changesets are harder to review and harder to roll back. Risk compounds.

What to check: What caused the last unplanned deployment freeze? Has the underlying cause been addressed?

See what a delivery model without these gaps looks like

What good looks like

Key takeaway: Good delivery hygiene reduces the number of decisions that require a human to get right every time.

A delivery model that handles these well shares a few characteristics:

• Configuration lives in version control, making infrastructure decisions reviewable and reversible.
• Environments are created from the same source, so staging behaves like production.
• Deployments are triggered by Git. The commit history is the deployment record.
• Access is scoped and auditable, with a clear owner per environment.

Upsun builds around these principles: configuration lives in YAML files committed to your repository, each branch can produce a full isolated environment, and access is managed at the environment level. 

Quick self-review questions

Key takeaway: If any of these takes more than a few minutes to answer, that is itself a finding.

Run through these before your next audit:

1. If a team member left today, could someone else deploy confidently using only what is in the repository?
2. When was the last time you tested a rollback end-to-end?
3. Can you produce a current list of everyone with production access and justify each entry?
4. Is staging in sync with production configuration right now?
5. How many deployment steps require direct action from a named individual?

How to spot which gaps to address first

Key takeaway: Gaps that fail silently are the ones that compound into serious incidents. Visibility is the first step.

Prioritize based on two factors:

• How often does this gap affect you? Weak rollback paths matter more if you deploy frequently. Configuration drift matters more in long-lived environments.
• How hard is it to detect when something goes wrong? Gaps that fail silently, like access sprawl or environment inconsistency, deserve higher priority than those that produce immediate errors.

Start with the gap that is both common and hard to detect.

Ready to review your delivery model with the Upsun team? Book a reliability review

Learn more

• https://upsun.com/blog/dora-exit-strategy-for-financial-services/
• https://upsun.com/blog/git-driven-environments-infrastructure-as-code/
• https://upsun.com/blog/developer-guide-to-building-apps-without-infrastructure-burden/
• https://upsun.com/blog/unified-cloud-management-platform/

Frequently asked questions (FAQ)

Is this relevant if we already have a security team running audits? 

Yes, and it's complementary rather than duplicative. Most security audits focus on application code, network configuration, and access policies. The delivery layer (environment consistency, deployment process, configuration management) is frequently out of scope for a standard audit and is where structural gaps accumulate between audit cycles.

How do we prioritize fixing these if we have limited platform engineering capacity? 

Start with the gaps that are both common and silent. Configuration drift and unclear ownership are the two that cause the most downstream cost because they're hard to detect until they compound. Both can be partially addressed by moving infrastructure definition into version control, which doesn't require a dedicated platform team, just a change to how configuration is managed.

What's the relationship between these weak points and compliance frameworks like SOC 2 or ISO 27001? 

Several of the seven map directly to controls in both frameworks: access control patterns, configuration management, and deployment change records are explicit requirements in most compliance frameworks. Closing these gaps in the delivery layer doesn't just reduce operational risk; it generates the audit evidence those frameworks require as a byproduct of normal operations rather than as a manual collection exercise.

How often should we run through this review? 

At minimum, before a major release, before an audit, and after any significant team change (new hires, departures, or restructuring). In practice, teams with healthy delivery hygiene build some of these checks into their regular sprint cycle so that gaps don't accumulate between reviews.