Wat is een Statement of Applicability binnen NEN 7510?
Een Statement of Applicability (SoA) is een verplicht document binnen NEN 7510 dat beschrijft welke beveiligingsmaatregelen een organisatie toepast, waarom bepaalde maatregelen zijn opgenomen en waarom andere bewust zijn uitgesloten. Het document vormt de brug tussen de risicoanalyse en de daadwerkelijke implementatie van informatiebeveiliging in de zorg.
NEN 7510 is de Nederlandse norm voor informatiebeveiliging in de zorgsector en is gebaseerd op de internationale ISO 27001-standaard. De SoA is daarbinnen geen bijzaak, maar een kernonderdeel dat aantoont dat een organisatie bewuste, onderbouwde keuzes maakt op het gebied van beveiliging. In dit artikel beantwoorden we de meest gestelde vragen over de SoA binnen NEN 7510 compliance.
Welke maatregelen moet een Statement of Applicability bevatten?
Een SoA binnen NEN 7510 moet alle beheersmaatregelen uit Annex A van de norm bevatten, inclusief een duidelijke vermelding of elke maatregel van toepassing is of niet. Voor elke opgenomen maatregel moet de organisatie de reden voor opname vermelden, de implementatiestatus beschrijven en aangeven of de maatregel al volledig is doorgevoerd.
Concreet betekent dit dat de SoA per maatregel de volgende informatie bevat:
- Of de maatregel van toepassing is (ja of nee)
- De reden voor opname, bijvoorbeeld op basis van wettelijke eisen, contractuele verplichtingen of risicobehandeling
- De huidige implementatiestatus
- Een verwijzing naar relevante beleidsdocumenten of procedures
- Bij uitsluiting: een expliciete en gedocumenteerde onderbouwing
Het doel is transparantie. Een auditor of toezichthouder moet op basis van de SoA direct kunnen beoordelen of de organisatie haar beveiligingskeuzes serieus neemt en of die keuzes aansluiten bij de geïdentificeerde risico’s.
Waarom moeten sommige maatregelen worden uitgesloten van de SoA?
Niet elke maatregel uit Annex A is relevant voor elke organisatie. Uitsluiting is toegestaan wanneer een maatregel aantoonbaar niet van toepassing is op de context, activiteiten of risico’s van de organisatie. De uitsluitingen moeten altijd schriftelijk worden onderbouwd en mogen nooit worden gebruikt om risico’s te omzeilen.
Een kleine zorginstelling zonder eigen softwareontwikkeling kan bijvoorbeeld de maatregelen rondom veilige ontwikkelpraktijken uitsluiten, mits zij geen eigen applicaties bouwt en dit aantoonbaar is. Wat niet mag, is een maatregel uitsluiten louter omdat de implementatie lastig of kostbaar is, terwijl het bijbehorende risico wel degelijk aanwezig is.
Een goed onderbouwde uitsluiting versterkt juist de geloofwaardigheid van de SoA. Het laat zien dat de organisatie actief heeft nagedacht over de relevantie van elke maatregel, in plaats van blindelings een sjabloon te volgen.
Hoe verschilt de SoA van een risicobehandelingsplan?
Het risicobehandelingsplan (RTP) beschrijft welke risico’s zijn geïdentificeerd en welke acties worden genomen om die risico’s te behandelen. De SoA vertaalt die beslissingen naar concrete beveiligingsmaatregelen en documenteert de status en onderbouwing daarvan. De twee documenten vullen elkaar aan, maar zijn niet hetzelfde.
Een eenvoudige manier om het onderscheid te onthouden:
- Risicobehandelingsplan: “We hebben risico X geïdentificeerd en kiezen ervoor dit te mitigeren via maatregel Y.”
- Statement of Applicability: “Maatregel Y is opgenomen in onze SoA omdat het risico X behandelt, en de implementatie bevindt zich in fase Z.”
Het RTP is dus het startpunt, de SoA is het resultaat. Beide documenten moeten consistent zijn met elkaar. Als een risico in het RTP wordt behandeld via een specifieke maatregel, moet die maatregel ook in de SoA als van toepassing zijn gemarkeerd met de juiste onderbouwing.
Wie is verantwoordelijk voor het opstellen van de SoA?
De eindverantwoordelijkheid voor de SoA ligt bij de organisatie zelf, doorgaans bij de Information Security Officer (ISO) of de functionaris die verantwoordelijk is voor het informatiebeveiligingsbeleid. In de praktijk wordt de SoA vaak opgesteld door een intern team of een externe adviseur, maar de formele goedkeuring hoort bij het management.
Bij organisaties die geen fulltime beveiligingsexpert in dienst hebben, is het niet ongebruikelijk dat een externe partij de SoA opstelt of begeleidt. Dat is legitiem, zolang de organisatie zelf de inhoud begrijpt, onderschrijft en kan verantwoorden tegenover een auditor. Een SoA die puur door een externe partij is ingevuld zonder betrokkenheid van de organisatie, mist de interne verankering die noodzakelijk is voor een geloofwaardige certificering.
Voor organisaties die overwegen externe ondersteuning in te schakelen, biedt een virtuele CISO een praktische manier om deze verantwoordelijkheid professioneel te beleggen zonder een fulltime aanstelling.
Hoe vaak moet een Statement of Applicability worden herzien?
Een SoA moet minimaal jaarlijks worden herzien en ook na elke significante wijziging in de organisatie, de IT-omgeving of het dreigingslandschap. NEN 7510 vereist dat het document actueel blijft en de werkelijke situatie weerspiegelt. Een verouderde SoA is bij een audit een direct aandachtspunt.
Situaties die aanleiding geven tot een tussentijdse herziening zijn onder meer:
- Introductie van nieuwe systemen of cloudoplossingen
- Wijzigingen in wet- en regelgeving, zoals nieuwe privacyvereisten
- Beveiligingsincidenten die blootleggen dat bestaande maatregelen onvoldoende zijn
- Organisatorische veranderingen, zoals fusies of nieuwe samenwerkingsverbanden
- Uitbreiding van activiteiten naar nieuwe sectoren of markten
Een jaarlijkse herziening is het minimum, maar in dynamische omgevingen verdient een frequentere evaluatie de voorkeur. Behandel de SoA als een levend document, niet als een eenmalig project.
Wat zijn veelgemaakte fouten bij het opstellen van een SoA?
De meest voorkomende fout is het klakkeloos overnemen van een standaardsjabloon zonder de inhoud te koppelen aan de eigen risicoanalyse. Een SoA die niet aansluit op de specifieke context van de organisatie is bij een audit weinig waard, ongeacht hoe netjes het document eruitziet.
Andere veelgemaakte fouten zijn:
- Ontbrekende onderbouwing bij uitsluitingen: Maatregelen uitsluiten zonder schriftelijke motivatie is een directe afwijking van de norm.
- Verouderde implementatiestatus: De SoA beschrijft de situatie van twee jaar geleden, terwijl de werkelijkheid is veranderd.
- Inconsistentie met het risicobehandelingsplan: Risico’s die in het RTP worden behandeld, ontbreken in de SoA of omgekeerd.
- Geen eigenaarschap binnen de organisatie: Het document is extern opgesteld, maar intern niet begrepen of gedragen.
- Te generiek taalgebruik: Vage omschrijvingen als “maatregel is geïmplementeerd” zonder verdere toelichting bieden een auditor onvoldoende houvast.
Een goed opgestelde SoA is specifiek, actueel en intern verankerd. Het is een document dat de organisatie zelf kan verdedigen, niet alleen een papieren exercitie voor een certificeringsaudit.
Hoe Hofsecure helpt bij NEN 7510 compliance
Het opstellen van een correcte en auditwaardige Statement of Applicability vraagt om diepgaande kennis van de norm én van de specifieke context van uw organisatie. Wij ondersteunen organisaties in de zorg en aanverwante sectoren bij het volledige NEN 7510-traject, van risicoanalyse tot een certificeringsgereed documentatiepakket.
Wat wij concreet bieden:
- Begeleiding bij het opstellen of herzien van de SoA, afgestemd op uw organisatie
- Afstemming tussen risicobehandelingsplan en SoA zodat beide documenten consistent zijn
- Ondersteuning bij het onderbouwen van uitsluitingen op een auditwaardige manier
- Praktische begeleiding richting NEN 7510-certificering, inclusief interne audits
- Optionele doorlopende ondersteuning via onze CISO-as-a-Service voor blijvende naleving
Wij combineren defensiegraad beveiligingsexpertise met een pragmatische, zakelijke aanpak die past bij de realiteit van middelgrote organisaties. Geen onnodige complexiteit, wel solide beveiliging die werkt in de praktijk.
Wilt u weten hoe wij uw organisatie kunnen helpen met NEN 7510? Neem contact op voor een vrijblijvend gesprek.
