It started with DevOps. Then came NetOps. Now there is SecOps — or is it DevSecOps? Or SecDevOps? The proliferation of X-Ops labels reflects real organisational change, but it also risks replacing one problem with another: swapping old silos for new ones with shinier names.
The Terminology Trap
Shakespeare argued that a rose smells just as sweet regardless of what you call it. The same logic applies to operations teams. Renaming a team does nothing if the underlying behaviours and practices remain unchanged. When organisations fixate on what to call their security function — SecOps, DevSecOps, SecDevOps — they often lose sight of the actual goal: delivering applications faster, more frequently, and more securely through collaboration.
This is not a new phenomenon. When enterprise private cloud first emerged, critics dismissed it because it did not fit a precise definition of “cloud.” What those critics missed was that the measure of success is outcome — improved agility, efficiency, and speed — not adherence to someone else’s taxonomy. Teams that succeeded did so by changing how infrastructure was provisioned, configured, and managed, using technology to drive new behaviours and practices.
Modern Ops vs. Traditional Ops: A More Useful Distinction
Rather than debating which X-Ops label to use, a more practical framework is simpler: you are either practising modern ops or traditional ops, with many teams sitting somewhere in the transition between the two.
- Traditional ops organises work in functional silos — networking, infrastructure, security, development — where each team operates largely independently, with handoffs creating friction and slowing delivery.
- Modern ops uses cloud, automation, and pipeline-driven delivery to codify processes, reduce handoff friction, and speed deployment. Critically, modern ops teams are collaborative and communicative by design.
The distinction is behavioural, not cosmetic. A team that calls itself DevSecOps but still works in isolation from development and networking is just a traditional ops team with a modern name.
Why Security Cannot Be Siloed
One of the most damaging unintended consequences of creating a dedicated, labelled security team is that it implicitly gives every other team permission to abdicate security responsibilities. If security is in the team name — DevSecOps, SecOps — other teams can reasonably assume it is someone else’s problem.
That assumption is dangerous. Application security is not a single layer — it is a full stack concern:
- Network security controls what devices and services can communicate with which infrastructure and applications.
- Transport security protects data in motion across service boundaries.
- Application security addresses vulnerabilities within the application itself — dependencies, authentication, authorisation, input validation, and more.
- Operational environment security covers the container orchestration platforms, cloud configuration, IAM policies, and pipeline tooling that run the application.
The attack surface for a modern cloud-native application spans all seven layers of the networking stack and extends into the infrastructure and deployment pipeline surrounding it. No single specialised team can own that surface in isolation. Effective security requires network, infrastructure, storage, and development expertise working together — continuously, not just at release gates.
Labels Have Real Organisational Effects
In networking and container orchestration, labels are powerful tools. Labels tag traffic and enforce policy; in Kubernetes, labels isolate workloads, restrict communication, and define the blast radius of a compromise. Labels constrain and disallow.
Organisational labels work the same way. When a team is called “the security team,” that label draws a boundary — implicitly constraining who is responsible for security and disallowing others from feeling accountable. The label that was meant to signal expertise ends up building a wall.
What Modern Ops Actually Looks Like
Modern ops teams share several defining characteristics that go beyond tooling choices:
- Shared ownership of outcomes. Delivery speed, reliability, and security are collective responsibilities, not departmental KPIs.
- Pipeline-driven delivery. Processes — including security checks — are codified in CI/CD pipelines, making them repeatable, auditable, and fast.
- Continuous communication. Teams do not wait for scheduled handoffs. Cross-functional collaboration happens in the flow of work.
- Technology-enabled modernisation. Cloud, infrastructure-as-code, policy-as-code, and automation replace slow manual processes — not just for delivery, but for security validation and compliance too.
- Results over titles. Modern ops practitioners are defined by what they produce, not by the label on their team page.
The Path Forward: Stop Counting Silos, Start Breaking Them
Digital transformation in IT ultimately requires modernising the entire operational model — not just the technology, but the teams and the culture. That means moving security left into the development process, embedding network and infrastructure expertise into delivery pipelines, and treating every engineer as a stakeholder in secure, reliable delivery.
The goal is a collaborative, adaptive delivery and deployment pipeline that ships value to the business quickly and safely. Whether you call the people who build it DevSecOps, modern ops, or something else entirely matters far less than whether they actually work together.
Stop spending cycles debating what to call each other. Start spending them tearing down the walls that slow you down and leave your applications exposed.