Who is accountable when security requirements are not translated into design decisions before implementation?

Why This Matters for Security Teams

When security requirements are not translated into design decisions before implementation, accountability becomes blurred across security, product, and engineering. That is exactly where failures appear: not because teams lacked intent, but because the control never became a concrete requirement, a traceable decision, or a build constraint. NIST’s control catalog makes the expectation clear in practice: design, authorization, and change management all need enforceable evidence, not verbal agreement alone.

This matters even more for Non-Human Identities, where secrets, service accounts, API keys, and agent credentials can be embedded early in pipelines and then reused for months. NHI Mgmt Group has documented how widespread exposure is in practice, including the Ultimate Guide to NHIs showing that 96% of organisations store secrets outside secrets managers in vulnerable locations. The governance lesson is simple: if design inputs do not reach engineering before build starts, the organisation cannot later prove that security was actually engineered in. In practice, many security teams encounter the missing control only after implementation has already hardened the risk.

How It Works in Practice

Accountability should be assigned to the function that owns the decision and the function that owns the implementation. Security leadership defines the requirement, risk threshold, and approval path; product and engineering translate that into architecture, backlog items, acceptance criteria, and testable controls. This is not a policy exercise alone. It is a traceability exercise that links a requirement to a design choice, then to an implementation check.

In a mature workflow, the security requirement is converted into specific design constraints such as authentication method, credential lifetime, logging expectations, segmentation boundaries, and secret handling rules. That design is reviewed before implementation, and the approval is retained as evidence. NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because it treats security as a set of operationalized controls, not a memo. For NHI-specific risk, the State of Non-Human Identity Security shows why this discipline matters: lack of credential rotation is cited as a top cause of NHI-related attacks by 45% of organisations.

• Security owns the standard, risk exception process, and sign-off criteria.
• Engineering owns the design changes, implementation details, and control evidence.
• Product owns prioritisation so security work is not deferred until after release.
• All three must agree on traceability from requirement to design to validation.

Controls should be written so they are testable before code is merged. For example, if a system uses service accounts or API keys, the design should specify where secrets are stored, how they are rotated, and what telemetry proves compliance. The Schneider Electric credentials breach is a reminder that credential exposure becomes much harder to manage once implementation choices are already in production. This guidance tends to break down in fast-moving delivery environments where architecture review happens after deployment because the design no longer constrains the build.

Common Variations and Edge Cases

Tighter pre-implementation review often increases delivery overhead, so organisations must balance speed against the cost of rework and exposure. The core tradeoff is not whether security should be involved, but how early the decision becomes binding.

There is no universal standard for exactly where accountability ends between security and engineering, but current guidance suggests a shared model: security defines what must be true, engineering proves how it will be true, and product ensures the work is scheduled. In regulated or high-risk environments, this often extends to formal architecture review boards and documented risk acceptance. In lower-risk services, lighter-weight review may be sufficient if the control remains traceable.

Edge cases appear when teams use platform engineering, outsourced development, or autonomous delivery pipelines. In those environments, implementation can happen faster than human review, so the accountable party must be the team that controls the pipeline gate and release authority. That is especially important for NHI-heavy systems because one missed design decision can propagate into hundreds of service accounts, tokens, or integrations. Best practice is evolving, but the underlying principle remains stable: if a requirement cannot be found in the design artefact, it is not yet accountable, and if it cannot be tested, it is not yet real.

Related resources from NHI Mgmt Group

• Who is accountable when AI-assisted design review misses a security issue before release?
• Who should be accountable when app access decisions affect security, compliance, and spend?
• How should security teams design authorization flows when a denial means the user may still be eligible after remediation?
• What do security teams get wrong about role design and access governance in ERP cloud projects?