Verklaring van toepasselijkheid: zo stelt u hem op

De verklaring van toepasselijkheid is het document waarin u per beheersmaatregel uit ISO 27001 vastlegt of u hem toepast en waarom. In het Engels heet hij Statement of Applicability, vaak afgekort tot SoA. Het is het enige document dat de norm met zoveel woorden verplicht stelt.

Dat maakt hem belangrijker dan zijn saaie naam doet vermoeden. Een auditor pakt hem er vrijwel altijd als eerste bij, want in dit ene document ziet hij of uw risicobeoordeling en uw maatregelen op elkaar aansluiten.

Hieronder leest u wat erin hoort, hoe u hem opstelt zonder er weken aan kwijt te zijn, en waar in de praktijk de gaten vallen.

Wat erin hoort

De verklaring is in de kern een tabel met alle beheersmaatregelen uit Annex A. Per maatregel legt u vier dingen vast.

• Past u hem toe? Ja of nee, geen tussenweg.
• Waarom? Bij ja: welk risico of welke eis vraagt erom. Bij nee: waarom hij niet van toepassing is.
• Hoe is hij ingevuld? Een verwijzing naar het beleid, de procedure of het systeem waarin het geregeld is.
• Wie gaat erover? De verantwoordelijke rol, niet per se een naam.

Meer is niet nodig. De valkuil is om er een tweede beleidsdocument van te maken met lange beschrijvingen per maatregel. Dat wordt niet gelezen en het loopt gegarandeerd uit de pas met de werkelijkheid.

De onderbouwing is waar het om draait

Auditors kijken niet zozeer naar welke maatregelen u heeft gekozen, maar naar of de keuze te volgen is. Een maatregel uitsluiten mag prima, mits de reden klopt.

Goede redenen om iets uit te sluiten zijn concreet en verifieerbaar. U ontwikkelt zelf geen software, dus de maatregelen over veilige ontwikkeling zijn niet van toepassing. U heeft geen eigen serverruimte, dus de fysieke maatregelen daarvoor liggen bij uw hostingpartij, en dat legt u vast in het contract.

Wat niet werkt is een uitsluiting zonder redenering, of een reden die neerkomt op “dit doen wij niet”. Het verschil tussen een maatregel die niet van toepassing is en een maatregel die u gewoon niet heeft ingericht, is precies wat de auditor wil zien.

Zo stelt u hem efficiënt op

Begin niet bij de maatregelenlijst maar bij uw risicobeoordeling. Loop uw risico’s langs en noteer per risico welke maatregelen u ertegen inzet. Dan heeft u het grootste deel van de kolom “waarom” al ingevuld, met een onderbouwing die klopt.

Loop daarna de rest van de lijst langs. Wat overblijft zijn maatregelen die geen enkel risico afdekken. Bij elk daarvan is de vraag: mis ik een risico, of is deze maatregel echt niet van toepassing? Beide antwoorden zijn goed, zolang u het opschrijft.

Houd de vorm simpel. Een spreadsheet volstaat bij de meeste organisaties. Wat telt is dat er een versienummer en een datum op staan en dat duidelijk is wie hem heeft vastgesteld.

Waar de gaten vallen

Drie dingen komen bij vrijwel elke eerste audit terug.

Het eerste is een verklaring die niet meeloopt. Hij is opgesteld bij de start en daarna niet meer bijgewerkt, terwijl er in de tussentijd van alles is veranderd. Elke wijziging in uw risico’s of maatregelen hoort erin.

Het tweede is een verwijzing die nergens heen gaat. Er staat dat iets in het toegangsbeleid is geregeld, maar dat document bestaat niet of behandelt het onderwerp niet. Dat valt meteen op, want de auditor volgt die verwijzingen.

Het derde is een maatregel die op ja staat terwijl er niets is ingericht. Dat is ernstiger dan een eerlijke uitsluiting, want het is een onjuiste verklaring in een document dat u zelf heeft vastgesteld.

Hoe hij in de audit wordt gebruikt

In fase 1 van de certificeringsaudit is de verklaring een van de eerste documenten die wordt opgevraagd. De auditor kijkt of hij compleet is, of de onderbouwingen steek houden en of de verwijzingen kloppen.

In fase 2 wordt hij het draaiboek. De auditor kiest er maatregelen uit en toetst in de praktijk of het klopt wat u erover heeft opgeschreven. Staat er dat toegangsrechten elk kwartaal worden beoordeeld, dan vraagt hij naar de laatste beoordeling.

Bereid u daarop voor door zelf dezelfde steekproef te doen bij de interne audit. Wat u in de audit checklist ziet terugkomen staat in de ISO 27001 audit checklist.

Wat een goede onderbouwing onderscheidt van een slechte

Auditors lezen honderden van deze documenten en herkennen binnen een paar regels of er is nagedacht. Het verschil zit in de mate waarin de reden verifieerbaar is.

Een goede onderbouwing verwijst naar een feit dat iemand kan controleren. “Niet van toepassing, wij ontwikkelen zelf geen software en besteden dat volledig uit aan partij X” is te toetsen: de auditor kan naar het contract vragen.

Een slechte onderbouwing verwijst naar een oordeel. “Niet relevant voor onze organisatie” of “risico is laag” zegt niets wat te controleren valt, en roept dus juist vragen op.

Let er ook op dat de onderbouwing bij de maatregel past. Een uitsluiting van fysieke maatregelen omdat u geen serverruimte heeft, is prima. Diezelfde uitsluiting bij een maatregel over toegang tot uw kantoor is dat niet, want dat kantoor heeft u wel.

Hoe u hem actueel houdt zonder er werk van te maken

De meest voorkomende bevinding is niet een fout in de verklaring maar een verklaring die is blijven stilstaan. Drie gewoontes voorkomen dat.

De eerste is hem koppelen aan uw risicobeoordeling. Wijzigt er een risico, dan loopt u in dezelfde beweging de bijbehorende maatregelen na. Dat is een handeling van vijf minuten in plaats van een aparte ronde.

De tweede is een vaste controle bij de voorbereiding van de interne audit. Loop dan alle verwijzingen door en klik ze aan. Documenten worden hernoemd en verplaatst, en dat merkt u alleen als u kijkt.

De derde is een eigenaar. Een document zonder eigenaar veroudert, hoe goed het ook is opgezet. Beleg het bij dezelfde persoon die de risicobeoordeling bewaakt, want die twee horen bij elkaar.

Veelgestelde vragen over de verklaring van toepasselijkheid

Is de verklaring van toepasselijkheid verplicht?

Ja. ISO 27001 noemt hem met zoveel woorden als verplichte gedocumenteerde informatie. Het is daarmee het enige document dat de norm expliciet bij naam verplicht stelt.

Mag ik maatregelen uitsluiten?

Zeker, en dat gebeurt bij vrijwel elke organisatie. De voorwaarde is dat u onderbouwt waarom een maatregel niet van toepassing is. Een goed onderbouwde uitsluiting is geen bevinding. Een uitsluiting zonder redenering wel.

Hoe uitgebreid moet de onderbouwing zijn?

Een of twee zinnen per maatregel is genoeg, zolang ze concreet zijn. “Niet van toepassing, wij ontwikkelen zelf geen software” is prima. “Niet relevant voor onze organisatie” is dat niet, want daar kan een auditor niets mee.

In welk formaat lever ik hem aan?

Dat schrijft de norm niet voor. Een spreadsheet is bij de meeste organisaties het handigst omdat u kunt filteren en sorteren. Zorg wel voor versiebeheer: een datum, een versienummer en wie hem heeft vastgesteld.

Hoe vaak moet hij worden bijgewerkt?

Bij elke wijziging in uw risico’s of maatregelen, en verder minimaal een keer per jaar samen met de rest van uw jaarcyclus. Een verklaring die een jaar stilstond terwijl de organisatie veranderde, valt bij de controleaudit direct op.