De relevante vraag over de omvang van een DevSecOps-team is niet: “Hoeveel security engineers moeten we aannemen?” De juiste vraag is: “Welke securityverantwoordelijkheden vragen continu eigenaarschap en hoeveel capaciteit is daarvoor nodig?” Twee SaaS-bedrijven met 100 medewerkers kunnen een volledig andere opzet nodig hebben. Het ene bedrijf draait één product op één cloudplatform. Het andere werkt met acht productsquads, tientallen repositories en een groeiende achterstand aan bewijsstukken voor enterprise-klanten.
TL;DR
Plan capaciteit op basis van eigenaarschap en werkdruk
De meeste middelgrote SaaS-bedrijven hebben geen grote, zelfstandige DevSecOps-afdeling nodig. Een praktisch beginpunt is één aangewezen DevSecOps-verantwoordelijke voor een klein engineeringteam. Voeg daarna security champions en specialistische ondersteuning toe wanneer het aantal repositories, de releasefrequentie, de cloudscope en de compliancewerkdruk groeien.
- Begin met duidelijk eigenaarschap voordat u extra capaciteit toevoegt.
- Voeg security champions toe wanneer één verantwoordelijke niet langer voldoende context kan behouden over meerdere productsquads.
- Voeg dedicated capaciteit toe wanneer remediation, pipeline-controls of bewijswerk structureel concurreren met productdelivery.
- Bepaal de omvang van de functie op basis van werkdruk en risico, niet alleen op basis van het totale aantal medewerkers.
Wat betekent de omvang van een DevSecOps-team?
De omvang van een DevSecOps-team is de hoeveelheid én de mix van capaciteit die nodig is om security binnen softwaredelivery te beheren. Het gaat om meer dan medewerkers met “DevSecOps” in hun functietitel.
Een werkbaar capaciteitsmodel omvat meestal vijf verantwoordelijkheden:
- Een DevSecOps-verantwoordelijke bepaalt pipeline-regels, triagestandaarden, release-gates en remediationworkflows.
- Security champions brengen product- en codecontext vanuit afzonderlijke squads.
- Een cloud- of infrastructure-as-code-specialist beheert cloudtoegang, configuratie en infrastructuurrisico’s.
- Een application security reviewer ondersteunt threat modelling, secure code review en complexe findings.
- Een verantwoordelijke voor compliancebewijs houdt controleregistraties, uitzonderingen, toegangsreviews en remediationbewijs klaar voor beoordeling.
In een kleiner bedrijf kan één persoon meerdere van deze verantwoordelijkheden combineren. Naarmate delivery groeit, moeten de verantwoordelijkheden worden gescheiden. Anders wordt van dezelfde persoon verwacht dat die scanners configureert, architectuur beoordeelt, elke finding oplost, developers traint én auditbewijs voorbereidt.
Het Secure Software Development Framework van NIST volgt dezelfde benadering op basis van eigenaarschap. Het adviseert om secure-developmentrollen te verdelen over developers, testers, product owners, security champions, platform engineers en management, in plaats van security bij één geïsoleerde functie neer te leggen.
Voor lezers die eerst het operationele model willen bepalen, laat de gids over wat DevSecOps betekent voor Europese technologieleiders zien hoe deze verantwoordelijkheden in de software delivery lifecycle passen.
De praktische toets is dekking. Als elke terugkerende securitytaak een eigenaar, een ritme en een escalatiepad heeft, kan de opzet groot genoeg zijn. Als findings, uitzonderingen of verzoeken om bewijs blijven wachten op één overbelaste engineer, is de functie al te klein.
| Engineeringomvang | Dekkingsmodel |
|---|---|
| 5-10 engineers | Eén aangewezen verantwoordelijke beheert security en stuurt de uitvoering aan. |
| 10-25 engineers | Eén verantwoordelijke plus securitycontacten binnen elke belangrijke productsquad. |
| 25-75 engineers | Een klein dedicated DevSecOps-team met security champions en gedeelde cloudondersteuning. |
| 75-150 engineers | Specialisten voor platform, AppSec en cloud, plus een aangewezen eigenaar voor bewijsstukken. |
| 150+ engineers | Een centrale security- of platformfunctie met guardrails, gedeelde platforms en governance. |
Teamomvang per fase van het engineeringteam
Voor de meeste SaaS-bedrijven met 50 tot 500 medewerkers moet DevSecOps-capaciteit worden gepland op basis van de werkdruk binnen engineering, niet alleen op basis van het totale personeelsbestand.
Het aantal engineers is een bruikbaar startsignaal, omdat dit een indicatie geeft van het aantal squads, repositories en releases dat ondersteuning nodig heeft. De uiteindelijke keuze moet ook rekening houden met cloudcomplexiteit, de gevoeligheid van gegevens, leveranciersbeoordelingen door klanten en de toepasselijke regelgeving.
De onderstaande bandbreedtes zijn bedoeld voor capaciteitsgesprekken. Het zijn geen vaste branchenormen voor de verhouding tussen DevSecOps-engineers en developers.
| Engineeringfase | Typisch risicoprofiel | Minimale capaciteitsopzet | Waarschuwingssignaal | Aanbevolen vervolgstap |
|---|---|---|---|---|
| 5-10 engineers | Eén product, beperkt aantal repositories en één primaire cloudomgeving. | Eén aangewezen verantwoordelijke, vaak een DevOps- of senior engineering lead, met specialistische review wanneer nodig. | Securitywerk heeft geen gereserveerde capaciteit en gebeurt alleen vóór een klantreview of release. | Reserveer capaciteit voor pipeline-controls, toegangsreviews en vulnerability triage. |
| 10-25 engineers | Eén of twee squads, groeiend gebruik van CI/CD en meer afhankelijkheden van derden. | Eén aangewezen DevSecOps-verantwoordelijke met een securitycontact binnen elk belangrijk productgebied. | De verantwoordelijke besteedt het grootste deel van de sprint aan findings in plaats van controls te verbeteren. | Formaliseer de verantwoordelijkheden van security champions en definieer remediation-SLA’s. |
| 25-75 engineers | Meerdere squads, meerdere services, frequente releases en enterprise-klanten. | Eén of twee dedicated DevSecOps-engineers, security champions per squad en gedeelde cloudondersteuning. | Findings bewegen tussen teams zonder duidelijke eigenaar of missen herhaaldelijk de afgesproken datum. | Voeg dedicated capaciteit toe en organiseer maandelijks een securityreview over de squads heen. |
| 75-150 engineers | Meerdere platforms, cloudaccounts en productlijnen. | Twee tot vier dedicated specialisten, een championnetwerk, cloud/IaC-dekking en een aangewezen eigenaar voor bewijsstukken. | Architectuurreviews, risico-uitzonderingen en bewijsverzoeken blijven liggen achter dagelijkse pipeline-ondersteuning. | Scheid platform-, application security- en bewijsverantwoordelijkheden. |
| 150+ engineers | Grote productportfolio, veel services, gedistribueerde engineering en formele governance. | Een centrale security- of platform engineeringfunctie, squad champions en dedicated rollen voor AppSec, cloud en governance. | Squads hanteren verschillende release-regels, severity-drempels of uitzonderingsprocessen. | Standaardiseer controls via gedeelde platforms, policy-as-code en centrale governance. |
Een SaaS-bedrijf met 50 medewerkers en tien engineers heeft mogelijk genoeg aan één aangewezen verantwoordelijke en toegang tot specialistische ondersteuning. Een ander bedrijf met dezelfde omvang, gereguleerde klanten, meerdere repositories en wekelijkse securityvragenlijsten kan veel eerder een dedicated engineer nodig hebben.
Compliancewerk verandert de berekening, omdat het terugkerende taken voor eigenaarschap en bewijs creëert:
- ISO/IEC 27001 vereist een managementsysteem voor informatiebeveiliging waarin is vastgelegd hoe securityrisico’s worden beheerd, beoordeeld en verbeterd.
- AVG Artikel 25 behandelt gegevensbescherming door ontwerp en door standaardinstellingen. AVG Artikel 32 vereist technische en organisatorische maatregelen die passen bij het verwerkingsrisico.
- NIS2 Artikel 21 omvat voor organisaties binnen de scope onder meer security bij de verwerving, ontwikkeling en het onderhoud van systemen, vulnerability handling, ketenbeveiliging en beoordeling van de effectiviteit van controls.
- Securityvragenlijsten van leveranciers of enterprise-klanten kunnen een aparte bewijswerkdruk creëren, ook wanneer het bedrijf niet rechtstreeks onder een specifieke regeling valt.
De consequentie voor de teamomvang is direct. Een bedrijf dat elke maand pipelinebewijs moet opleveren, heeft meer capaciteit nodig dan een vergelijkbaar bedrijf zonder formele verzoeken om onderbouwing.
Wanneer één DevSecOps-engineer genoeg is
Eén DevSecOps-engineer kan genoeg zijn wanneer de deliveryomgeving overzichtelijk is, securitywerk prioriteit krijgt en developers verantwoordelijk blijven voor remediation.
Dit model werkt meestal wanneer de meeste van de volgende voorwaarden gelden:
- Het bedrijf beheert één hoofdproduct of platform.
- Repositories gebruiken een consistente CI/CD-opzet.
- De cloudinfrastructuur volgt één gedocumenteerde architectuur.
- Security findings worden toegewezen aan productteams en niet uitsluitend opgelost door de DevSecOps-engineer.
- Het aantal high-risk uitzonderingen blijft beheersbaar.
- Eén interne leider is verantwoordelijk voor risicoacceptatie en beslissingen over bewijsstukken.
- Klantvragenlijsten en auditverzoeken komen volgens een voorspelbaar ritme binnen.
De engineer moet eigenaar zijn van het systeem rondom het werk. Dat omvat scannerconfiguratie, severity-regels, release-gates, triage, begeleiding van developers en rapportage. Productteams blijven verantwoordelijk voor het oplossen van kwetsbaarheden in de code en services die zij beheren.
Het model begint te falen wanneer de engineer zowel control owner als algemene remediationcapaciteit wordt. Toolonderhoud schuift op omdat klantbewijs urgent is. Developertraining wordt uitgesteld omdat een release geblokkeerd is. Architectuurreviews wachten omdat de vulnerability backlog is gegroeid.
Let op deliverymetrics die vroeg laten zien dat het model vastloopt. DORA gebruikt metrics zoals change lead time, deployment frequency, change failure rate en failed deployment recovery time. Als securityreviews de lead time structureel verhogen of herstelwerk vertragen, raakt het capaciteitsprobleem het deliverysysteem en niet alleen de takenlijst van één persoon.
Een 90-daagse DevSecOps-implementatieroadmap kan de eerste basislijn voor eigenaarschap, pipelines en bewijs neerzetten. Bepaal de structurele teamomvang nadat deze basislijn zichtbaar maakt hoeveel terugkerend werk de controls creëren.
| Waarschuwingssignaal | Wat er gebeurt |
|---|---|
| 1. Triage vertraagt | Kritieke of high findings krijgen niet binnen één werkdag een eigenaar. |
| 2. Pipelinewerk loopt achter | Security-gates worden niet onderhouden zonder geplande pipelineverbeteringen uit te stellen. |
| 3. Bewijs wordt handmatig herbouwd | Het team kan bewijsverzoeken niet beantwoorden zonder documenten opnieuw samen te stellen. |
| 4. Begeleiding komt te laat | Hetzelfde probleem verschijnt in meerdere repositories voordat developers richtlijnen krijgen. |
| 5. Dekking hangt af van één persoon | De verantwoordelijke kan geen verlof opnemen zonder approvals of triage stil te leggen. |
Een capaciteitscheck met vijf vragen
Beoordeel deze vragen aan het einde van elk kwartaal:
- Krijgt elke critical of high finding binnen één werkdag een eigenaar?
- Worden security-gates onderhouden zonder gepland pipelinewerk te vertragen?
- Kan het team een bewijsverzoek beantwoorden zonder registraties handmatig opnieuw op te bouwen?
- Krijgen developers begeleiding voordat hetzelfde probleem in meerdere repositories verschijnt?
- Kan de DevSecOps-verantwoordelijke verlof opnemen zonder approvals of triage stil te leggen?
Drie of meer antwoorden met “nee” betekenen dat één persoon niet langer voldoende dekking biedt.
Wanneer u een security champions-model nodig heeft
U heeft een security champions-model nodig wanneer meerdere productsquads securitycontext vragen, maar een centrale DevSecOps-engineer niet bij elke design review, pull request-bespreking of backlogbeslissing kan aansluiten.
Een security champion is een engineer binnen een productsquad die als eerste securitycontact optreedt. De champion kent het product, communiceert nieuwe risico’s met de squad en escaleert beslissingen die specialistische beoordeling nodig hebben.
OWASP adviseert om te starten met het identificeren van teams, het definiëren van de rol, het aanwijzen van champions, het opzetten van communicatiekanalen, het bouwen van een kennisbank en het onderhouden van deelname. OWASP merkt ook op dat organisaties met één of twee champions kunnen beginnen voordat zij het programma uitbreiden naar alle developmentteams.
De champion mag geen onbetaalde securityafdeling binnen de squad worden. De rol vraagt gereserveerde capaciteit, training en een duidelijk escalatiepad.
Een bruikbare verdeling van verantwoordelijkheden ziet er als volgt uit:
| Verantwoordelijkheid | DevSecOps-verantwoordelijke | Security champion | Cloud/IaC-specialist | AppSec-reviewer | Bewijsverantwoordelijke |
|---|---|---|---|---|---|
| Pipeline-regels en severity-drempels definiëren | Eindverantwoordelijk | Geraadpleegd | Geraadpleegd | Geraadpleegd | Geïnformeerd |
| Routine findings triëren | Eindverantwoordelijk | Verantwoordelijk voor squadcontext | Geraadpleegd | Geraadpleegd bij complexe findings | Geïnformeerd |
| Kwetsbaarheden in producten oplossen | Ondersteunt | Coördineert met developers | Ondersteunt infrastructuurfixes | Beoordeelt high-risk fixes | Geïnformeerd |
| Cloud- en IaC-wijzigingen beoordelen | Geraadpleegd | Levert productcontext | Eindverantwoordelijk | Geraadpleegd | Geïnformeerd |
| Threat modelling of complexe code review uitvoeren | Coördineert | Neemt deel | Geraadpleegd | Eindverantwoordelijk | Geïnformeerd |
| Risico-uitzonderingen goedkeuren | Bereidt advies voor | Levert impactcontext | Geraadpleegd | Geraadpleegd | Legt de beslissing vast |
| Audit- en vragenlijstbewijs bijhouden | Levert technische registraties | Levert squadregistraties | Levert infrastructuurregistraties | Levert reviewbewijs | Eindverantwoordelijk |
Het model wordt bruikbaar bij ongeveer drie of meer productsquads, of eerder wanneer squads verschillende stacks gebruiken en onafhankelijk releasen. Elke champion kan routinevragen afhandelen en lokale context meenemen naar een maandelijkse championmeeting.
De centrale DevSecOps-verantwoordelijke blijft eigenaar van beleid, tooling, high-risk escalatie en consistentie tussen producten. Champions vergroten het bereik. Zij vervangen geen specialistische capaciteit.
Wilt u een capaciteitsgat sluiten?
Alleen op basis van headcount bepalen hoeveel DevSecOps-capaciteit nodig is, mist de belangrijkste beperking: eigenaarschap. Sunbytes kan helpen bepalen welke verantwoordelijkheden nu een aangewezen eigenaar nodig hebben, welke bij security champions kunnen liggen en waar dedicated capaciteit moet worden toegevoegd.
Wanneer u uitbestede of dedicated DevSecOps-ondersteuning toevoegt
Voeg uitbestede of dedicated DevSecOps-ondersteuning toe wanneer het ontbrekende werk terugkerend, meetbaar en te specialistisch is om over het bestaande team te verdelen.
De duidelijkste signalen zijn operationeel:
- De remediation backlog groeit gedurende twee of meer sprints.
- Securitytools produceren findings, maar niemand heeft capaciteit om ze af te stemmen of te triëren.
- Een nieuw cloudplatform, CI/CD-systeem of nieuwe productlijn heeft controls nodig.
- Enterprise-vragenlijsten onderbreken het engineeringwerk herhaaldelijk.
- Bewijs voor ISO 27001, AVG of NIS2 heeft geen vaste eigenaar.
- Een lokale vacature blijft open terwijl het deliveryrisico blijft groeien.
- Het bedrijf heeft tijdelijk extra capaciteit nodig voor certificering, migratie of een belangrijke klantreview.
Kies het ondersteuningsmodel op basis van de vorm van het werk.
Gebruik projectspecialisten voor een afgebakende wijziging
Een afgebakend project past wanneer het resultaat een duidelijk eindpunt heeft, zoals SAST invoeren, een AWS-account beoordelen, pipeline-gates opzetten of een specifieke remediation backlog wegwerken.
Dit model is minder geschikt wanneer het bedrijf na afloop van het project ook wekelijkse triage, begeleiding van developers en onderhoud van bewijsstukken nodig heeft.
Gebruik één dedicated engineer voor terugkerend eigenaarschap over meerdere sprints
Een dedicated engineer past wanneer het werk elke sprint terugkomt en de rol toegang nodig heeft tot de engineeringbacklog, repositories, pipelines en cloudomgeving.
De scope van de rol moet vaststaan voordat de werving begint. De DevSecOps-rolscorecard en interviewgids maakt onderscheid tussen pipeline security, cloud/IaC, application security, vulnerability management en bewijsverantwoordelijkheden.
Gebruik een klein dedicated team wanneer meerdere werkstromen parallel lopen
Een klein team wordt nuttig wanneer het bedrijf tegelijk pipeline-implementatie, cloud security, AppSec-review en bewijswerk nodig heeft. Eén persoon moet anders continu tussen specialistische domeinen wisselen en wordt zelf de bottleneck voor approvals.
De DevSecOps-teamwervingsgids voor Europese bedrijven legt uit hoe u kiest tussen vaste interne werving, freelance ondersteuning en dedicated capaciteit. Teams die managed dekking zoeken in plaats van een embedded specialist kunnen ook het operationele model van DevSecOps as a Service vergelijken.
Het interne team moet in elk model beslissingsbevoegdheid houden. Risicoacceptatie voor het product, businessprioriteiten en het definitieve eigenaarschap over releases mogen niet zonder expliciete governance worden overgedragen aan een externe engineer.
Hoe Sunbytes de juiste DevSecOps-dekking helpt ontwerpen
Sunbytes helpt Nederlandse en Europese SaaS-bedrijven om een capaciteitsgat om te zetten in een duidelijk gedefinieerde rol of een dedicated teamopzet.
Het proces begint bij het werk, niet bij een vooraf gekozen teamomvang:
- Breng repositories, productsquads, cloudomgevingen en releasefrequentie in kaart.
- Inventariseer terugkerende verantwoordelijkheden voor pipeline-controls, cloud/IaC, AppSec, remediation en bewijs.
- Bepaal welke beslissingen bij interne engineering, security of management moeten blijven.
- Definieer de scope voor een dedicated engineer of klein team.
- Leg het onboardingplan, de toegangsgrenzen en de resultaten voor de eerste 30 dagen vast.
- Volg delivery via afgesproken signalen, zoals change lead time, remediation throughput en de voltooiing van bewijsstukken.
Sunbytes combineert verantwoordelijkheid vanuit Nederland met engineeringdelivery vanuit Vietnam. Een overlap van 4 tot 5 uur tussen Amsterdam en Vietnam ondersteunt sprintbeslissingen, security-escalatie en handoverreviews. Dedicated senior capaciteit kan doorgaans binnen 2 tot 4 weken operationeel zijn wanneer de scope, toegang en het interviewproces gereed zijn.
Delivery vindt plaats binnen het ISO 27001-gecertificeerde managementsysteem voor informatiebeveiliging van Sunbytes. De certificering maakt een klantproduct niet automatisch compliant, maar biedt wel een gecontroleerde omgeving voor toegang, informatieverwerking en gedocumenteerde deliveryprocessen.
Wanneer één engineer de bottleneck is geworden, herstellen extra tools de dekking niet. Splits het werk op in verantwoordelijkheden, wijs interne besliseigenaren aan en voeg capaciteit toe op basis van het onopgeloste werk.
Dedicated DevSecOps-capaciteit toevoegen
Hire dedicated DevSecOps engineers om capaciteit voor pipelines, cloud, remediation of bewijs toe te voegen zonder eerst de volledige engineeringorganisatie opnieuw in te richten.
FAQs
Een klein SaaS-engineeringteam kan beginnen met één aangewezen DevSecOps-verantwoordelijke en specialistische ondersteuning wanneer dat nodig is. Bedrijven met meerdere productsquads hebben vaak één of twee dedicated engineers plus security champions nodig. Grotere organisaties kunnen afzonderlijke rollen nodig hebben voor cloud, application security en bewijsstukken. Het uiteindelijke aantal moet aansluiten op werkdruk, risico en productcomplexiteit, niet op een vaste ratio.
Eén engineer kan genoeg zijn voor een bedrijf met 50 medewerkers wanneer het engineeringteam klein is, het platform consistent is en productdevelopers hun eigen findings oplossen. Eén engineer is waarschijnlijk niet genoeg wanneer het bedrijf meerdere onafhankelijke squads, meerdere cloudomgevingen of zware bewijsverplichtingen heeft. Alleen het totale aantal medewerkers geeft geen antwoord op de vraag.
Een security champions-model wijst binnen elke productsquad een engineer aan als eerste securitycontact. Champions ondersteunen routinebeoordelingen, vragen van developers en escalaties, terwijl de centrale DevSecOps- of securityverantwoordelijke eindverantwoordelijk blijft voor beleid, tools en high-risk beslissingen. Het model werkt het best wanneer champions training en gereserveerde capaciteit krijgen.
Dagelijkse DevSecOps-delivery hoort meestal dicht bij engineering te liggen, omdat het werk repositories, CI/CD, cloudinfrastructuur en releaseprocessen raakt. Security leadership bepaalt het risicobeleid, de bevoegdheid voor uitzonderingen en de verwachtingen voor controls. Een praktisch model geeft engineering operationeel eigenaarschap en security de governancebevoegdheid.
Gebruik externe ondersteuning wanneer het werk duidelijk is afgebakend, maar het interne team onvoldoende capaciteit of specialistische ervaring heeft. Een kort project kan een toolimplementatie of cloudreview afhandelen. Een dedicated engineer past beter wanneer triage, developerondersteuning, remediation en bewijswerk meerdere sprints doorgaan.
Begin met één aangewezen centrale verantwoordelijke en wijs daarna per onafhankelijke squad een security champion aan. Voeg dedicated specialistische capaciteit toe wanneer de centrale verantwoordelijke pipeline-regels niet kan onderhouden, high-risk wijzigingen niet tijdig kan beoordelen of remediation- en bewijswerk niet actueel kan houden. Squads met verschillende cloudplatforms of technologiestacks kunnen eerder aparte cloud- of AppSec-ondersteuning nodig hebben.
Laten we beginnen met Sunbytes
Laat ons uw eisen voor het team weten en wij nemen meteen contact met u op.
