Prepare The Organization

Expanded Definition

Prepare the Organization is the SSDF practice area that turns secure development from an individual habit into an organisational capability. It defines the people, process, and governance conditions that must exist before secure coding, verification, and release practices can work reliably at scale.

In practice, this means establishing ownership, decision rights, training expectations, and repeatable workflows so that security is built into engineering rather than added as an afterthought. The boundary is important: this practice area does not prescribe every code-level control, but it creates the operational foundation those controls depend on.

Guidance varies across organisations, but the common thread is maturity in process design, role clarity, and enablement. A secure development programme fails quickly when responsibilities are informal or when teams rely on ad hoc review rather than defined checkpoints. For practitioners, the most common misunderstanding is treating “prepare” as administrative overhead instead of the mechanism that makes secure delivery consistent.

For broader programme structure, the NIST Cybersecurity Framework 2.0 provides a useful governance lens, while OWASP SAMM helps teams think about software assurance maturity as a measurable organisational practice.

Examples and Use Cases

• A product team assigns security ownership for each application component before the first release cycle begins.
• An engineering organisation defines secure code review, dependency approval, and exception handling workflows so teams do not invent their own process.
• Security and development leaders agree on training expectations for engineers, reviewers, and approvers so that control ownership is clear.
• Release engineering embeds required checks into CI/CD paths, making the secure path the default rather than relying on manual enforcement.
• Programme leads create shared standards for documentation, escalation, and sign-off so that secure delivery works across multiple teams.

These examples often trade speed for consistency at the start, but that tradeoff usually pays back by reducing rework, ambiguity, and late-stage security friction.

Security Implications

When an organisation has not properly prepared for secure development, the failure usually appears as inconsistency. Teams may follow different review standards, apply controls unevenly, or skip steps when delivery pressure rises. The result is not only weaker code, but also weaker accountability for security decisions.

That gap can create recurring defects, missed validation, unclear exception handling, and a false sense that security is “somebody else’s job.” Over time, the organisation accumulates avoidable exposure because secure practices depend on memory and heroics instead of repeatable process.

A useful practitioner observation is that process gaps often show up first in handoffs: if the team cannot explain who approves what, when a control is mandatory, and how exceptions are recorded, the secure-development system is already fragile.

NHIMG research on non-human identities shows how often organisations lack strong operational discipline elsewhere, with only 20% having formal processes for offboarding and revoking API keys. That kind of gap is a reminder that secure programmes fail when ownership and routine execution are unclear.

Security, Operational and Governance Implications

Prepare the Organization matters because it is the layer that makes all later development security work governable. If training, ownership, and workflows are weak, then secure coding, testing, and release controls become inconsistent and hard to audit.

The governance implication is straightforward: leaders need named responsibility, documented process, and a shared baseline for how secure work is done. Without that foundation, security exceptions multiply, metrics become noisy, and management cannot tell whether development teams are operating consistently.

Operationally, this practice area also shapes how quickly the organisation can absorb new requirements, such as policy updates, tooling changes, or additional review gates. Well-prepared teams can adapt without re-litigating every step, while poorly prepared teams turn each change into friction.

For practitioners, the key is to treat preparation as a control-enabling function. The more repeatable the process foundation, the less security depends on individual judgement and the more it becomes part of normal engineering execution.

Related resources from NHI Mgmt Group

• How should organisations prepare their NHI programmes for Agentic AI adoption?
• How can organisations prepare identity programmes for AI-enabled access?
• How should security teams prepare for ransomware when attackers move at AI speed?
• How should organisations prepare identity controls for DORA compliance?