WHITE PAPER

DevSecOps
Maturity Model
A blueprint for assessing and advancing your
organization’s DevSecOps practices.

datadog.com
DevSecOps Maturity Model 2

Table of Executive Summary 3

contents
1
Three key DevSecOps questions for leaders 4
to answer

2
The DevSecOps Maturity Model 6

3
Implications for your DevSecOps Journey 11

4
The Business Value of DevSecOps 14

5
Getting Started 16

Authors 16

About Datadog 17

Appendix: Detailed Maturity Model 18

datadog.com
DevSecOps Maturity Model 3

Executive Organizations must advance their DevSecOps practices to deliver high

Summary quality, secure digital services to market quickly and efficiently. In order to
do that, leaders must ask themselves three key questions:

– What is our current level of DevSecOps maturity?

– Where is our desired level of DevSecOps maturity?

– How do we get there?

This white paper introduces a DevSecOps maturity model that technical

leaders can use to answer these three questions, and enable their
organizations to stay competitive in the digital economy.

We close with a discussion of the metrics leaders can use to demonstrate

the business value of their DevSecOps initiative.

datadog.com
DevSecOps Maturity Model 4

1 DevSecOps is a necessary requirement for organizations to deliver at

the speed and quality necessary to compete and innovate in the digital
Three key
economy. However, while leaders acknowledge that DevSecOps is a
DevSecOps
strategic imperative, organizations struggle to get started on the journey
questions for
and advance their practices. In order to move forward, technical leaders
leaders to answer
must ask themselves three key questions:

1. Where is my organization now?

2. Where do I want my organization to be?

3. How do we get there?

The first question requires an honest assessment of the organization’s

current DevSecOps competencies. The second question asks leaders to
define what “good” looks like for their business given their competitive
landscape. Finally, leaders need to identify initiatives that will bridge the
gap between where they are now and where they want to be.

To answer the three key questions, technical leaders need a

maturity model
According to software development expert Martin Fowler:

“A maturity model is a tool that helps people assess the current

effectiveness of a person or group and supports figuring out
what capabilities they need to acquire next in order to improve
1
their performance.”

A maturity model presents a prescriptive point of view on a particular

domain and the most efficient and effective method to advance within that
domain, as shown below:

EXPERT

ADVANCED
We want to get here

INTERMEDIATE
We need to get here first

BEGINNER
We’re here
1
https://martinfowler.com/bliki/MaturityModel.html

datadog.com
DevSecOps Maturity Model 5

Methodology
Our technical enablement teams work hand in hand with customers to
help drive their DevSecOps transformations. In addition, we have more
than 10 years of experience helping over 14,000 companies drive DevOps
(and now DevSecOps) practices. As a result, we’ve observed companies
at all levels of DevSecOps maturity and seen their paths of progression.
We’ve built a DevSecOps maturity model that distills these customer
experiences into efficient paths that any organization can replicate.

DevOps vs. DevSecOps

The DevOps movement emerged more than 10 years ago to improve the
speed and quality of writing and running software by encouraging greater
collaboration and shared responsibility between Dev and Ops teams.
Organizations are still progressing in their DevOps journeys with varying
degrees of speed and success.

The increasing velocity of DevOps teams has opened the door for two
complications: (1) security issues are overlooked because DevOps teams
are mainly concerned with functional and performance characteristics
of software, not security, and (2) security is a bottleneck (or ignored)
because security teams still exist in a separate silo with separate tools,
culture, and processes from their DevOps counterparts (who are also
moving with increasing speed).

Importantly, these complications, which slow down the DevOps

lifecycle, are also occurring at a time when security itself is of increasing
importance. Organizations are under continuous attack from a wide variety
of threat actors. As more business is conducted through digital channels
and as organizations’ attack surface increases, technical and business
risks correspondingly grow.

datadog.com
DevSecOps Maturity Model 6

DEVSECOPS LAYERS IN SECURITY CONTROLS, TOOLS, AND PRACTICES

THROUGHOUT THE DEVOPS LIFECYCLE.

R I S SE
SK S

SE CAN
A

ER
AN R E
EL T

CU
OD EA

S
SF
TR ECU

RI
M HR

SM

T
S
T

Y
EN
T
SEC

OP

DE
SE

SE ATC
DI RE

EL

CU H
P
EA

PL
G
CO ECU

PL
N

RI
V

OY

TY
S

L
A
DE

RE
N
DEV OPS

E
SE S C

AT
BU
CU OD
A

T TY
OB
RI E

ER

DI RI
I
TY

LD

AU ECU
SE
ST

OP

S
RV
TE
SA

E
GN TA
ST

IT ITY
SE NA
SI IGI

OR
CU LY

ON R
A
D

M ECU
RI SIS
DA

TY

S
TE EN
ST

ST
P

All these developments suggest that Security must be more deeply

integrated into the DevOps lifecycle. DevSecOps is therefore the logical
next stage of evolution in the DevOps movement. By integrating security
teams and practices into DevOps workflows, firms can further accelerate
their speed of delivery, increase the quality of their software, and boost
the reliability of their services in production. Breaking silos between
security teams and DevOps teams is essential for realizing the full
potential of the DevOps movement. DevSecOps is not a departure from
DevOps, but is simply the next evolution of DevOps.

2 The DevSecOps Maturity Model identifies four stages of maturity across

six major competency areas. Below, we give an overview of each stage and
The DevSecOps
competency area before presenting the full maturity model.
Maturity Model
The Stages
We identify four key stages of DevSecOps maturity. These stages are based
on patterns witnessed in thousands of diverse organizations. Importantly,
there are no shortcuts to advancing, and no ways to “leapfrog” a level.
DevSecOps as represented by the maturity model is a journey.

datadog.com
DevSecOps Maturity Model 7

– Beginner: This phase marks the beginning of the DevSecOps journey.

Most important is a shift in culture and mindset that emphasizes
sharing and collaboration across technical disciplines, and a desire to
improve performance as a team. This is the foundation of DevSecOps.

– Intermediate: In this stage, organizations are consistently releasing

software but may experience bottlenecks, performance issues, and
some team friction. While security controls are shifting earlier in the
development process, much of the security-related work is still done
towards the end of the process, which can slow down release cycles
and result in lower quality code.

– Advanced: In this stage, organizations are highly efficient and

productive, releasing high quality, secure software on a regular basis to
a reliable platform. Security checkpoints are embedded throughout the
software development lifecycle.

– Expert: These are DevSecOps practices employed by the most

cutting edge organizations. These organizations release high quality
code multiple times per day. Security controls are deeply embedded
throughout the SDLC, and security has ceased to be a siloed domain. A
key aspect of this stage of maturity is a very high level of automation of
processes across Development, Operations, and Security.

The Competencies
The DevSecOps Maturity Model covers six key competencies:

– People & Culture: This competency is the foundation of DevSecOps.

This area encompasses organizational structure, communication
styles, values, incentives, behaviors, leadership, and individual and
team health.

The remaining five competencies can be mapped to the major phases

of the end-to-end DevSecOps lifecycle. These competency areas blend
process and technology.

– Plan & Develop: This competency area encompasses how work is

prioritized, how much work is planned versus unplanned, how much
work is new feature development versus paying down technical debt,
and how much risk assessment and code validation factors into the
earliest stage of the development process.

datadog.com
DevSecOps Maturity Model 8

– Build & Test: This area covers testing processes and automation,
quality assurance, code scanning techniques, and build and
signature validation.

– Release & Deploy: This competency focuses on deployment strategies

and release frequency, automation of the deployment process, and
validation and remediation of deployment issues.

– Operate: This area covers infrastructure as code, capacity planning,

scaling and reliability, chaos testing and red teaming, patching, and
disaster recovery.

– Observe & Respond: This competency focuses on Service Level

Objectives (SLOs), vulnerability and misconfiguration scanning, security
monitoring, user experience monitoring, incident management, and
post-mortems.

The Model
In the matrix below, each of the six competency areas encompasses a
series of separate competencies, at least two of which are a security-
related competency. For each competency, we identify four levels of
maturity: Beginner, Intermediate, Advanced, and Expert.

(Note: the Appendix to this document contains additional detail on each

cell in the matrix below.)

datadog.com
DevSecOps Maturity Model 9

COMPETENCY BEGINNER INTERMEDIATE ADVANCED EXPERT

People & Culture – Functional teams – Silos breaking – Continuous – Cross-functional

siloed down collaboration teams aligned
– High inter-team – Embracing across teams to products and
friction experimentation & – Blameless culture services

– Nascent transparency – Comprehensive – High trust,

onboarding – Onboarding onboarding experimentation,
processes process exists process learning culture

– Burnout common – Burnout openly – Burnout quickly – Burnout rare

discussed addressed

Plan & Develop – Risk and security – Limited risk – Threat modeling – Extensive threat
not considered assessment and risk modeling/risk
– High technical – Moderate assessments assessment
debt technical debt – Low technical – Minimal technical
– Excessive bug – Moderate bug fix debt debt
fix work work – Low bug fix work – New feature focus
– Code not – Some code – All code validated – All code validated
validated validation automatically

Build & Test – Manual testing – Partial test – High test – Complete test
– No code scanning automation automation automation

– No build/signature – Partial code – Dynamic code – Comprehensive

validation scanning scanning dynamic code
– Partial build/ – Significant scanning
– Limited core
functionality signature build/signature – Comprehensive
testing validation validation build/signature
– Partial core – Significant core validation
functionality functionality – Comprehensive
testing testing core functionality
testing

Release & Deploy – Manual – Partial – High deployment – Full deployment

deployments deployment automation automation
– Large, infrequent automation – Small, weekly – Numerous daily
releases – Medium-sized, releases releases
– No deployment monthly releases – Detailed – Automated
security posture – Basic deployment deployment deployment failing
criteria security posture security posture – Bias to fast
– Difficult to criteria criteria forward fixes
remediate failed – Acceptable failed – Fast failed
deployment deployment deployment
remediation times remediation times

datadog.com
DevSecOps Maturity Model 10

COMPETENCY BEGINNER INTERMEDIATE ADVANCED EXPERT

Operate – Manual – Partial – Extensive – All infrastructure

provisioning/ configuration/ configuration/ configurations
configuration provisioning provisioning and instructions
– Long capacity automation automation instantiated as
planning cycles – OpEx-based – Capacity code

– Manual scaling capacity planning planning based – Capacity planning

– Partial auto- on seasonality/ based on granular
– Single availability growth usage trends/
zone scaling
– Significant auto- predictions
– No chaos testing – Multi-availability
zone/region scaling – Comprehensive
or red teaming auto-scaling
– Basic chaos – Multiple cloud
– Poor patching providers / high – Multiple cloud
hygiene testing or red
teaming availability providers / very
– No disaster – Significant chaos high availability
recovery strategy – Basic patching
hygiene testing & red – Continuous chaos
teaming testing & red
– Basic DR strategy teaming
– Fast patching
– Comprehensive – Patching SLA
DR strategy – DR plans tested
often

Observe & Respond – No SLOs formed – Basic SLOs formed – SLOs & error – SLOs & error
– No vulnerability/ – Partial budgets favored budgets drive
misconfiguration vulnerability/ – Significant decisions
scanning misconfiguration vulnerability/ – Extensive
– No security scanning misconfiguration vulnerability/
metrics defined – Some security scanning misconfiguration
metrics defined & – Security metrics scanning
– Siloed telemetry
visible defined & visible – Security metrics
– User journeys for most services defined & visible
unknown – Some common
observability data – Common for 100% of
– Excessive MTTD sets observability data services
and MTTR platform – Standardized
– Basic
– No post-mortems understanding of – Detailed user metadata model
user experience journey visibility – Complete user
– Moderately high – Moderate-to-low journey visibility
MTTD and MTTR MTTD and MTTR – Very low MTTD
– Basic post- – Detailed post- and MTTR
mortems mortems – Clear, blameless
post-mortems

datadog.com
DevSecOps Maturity Model 11

3 Let’s return to the three key questions for technical leaders (Where is my
organization? Where do we want to be? How do we get there?), and discuss
Implications for
how the Maturity Model can help answer them.
your DevSecOps
Journey
Where is my organization now?
The DevSecOps Maturity Assessment
Technical leaders need to calibrate where their organizations are on the
DevSecOps maturity curve. Towards that end, we’ve developed an online
self-assessment tool based on the DevSecOps Maturity Model. The
assessment is 36 questions and takes 10 minutes to complete.

The assessment is a diagnostic tool that is not meant to be precise, but

to give a rough indication of an organization’s DevSecOps maturity, and
areas to consider for improvement. The assessment generates an overall
maturity score.

Because organizations often have varying levels of maturity across

competency areas, it’s valuable to plot maturity levels on radar / spider
charts, as shown below.

STEP 1: ASSESS WHERE YOUR ORGANIZATION IS

Maturity by Competency
Culture

Observe & Respond Plan & Develop

Overall Maturity
EXPERT Operate Build & Test
ADVANCED
INTERMEDIATE
BEGINNER
Release & Deploy

Based on the output of the assessment, leaders can see at a glance where
there is room for improvement and investment.

datadog.com
DevSecOps Maturity Model 12

Where do I want my organization to be? Moving right in

the matrix
Once leaders have a sense of where their organizations stand in their
DevSecOps practices, the next step is to determine what “good” looks like
given their industry and business goals. The stages at the far right of the
maturity model show what best-in-class DevSecOps practices look like in
today’s enterprises.

It’s important to note that DevSecOps maturity varies across industries.

An “Intermediate” rating might be highly competitive in one industry but
lagging in another industry.

A useful exercise is shown below. Here, we highlight a hypothetical

organization’s maturity across all competencies, and we highlight
reasonable targets to hit within the next 12–18 months.

STEP 2: DEFINE WHERE YOUR ORGANIZATION NEEDS TO GO

Beginner Intermediate Advanced Expert

Culture

Plan & Develop

Build & Test

Release & Deploy

Operate

Observe & Respond

Overall Maturity

Where we are Where we want to be

Keep in mind that progress is incremental. Advancing even one level of

overall maturity within 12 months is an accomplishment. Depending on the
amount of work to be done, leaders may need to set multi-year plans with
intermediate targets.

datadog.com
DevSecOps Maturity Model 13

It’s also important to remember that state of the art DevSecOps practice is
constantly evolving and advancing. An “Advanced” rating one year might
become an “Intermediate” rating the next. For this reason, it’s important
for both maturity models to stay up-to-date and for leaders to continually
reassess their organizations using the latest models.

How do I get there? One cell at a time.

Because DevSecOps is a holistic set of practices spanning people, process,
and technology, each competency reinforces the other competencies. For
this reason, an organization with low maturity in one area will likely not
be able to advance overall very quickly until the lowest maturity areas are
addressed. We recommend prioritizing low maturity areas first in order to
build a strong foundation for more advanced stages of maturity.

The cells in the maturity model show the incremental steps leaders can
take to move from one level to the next.

STEP 3: DETERMINE HOW YOU’LL GET THERE BY PRIORITIZING INITIATIVES

AND INVESTMENT AND NOMINATING OWNERS FOR EACH COMPETENCY AREA
AND INDIVIDUAL COMPETENCY

Beginner Intermediate Advanced Expert

Culture Q2 Owner Q3

Plan & Develop Q1 Owner Q2

Build & Test Q2 Owner

Release & Deploy Q2 Owner Q3

Operate Q1 Owner Q2

Observe & Respond Q1 Owner Q2

Overall Maturity Q2 Owner/Leader Q3

Where we are How we're getting there Where we want to be

datadog.com
DevSecOps Maturity Model 14

Each of the competency categories and each of the specific competency

areas is a large topic unto itself. We recommend leaders enlist direct
reports to own specific competency areas, who can then enlist their team
members to own specific competencies (e.g. Test Automation).

4 DevSecOps drives more productive, collaborative, and responsive

teams that deliver high quality, secure software faster to highly reliable
The Business
production environments. This translates to tangible business value. Let’s
Value of
break down how.
DevSecOps
Four primary value drivers
Organizations that adopt the DevSecOps practices in the maturity model
realize business value through four key drivers:

1. Faster, more agile delivery and reduced time to market: DevSecOps

enables organizations to deliver applications to market faster,
and confidently iterate revenue-impacting applications with more
frequency to protect and grow revenue. The integration of security into
DevOps workflows eliminates potential bottlenecks and accelerates
organizations’ efficiency and agility.

2. Improved security posture and reduced risk: DevSecOps integrates

security stakeholders and security practices into all phases of the
software development lifecycle and the operation of services in
production. Greater collaboration, trust, and transparency among Dev,
Sec, Ops teams results in lower risk software.

3. Reduced operational and development costs: The fast feedback loops

of DevSecOps practices streamline the software development life cycle
and eliminate the vast mtajority of issues before they reach production
environments. Incidents that do occur are resolved very quickly.

4. Improved customer experiences and satisfaction: By producing

higher quality and more secure software, DevSecOps increases the
value organizations provide to their customers. Customers also value
more frequent enhancements and upgrades to their services. Finally,
customer satisfaction is also boosted when organizations are able to
observe systems from the end-users’ perspective and have visibility
into end-to-end customer journeys.

datadog.com
DevSecOps Maturity Model 15

METRIC COSTS CUSTOMER REVENUE

Faster, more Release QA time required Customers/ Revenue from

agile delivery frequency to identify, market share new customers
and reduced Time to market recreate, and Customer Revenue from
time to market document satisfaction increase in
Issues identified defects
in Dev & QA Customer share share of wallet
environments Developer of wallet Revenue from
wait time accelerated
time to market
Revenue from
new products
Revenue
from pricing
innovation

Improved security MTTD/MTTR Engineer time to Customer Lost revenue

posture and FTEs involved resolve incidents satisfaction due to outages
reduced risk per incident Tech support Customer share Revenue from
Customer center costs of wallet reduced churn
complaint calls Financial Customer churn Revenue from
Incidents/ losses due to higher share
outages performance of wallet
degradation
or security
incidents

Reduced Release Engineer time to

operational and frequency resolve incidents
development costs Issues identified QA time required
in Dev & QA to identify,
environments recreate, and
Incidents/ document
outages defects
Developer
wait time
Over-provisioning
infrastructure

Improved customer Customer Tech support Customer Revenue from

experiences and satisfaction center costs satisfaction reduced churn
satisfaction Customer share Revenue from
of wallet higher share
Customer churn of wallet

datadog.com
DevSecOps Maturity Model 16

DevSecOps business value metrics

As organizations increase their DevSecOps maturity, the business value
derived from each of these drivers increases. The table above covers in
more detail the business value of each driver in terms of productivity
metrics, customer metrics, costs, and revenue.

Technical leaders can and should measure their DevSecOps journeys using
the above metrics. These metrics are essential for demonstrating progress
throughout the organization, and for justifying the investments necessary
to progress along the maturity curve.

5 The DevSecOps Maturity Model is based on patterns we’ve seen working

with thousands of customers to advance their DevSecOps practices. It has
Get Started
been validated with customers and used as a tool to help leaders answer
the three key questions: Where are we? Where do we want to go? How do
we get there?

We recommend technical leaders complete the 10-minute DevSecOps Self-

Assessment to take the first step in your DevSecOps journey.

Authors Jeremy Garcia, Director, Technical Community & Open Source

Andrew Krug, Technical Evangelist

Fahim Ghaffar, Vice President, Technical Services

Boyan Syarov, Principal Solutions Engineer

Christy Pasion, Director, Technical Enablement

Ziquan Miao, Senior Technical Account Manager

datadog.com
DevSecOps Maturity Model 17

About Datadog Datadog is the monitoring and security platform for cloud applications.
Our SaaS platform integrates and automates infrastructure monitoring,
application performance monitoring and log management to provide
unified, real-time observability of our customers’ entire technology stack.
Datadog is used by organizations of all sizes and across a wide range of
industries to enable digital transformation and cloud migration, drive
collaboration among development, operations, security and business
teams, accelerate time to market for applications, reduce time to problem
resolution, secure applications and infrastructure, understand user
behavior and track key business metrics.

For more information, visit datadoghq.com

datadog.com
DevSecOps Maturity Model 18

Appendix:
Detailed Maturity Model

datadog.com
DevSecOps Maturity Model 19

1. Culture

COMPETENCY BEGINNER INTERMEDIATE ADVANCED EXPERT

Communication Siloed by Limited to Dev and Security Regular

functional team. Ops teams. Security stakeholders communication
remains siloed, and regularly share with and sharing
team members don't Dev and Ops teams across operations,
know who to report but not as frequently development, and
security concerns to. as Dev and Ops security. Team
teams share. members know who
to report security
concerns to.

Onboarding No standardized Onboarding process Engineers are Comprehensive

onboarding process. exists, but engineers considered onboarding process
are not fully productive after enables engineers to
productive after onboarding. be fully productive
completing and ramp and ramp up quickly.
up time is long.

Accountability Fear, lack of Fear of Blameless culture Transparent,

trust, blame, and experimentation, and frequent blameless, high
fingerpointing. some transparency, experimentation. trust, learning
behind the scenes culture, and
fingerpointing. experimentation.

Team health Team members Team members Team members Burnout is rare,
not able to discuss openly discuss are able to discuss but is openly
burnout and not burnout, but are not burnout and are discussed and
empowered to take empowered to take empowered to take quickly addressed.
mitigation measures. mitigation measures. mitigation measures.

datadog.com
DevSecOps Maturity Model 20

2. Plan & Develop

COMPETENCY BEGINNER INTERMEDIATE ADVANCED EXPERT

Risk assessment Security and risk are Security and risk Risk assessment or Risk assessment or
not considered at considerations threat modeling is threat modeling is
the beginning of the are introduced conducted at the used for every new
development cycle. in middle-to-late beginning of some service as part of
stages of the but not all services the design phase.
development cycle. at the design stage.

Technical debt Technical Technical debt Technical debt Technical debt

management debt increases is semi-regularly management is reduction across
uncontrolled. reduced but emphasized. applications and
reduction is not infrastructure is
prioritized. consistently tackled
and remains low.

Prioritization Engineers spend Engineers are Engineers spend Engineers spend

the majority of their frequently most of their time the majority of
time performing interrupted by on new features, their time creating
unplanned/ unplanned / bug fix but unplanned work new customer-
bugfix work and work, which delays is still significant. facing features and
remediating planned releases. functionality.
incidents.

Code validation Code is not validated Code is validated Static code Static code
after development. partially and analysis (e.g. Static analysis (e.g. Static
manually after application security application security
development. testing, or SAST) testing, or SAST) is
is performed on performed during the
some code to development phase
prevent commits of to prevent commits
vulnerable code. of vulnerable code.

datadog.com
DevSecOps Maturity Model 21

3. Build & Test

COMPETENCY BEGINNER INTERMEDIATE ADVANCED EXPERT

Test automation Manual testing Testing is partially Testing is mostly Testing is fully
is performed by automated automated. automated and
dedicated teams. with significant various testing
manual testing. regimes are applied
at all stages of
the development
lifecycle.

Code scanning Committed code is Some code is Dynamic code Dynamic code
not scanned to stop scanned to stop scanning (e.g. scanning (e.g.
the packaging of the packaging of Dynamic application Dynamic application
vulnerable code. vulnerable code. security testing, or security testing, or
DAST) is performed DAST) is performed
on some committed on all committed
code to stop the code to stop the
packaging of packaging of
vulnerable code. vulnerable code.

Build validation Builds and signatures Builds and Most builds and Builds and signatures
are not validated to signatures are signatures are are automatically
block unsigned or partially validated automatically validated to
vulnerable packages. to block unsigned or validated to block unsigned or
vulnerable packages. block unsigned or vulnerable packages.
vulnerable packages.

Quality assurance Core business Infrequent or The core business The core business
functionality is manual testing functionality of functionality of
not tested. of core business many applications all applications is
functionality. is frequently and continuously and
automatically tested. automatically tested.

datadog.com
DevSecOps Maturity Model 22

4. Release & Deploy

COMPETENCY BEGINNER INTERMEDIATE ADVANCED EXPERT

Deployment Teams manually Partial automation of Automation of most Tooling allows

automation move code from deployment process. of the deployment fully automated
one environment process. deployments into
to another. production.

Deployment Waterfall New code is released Agile methodology Agile methodology

strategy methodology semi-regularly and modern and modern
results in large, (e.g. monthly). deployment deployment
infrequent releases. strategies (e.g. strategies (e.g.
canary, blue-green, canary, blue-green,
shadow) support shadow) facilitate
regular releases releases multiple
(e.g. weekly). times per day.

Deployment There is no criteria There is a limited A set of criteria A set of criteria

validation for failing a new set of criteria exists for failing a exists for failing a
deployment based for failing a new new deployment new deployment
on security posture. deployment based based on security based on security
on security posture, posture, but posture, and it
and deployment implemention is not is automatically
validation is fully automated. implemented.
inconsistent.

Deployment Remediating a failed Teams have the Teams can quickly Teams are biased
remediation deployment is a ability to quickly roll back a failed to forward fixing
time consuming and roll back a failed deployment but deployment issues,
manual process. deployment. often make a and are capable of
forward fix instead. doing so quickly.

datadog.com
DevSecOps Maturity Model 23

5. Operate

COMPETENCY BEGINNER INTERMEDIATE ADVANCED EXPERT

Platform Configuration Infrastructure Infrastructure Infrastructure

management management configurations configurations fully managed by
sprawl and lack partially committed committed to code configuration
of deployment to code repository repository with management/
templating. and some manual mostly automatic orchestration tools
processes exist. deployments. and committed to
code repository.

Capacity planning Long capacity Capacity planning Capacity planning Capacity planning
planning cycles leverages OpEx leverages OpEx leverages OpEx and
(annual or quarterly) budget, but and informed based on seasonality
leveraging CapEx limited insight by seasonality and growth data.
budget. into seasonality and growth.
and growth.

Scaling Manual scaling. Pre-warmed Partial auto-scaling Auto-scaling occurs

environments with of the environment. when certain
mix of automatic conditions are
and manual scaling met (e.g. influx of
processes. legitimate requests).

Reliability Production Production Production Highly available

environments run environments span environments production
on single cloud multiple availability span multiple environments
provider region or zones and/or regions. AZs, regions, span multiple
availability zone. cloud providers. AZs, regions,
cloud providers.

Resiliency testing Environments Performance Frequent chaos Continuous chaos

not tested to the testing only in testing on some tests on production
breaking point and pre-production production environment.
no red team tests/ environments. environments. Continuous red
adversary simulation Infrequent red Frequent red team tests.
conducted. team testing. team testing.

Patching Patching is Regular patching Consistent patching Established SLA

infrequent and but systems remain after vulnerabilities for patching
not systematic. vulnerable for long detected but no systems found to
periods of time. established SLA. be vulnerable.

Disaster No DR strategy DR strategy in DR strategy in DR strategy in place

recovery (DR) in place. place but not place that is tested that is tested at
tested regularly and semi-regularly. regular intervals.
involves significant
downtime.

datadog.com
DevSecOps Maturity Model 24

6. Observe & Respond

COMPETENCY BEGINNER INTERMEDIATE ADVANCED EXPERT

Service level No SLOs formed. Rudimentary SLOs SLOs and error SLOs and error
objectives (SLOs) formed which may budgets are primary budgets are the
not reflect user indicators of primary driver
experience. service reliability. of engineering
decisions.

Vulnerability & No scanning. Some infrastructure Most infra and Continuous scanning
misconfiguration and applications apps scanned. of all infra and apps.
scanning scanned.

Security monitoring Security metrics (e.g. Security metrics are Security metrics Security metrics
failed logins) not partially defined defined and partially defined and fully
defined or visible. and visible. visible for 100% visible for 100%
of services. of services.

User experience No visibility Partial visibility High visibility into Full visibility into all
into end-to-end into some customer most customer customer journeys.
customer journeys. journeys. journeys.

Data model Data is uncorrelated, Some common Common data Mature metadata
& access and ingested datasets, but not platform with model, via the use of
into separate easy to correlate, a metadata tags or labels, that is
systems owned by search, and filter. model, usable by usable by all teams.
separate teams Frequent context most teams.
and not shared. switching.

Incident Incident detection Incident detection Incident detection Incident detection

management and remediation and remediation and remediation and remediation
times excessively times improving times low and times very low and
long and not but not precisely roughly measured. rigorously measured.
precisely known. measured.

Post-mortems No formal template Inconsistent post- Blameless post- Blameless post-

or process for mortems that mortems created in mortems created in
post-mortems. are not entirely a timely manner. a timely manner with
blameless or clear. clear action items.

datadog.com