How many DevSecOps engineers does a mid-size SaaS need?

The useful DevSecOps team size question is not “How many security engineers should we hire?” It is “Which security responsibilities need continuous ownership, and how much capacity does that work require?”

Two SaaS companies with 100 employees can need very different setups. One may run a single product on one cloud platform. The other may operate eight product squads, dozens of repositories and a growing evidence backlog for enterprise customers.

TL;DR

Most mid-size SaaS companies do not need a large standalone DevSecOps department. A practical starting point is one named DevSecOps owner for a small engineering function, followed by security champions and specialist support as repositories, release frequency, cloud scope and compliance work grow. Use the ranges below as a planning model, not a universal engineer-to-developer ratio.

• Start with ownership before adding headcount.
• Add security champions when one owner cannot maintain context across multiple product squads.
• Add dedicated capacity when remediation, pipeline controls or evidence work repeatedly competes with delivery.
• Size the function against workload and risk, not total company headcount alone.

What does DevSecOps team size mean?

DevSecOps team size means the amount and mix of capacity required to own security inside software delivery. It includes more than employees with “DevSecOps” in their job title.

A working coverage model usually includes five responsibilities:

1. A DevSecOps owner sets pipeline rules, triage standards, release gates and remediation workflows.
2. Security champions bring product and code context from individual squads.
3. A cloud or infrastructure-as-code specialist handles cloud access, configuration and infrastructure risks.
4. An application security reviewer supports threat modelling, secure code review and complex findings.
5. A compliance evidence owner keeps control records, exceptions, access reviews and remediation evidence ready for review.

One person may cover several of these responsibilities in a smaller company. As delivery grows, the responsibilities need to separate so that the same person is not expected to configure scanners, review architecture, fix every finding, train developers and prepare audit evidence.

NIST’s Secure Software Development Framework takes the same ownership-led approach. It recommends defining secure development roles across developers, testers, product owners, security champions, platform engineers and management instead of treating security as the responsibility of one isolated role.

For readers who need the operating model before the sizing decision, this guide to what DevSecOps means for EU tech leaders explains how these responsibilities fit into the software delivery lifecycle.

The practical test is coverage. If every recurring security task has an owner, a cadence and an escalation path, the setup may be large enough. If findings, exceptions or evidence requests wait for one overloaded engineer, the function is already undersized.

Team size by engineering stage

For most SaaS companies with 50 to 500 total employees, DevSecOps coverage should be planned against engineering workload rather than company headcount alone.

Engineering count is a useful starting signal because it approximates the number of squads, repositories and releases that require support. The final decision should also account for cloud complexity, data sensitivity, customer due diligence and regulatory scope.

The ranges below are planning ranges created for capacity discussions. They are not industry-standard staffing ratios.

Engineering stage	Typical risk profile	Minimum coverage model	Warning signal	Recommended next step
5-10 engineers	One product, limited repositories, one main cloud environment	One named owner, often a DevOps or senior engineering lead, with specialist review when needed	Security work has no scheduled capacity and only happens before a customer review or release	Reserve capacity for pipeline controls, access review and vulnerability triage
10-25 engineers	One or two squads, growing CI/CD use, more third-party dependencies	One named DevSecOps owner with a security contact inside each main product area	The owner spends most of the sprint responding to findings rather than improving controls	Formalise champion responsibilities and define remediation SLAs
25-75 engineers	Several squads, multiple services, frequent releases and enterprise clients	One or two dedicated DevSecOps engineers, security champions per squad and shared cloud support	Findings move between teams without clear ownership or repeatedly miss target dates	Add dedicated coverage and a monthly cross-squad security review
75-150 engineers	Multiple platforms, cloud accounts and product lines	Two to four dedicated specialists, a champion network, cloud/IaC coverage and a named evidence owner	Architecture reviews, risk exceptions and evidence requests queue behind daily pipeline support	Separate platform, application security and evidence responsibilities
150+ engineers	Large product portfolio, many services, distributed engineering and formal governance	A central security or platform engineering function, squad champions and dedicated appsec, cloud and governance roles	Squads create different release rules, severity thresholds or exception processes	Standardise controls through shared platforms, policy-as-code and central governance

A 50-person SaaS company with ten engineers may only need a named owner and access to specialist support. A different 50-person company with regulated customers, several repositories and weekly questionnaires may need a dedicated engineer much earlier.

Compliance work changes the calculation because it creates recurring ownership and evidence tasks:

• ISO/IEC 27001 requires an information security management system that defines how security risks are managed, reviewed and improved.
• GDPR Article 25 addresses data protection by design and by default, while Article 32 requires technical and organisational measures appropriate to processing risk.
• NIS2 Article 21 includes security in system acquisition, development and maintenance, vulnerability handling, supply-chain security and assessments of control effectiveness for entities in scope.
• Vendor security questionnaires can add a separate evidence workload even where the company is not directly in scope for a specific regulation.

The sizing implication is direct. A company that prepares pipeline evidence every month needs more capacity than a similarly sized company with no formal assurance requests.

When one DevSecOps engineer is enough

One DevSecOps engineer can be enough when the delivery environment is contained, security work is prioritised and developers still own remediation.

The model usually works when most of these conditions are true:

• The company operates one main product or platform.
• Repositories use a consistent CI/CD setup.
• Cloud infrastructure follows one documented architecture.
• Security findings are assigned to product teams rather than fixed by the DevSecOps engineer alone.
• The number of high-risk exceptions remains manageable.
• One internal leader owns risk acceptance and evidence decisions.
• Customer questionnaires and audit requests arrive at a predictable cadence.

The engineer should own the system around the work. That includes scanner configuration, severity rules, release gates, triage, developer guidance and reporting. Product teams should continue to fix vulnerabilities in the code and services they own.

The model starts to fail when the engineer becomes both control owner and universal remediation resource. Tool maintenance slips because customer evidence is urgent. Developer training is postponed because a release is blocked. Architecture reviews wait because the vulnerability backlog has grown.

Watch delivery metrics for early evidence of that failure. DORA defines measures such as change lead time, deployment frequency, change failure percentage and failed deployment recovery time. If security review repeatedly increases lead time or delays recovery work, the capacity problem is affecting the delivery system rather than one person’s task list.

A 90-day DevSecOps implementation roadmap can create the first ownership, pipeline and evidence baseline. Long-term sizing should happen after that baseline shows how much recurring work the controls generate.

A five-question capacity check

Review these questions at the end of each quarter:

1. Does every critical or high finding receive an owner within one working day?
2. Are security gates maintained without delaying planned pipeline work?
3. Can the team answer an evidence request without rebuilding records manually?
4. Are developers receiving guidance before the same issue appears across several repositories?
5. Can the DevSecOps owner take leave without suspending approvals or triage?

Three or more “no” answers indicate that one person no longer provides enough coverage.

When you need a security champions model

You need a security champions model when several product squads require security context but a central DevSecOps engineer cannot join every design review, pull request discussion or backlog decision.

A security champion is an engineer inside a product squad who acts as the first security contact. The champion understands the product, communicates new risks to the squad and escalates decisions that need specialist review.

OWASP recommends starting by identifying the teams, defining the role, nominating champions, creating communication channels, building a knowledge base and maintaining participation. OWASP also notes that companies can begin with one or two champions before expanding the programme across development teams.

The champion should not become an unpaid security department inside the squad. The role needs protected capacity, training and an escalation path.

A useful responsibility split looks like this:

Responsibility	DevSecOps owner	Security champion	Cloud/IaC specialist	Appsec reviewer	Evidence owner
Define pipeline rules and severity thresholds	Accountable	Consulted	Consulted	Consulted	Informed
Triage routine findings	Accountable	Responsible for squad context	Consulted	Consulted for complex findings	Informed
Fix product vulnerabilities	Supports	Coordinates with developers	Supports infrastructure fixes	Reviews high-risk fixes	Informed
Review cloud and IaC changes	Consulted	Provides product context	Accountable	Consulted	Informed
Run threat modelling or complex code review	Coordinates	Participates	Consulted	Accountable	Informed
Approve risk exceptions	Prepares recommendation	Provides impact context	Consulted	Consulted	Records decision
Maintain audit and questionnaire evidence	Supplies technical records	Supplies squad records	Supplies infrastructure records	Supplies review evidence	Accountable

The model becomes useful at around three or more product squads, or earlier when squads use different stacks and release independently. Each champion can handle routine questions and bring local context into a monthly champion meeting.

The central DevSecOps owner still controls policy, tooling, high-risk escalation and cross-product consistency. Champions extend reach. They do not replace specialist capacity.

When to add outsourced or dedicated DevSecOps support

Add outsourced or dedicated DevSecOps support when the missing work is recurring, measurable and too specialised to distribute across the current team.

The clearest signals are operational:

• The remediation backlog grows for two or more sprints.
• Security tools produce findings, but no one has capacity to tune or triage them.
• A new cloud platform, CI/CD system or product line needs controls.
• Enterprise questionnaires repeatedly interrupt engineering work.
• ISO 27001, GDPR or NIS2 evidence has no consistent owner.
• A local vacancy has remained open while delivery risk continues to grow.
• The company needs a temporary capacity increase for certification, migration or a major customer review.

Choose the support model based on the shape of the work.

Use project-based specialist support for a defined change

A narrow project fits when the output has a finish line, such as introducing SAST, reviewing an AWS account, creating pipeline gates or clearing a specific remediation backlog.

This model is weaker when the company also needs weekly triage, developer guidance and evidence maintenance after the project ends.

Use one dedicated engineer for recurring cross-sprint ownership

A dedicated engineer fits when the work continues every sprint and the role needs access to the engineering backlog, repositories, pipeline and cloud environment.

The role should have a defined scope before recruitment begins. The DevSecOps role scorecard and interview guide separates pipeline security, cloud/IaC, application security, vulnerability management and evidence responsibilities.

Use a small dedicated team when several workstreams run in parallel

A small team becomes useful when the company needs pipeline implementation, cloud security, appsec review and evidence work at the same time. One person will otherwise switch between specialist domains and become the approval bottleneck.

The DevSecOps team hiring guide for EU companies explains how to choose between permanent internal hiring, freelance support and dedicated capacity. Teams looking for managed coverage rather than an embedded individual can also compare the operating model in DevSecOps as a Service.

The internal team must keep decision authority in every model. Product risk acceptance, business priority and final release ownership should not be transferred to an external engineer without explicit governance.

How Sunbytes helps design the right DevSecOps coverage

Sunbytes helps Dutch and European SaaS companies turn the coverage gap into a defined role or dedicated team setup.

The process starts with the work, not a preselected team size:

1. Map repositories, product squads, cloud environments and release cadence.
2. List recurring responsibilities across pipeline controls, cloud/IaC, appsec, remediation and evidence.
3. Identify which decisions must stay with internal engineering, security or management.
4. Define the scope for a dedicated engineer or small team.
5. Set the onboarding plan, access boundaries and first 30-day outcomes.
6. Track delivery through agreed signals such as change lead time, remediation throughput and evidence completion.

Sunbytes combines Netherlands-based accountability with engineering delivery from Vietnam. A 4 to 5-hour Amsterdam-Vietnam working overlap supports sprint decisions, security escalation and handover review. Dedicated senior capacity can normally be operational within 2 to 4 weeks when the scope, access and interview process are ready.

Delivery operates within Sunbytes’ ISO 27001-certified information security management system. Certification does not make a client product compliant by default, but it provides a controlled environment for access, information handling and documented delivery processes.

When one engineer has become the bottleneck, adding more tools will not restore coverage. The next step is to separate the work into responsibilities, assign internal decision owners and add capacity against the unresolved workload.

Let’s start with Sunbytes

Let us know your requirements for the team and we will contact you right away.

Name(Required)

First Last

Company(Required)

Email(Required)

How can we help you(Required)

How can we help you?Custom Software developmentDedicated Tech servicesHR services (Vietnam)Cybersecurity servicesOthers

How did you hear about us?(Required)

How did you hear about us?LinkedInClutchNewsletterSearch engine (Google, Bing, Yahoo,…)EmailReferralOthers

Message

untitled(Required)

I allow Sunbytes to contact me via email and phone

Untitled(Required)

I agree to the general terms & conditions

Captcha

Name

This field is for validation purposes and should be left unchanged.

Δ