Leestijd
11 minuten
22 juli 2026
Bewerkt: 22 juli 2026

Rolbeschrijving: Security Officer Energy Hub

Kennisbankartikel

Een energiehub brengt ondernemers, techniek en energievoorziening bij elkaar. Dat biedt kansen, maar maakt deelnemers ook afhankelijk van gezamenlijke systemen, leveranciers en afspraken. Daarom is het belangrijk dat iemand het overzicht houdt over veiligheid, continuïteit en cybersecurity.

In dit kennisbankartikel lees je wat de rol van Security Officer binnen een energiehub inhoudt. Je ontdekt waarom deze rol nodig is, welke verantwoordelijkheden erbij horen en hoe je de rol binnen een energiecoöperatie of samenwerkingsverband kunt beleggen. De Security Officer hoeft daarbij geen technisch cybersecurity-expert te zijn. Het gaat er vooral om dat één persoon het onderwerp bewaakt, de juiste vragen stelt en zorgt dat risico’s niet tussen organisaties en leveranciers in blijven liggen.

Waarom?

Waarom deze rol?

Een energiehub is een gedeeld energiesysteem op een bedrijventerrein. Meerdere ondernemers delen via een gezamenlijke aansluiting capaciteit, opslag en opwek, vaak aangestuurd door een energiemanagementsysteem (EMS) van een externe leverancier. Daarmee ontstaat een gemeenschappelijk technisch én cyberrisico: één kwetsbaarheid kan de beschikbaarheid van energie voor alle deelnemers raken.

In de praktijk blijkt dat veiligheid, continuïteit en cybersecurity binnen energie-coöperaties vaak "tussen wal en schip" vallen. Niemand is expliciet aangewezen als verantwoordelijke, iedereen denkt dat de leverancier het wel regelt, en de basis op het gebied van toegang, back-ups en incidentafhandeling blijft onbesproken. Dit document maakt die verantwoordelijkheid expliciet door één rol te benoemen: de Security Officer.

Uitgangspunt: Een energiehub zonder een Security Officer neemt veiligheid, continuïteit en cybersecurity niet serieus. Wie de rol invult is secundair aan het feit dát het belegd is. Beleg de rol vóórdat de energiehub operationeel wordt.

Positionering

Positionering van de rol

De Security Officer (SO) van een energiehub is een rol, geen functie en geen bestuurspositie. Het is een afgebakende verantwoordelijkheid die moet liggen bij een aanwijsbare persoon. Wie die persoon is, is minder belangrijk dan dat de rol daadwerkelijk wordt ingevuld en de verantwoordelijkheid voor veiligheid, continuïteit en cybersecurity ondubbelzinnig bij één iemand ligt.

De SO hoeft geen cybersecurity-expert te zijn. Wel is de SO eindverantwoordelijk voor het bewaken van het onderwerp, het uitvragen van leveranciers en het organiseren van externe expertise wanneer dat nodig is.

Wie?

Wie kan de rol invullen?

De rol kan op verschillende manieren ingevuld worden. Er is geen voorkeursvariant. Kies wat past bij de schaal en de samenstelling van de hub:

  • Een bestuurslid van het collectief (de coöperatie of vereniging). Praktisch bij kleinere hubs; het onderwerp ligt daarmee automatisch op de bestuurstafel.
  • Een ander lid van het collectief of een deelnemende onderneming. Hoeft geen bestuurder te zijn, maar heeft wel mandaat van het bestuur en rapporteert rechtstreeks aan het bestuur.
  • Een aparte functionaris of medewerker. Bijvoorbeeld een operationeel manager van de hub, een security officer van een van de aangesloten ondernemingen, of iemand die de rol naast een andere taak vervult.
  • Een externe Security Officer-as-a-Service. Bij grotere of complexere hubs, of wanneer er intern geen kandidaat is. Belangrijk is één vast intern aanspreekpunt voor het bestuur.

In alle gevallen geldt: benoem de rol in een formeel besluit, en zorg dat de naam en contactgegevens van de SO bekend zijn bij het bestuur, deelnemers en leveranciers, en dat er een vervanger is aangewezen voor afwezigheid en bij vertrek.

Wat de rol níet is

Wat de rol uitdrukkelijk niet is

De security officer is geen:

  • vervanging van de cybersecurity-verantwoordelijkheid van de EMS-leverancier, de netbeheerder of de aangesloten ondernemingen voor hun eigen systemen.
  • technische beheerder. De SO laat techniek uitvoeren door de leverancier of een ingehuurde partij.
  • incident response team. Wel: degene die zorgt dat er een incident response procedure bestaat en geoefend wordt.
  • formele bestuursfunctie. De rol kan door een bestuurder worden vervuld, maar dat is geen voorwaarde.
Verantwoordelijkheden

Verantwoordelijkheden

De verantwoordelijkheden zijn verdeeld over de belangrijkste risico’s van een energiehub. De Security Officer zorgt dat hierover duidelijke afspraken worden gemaakt. De technische uitwerking kan bij een specialist of leverancier liggen. 

1. Governance en ownership

  • Aanspreekpunt: is voor het bestuur, deelnemers en leveranciers het vaste aanspreekpunt voor alles wat met veiligheid, continuïteit en cybersecurity van de hub te maken heeft.
  • Beleid: zorgt dat de hub een (eenvoudig) cybersecuritybeleid op papier heeft, passend bij de schaal en de impact van de hub, en laat dit door het bestuur vaststellen.
  • Rapportage: rapporteert minimaal twee keer per jaar aan het bestuur over de stand van zaken, openstaande risico's en voorgestelde maatregelen.
  • Verzekering en aansprakelijkheid: houdt zicht op de cyberverzekering van de hub en op contractuele aansprakelijkheid richting leveranciers en deelnemers; adviseert het bestuur hierover.
  • Wet- en regelgeving: volgt de relevante kaders (NIS2 waar van toepassing, AVG, Network Code on Cybersecurity) en signaleert wanneer maatregelen nodig zijn.

2. Hardware en fysieke toegang

  • Asset-overzicht: zorgt dat er een actueel overzicht is van alle hardware in de hub: meetkasten, omvormers, batterijmanagementsystemen, gateways, routers, sensoren.
  • Fysieke beveiliging: zorgt dat technische ruimtes (regelkasten, batterijcontainers, communicatieapparatuur) afgesloten zijn en dat er een sleutel- of toegangsregister is.
  • Verwijdering en vervanging: ziet erop toe dat oude apparatuur veilig wordt afgevoerd, met wissen van configuratie en credentials.
  • Leveranciers op het terrein: bewaakt dat externe monteurs alleen onder begeleiding fysieke toegang krijgen tot kritieke installaties.

3. Software, EMS en OT-systemen

  • Versiebeheer: vraagt periodiek bij de EMS- of CEMS-leverancier op of alle software en firmware up-to-date is en welke patches openstaan.
  • Configuratie: zorgt dat instellingen van de EMS (regelstrategieën, schakelgrenzen, contracten met aggregators) gedocumenteerd zijn en niet ongezien gewijzigd kunnen worden.
  • Netwerksegmentatie: vraagt aan de leverancier of OT-systemen (sturing) en IT-systemen (rapportage, kantoor) logisch gescheiden zijn.
  • Veilige ontwikkeling: neemt bij selectie van een EMS-leverancier cybersecurity-eisen mee in de uitvraag (zie checklist Uitvraag Leveranciers).

4. Data, opslag en back-ups

  • Datacatalogus: weet welke data de hub verzamelt (meetdata, contracten, verbruiksprofielen van deelnemers) en waar die wordt opgeslagen.
  • Back-up: zorgt dat configuratie en bedrijfskritische data periodiek worden geback-upt, op een gescheiden locatie, en dat de restore minimaal jaarlijks wordt getest.
  • Bewaartermijnen: stelt vast hoe lang welke data bewaard wordt, in lijn met AVG en contractuele afspraken.
  • Datadeling: controleert met welke derden (aggregator, netbeheerder, energieleverancier) data wordt gedeeld en op welke juridische basis.

5. Logische toegang en identiteit

  • Toegangsregister: houdt actueel wie toegang heeft tot het EMS-portaal, de monitoringsomgeving en eventuele andere systemen, met welk rechtenniveau.
  • Multi-factor authenticatie (MFA): stelt MFA verplicht voor alle accounts met sturings- of configuratierechten — uitzonderingen alleen op schriftelijke motivatie.
  • In- en uitdiensttreding: zorgt dat bij wisseling van bestuursleden, deelnemers of leveranciers de toegang direct wordt herzien.
  • Gedeelde accounts: verbiedt het delen van inloggegevens en zorgt dat elke gebruiker een eigen account heeft.
  • Wachtwoordbeleid: stelt minimale eisen aan lengte, gebruik van 2FA, uniciteit en wachtwoordmanagers op.
  • Periodieke toegangsreview: controleert minimaal halfjaarlijks alle bestaande toegangsrechten op het principe van minimale rechten (least privilege): heeft elke gebruiker nog steeds de toegang die bij zijn rol past?

6. Beleid voor deelnemers en gedeelde infrastructuur

Bij een energiehub zijn alle deelnemers met elkaar verbonden. De hardware en software van één ondernemer kunnen daardoor invloed hebben op de hele hub. Denk aan een batterij die door het EMS wordt aangestuurd, een laadpaal op het gezamenlijke net of een opslagsysteem dat een deelnemer via een eigen portal beheert. Als zo’n systeem wordt gehackt, kan dat gevolgen hebben voor alle deelnemers. Daarom zorgt de Security Officer ook voor duidelijke veiligheidsafspraken met deelnemers. 

  • Aansluitvoorwaarden: stelt minimumeisen op voor hardware en software die deelnemers koppelen aan het gedeelde energiesysteem (firmware-updates, ondersteunde communicatieprotocollen, certificering). Deze eisen zijn onderdeel van de aansluitovereenkomst.
  • Toegang van deelnemers tot gedeelde systemen: regelt welke rol een deelnemer heeft in het EMS-portaal (alleen-lezen voor eigen data, geen rechten op gedeelde sturing) en bewaakt dat deelnemers geen toegang krijgen tot elkaars data.
  • Toegang tot opslagsystemen van deelnemers: maakt expliciet wie — de deelnemer zelf, de hub-operator, de EMS-leverancier, een aggregator — onder welke voorwaarden mag schakelen of uitlezen op een batterij of opslagsysteem dat eigendom is van een deelnemer. Legt dit vastin een Joint Controllership- of vergelijkbare overeenkomst.
  • Verantwoordelijkheid bij compromittering: stelt vooraf vast wat er gebeurt als een systeem van één deelnemer gecompromitteerd raakt: wordt het automatisch losgekoppeld van het gedeelde systeem? Wie beslist daarover? Wie informeert de andere deelnemers?
  • Onboarding en offboarding: zorgt voor een vaste procedure als een nieuwe deelnemer toetreedt(security-check op de gekoppelde systemen) en vertrekt (verwijderen van toegang, ontkoppelen van eventuele integraties).
  • Awareness richting deelnemers: informeert deelnemers periodiek over hun verantwoordelijkheden, onder andere over phishing, gedeelde inloggegevens en het melden van verdachte activiteit.

7. Communicatie en connectiviteit

  • Externe verbindingen: weet welke verbindingen er van en naar de hub lopen (cloud-koppeling EMS, aggregator, netbeheerder, monitoring) en of deze versleuteld zijn.
  • Remote access: bewaakt op afstand-toegang van leveranciers: alleen via vooraf afgesproken kanalen, met logging en MFA.

8. Awareness en training

  • Bewustwording: organiseert minimaal jaarlijks een bewustwordingsmoment voor bestuur, deelnemers en kerngebruikers, gericht op herkenbare risico's zoals phishing, ongeoorloofde toegang en social engineering.
  • Phishing-test: organiseert minimaal jaarlijks een phishingsimulatie en bespreekt de resultaten anoniem in de groep, zonder mensen aan de schandpaal te nagelen.
  • Onboarding: zorgt dat nieuwe bestuursleden, deelnemers en leveranciers bij start een korte introductie krijgen op het cybersecuritybeleid en de meldroute.
  • Lessen na incidenten: deelt de hoofdlijnen van een incident (anoniem waar nodig) met deelnemers en leveranciers, zodat de hele gemeenschap leert.

9. Incidenten en continuïteit

  • Meldingen: maakt expliciet wat als incident moet worden gemeld: niet alleen bevestigde aanvallen, maar ook vermoedens van ongeoorloofde toegang, verlies van apparatuur, onverwachte schakelacties van de EMS, phishing-pogingen en verdachte e-mails.
  • Meldroute: richt één duidelijke meldroute in (één e-mailadres of telefoonnummer) en zorgt dat dit kanaal bekend is bij alle bestuursleden, deelnemers, leveranciers en operators. De SO is eerste ontvanger, met een vaste vervanger.
  • Reactietijden: definieert hoe snel een melding wordt opgepakt (bijvoorbeeld: binnen 4 uur tijdens kantooruren, binnen 24 uur daarbuiten) en welke meldingen direct doorbellen rechtvaardigen.
  • Incident response plan: bewaakt het bestaan van een eenvoudig plan: wie wordt gebeld, wat wordt afgekoppeld, hoe wordt teruggevallen op handmatige sturing, wie informeert de deelnemers.
  • Externe meldplichten: kent de meldplichten richting toezichthouders (waar NIS2 van toepassing is: 24 uur voor early warning, 72 uur voor incidentmelding, 1 maand voor eindrapport) en richting deelnemers; weet wie de melding doet en wanneer.
  • Oefenen: organiseert minimaal jaarlijks een tabletop-oefening met bestuur, leverancier en bij voorkeur een aantal deelnemers.
  • Logging en bewijsmateriaal: zorgt dat de leverancier voldoende logs bewaart om een incident achteraf te kunnen onderzoeken (minimaal 6 maanden, afhankelijk van wettelijke eisen).
  • Lessons learned: evalueert na elk incident en na elke oefening; vertaalt bevindingen naar concrete aanpassingen van beleid, techniek of training.

10. Leveranciers en keten

  • Uitvraag: neemt cybersecurity-eisen mee in elke uitvraag voor EMS, CEMS, aggregator, installateur en onderhoud.
  • Contracten: bewaakt dat in leverancierscontracten afspraken staan over meldplicht bij incidenten, kwetsbaarheidsbeheer en exit (wat gebeurt er met data en toegang bij beëindiging).
  • Classificatie: deelt leveranciers in naar impact (een EMS-leverancier heeft meer impact dan een installateur van zonnepanelen); zwaardere eisen voor leveranciers met grotere impact.
  • Periodieke review: vraagt jaarlijks bij hoofdleveranciers een rapportage op over hun eigen security (bv. ISO 27001, SOC 2, NIS2-status, pentest-resultaten op hoofdlijnen).
  • Onderaannemers: vraagt actief uit welke onderaannemers de leverancier inzet (vierde-partijrisico) en welke afspraken daar gelden.

11. Risicobeheer, toetsing en continue verbetering

Dit is een belangrijk onderdeel van de rol, als het gaat om ISO 27001. Het gaat niet om beleid dat je één keer maakt en daarna weglegt. De Security Officer zorgt voor een vaste cyclus: plannen maken, uitvoeren, controleren en verbeteren (Plan-Do-Check-Act). Voor een energiehub hoeft dat niet ingewikkeld te zijn, zolang het maar regelmatig gebeurt. 

  • Risicoregister: houdt een eenvoudig overzicht bij van de belangrijkste risico's voor de hub, met per risico een inschatting van kans en impact, een eigenaar en de gekozen aanpak (accepteren, mitigeren, verzekeren, vermijden). Het register hoeft niet meer dan één pagina te zijn.
  • Risicobeoordeling: actualiseert het register minimaal jaarlijks en altijd na een significante wijziging (nieuwe deelnemer, nieuwe leverancier, nieuwe wet, na een incident).
  • Toetsing van het beleid: toetst het cybersecuritybeleid en de bijbehorende procedures minimaal jaarlijks aan de praktijk: werken ze nog, worden ze opgevolgd, zijn er nieuwe risico's die niet gedekt worden?
  • Audits en controles: voert minimaal jaarlijks een interne controle uit op de belangrijkste maatregelen (toegangsrechten, back-up restore, MFA-dekking, logging). Voor grotere hubs: overweeg een externe audit elke 2 tot 3 jaar.
  • Verbeterpunten: stelt verbeterpunten op uit drie bronnen: (1) bevindingen uit de jaarlijkse toetsing, (2) lessons learned uit incidenten en oefeningen, (3) externe signalen zoals nieuwe wetgeving of dreigingsbeelden. Verbeterpunten krijgen een eigenaar, een termijn en een prioriteit.
  • Voortgang bewaken: houdt een eenvoudige verbeterlijst bij en bespreekt de voortgang in elke halfjaarlijkse rapportage aan het bestuur.
  • Documentatiebeheer: zorgt dat beleidsstukken, procedures, registers en rapportages versiebeheerd zijn (versienummer, datum, auteur) en op één centrale plek vindbaar zijn.
Organisatie