How should security and development teams start building a DevSecOps culture that actually changes behaviour?

Turning DevSecOps Culture Into Daily Team Behaviour

DevSecOps culture only changes behaviour when security stops feeling like a review gate and starts feeling like part of how work moves. That shift depends on shared goals, clearer ownership, and visible feedback loops that developers and security staff both trust. A useful benchmark is whether teams make safer choices without waiting for a separate security function to force them, which is where control design and collaboration have to reinforce each other. The NIST SP 800-53 Rev 5 Security and Privacy Controls catalogue is useful here because it shows how governance, engineering, and monitoring controls can be distributed across delivery rather than concentrated at the end.

In practice, many organisations discover their culture problem only after repeated handoffs and late-stage findings have already trained teams to treat security as someone else’s job.

How Shared Delivery Practices Change the Way Teams Work

The mechanics of culture change are practical, not symbolic. Teams change behaviour when the path of least resistance becomes the secure path. That usually means wiring security requirements into the same tools and ceremonies developers already use, then measuring whether those signals actually influence decisions. If a finding is invisible until release day, the process still behaves like a checkpoint. If a control is embedded in planning, code review, testing, and deployment, it can shape choices earlier and with less rework.

Working agreements matter because they define what each team is responsible for, when escalation is required, and what “done” means for risky changes. Shared language matters because security and engineering often use the same words differently, which creates avoidable conflict. Shared metrics matter because teams follow what is measured, but only when the metric reflects something they can influence. For example, lead time, defect escape rate, policy exceptions, and time to remediate high-risk issues are more useful than vanity scores that reward activity without changing outcomes.

• Integrate security checks into build and deployment pipelines where they inform decisions early.
• Use agreed acceptance criteria so teams know when a change is actually ready.
• Automate routine enforcement so humans focus on exceptions and design trade-offs.
• Provide fast, specific feedback so developers can fix issues while context is still fresh.

Security education also has to be contextual. Generic awareness rarely changes engineering behaviour, but training tied to the team’s actual stack, release patterns, and recurring failure modes can improve judgment. Where controls are hard to use, teams tend to route around them, so adoption depends on whether the secure path is also the practical path. That is why culture work and engineering work cannot be separated. In practice, the cultural breakthrough usually appears when teams start discussing risk in the same planning cycle as delivery, not after deployment.

Where DevSecOps Culture Usually Stalls

Tighter security integration often increases short-term coordination overhead, so organisations must balance consistency against the friction that slows delivery if every safeguard is handled manually. The biggest stall point is when teams add security tooling without changing decision-making, which creates more alerts but no new behaviour. Another common problem is mismatched velocity, where security expectations are set too late for realistic remediation and developers learn to treat findings as negotiable noise.

There is also a genuine trade-off between standardisation and autonomy. Highly centralised security approval can reduce risk in a few critical areas, but it often weakens team ownership and delays learning. By contrast, fully decentralised responsibility can work only when teams have the maturity, guardrails, and telemetry to make sound choices. Guidance versus consensus is not settled everywhere on the exact balance, but the practical test is whether the operating model changes what people do during design, coding, and release, not just what they say in workshops.

Another edge case is highly regulated or platform-heavy environments, where the culture shift may need to begin with one shared platform control plane before it can spread across product teams. In those settings, the first win is often consistency, not creativity. The model breaks down when security teams optimise for more gates and developers optimise for faster exceptions, because that arrangement preserves old incentives under a new label.

Practitioner Guidance

What to prioritise: Establish one or two working agreements that change day-to-day behaviour, such as when security must be consulted and what evidence is required to pass a change, before expanding to broader culture programmes.

What to verify: Check whether the shared process actually reduces surprise work for developers and whether security findings are being resolved earlier in the lifecycle. If the same issues keep reappearing at release, the culture shift has not taken hold.

Common mistake: Treating tooling as culture. Tooling helps only when it changes who makes decisions, when those decisions happen, and what evidence is visible at each step.

Practitioner takeaway: The culture changes when teams can make the secure choice quickly, repeatedly, and with less friction than the unsafe alternative.

Related resources from NHI Mgmt Group

• Who is accountable for building a security culture that actually changes employee behaviour?
• How should security teams build an AI risk repository that actually changes behaviour?
• How should security teams implement employee risk scoring in a way that actually changes behaviour?
• How do security teams know if secretless development is actually working?