Soms is de lastigste security-vraag niet: wat missen we nog? Maar: welke beslissing schuiven we voor ons uit, omdat niemand helder durft te zeggen welk bewijs nu eigenlijk genoeg is?
Dat moment kan herkenbaar zijn voor softwareleiders. Een klant vraagt door, een prospect wil een security-antwoord vóór de demo, een board wil comfort, een teamlid deelt een zorg in Slack. Bijna vanzelf ontstaat dezelfde reflex: we moeten hier méér mee. Nog een check. Nog een overzicht. Nog een traject. Begrijpelijk. Alleen wordt security daar niet altijd bestuurbaar van. Vaak wordt het vooral groter.
Die reflex valt extra op in weken waarin het nieuws zwaar is. Terwijl ik dit schreef, kwamen er berichten binnen over onrust in Belfast na een ernstig geweldsincident, met brandstichting op meerdere plekken en mensen die de straat opgingen (NOS, 2617875). Dat staat inhoudelijk ver van software-governance, en ik wil die werelden niet aan elkaar plakken. Wat zo'n bericht wel doet, is herinneren hoe snel een acute gebeurtenis elders onrust en reflexen oproept, het gevoel dat je "iets" moet, ook als nog niet helder is wát precies. Een vergelijkbaar mechanisme duikt geregeld op in security-gesprekken binnen softwareteams: hoe groter de onrust, hoe groter de neiging om breed te reageren in plaats van scherp.
De ongemakkelijke vraag wordt daarom kleiner en scherper: als er deze week één security-besluit genomen moet worden, welk minimale bewijs is dan echt nodig om dat besluit verantwoord te nemen? Die vraag brengt rust. Niet omdat alles dan opgelost is, maar omdat je uit de mist van algemene intentie stapt en teruggaat naar bestuurbare realiteit.
De spanning zit zelden in onwil, maar in te veel mogelijke acties tegelijk
In gesprekken met softwareleiders zit de wrijving zelden in desinteresse voor security. Integendeel. De intentie is er meestal volop. De spanning zit ergens anders.
Er zijn te veel mogelijke ingrepen tegelijk, en te weinig gedeeld beeld van wat nú eerst bewijs vraagt. Dus ontstaan bekende patronen: een spreadsheet met open eindjes, een Slack-thread met goede zorgen maar zonder eigenaar, een roadmap-item dat steeds een sprint opschuift, een tooldemo die vooral geruststelling belooft. Op papier gebeurt er veel. In de praktijk blijft de beslisvraag vaak staan.
Wat mij daarbij opvalt: in teams waar security-werk vooral leeft in chatkanalen, ontbreekt meestal niet de kennis, maar het moment waarop iemand expliciet zegt: "ik ben hier eigenaar van tot dit besluit rond is". Het verschil tussen een discussie en een beslissing zit vaak in die ene zin.
Voor een CTO, founder of productleider is dat een lastig evenwicht. Je wilt niets bagatelliseren. Maar je wilt je team ook niet een nieuwe onderzoekslus in trekken als de kernvraag nog niet scherp is.
Drie simpele lenzen voor een beter gesprek
Als security vaag of omvangrijk begint te voelen, helpt het om niet meteen breder te kijken, maar preciezer. Drie lenzen zijn dan vaak genoeg: bewijs, eigenaarschap en prioriteit.
De eerste is bewijs. Niet elk risico vraagt om een volledig programma voordat je iets mag besluiten. Soms is één zichtbaar signaal al genoeg om richting te kiezen. Een enterprise-klant vraagt bijvoorbeeld zelden om "meer security" in algemene zin, maar heel specifiek wie toegang heeft tot productiegegevens en hoe dat wordt gelogd. Dan is de relevante vraag niet of je hele landschap volledig in kaart is. De relevante vraag is: welk concreet bewijs kunnen we deze week laten zien over toegangsrechten, logging en review?
De tweede is eigenaarschap. Een zorg zonder eigenaar wordt bijna automatisch discussie. Een zorg mét eigenaar wordt bestuurbaar, zelfs als nog niet alles bekend is. Dat eigenaarschap hoeft niet zwaar te zijn. Het kan al genoeg zijn dat één engineering manager, één platform lead of één founder zegt: ik trek deze beslisvraag tot we weten wat voldoende bewijs is.
De derde is prioriteit. Teams maken security soms onnodig zwaar doordat alles tegelijk belangrijk klinkt. Een lange actielijst zonder volgorde geeft vooral mentale druk. Een proportionele volgorde werkt beter: wat moet eerst bewezen worden om één zakelijke of technische beslissing mogelijk te maken? Je organiseert security dan niet rond volledigheid, maar rond bestuurbare voortgang.
Een klein tafereel: de vraag achter de vraag
Stel je een dinsdagmiddag voor. Er staat een prospectdemo gepland voor donderdag. Sales heeft een bericht doorgestuurd: de prospect is enthousiast, maar wil vóór de volgende stap iets meer vertrouwen voelen rond security. Niet eens een volledige vragenlijst. Gewoon genoeg om intern verder te kunnen.
In veel teams is dit het moment waarop de scope ineens uitwaaiert. Er komt een documentverzoek. Iemand noemt certificering. Er wordt geroepen dat policies geüpdatet moeten worden. Een leverancier plant een call in. Voor je het weet, is een concrete vraag veranderd in een vage wolk van werk.
Maar vaak zit de echte voortgang in een kleiner gesprek. Niet: wat moeten we allemaal nog optuigen? Wel: welke beslissing wil die prospect eigenlijk kunnen nemen, en welk bewijs hebben ze minimaal nodig om die stap rustig te zetten?
Misschien blijkt dat helemaal niet om een volledig securityprogramma te gaan, maar om drie dingen: wie heeft toegang tot klantdata, hoe worden wijzigingen vastgelegd en wie is eigenaar van incidentcoördinatie. Eén platform lead die maandagochtend zegt: "ik lever donderdag voor de demo een export van admin-toegang plus de laatste review" verandert het gesprek meer dan een nieuw traject. Het is nog steeds serieus. Maar het is niet meer diffuus.
Een ander patroon dat geregeld opduikt: een team gaat ervan uit dat logging op een kritiek API-pad keurig loopt, en ontdekt bij een rustige review dat één service sinds een refactor alleen nog errors logt, geen access events. Geen drama, wel precies het type aanname dat zichtbaar wordt zodra je één concreet bewijsstuk opvraagt in plaats van een breed overzicht.
En precies daar ontstaat ruimte. Het team hoeft niet te doen alsof alles af is. Het hoeft alleen helder te maken wat nu waarneembaar, belegd en uitlegbaar is. Dat geeft iets wat in security vaak onderschat wordt: vertrouwen zonder theater.
Bestuurbare security begint vaak met een kleinere eerste stap dan je denkt
Een goede eerste stap voelt meestal bijna te klein. Kies niet meteen een programma. Kies één beslisvraag.
Bijvoorbeeld:
- Kunnen we deze klant rustig antwoorden op hun vraag over toegang?
- Is voor dit onderdeel duidelijk wie eigenaar is als er iets misgaat?
- Hebben we genoeg bewijs om dit releasebesluit te nemen?
- Weten we waar nog aannames zitten in plaats van feiten?
Bepaal daarna niet al het bewijs dat ooit nuttig zou zijn, maar alleen het minimale bewijs dat deze vraag deze week verder brengt. Dat kan verrassend concreet zijn. Een export van toegangsrechten. Een korte review van admin-accounts. Een overzicht van incidentrollen. Een check of logging op één kritiek pad daadwerkelijk werkt zoals iedereen denkt dat het werkt.
Het effect is groter dan het lijkt. Je verlaagt niet alleen de omvang van het werk. Je verhoogt ook de kwaliteit van eigenaarschap. Mensen weten weer waar het gesprek over gaat. Een abstract onderwerp krijgt een begrensde volgende stap. En beslissingen worden kleiner, maar vaak beter.
Dat is ook de reden dat brede security-initiatieven soms stroef lopen wanneer ze te vroeg komen. Niet omdat ze per definitie verkeerd zijn, maar omdat ze starten vóór er een scherp, gedeeld signaal is dat richting geeft.
Eerst een signaal, dan pas verbreden
Voor leiders is dat misschien wel de belangrijkste verschuiving. Niet eerst alles inventariseren en daarna hopen dat er prioriteit uit ontstaat. Maar eerst één zichtbaar signaal kiezen waar bewijs ontbreekt, eigenaarschap nodig is en een echte beslissing op wacht. Dan wordt security een bestuurbaar gesprek in plaats van een verzamelnaam voor onrust.
Dat is geen pleidooi voor minder serieus zijn. Juist het omgekeerde. Het is een pleidooi voor proportionele scherpte. Hoe volwassener een softwareorganisatie wordt, hoe minder waarde er zit in algemeenheden als "we moeten hier meer mee". De nuttige vraag wordt dan: wat moet er precies waarneembaar zijn zodat we niet groter reageren dan nodig, maar ook niet vager blijven dan verantwoord is?
Als je die vraag eenmaal goed stelt, volgt de volgende stap vaak rustiger dan verwacht. Niet via een allesomvattend traject, maar via een klein signaal met een eigenaar en een besluit dat daardoor eindelijk genomen kan worden.
Denk eens aan de eerstvolgende klantvraag, release of toegangsreview die deze week op je bureau ligt: welk klein stukje bewijs zou daar het besluit verantwoord maken, en wie zou daar morgen eigenaar van kunnen zijn?
Wil je dat klein en scherp maken voor je eigen context, dan is de Pathfinder Signal route daar precies voor bedoeld: eerst helder krijgen welk security-signaal nu echt om bewijs, eigenaarschap en prioriteit vraagt, en pas daarna bepalen of verbreding zinvol is.