This article is based on a commentary originally published on cloudcomputing-news.net (December 2019). The arguments remain relevant to any organisation navigating cloud security and operational transformation.
The Terminology Treadmill: DevOps, NetOps, SecOps, and Beyond
It started with DevOps. Then came NetOps. Then SecOps. Then DevSecOps. Then SecDevOps. The labels multiply faster than the cultural change they are supposed to represent. Too often, the end result is the same old organisational silos with shiny new job titles — and a workforce that spends more time debating what to call each other than actually changing the behaviours and practices that slow software delivery down.
Shakespeare observed that a rose would smell as sweet by any other name. Applied to modern IT operations, the corollary is blunt: renaming a team changes nothing if the team’s core behaviours and communication patterns stay the same.
The Real Lesson from the Early Cloud Era
When enterprise private cloud first emerged, pundits dismissed on-premises cloud deployments because they did not match a particular definitional purity of “cloud.” Those critics missed the point entirely. Organisations that built private clouds were not trying to win a definitions contest — they were pursuing agility, efficiency, and speed by changing how infrastructure was provisioned, configured, and managed. They changed behaviours and practices through technology, and that is what delivered value.
The same lesson applies to the current X-Ops naming wars around security. The outcome — faster, more secure software delivery — is the measure of success. Whether you achieve it through a team called SecOps or DevSecOps or simply a well-integrated engineering team is irrelevant if the underlying collaboration is not there.
Modern Ops vs. Traditional Ops: A More Useful Distinction
Rather than adding yet another X-Ops label, it is more productive to draw a single, meaningful line:
- Modern ops — teams that use cloud, automation, and codified pipelines to accelerate delivery and deployment, and that work collaboratively across disciplines to achieve it.
- Traditional ops — teams still operating in functional silos, relying on manual handoffs, and treating security, networking, and infrastructure as separate kingdoms with separate gatekeepers.
- Transitional ops — teams genuinely moving between the two, adopting modern tooling but still working through the cultural change required to make it stick.
Most organisations fall into the transitional category. Acknowledging that honestly is more useful than prematurely branding yourself “DevSecOps” while your security team still receives tickets at the end of a release cycle.
What Modern Ops Actually Looks Like in Practice
Modern ops teams share several practical characteristics that go well beyond terminology:
- Pipeline-first thinking: Processes are codified into delivery and deployment pipelines rather than enforced through manual review gates. Security checks, compliance scans, and infrastructure validation are automated steps inside the same pipeline that developers use every day.
- Shared ownership of outcomes: No single team “owns” security or reliability and then hands it off. Everyone in the pipeline — developers, network engineers, platform engineers, security specialists — is accountable for the quality of what ships.
- Free communication across disciplines: Modern ops teams communicate openly and frequently. The conversation between a developer and a network engineer does not require a formal change request as a prerequisite.
- Technology as an enabler, not a gate: Automation, observability, and policy-as-code tools are used to speed delivery, not to create new approval bureaucracies with digital wrappers.
Why Cloud Security Specifically Cannot Tolerate Silos
Application security in a cloud-native environment is a full-stack problem. The attack surface for a modern application spans all seven layers of the network stack, plus the container runtime, the orchestration platform, the CI/CD pipeline, and the identity and access management layer. No single team with a specialised label can cover all of that alone.
Effective cloud security requires:
- Network security — controlling which services can communicate with which infrastructure, enforcing encryption in transit, segmenting workloads.
- Transport security — TLS configuration, certificate management, mutual authentication between services.
- Application security — secure coding practices, dependency scanning, runtime application self-protection, API security.
- Infrastructure security — hardened base images, secrets management, least-privilege IAM policies, configuration drift detection.
- Operational security — logging, monitoring, alerting, and incident response integrated into the same toolchain the delivery team uses.
Creating a dedicated SecDevOps team and treating these responsibilities as their problem — because it is in their name — is one of the most common and dangerous failure modes in cloud security programmes. It gives every other team implicit permission to abdicate security responsibility. The result is predictable: security becomes a bottleneck at the end of the pipeline rather than a continuous property of the system.
Labels in Organisations Work Like Labels in Networks
In network engineering, labels are used to tag traffic and apply policies that control what can communicate with what. In container orchestration platforms, labels isolate and restrict workloads — they constrain and disallow. Labels are tools of separation.
Organisational labels work the same way. Giving a team a highly specific name creates an implicit boundary. Other teams use that label to justify not thinking about the concern that label represents. “That’s a SecOps question” becomes the reflex that kills shared accountability.
This does not mean specialisation is wrong — deep expertise in network security or application security is genuinely valuable. The problem is treating that expertise as a reason for separation rather than a reason for close collaboration. Specialists should be embedded in cross-functional teams or at minimum have direct, low-friction communication channels with every other part of the delivery pipeline.
Practical Steps Toward a Silo-Free Security Culture
If your organisation is in the transitional state between traditional and modern ops, the following practices move the needle on collaboration without requiring a corporate rebrand:
- Embed security requirements in the definition of done. No feature, no infrastructure change, and no configuration update is “done” until it meets documented security criteria. This makes security a shared delivery concern, not a post-release audit.
- Put security tooling in the developer’s workflow. Static analysis, dependency vulnerability scanning, container image scanning, and secrets detection should run automatically in the same CI pipeline developers already use. Friction is the enemy of adoption.
- Run cross-functional threat modelling sessions. Bring developers, network engineers, platform engineers, and security specialists into the same room (or video call) at the start of significant features. Shared understanding of risk does more for security posture than any gate at the end of the pipeline.
- Measure security outcomes, not security activity. Track mean time to remediate vulnerabilities, the percentage of deployments that include a security scan result, and the number of security-related production incidents. Avoid measuring team output (tickets closed, reviews completed) in isolation from delivery outcomes.
- Use policy as code. Encode security and compliance requirements as machine-readable policies (using tools such as Open Policy Agent, or cloud-native equivalents) so that enforcement is automated and consistent, not dependent on a single team reviewing every change manually.
The Bottom Line
Digital transformation in IT operations is ultimately about changing behaviours and practices — using technology as the accelerant. The naming conventions adopted along the way are secondary. Whether a team is called DevSecOps, SecOps, or simply “platform engineering” matters far less than whether that team is genuinely collaborating with every other discipline in the delivery pipeline, treating security as a shared property of the system rather than a gate at its end.
Stop spending cycles on what to call each other. Start spending them on building a delivery pipeline that is fast, frequent, and secure by default — with network, security, infrastructure, storage, and development expertise working together at every stage.
That is what modern ops looks like. Everything else is just a label.