ITSM and DevSecOps: Why They Need Each Other

How Service Design and Security-First Development Create Resilient, High-Performing Operations

The integration of ITSM frameworks with DevSecOps practices is redefining the way organisations handle technology service delivery. By embedding security and operational governance at every stage — from code inception through to production support — organisations transform themselves into more resilient, compliant, and customer-focused operations. Here’s a look at why this convergence isn’t just desirable; it’s essential, and more importantly, how to actually make it work in practice.

---

1. Setting the Scene: The World We’re Operating In

Before we get into the mechanics of how ITSM and DevSecOps should work together, it’s worth pausing to appreciate the environment we’re all navigating.

Cyber threats are growing in sophistication and frequency. Regulatory requirements — from GDPR to ISO 27001 to industry-specific compliance frameworks — are tightening. Organisations are deploying software faster than ever. At the same time, end users expect seamless, uninterrupted services and have little tolerance for outages or security incidents.

This creates a paradox: organisations need to move faster and be safer and be more governed. That feels contradictory. In reality, it’s only contradictory if you treat speed, security, and governance as separate concerns managed by separate teams. When you bring ITSM and DevSecOps together, they stop being competing priorities and start reinforcing each other.

In my opinion, this is one of the most important conversations happening in IT service management right now. Too many organisations still treat these disciplines as distinct universes — and they’re paying for that in the form of security incidents, compliance failures, and team burnout.

---

2. The Problem: A False Divide

For years, ITSM and development have existed in separate camps. Operational teams managed the Service Desk, Incident Management, Change Management, and Problem Management processes. Development teams shipped code. Security was either a gatekeeper sitting between them or an afterthought bolted on at the very end of the delivery cycle.

The result? Everyone doing their job, but nobody fully serving the mission.

This separation creates a predictable set of problems:

• Siloed accountability: When the Incident Management team doesn’t know how a piece of code was built, incident response becomes slower, less effective, and more reliant on escalating to the development team every time something unusual occurs.
• Compliance confusion: ITSM frameworks like ITIL® 4 demand governance and auditability, yet DevOps teams often lack visibility into the operational estate they’re contributing to. Change records are incomplete. CIs (Configuration Items) are undocumented. CMDB entries are stale.
• Security gaps: Security reviews happen in isolation from both development and operations, missing the broader operational context that matters most when determining real-world risk.
• Slower time-to-resolution: When an incident occurs, teams spend more time working out who owns the problem than actually solving it. Communication channels are unclear. Runbooks don’t exist or weren’t written by anyone who understands the deployed service.
• Technical debt compounds quietly: Without governance, shortcut decisions made during development become long-term operational liabilities. These only surface during incidents — at the worst possible time.

In my opinion, this divide persists largely because organisations have never formally asked: “How should these teams work together to serve the same mission?” That question is long overdue. Now let’s answer it.

---

3. Understanding DevSecOps: Security by Design

Before we explore the integration, it’s worth being clear about what DevSecOps actually means — because it’s a term that gets used loosely.

DevSecOps extends the DevOps philosophy (collaboration between development and operations to enable continuous delivery) by placing security at the centre of the process — not at the end. It’s the recognition that security can no longer be a “phase” or a handoff. It has to be a continuous practice.

In practical terms, DevSecOps means:

• Shift-left security: Vulnerability scanning, Static Application Security Testing (SAST), and dependency checking happen in the CI/CD pipeline — catching issues at the point of development rather than in production.
• Infrastructure as Code (IaC): Infrastructure configuration is written as code, version-controlled, peer-reviewed, and testable. Drift from a known-good state becomes visible and manageable.
• Automated compliance: Security controls are embedded into every build and deployment pipeline. Compliance becomes a by-product of good engineering, not a separate audit exercise.
• Shared responsibility: Developers own security outcomes alongside feature delivery. Security teams move from gatekeepers to enablers — providing tooling, guidance, and guardrails rather than blocking gates.
• Continuous monitoring: Security doesn’t stop at deployment. Threat detection, anomaly alerting, and vulnerability management continue throughout the operational life of the service.

This is, frankly, brilliant. When done well, DevSecOps dramatically reduces the cost of fixing security issues, improves compliance posture, and creates a culture where quality and security are everyone’s problem — not just a specialist team’s.

But here’s the gap: DevSecOps as typically implemented stops at the deployment gate. The pipeline runs, the code is deployed, and the development team moves on to the next sprint. What happens then?

• Who monitors for security drift in the weeks and months after deployment?
• Who responds when a vulnerability is discovered in production — and does that response follow a structured Incident Management process?
• Where do security-related changes fit into Change Management and Release Management processes?
• How does the organisation learn from security events in a way that feeds back into service design?

Without ITSM discipline, the honest answer to most of these questions is: “We’ll figure it out when something breaks.” That’s not a strategy.

---

4. What ITSM Brings to DevSecOps

ITSM frameworks — particularly ITIL® 4 — provide something DevSecOps teams desperately need: governance, predictability, and structured learning.

Let’s look at where ITSM adds the most value.

Service Design with Security Built In

ITSM’s Service Design phase is perhaps the most underused capability in the context of DevSecOps. Done well, it’s not a documentation exercise — it’s a structured conversation that forces clarity before a line of code is written.

A Service Design Document (SDD) for a new or significantly changed service should answer:

• Service Architecture: How is this service built, deployed, and hosted? What are the dependencies? What CIs need to be registered in the CMDB?
• Security Requirements: What’s the threat model? What data does this service handle, and what are the classification and handling requirements? What compliance obligations apply — GDPR, PCI DSS, ISO 27001, or others?
• Operational Requirements: How will the team monitor this in production? What alerting thresholds matter? How will patches and updates be applied?
• Support Model: Who owns Level 1, 2, and 3 support? What are the SLAs and escalation paths? What does the on-call rota look like?
• Continuity and Recovery: What’s the RTO (Recovery Time Objective) and RPO (Recovery Point Objective)? What happens if this service fails? Is there a DR plan?

By formalising this before development begins, organisations avoid some of the most expensive surprises in IT — discovering at deployment that nobody knows how to support the thing that was just built.

It also creates a shared language. Development teams understand the operational context they’re building for. Operations teams understand the design decisions that were made. Security teams have documented what controls were agreed. Everyone has a common reference point.

Change Management as a Safety Valve

DevSecOps teams deploy frequently — sometimes many times per day. That velocity is a genuine competitive advantage. But without Change Management discipline, you lose something critical: traceability.

When a security incident occurs in production, one of the first questions asked is: “What changed?” Without a change record, you’re reverse-engineering from logs and hoping you can reconstruct the timeline. That costs time and increases risk.

Lightweight Change Management — not bureaucratic approval gates, but clear logging and rollback capability — is what DevSecOps actually needs from ITSM. Specifically:

• Standard changes: Pre-approved, low-risk, repeatable deployments that can be automated and logged without human approval each time.
• Normal changes: Planned deployments with defined risk assessment, rollback plan, and communication — assessed by the Change Advisory Board (CAB) as appropriate.
• Emergency changes: A fast-track process for urgent security patches or critical fixes, with retrospective review to capture learning.

The key insight here is that ITIL® 4 doesn’t mandate bureaucracy. It mandates appropriate governance. A well-designed Change Management process for a DevSecOps environment is lightweight by design — automated where the risk is low, human where judgment is required.

Configuration Management and the CMDB

This one is often overlooked, but it’s arguably where some of the most significant operational value lies.

A well-maintained Configuration Management Database (CMDB) gives every team a single source of truth for the operational estate:

• What services exist?
• What are the dependencies between them?
• What versions are deployed where?
• What’s the security posture of each configuration item?

In a DevSecOps context, IaC and automated discovery tools make CMDB maintenance far more achievable than it used to be. Every deployment can update the CMDB automatically. Every infrastructure change is tracked.

When a vulnerability is announced in a third-party library, a well-maintained CMDB can immediately tell you which services are affected. That’s the difference between a targeted, rapid response and a frantic, organisation-wide scramble.

Incident Management: Structure in the Storm

When a security incident occurs in production — a data breach, a vulnerability exploit, a denial-of-service attack — the last thing you want is chaos. ITSM’s Incident Management process provides the structure to respond effectively:

• Rapid triage: Severity, impact, and urgency are assessed against a consistent priority matrix. The right people are engaged at the right time.
• Clear communication: Stakeholders — from end users to senior leadership — receive timely, accurate updates. Nobody is left wondering what’s happening.
• Coordination: Multiple teams (Security, Development, Operations, Networking) work within a clear command structure rather than across each other.
• Evidence preservation: Actions taken during incident response are documented, which matters enormously in a post-incident investigation or regulatory context.

DevSecOps culture brings speed and technical depth. ITSM brings the process framework that stops speed from becoming chaos.

Problem Management as a Learning Engine

This is where the real long-term value lies. Problem Management — in the ITIL® 4 sense — is about understanding the root causes of incidents and driving systemic improvements.

When a security incident closes, the natural DevSecOps instinct is to fix the code and ship the patch. That’s necessary, but it’s not sufficient. Problem Management asks the harder questions:

• Why did this vulnerability exist in the first place? Was it a code review failure? A missing security control in the pipeline? A design decision made without full information?
• Was there a detection gap? Why did this reach production without being caught?
• Did our incident response work? Where did communication break down? Were the right people engaged quickly enough?
• What do we need to change in our service design, our development practices, or our operational processes to prevent recurrence?

These questions, answered systematically and fed back into the DevSecOps pipeline, create a genuine learning organisation. Over time, the same classes of security incident stop recurring. The team gets smarter. The service gets safer.

---

5. What DevSecOps Brings to ITSM

Of course, the relationship runs both ways. Traditional ITSM — particularly when it has evolved without modernisation — can become slow, bureaucratic, and resistant to change. It’s not uncommon to find ITSM teams still relying on manual processes, lengthy approval chains, and documentation that nobody reads because nobody has time to keep it current.

DevSecOps practices are a genuine cure for this:

• CI/CD pipelines: Automation replaces manual, error-prone deployment processes. Changes are deployed faster, more safely, and with a complete audit trail — everything Change Management ever wanted, without the approval theatre.
• Infrastructure as Code: Configuration drift — one of the great enemies of operational stability — effectively disappears. Every infrastructure state is defined in code, version-controlled, and reproducible. This is a dream for Configuration Management and CMDB accuracy.
• Observability culture: DevSecOps teams instrument everything. Metrics, logs, traces — structured, queryable, and real-time. This data feeds ITSM’s Monitoring and Event Management processes, enabling genuinely proactive service management rather than reactive firefighting.
• Automated testing: Quality gates in the CI/CD pipeline mean that issues are caught before they become incidents. Fewer production incidents means less pressure on the Service Desk and a better end user experience.
• Psychological safety and blameless culture: DevSecOps culture actively encourages learning from failure without assigning blame. When this philosophy is applied to ITSM’s Problem Management reviews, you get far richer post-incident retrospectives — and far more honest conversations about what actually went wrong.

Perhaps most importantly, DevSecOps brings velocity. ITSM without DevSecOps can become a bureaucratic weight that slows delivery and frustrates development teams. ITSM with DevSecOps becomes a safety harness — providing structure and governance without friction.

---

6. The Cultural Challenge: Harder Than the Technical One

I want to be honest here, because many articles on this topic gloss over the most difficult part: the cultural gap between ITSM and DevSecOps teams is often wider than the technical one.

ITSM practitioners tend to be process-oriented. They think in terms of governance, auditability, and risk management. They’re often cautious by nature — for good reason, given that their job is to protect service stability.

DevSecOps practitioners tend to be engineering-oriented. They think in terms of shipping code, solving problems fast, and iterating. Bureaucracy feels like friction to them. “Move fast and fix things” is closer to their instinct than “move carefully and document everything.”

These aren’t incompatible worldviews — but they can feel that way, especially when the relationship hasn’t been deliberately designed.

In my experience, the organisations that bridge this gap successfully do a few things differently:

• They build shared goals. Not “ITSM team goals” and “DevSecOps team goals” — but shared outcomes around service quality, security posture, and customer experience. When everyone is measured against the same outcomes, the motivation to collaborate follows naturally.
• They invest in shared language. DevSecOps engineers who understand ITIL® 4’s service value chain are better collaborators. ITSM practitioners who understand CI/CD pipelines are better at designing governance that works for engineering teams. Cross-training and joint working sessions make a significant difference.
• They design governance that earns respect. ITSM governance that DevSecOps teams experience as pure friction will be worked around. Governance that is lightweight, automated where appropriate, and clearly connected to real risk management will be adopted willingly.
• They celebrate joint wins. When a security incident is resolved quickly because the team had good runbooks, a clear escalation path, and well-maintained monitoring — that’s a joint win for ITSM and DevSecOps. Make that visible.

---

7. How to Make Them Work Together: A Practical Playbook

So what does this look like in practice? Here’s a structured approach that organisations can adapt to their own context.

Start with the Service Design Document

Before code is written for a new service — or a significant change to an existing one — DevSecOps teams and Operations teams should collaborate on a Service Design Document (SDD).

The SDD should be lightweight enough to be completed and maintained without becoming a bureaucratic burden, but substantive enough to answer the questions that matter:

• Architecture, topology, and CMDB entries.
• Security controls, threat model, and compliance requirements.
• Deployment process and pipeline design.
• Runbooks for common operational scenarios.
• Monitoring thresholds, alerting strategy, and escalation paths.
• Support model, SLA commitments, and on-call arrangements.
• Continuity and recovery plans.

This isn’t documentation for documentation’s sake. It’s the artefact that enables the Operations team to support the service confidently from day one, and that gives the Security team the context to assess risk accurately.

Embed Operability into the Definition of Done

DevSecOps teams use a “Definition of Done” (DoD) to determine when a piece of work is genuinely complete. In a mature DevSecOps environment, that DoD should include operational readiness criteria:

• Are there runbooks for common failure scenarios?
• Is monitoring configured and alerting tested?
• Are logs structured, labelled correctly, and queryable?
• Has the CMDB been updated?
• Is there a documented rollback plan?
• Has the Operations team confirmed they can support this?

This single change — adding operability to the Definition of Done — shifts the conversation from “we deployed it, so it’s done” to “it’s only done when Operations can support it safely.” That’s a meaningful cultural shift with very tangible outcomes.

Design Your Change Management Process for Speed

If your Change Management process is a bottleneck, it isn’t well-designed — it’s just a gate. The goal of Change Management in a DevSecOps environment should be:

• Standard changes: Fully automated. Low-risk, pre-approved change types are logged automatically by the CI/CD pipeline. No human approval required. This covers the vast majority of routine deployments.
• Normal changes: A defined risk assessment process that is fast and proportionate. For most normal changes, this should be achievable within hours — not days. The CAB should be a focused discussion, not a committee meeting.
• Emergency changes: A clear fast-track process that can authorise urgent security patches within minutes if needed, with full retrospective documentation.

If your Change Management process cannot support a critical security patch being deployed to production within an hour when it needs to be, it is a liability — not a governance framework.

Create Joint Incident Response Playbooks

Incident response is too important to be improvised. Every major service should have a documented incident response playbook that covers:

• Detection: How will security incidents be detected? What monitoring and alerting is in place? Who receives the alert?
• Triage: How is severity assessed? Who makes the call on priority?
• Engagement: Who is contacted, in what order, and through what channel? This should cover Security, Development, Operations, Management, Legal, and Communications as appropriate.
• Containment: What immediate actions can be taken to limit the impact?
• Resolution: Who leads the technical response? How are actions coordinated and documented?
• Communication: Who updates stakeholders? How frequently? What do they say?
• Recovery: How is the service safely returned to normal operation? What validation is required before declaring the incident closed?
• Review: When does the Problem Management review happen, and who attends?

These playbooks should be written jointly by DevSecOps and ITSM practitioners, tested regularly through tabletop exercises, and updated whenever a real incident reveals a gap.

Establish a Shared Observability Platform

One of the most practical steps an organisation can take is consolidating monitoring and observability tooling so that both DevSecOps and ITSM teams are working from the same data.

DevSecOps teams need granular technical telemetry: application performance metrics, error rates, latency distributions, security event logs. ITSM teams need service-level views: is the service available? Is it performing within SLA? Are there patterns in incidents that suggest an underlying Problem?

A well-architected observability platform serves both. When an incident occurs, everyone is looking at the same dashboard — which makes coordination dramatically easier and eliminates the all-too-common scenario of teams arguing about different data sources whilst a production system is degraded.

Build a Joint Continuous Improvement Loop

ITIL® 4’s Continual Improvement practice and DevSecOps retrospectives are, philosophically, the same thing: a structured commitment to learning and getting better. Combining them creates something more powerful than either alone.

My preference when setting this up is a regular joint review — monthly or quarterly depending on the organisation’s pace — where:

• Recent incidents and their root causes are reviewed together.
• Patterns across incidents are identified and fed into Problem Management.
• Security improvements identified through DevSecOps scanning are prioritised alongside operational improvements.
• Service Design practices are updated to reflect lessons learned.
• Key metrics — deployment frequency, change failure rate, mean time to recovery, security vulnerability age — are reviewed against targets.

This joint cadence keeps both disciplines honest and ensures that improvement actions don’t fall into a gap between teams.

---

8. A Practical End-to-End Example

Let’s make this concrete. Imagine a financial services organisation is building a new customer-facing API for account balance enquiries. Here’s how ITSM and DevSecOps work together across the full lifecycle:

1. Service Design The product team, development lead, security engineer, and operations manager collaborate on an SDD. They document the architecture, identify PCI DSS compliance requirements, define the support model, agree monitoring thresholds, and register the planned CIs in the CMDB. Security controls — encryption in transit and at rest, API rate limiting, authentication requirements — are agreed and documented before a line of code is written.

2. Development The development team builds with security scanning integrated into every pull request. SAST tools flag a potential SQL injection vulnerability before code is merged. Dependency scanning identifies a known vulnerability in a third-party library — it’s patched before it ever reaches production. IaC defines the deployment topology, reviewed against the agreed architecture in the SDD.

3. Testing In staging, the Operations team validates that monitoring is configured correctly and that alerting fires as expected. They run through the incident response playbook against a simulated failure scenario. The team identifies a gap in the escalation path for out-of-hours incidents — it’s fixed before go-live.

4. Deployment The change is raised as a normal change, reviewed at CAB with the agreed risk assessment. The deployment is executed through the automated CI/CD pipeline, logged automatically in the change record. The CMDB is updated as the infrastructure is provisioned.

5. Operation The service enters production with clear runbooks, structured logging, and a known support model. When a minor performance incident occurs three weeks later, the Service Desk team can triage it confidently, escalate to the right Level 2 team, and resolve it within SLA — without needing to contact the development team at 11pm.

6. Security Event Two months after go-live, a zero-day vulnerability is announced in the API framework being used. The CMDB immediately identifies this service as affected. An emergency change is raised, the security patch is deployed through the CI/CD pipeline within four hours, and the change is documented. An Incident record is raised, assessed as contained, and closed. A Problem record captures the root cause and drives a review of how similar vulnerabilities will be detected faster in future.

7. Continuous Improvement At the monthly joint review, the security event is discussed alongside three other incidents from the period. A pattern emerges — the team isn’t getting enough lead time on third-party vulnerability announcements. The DevSecOps team commits to implementing automated dependency monitoring. ITSM updates the Incident response playbook to include a CMDB impact assessment step when zero-days are announced.

That is ITSM and DevSecOps working together. Each discipline making the other more effective.

---

9. Common Pitfalls to Avoid

Pitfall 1: Treating ITSM as “Change Control Theatre”

ITSM is governance, not bureaucracy. If your Change Management process requires three human approvals for a routine hotfix whilst a production system is degraded, something has gone wrong in the design of your process — not in the principle of Change Management itself. Automate where risk is low. Apply human judgment where it genuinely matters.

Pitfall 2: Treating DevSecOps as “No Oversight Needed”

“We’re DevSecOps, we don’t need Change Management” is a sentiment I hear occasionally — and it’s how organisations end up with undocumented infrastructure, incomplete CMDB records, and compliance violations that only surface during an audit. Governance and speed are not opposites. A well-designed governance framework enables speed by reducing the risk of the failures that slow everything down.

Pitfall 3: Keeping the Teams Organisationally Separate

If your ITSM team and your DevSecOps team report into different parts of the organisation with different goals and metrics, they will optimise for different things — and spend energy working around each other rather than with each other. Shared goals, shared metrics, and shared forums for collaboration are non-negotiable.

Pitfall 4: Starting with Tooling Instead of Process

It’s tempting to solve this problem by buying a platform that “integrates ITSM and DevSecOps.” Tools matter — but they don’t solve process problems. Define how you want the teams to work together first. Then choose tooling that supports that operating model. Tools chosen before the process is clear usually end up creating integration debt rather than reducing it.

Pitfall 5: Treating Security as a Gate Rather Than a Practice

Even within a DevSecOps model, Security teams sometimes revert to being gatekeepers — reviewing deployments at the end of the pipeline rather than embedding controls at the beginning. Security’s role should be to enable fast, safe delivery — not to slow it down. If your security reviews are a bottleneck, the answer isn’t fewer reviews; it’s earlier, automated ones.

---

Conclusion

ITSM and DevSecOps are not competitors. They never were. They’re two disciplines that were always trying to solve adjacent problems — governance and stability on one side, speed and security on the other — without enough dialogue about how to serve those goals together.

The organisations that are getting this right have recognised something important: you don’t choose between governance and agility, between security and speed, between structure and innovation. You design your operating model so that all of these things reinforce each other.

ITIL® 4’s service value chain, combined with DevSecOps engineering practices and a culture of continuous improvement, creates something genuinely powerful: an IT function that can move quickly, respond to threats confidently, learn from every failure, and deliver services that users trust.

That isn’t a future state. Organisations are doing it right now. The question is whether yours is one of them — and if not, what the first step looks like for your context.

---

Hopefully this has been useful to you and I wish you well on your ITSM journey…