Soms is de lastigste vraag in security niet of een maatregel streng genoeg is, maar of iemand nog precies kan uitleggen waarom die maatregel hier, voor dit geval, op deze manier geldt.
Dat is een ongemakkelijke vraag. Juist omdat veel teams met goede intenties werken. Er is druk op leveringen, een incident dat nog nazingt, een klantvraag die snel beantwoord moet worden, een auditpunt dat ergens op de achtergrond meekijkt. Dan ontstaat er gemakkelijk iets wat logisch voelt: een extra controle voor iedereen, een tijdelijke beperking die blijft hangen, een uitzondering die in een Slack-thread is afgesproken maar nergens echt landt.
Het probleem zit dan vaak niet in onwil. Het zit in iets stillers: we ruilen specifiek eigenaarschap in voor generieke maatregelen, omdat dat sneller voelt.
Wanneer snelheid net iets te veel wint van precisie
In softwareteams gebeurt dit zelden als groot moment. Vaker als optelsom van kleine beslissingen.
Een toegangsrecht wordt voor een hele groep aangepast, omdat het eenvoudiger is dan per rol kijken.
Een vendor-vraag blijft hangen tussen security, engineering en procurement, dus er komt een brede blokkade totdat “het helder is”.
Een release wordt vertraagd door extra checks, maar niemand kan later nog goed terughalen welke concrete afweging daaronder lag.
Een uitzondering op beleid wordt wel gegeven, maar de eigenaar van die uitzondering is na twee sprints uit beeld.
Van buiten lijkt dat misschien besluitvaardig. Van binnen voelt het vaak diffuser. Niet omdat mensen hun werk niet serieus nemen, maar omdat generieke maatregelen in het moment overzichtelijker zijn dan scherp kiezen: waar zit het echte punt, wie is eigenaar, en welk bewijs vinden we hier voldoende?
Voor leiders is dat relevant, omdat je hier een patroon ziet dat groter is dan security alleen. Het gaat over bestuurbaarheid. Over de vraag of beslissingen later nog te begrijpen, te verdedigen en waar nodig bij te sturen zijn.
Het nieuws is geen vergelijking, wel een spiegel
Die vraag kwam bij mij terug door berichtgeving uit Canada. NOS schreef deze week over een zaak waarin opnieuw een gevangene werd vrijgelaten nadat een rechter oordeelde dat hij onjuist was behandeld door gevangenispersoneel. In dezelfde instelling waren eerder meerdere vergelijkbare zaken geweest, waarbij collectieve bestraffing een rol speelde.
De context daarvan staat natuurlijk ver af van software of bedrijfssecurity. Het is geen vergelijking, en dat moet het ook niet worden.
Maar als aanleiding is het wel een bruikbare spiegel. Omdat het laat zien wat er kan gebeuren wanneer een systeem in generieke maatregelen schiet en het onderscheid tussen individuele afweging, aantoonbare onderbouwing en duidelijk eigenaarschap vervaagt.
In organisaties gebeurt dat op veel minder dramatische manieren. Toch is het patroon herkenbaar genoeg om serieus te nemen. Niet omdat dezelfde feiten spelen, maar omdat besluitvorming overal kwetsbaar wordt zodra “voor de zekerheid voor iedereen” de plaats inneemt van “hierom, op deze plek, met deze eigenaar”.
En precies daar ontstaan later de lastigste gesprekken. Niet bij de eerste beslissing, maar bij de terugblik erop.
Wie heeft dit besloten?
Waar was dat op gebaseerd?
Geldt dit nog steeds?
Was dit proportioneel?
Als die vragen alleen met interpretatie, contextverlies of losse screenshots te beantwoorden zijn, dan heb je meestal geen toolingprobleem. Dan heb je een eigenaarschapsprobleem.
De reflex helpt niet altijd: meer audit, meer tooling, meer laagjes
Wat veel leiders dan verstandig proberen te doen, is opschalen in serieusheid. Een bredere review. Een nieuw programma. Extra tooling. Meer controlepunten in het proces.
Dat is begrijpelijk. Maar het helpt niet altijd als eerste stap.
Want als de kernvraag nog vaag is, vergroot je met zo’n reflex soms vooral de mist. Je krijgt meer werk, meer signalen, meer overleg, maar niet per se meer helderheid over welke securitybeslissingen echt belangrijk genoeg zijn om expliciet eigenaarschap en onderbouwing te vragen.
Dat zie je vaak terug in heel gewone situaties:
- een policy bestaat, maar uitzonderingen leven elders;
- een controle is ingericht, maar het doel ervan is intussen verschoven;
- een prioriteit staat hoog op papier, maar heeft geen echte beslisser;
- een maatregel blijft bestaan omdat niemand eigenaar is van het afbouwen ervan.
Dan voelt security zwaar, terwijl het werkelijke gemis vaak klein en precies is: één plek waar bewijs, eigenaar en prioriteit weer bij elkaar moeten komen.
Dat is ook de reden dat een brede security-audit vaak te vroeg komt als reflex. Niet omdat audits onzin zijn, maar omdat ze pas waarde krijgen als je al iets scherper ziet waar bestuurbaarheid ontbreekt.
Zonder dat zicht vergroot je vooral de stapel.
Een kleiner begin geeft vaak meer rust dan een groter plan
Wat dan wel werkt, is kleiner kijken dan je intuïtie zegt.
Niet naar “onze hele security-aanpak”, maar naar één recente beslissing.
Bijvoorbeeld:
een toegangsuitzondering voor een leverancier; een tijdelijke maatregel na een incident; een policy-afwijking voor een klantdeal; een extra controle voor een release; een blokkade op een integratie of tool.
Pak er één. Alleen die.
En toets vervolgens drie dingen.
Is er bewijs dat uitlegt waarom deze beslissing toen logisch was?
Is er een eigenaar die zich nu nog verantwoordelijk weet voor de afweging?
Is de prioriteit expliciet genoeg geweest, of heeft urgentie de plaats ingenomen van keuze?
Meer hoeft het eerst niet te zijn.
Juist die kleinheid maakt het bruikbaar. Een leider hoeft niet te wachten op een projectplan. Een CISO hoeft niet eerst een nieuw operating model te tekenen. Een founder hoeft niet meteen de hele organisatie mee te nemen in een volwassenheidsverhaal.
Één beslissing is vaak genoeg om een patroon zichtbaar te maken.
Soms ontdek je dat het eigenlijk goed geregeld is, maar slecht zichtbaar. Ook dat is winst.
Soms blijkt dat de afweging prima was, maar de eigenaar niet meer helder. Dan weet je waar de spanning zit.
En soms zie je dat iets wat als securitymaatregel begon, inmiddels vooral gewoonte is geworden. Dan ontstaat er ruimte voor een rustiger, proportioneel gesprek.
Dat is vaak waardevoller dan nog een algemeen debat over “meer security” of “minder frictie”.
Van discussie naar signaal: een rustigere route voor leiders
Voor softwareleiders is dat misschien wel de belangrijkste verschuiving: weg van alles tegelijk willen begrijpen, en terug naar een klein signaal dat bestuurbaarheid zichtbaar maakt.
Niet omdat klein altijd beter is, maar omdat eigenaarschap zelden begint in abstractie.
Het begint meestal in een concrete situatie. Een supportvraag die ongemerkt een beleidsuitzondering werd. Een release note die een extra controle triggerde. Een Slack-thread waarin een tijdelijke keuze permanent werd. Een roadmap-item dat security-raamwerk heet, maar eigenlijk onduidelijk eigenaarschap verbergt.
Daar zit de echte opening.
Niet in harder praten over risico. Wel in kalm aanwijzen waar een beslissing vandaag nog niet goed genoeg terug te voeren is op bewijs, eigenaar en prioriteit.
Dat maakt security niet kleiner. Het maakt haar beter bestuurbaar.
En het geeft teams vaak iets terug wat in drukke periodes snel verloren gaat: het gevoel dat besluiten weer proportioneel mogen zijn.
Als dit gesprek intern relevant voelt, hoeft de volgende stap dus niet groot te zijn. De Pathfinder Signal-route is juist bedoeld om eerst signalen te ordenen: waar ontbreekt nu vooral bewijs, waar eigenaarschap, en waar prioriteit? Pas daarna wordt duidelijk wat wel of niet groter gemaakt moet worden.
Misschien is dat de ongemakkelijke vraag die het meeste oplucht: niet of jullie genoeg security doen, maar op welke ene securitybeslissing vandaag één extra laag eigenaarschap of onderbouwing al verschil zou maken.