Blog - Hoe je ruzie en discussie over (security)rapportages kunt vermijden

Wanneer professionals securityrapportages of -adviezen schrijven voor lezers, inclusief (betalende) opdrachtgevers, kunnen ruzies of discussies ontstaan over de tekst. Hieronder toon ik mogelijke probleemgebieden en geef ik ook schrijfadviezen.

Ieder mens heeft zijn eigen waarneming van de werkelijkheid en vindt dat ‘de ware’. In die werkelijkheid zijn securityonderwerpen te zien. Maar niet alle mensen vinden exact dezelfde dingen ‘eigenlijk een security-onderwerp’. In het leven bestaan risico’s: dingen die fout kunnen gaan. Een voor jou relevant risico vormt een dreiging. Schat je de kans dat het je ooit overkomt zeer laag in, dan noem je het een ‘threat’, die een manager dan kan ‘parkeren’ (lees: geen geld aan besteden).

Een security officer moet volgens mij zijn collega’s waarschuwen voor die risico’s, dreigingen of threats. Als er meer dan drie mensen in je bedrijf werken, is het handig dit niet mondeling, maar schriftelijk te doen. Regelmatig schrijft een security officer voor gelijkgestemden, die ongeveer hetzelfde van security weten. Soms voor opdrachtgevers die er méér van weten – dit vrijwel alleen in opleidingen wanneer een docent je als test iets laat opschrijven wat hij allang heel goed weet. En als security professional schrijf je vaak voor ‘managers’, die (veel) minder van security weten dan jij.

Schrijver en lezer verschillen dus qua kennisniveau op het vlak van security. Er is een deelgebied dat beiden begrijpen. Onderwerpen boven dat gebied zijn te moeilijk. Onderwerpen eronder zijn te gemakkelijk en daardoor niet ‘interessant’ genoeg om op te nemen in het rapport. In het algemeen signaleert een schrijver meer securityrisico’s dan een lezer wanneer er sprake is van:

• hogere of meer security opleiding
• langere en/of bredere ervaring (binnen de huidige organisatie of de branche)
• een advies of rapportage meer op de lange termijn (strategisch) dan op de korte termijn (operationeel/brandjes blussen) gericht
• een advies of rapportage meer op detail dan op de grote lijn gericht
• meer technische (inhoudelijke) belangstelling, inzicht en ervaring dan uitsluitend ‘loopt het proces?’

Een lastige combinatie om securityrapporten in te bespreken is een inhoudelijk zeer ervaren professional als auteur versus een onervaren manager in haar/zijn eerste algemeen (proces) leidinggevende rol als lezer/opdrachtgever.


















Zoals bij veel ingewikkelde situaties kan een 2x2 matrix hier verduidelijking brengen. De probleem 1 en probleem 2 gebieden uit figuur 1 vormen samen groep ‘D’ in figuur 2. Let op: de scheidingslijn is onduidelijk. De meeste opdrachtgevers die ik heb ontmoet, geven namelijk niet graag toe dat een security-onderwerp voor hen ‘te moeilijk’ is. Ze zullen het onderwerp daarom ‘onbelangrijk’ noemen.





















Er zijn onderwerpen (of risico’s) die voor zowel schrijver als lezer belangrijk en begrijpelijk zijn. Deze komen daarom in het rapport en gaan over het te analyseren onderwerp. Daar wil de lezer immers wat over weten, daar betaalt de opdrachtgever voor en dat is het kennisgebied van de schrijver. Deze punten geven in het algemeen geen aanleiding tot discussie (zie A).

Er zijn ook onderwerpen (of risico’s) die zowel schrijver als lezer onbelangrijk of oninteressant vinden (zie B). Deze staan dus niet in het rapport en kunnen daarom per definitie niet tot discussie leiden - althans, niet reeds bij bespreking van het concept-rapport.

Er zijn onderwerpen die voor de schrijver niet belangrijk zijn, maar voor de lezer wel. Vooral als deze ook de opdrachtgever is. Wie gaf de onderzoeksopdracht? Is daarbij naar de letter het correcte (EU) aanvraagprotocol gevolgd? Is het onderzoek een week later opgeleverd dan tijdens de opdrachtverstrekking was beloofd? Is er ontzettend goed meegewerkt door de lezer aan de totstandkoming van het rapport en heeft de auteur zoiets positiefs nog nooit meegemaakt en mag dat ook wel eens gezegd worden?

Deze dingen zijn gemakkelijk toe te voegen, omdat ze meestal voor de schrijver de strekking van het rapport (of: ‘de conclusie’) niet wezenlijk veranderen. En ze verbeteren wel de sfeer en samenwerking met de lezer/opdrachtgever. Zeker wanneer er nog vervolgopdrachten moeten worden uitgevoerd. Ook onderwerpen in groep C hoeven dus geen reden tot discussie te zijn. Of zijn het alleen bij conceptbespreking van het eerste rapport in een serie – want je kunt je eigen schrijfstijl natuurlijk voortaan aanpassen op een vaste lezer. Zo, een extra gratis schrijftip!

Lastig wordt het pas in groep D. De schrijver schrijft ze op, want vindt ze belangrijk, maar de lezer vindt dat niet en wil die onderwerpen eruit hebben of sterk afgezwakt in hun formulering. Ik noem hier enkele zaken die je beter niet in een securityrapport kunt opnemen.
1. Het probleem is onoplosbaar. Dit kan op zich natuurlijk wel het geval zijn. Maar als je het zo opschrijft, loop je grote kans dat lezers jou als auteur ‘een pessimistische, negatieve zwartkijker’ gaan noemen - en je niet meer inhuren als externe adviseur. Of juist ‘verzuurd, te lang op dezelfde plek, niet meer passend in het team’ - en je als interne adviseur een nieuwe kans elders gaan gunnen.
2. De oplossing is onbetaalbaar. Ook dit komt in de praktijk wel regelmatig voor. Als de kosten de baten overstijgen bijvoorbeeld. Het is echter van groot belang louter het bedrag van de door jou ingeschatte kosten te noemen. De conclusie dat dit belachelijk veel is voor wat het oplevert, moet je aan de lezer zelf overlaten. Het mooiste is als je rapport uiteindelijk bij de baas van de opdrachtgever terechtkomt en dat die hoogste baas meteen inziet dat het onbetaalbaar is. Karma!
3. Het probleem is veroorzaakt door persoon X. Vooral niet als persoon X de opdrachtgever is. Dit feit kan natuurlijk heel goed des poedels kern zijn qua ‘Root Cause Analysis’, maar je moet het niet opschrijven als je daar wilt blijven werken (intern of extern). Uiteindelijk komt de waarheid wel boven. Op dat waarheidsmoment moet je overigens ook niet in gezelschap zeggen: ‘told you so’.
4. Een oplossing is in principe mogelijk, ware het niet dat persoon X dit niet heeft gedaan, of dat wel heeft nagelaten, of niet in staat is tijdig te besluiten over zus en zo, of te incompetent is om een genomen besluit uitgevoerd te krijgen. Dit is eigenlijk hetzelfde als (3). Omdat je als auteur nog allerlei oplossingen, verbetermogelijkheden en mogelijke correcties ziet, probeer je die – positief denkend als je bent – toch aan de lezer aan te reiken. Niet doen.

Als je deze vier weglaat, blijven er nog enkele potentiële discussiepunten over, maar die moet je dan als professional zelf maar even oplossen. En als je er echt goed naar kijkt, zie je ze mogelijk toch in het rijtje staan en kun je zo ruzie en discussie over je rapport of advies vermijden.

Robert Metsemakers

Robert Metsemakers schrijft op persoonlijke titel en is als ervaren IT-auditor en informatiebeveiligingsexpert beschikbaar voor security-advies en (algemene) schrijfopdrachten via robert.metsemakers@gmail.com

Dit blog verscheen in IB2-2023.