DevOps and SecOps Began as Separate Efforts — And Why Convergence Now Matters

This article is based on analysis originally published by CSO Online. The observations about organizational silos, DevSecOps convergence, and GDPR-driven change reflect the state of the industry as of late 2017 but remain largely relevant today.

The Silo Problem: Fraud, Security, and Ops Operating in Isolation

In most enterprises, anti-fraud, security, and authentication teams have historically operated as separate domains. IT Operations sits even further away from these functions. The reasons are familiar to anyone who has worked inside a large organization:

• Silo mentality: individual teams optimise for their own discipline rather than shared outcomes.
• Political momentum: entrenched reporting structures make reorganisation difficult.
• Decentralised vendors: different third-party providers serve each function, deepening the divide.
• Low urgency (historically): the cost of poor coordination was invisible until a breach or a compliance deadline made it painfully visible.

In a typical siloed enterprise, the CISO and IT security team own threat detection and controls. Risk and compliance executives own anti-fraud and data protection. A separate Ops team — often reporting to the CIO or even the CFO — owns infrastructure and service delivery. These groups rarely collaborate unless a crisis forces them to.

Why Siloed Collaboration Breaks Down

The problem isn’t animosity between teams. Most security, fraud, and ops professionals share the same ultimate goal: protect the business and serve customers safely. The friction comes from structural misalignment:

• Inconsistent communication cadences — teams only synchronise reactively, not proactively.
• Conflicting incentives — security teams are measured on risk reduction; ops teams on uptime and velocity; fraud teams on loss rates. These metrics can pull in opposite directions.
• Duplicated tooling — each silo procures its own monitoring, alerting, and analytics stack, creating blind spots at the boundaries.
• Crisis-only coordination — collaboration that only happens during incidents is too slow, too expensive, and too late.

How DevOps and SecOps Show the Way

DevOps and SecOps started as entirely separate movements. DevOps grew from the frustration of developers and operations engineers working against each other; SecOps emerged from the recognition that bolting security onto finished software was both expensive and ineffective. Over time, practitioners in both camps discovered that their goals were complementary and that shared tooling, shared metrics, and shared culture produced better outcomes than parallel silos.

The result was DevSecOps: a model in which security practices are embedded into every stage of the software delivery pipeline rather than applied as a final gate. Threat modelling happens at design time. Static analysis and dependency scanning run in CI. Security engineers sit in sprint planning. Incident response feeds back into development priorities.

The same logic applies to the broader convergence of fraud prevention, authentication, and security operations. These disciplines share data, share adversaries, and share customers. Treating them as independent functions means each team sees only part of the picture — and attackers exploit the gaps between teams.

A Converged Model: Fraud, Authentication, and Security Together

The practical case for convergence rests on several pillars:

1. Shared Signals, Better Decisions

Fraud signals (unusual transaction patterns, device fingerprint anomalies) and security signals (credential stuffing attempts, anomalous API calls) often describe the same attack from different angles. A unified data pipeline lets analysts correlate these signals in real time rather than comparing reports after the fact.

2. Consistent Authentication Across Channels

When authentication is owned by multiple teams, the customer experience becomes inconsistent: a user might face different friction levels on mobile versus web versus call-centre interactions. An omnichannel authentication model — where a single policy engine governs risk-based authentication regardless of channel — requires fraud, identity, and security teams to define policy together and share the same risk signals.

3. Regulatory Pressure

Regulations such as the EU’s General Data Protection Regulation (GDPR) and similar data protection frameworks in other jurisdictions require organisations to demonstrate a holistic understanding of where personal data lives, how it is protected, and who can access it. Fragmented teams with fragmented tooling struggle to produce the unified data inventory and control evidence that regulators expect. A converged team, sharing a common asset register and control framework, is structurally better positioned for compliance.

The Real Obstacles to Convergence

Acknowledging that convergence is desirable is the easy part. Executing it is harder. The main barriers are not technical:

• Reporting structure: whose budget funds the converged team? Who does the unified function report to — the CISO, the CRO, the CIO?
• Cultural inertia: professionals who have built careers in a specialist discipline may resist joining a broader team with blurred boundaries.
• Process complexity: convergence can easily become a waterfall-style reorganisation project that takes two years to deliver and arrives too late. An agile, incremental approach — shared tooling first, shared metrics next, shared team structures last — is more likely to succeed.
• Vendor fragmentation: existing contracts and integrations with specialist vendors in each domain create switching costs and integration work.

Applying Agile Principles to Organisational Convergence

The DevOps movement succeeded, in part, because it did not begin with a grand reorganisation. It began with small, cross-functional teams experimenting with shared tooling and shared metrics — and proving value in short cycles. The same approach applies here:

1. Start with a shared data layer. Integrate fraud signals, authentication events, and security telemetry into a common SIEM or data lake so all teams can query the same source of truth.
2. Define shared KPIs. Agree on metrics that span team boundaries — for example, time-to-detect an account takeover, or false-positive rate on authentication challenges.
3. Run joint incident reviews. When a fraud event or security incident occurs, include all relevant disciplines in the post-mortem. This builds mutual understanding faster than any formal reorganisation.
4. Evolve structure to follow culture. Once teams trust each other and share goals, structural changes (shared reporting lines, unified budgets) are much less disruptive.

The Bottom Line

DevOps demonstrated that development and operations teams produce better software faster when they share goals, tooling, and culture rather than throwing work over a wall. SecOps demonstrated that security is more effective when it is embedded in delivery pipelines rather than applied at the end. The same logic now applies to the broader convergence of fraud prevention, authentication, security operations, and IT ops.

The threat environment is escalating. Regulatory expectations are rising. Customer tolerance for friction caused by inconsistent authentication is falling. Organisations that break down the silos between these disciplines — incrementally, with an agile mindset, and without waiting for a perfect organisational blueprint — will be better positioned to detect attacks earlier, respond faster, and deliver a seamless experience to their customers.

The tools and the talent already exist inside most enterprises. What is required is the willingness to set aside political boundaries and build the shared context that makes genuine collaboration possible.