When should organisations continue a deployment after a custom step fails?

Organisations should continue only when the failed step is not a gate for safety, compliance, or access control, and when later steps or external controls can still detect and contain risk. If a failed step affects trust, policy enforcement, or change integrity, continuing can turn a recoverable issue into an undetected production problem.

Why This Matters for Security Teams

A failed custom step is not just a pipeline inconvenience. It can mean policy was not enforced, a secret was not rotated, a change was not validated, or an approval control never executed. For organisations running software delivery or agentic workflows, the key question is whether the failed step was informational or whether it was acting as a trust boundary. Current guidance suggests treating any step tied to access, compliance, or change integrity as a stop condition, because continuing can preserve a broken state while making the failure harder to detect later.

This is especially important in environments where secrets, API keys, and credentials move through automation. NHIMG research on the State of Secrets in AppSec shows how easily secrets management gaps persist even in mature programs, while the DeepSeek breach illustrates how a single exposure can cascade into broader data and credential risk. In practice, many security teams encounter the real impact of a failed step only after the deployment has already crossed into production.

How It Works in Practice

The practical decision is less about whether a step failed and more about what the step controlled. If the step was verifying a signature, enforcing a policy, generating an ephemeral secret, or confirming a rollback guard, then continuing usually bypasses the mechanism that keeps the deployment trustworthy. If the step was generating a report, collecting a non-blocking metric, or enriching observability, then continuing may be acceptable if other controls still provide coverage.

Security teams should classify custom steps into three buckets: gate, signal, or convenience. Gate steps must stop the deployment because they establish trust or prevent unsafe release. Signal steps should alert and trigger review, but may not need a hard stop if compensating controls exist. Convenience steps improve workflow quality but do not materially affect risk. That classification should be explicit in pipeline policy, not left to individual judgment.

For AI-driven or autonomous workflows, the bar is even higher. A failed step in an agentic pipeline can mean runtime authorisation, secret issuance, or tool-access validation never happened. Standards and guidance such as the NIST Cybersecurity Framework 2.0 and the NIST AI risk guidance reinforce the need to preserve control integrity rather than merely keep systems moving. Where organisations use runtime policy checks, the deployment should continue only if another enforced control can prove the same condition at execution time.

• Stop automatically when the step enforces policy, identity, access, or integrity.
• Continue only when a later control can detect the same failure and contain it.
• Record the failure as a release risk, not just an operational warning.
• Require an explicit owner to approve any exception, with a defined expiry.

These controls tend to break down when teams treat every failed step as non-blocking in high-change environments, because repeated exceptions quickly turn into a normalised release path.

Common Variations and Edge Cases

Tighter release gating often increases operational overhead, requiring organisations to balance deployment speed against the cost of false stops and manual review. That tradeoff becomes sharper in heavily automated platforms, where a failed custom step may be caused by transient infrastructure noise rather than true release risk.

Best practice is evolving, but a useful rule is to ask whether the step failure changes the system’s security posture or only its convenience. A failed notification step, for example, may justify continuation if monitoring and audit logging still function. A failed secret-rotation step does not, because the deployment may proceed with credentials that are already too broad or too old. Similarly, if a custom approval step is merely duplicated by a mandatory downstream control, continuation may be acceptable only when that downstream control is verified and enforced.

In regulated environments, the answer is usually stricter. If the step relates to evidence collection, approval traceability, or change integrity, continuing can create audit gaps even when the application still runs. The safest pattern is to define in advance which step types are hard stops, then validate those decisions against current control frameworks such as the NIST Cybersecurity Framework 2.0. Where organisations are unsure, they should treat the failure as blocking until a compensating control is documented and tested.

There is no universal standard for this yet, but the operational test is simple: if continuing would hide a broken control, stop; if continuing still leaves full detection and containment in place, proceed with documented exception handling.

Related resources from NHI Mgmt Group

• How should organisations choose between lightweight self-hosted password management and a fuller deployment model?
• How can organisations use application-level custom fields to improve ownership and filtering in SaaS governance?
• How do organisations use custom branding without weakening governance in an MCP platform?
• How should organisations choose between locking a vault and logging out after timeout in high-risk environments?