Who is accountable when security only appears after code has already been written?

Accountability sits with the teams that own the software delivery process, because security outcomes are shaped at creation, not just at review. Regulators and customers increasingly expect evidence of control, not intent. If security starts after code exists, organisations inherit larger exposure windows, harder remediation, and weaker proof that risk was managed appropriately.

Why This Matters for Security Teams

When security is added only after code exists, accountability becomes blurred across engineering, security, product, and compliance functions. The practical problem is not just delayed remediation, but the loss of clear control ownership during design and build. That matters because software risk is shaped by decisions about dependencies, secrets handling, privilege boundaries, and deployment pipelines long before a release is approved. NIST’s control model in NIST SP 800-53 Rev 5 Security and Privacy Controls reinforces that security is a lifecycle responsibility, not a post-hoc review activity.

Security teams often assume a later scan or sign-off will compensate for weak upstream practices, but that usually fails when teams cannot prove who approved risky changes, who owns remediation, or which controls were actually enforced in the delivery chain. The real issue is governance: if the organisation cannot show security gates, traceability, and exception handling at the point of creation, it cannot demonstrate that risk was actively managed. In practice, many security teams encounter this only after a release has already widened the attack surface and created avoidable remediation debt, rather than through intentional secure delivery design.

How It Works in Practice

Accountability should follow the software delivery chain, with explicit ownership for code, build pipelines, third-party components, secrets, and release approvals. Security does not sit outside that chain. It is embedded through requirements, design review, code review, automated testing, artifact signing, and deployment controls. In mature environments, the question is not whether security participated, but whether the product and platform owners can prove controls existed before production exposure.

Operationally, this usually means:

• Assigning named owners for secure coding standards, dependency governance, and release exceptions.
• Using CI/CD checks to enforce policy before code is merged or deployed.
• Tracking secrets, tokens, and certificates as managed assets rather than informal configuration.
• Logging who accepted risk when a control was bypassed and for how long.
• Correlating application findings with CISA Secure by Design principles so ownership starts upstream, not at the incident stage.

This also intersects with identity governance. If code can create new service accounts, API keys, or agent permissions without review, then the software delivery process is effectively minting non-human identity authority. That is why current guidance increasingly treats secrets management, privilege assignment, and machine identity controls as part of delivery accountability rather than separate infrastructure tasks. For teams working in AI-enabled pipelines, the same logic applies to model artifacts, prompts, tool access, and release-time approvals.

Where this breaks down is in highly decentralised environments with unmanaged repositories, shadow CI/CD systems, and unclear ownership of platform services, because no single team can enforce consistent control points end to end.

Common Variations and Edge Cases

Tighter control often increases delivery friction, requiring organisations to balance speed against evidence of governance. That tradeoff is real, especially in fast-moving product teams, but it does not remove accountability. The right answer is usually not to move security later; it is to make approvals, testing, and exceptions lighter weight while still auditable.

There is no universal standard for exactly how much evidence every team must retain, but current guidance suggests the following distinctions matter. Regulated software, internet-facing services, and systems handling sensitive data need stronger traceability than low-risk internal tools. In some cases, a signed release record and policy-as-code checks may be enough. In others, especially where customer data, financial workflows, or privileged automation are involved, teams need stronger proof of design review, change approval, and monitoring.

Where agentic AI or automated build systems are involved, the accountability question becomes sharper. If an AI agent can modify code, select packages, or trigger deployment, then the organisation must define who controls that autonomy and who reviews its outputs. That is an emerging area, and best practice is evolving. For that reason, many teams are aligning delivery governance with NIST control expectations while also mapping software supply chain risk to NIST AI Risk Management Framework concepts where automation influences code creation or release decisions.

In practice, accountability gets contested most often when a breach exposes missing approvals, undocumented exceptions, or over-privileged pipeline access that no one thought would matter until an attacker exploited it.

Related resources from NHI Mgmt Group

• What breaks when security only happens after code is written?
• Why do secrets in source code remain a persistent security risk after removal?
• Who is accountable when suspicious activity is discovered after deposits have already been accepted?
• Who is accountable when stolen tokens are used after a device code phishing incident?