Kenniscentrum beveiliging: zo bouw je een interne wiki

Een inbraakmelding om 02:13 uur, een nieuwe collega die “even” het alarmsysteem uitschakelt voor werkzaamheden, een verzekeraar die vraagt om opleverdossier of certificaat, of een AVG-vraag over camerabeelden. In veel organisaties zit de kennis verspreid over mailboxen, WhatsApp-groepen en het hoofd van één collega. Dat werkt, tot het misgaat.

Een kenniscentrum beveiliging in de vorm van een interne wiki zorgt voor structuur: één plek waar procedures, verantwoordelijkheden en technische basisinformatie samenkomen. Het resultaat is minder ruis, snellere opvolging bij incidenten en beter aantoonbare compliance.

Wat is een kenniscentrum beveiliging (interne wiki) precies?

Een interne beveiligingswiki is een afgeschermde kennisbank voor alles wat je organisatie nodig heeft om beveiliging consistent te beheren. Denk aan:

• Procesafspraken (alarmopvolging, sleutelbeheer, bezoekers, closing procedures)
• Technische basisinformatie (zones, gebruikersrollen, toegangsprofielen, cameraposities)
• Compliance en documentatie (AVG, bewaartermijnen, contracten, oplevering, onderhoud)
• Incidentrespons (wie doet wat, wanneer, met welke informatie)

Belangrijk: een wiki is geen vervanging van een risicoplan of beveiligingsontwerp. Het is het operationele geheugen dat je plan uitvoerbaar maakt, ook als mensen wisselen of meerdere locaties hebben.

Waarom dit juist voor B2B-organisaties veel oplevert

Voor facility- en securitymanagers gaat het zelden om “meer techniek”, maar om grip. Een goed kenniscentrum helpt bij de meest voorkomende pijnpunten:

• Minder afhankelijkheid van fysieke checks: je legt vast wat je controleert, wanneer en waarom.
• Snellere incidentrespons: direct het juiste draaiboek, de juiste contactketen en de juiste locaties.
• Minder valse alarmen en miscommunicatie: eenduidige definities van zones, symbolen en acties.
• Beter schaalbaar: één standaard, per locatie een aanvulling.
• Aantoonbaarheid richting directie, auditors en verzekeraar: onderhoud, opvolging en verantwoordelijkheden zijn vastgelegd.

Wie al eens een alarmopvolging moest organiseren met verouderde telefoonlijsten, herkent de waarde. In dat kader is het ook nuttig om je opvolgingsproces scherp te hebben, zie bijvoorbeeld: Alarmopvolging bij bedrijven: wie belt, wie rijdt uit?

Begin bij het doel, niet bij de tool

De meest gemaakte fout is starten met “welke wiki-software nemen we?”. Start liever met drie vragen:

1. Welke beslissingen moeten mensen nemen tijdens een incident? (bijvoorbeeld bij een inbraakmelding, brandmelding, sabotage, stroomuitval)
2. Welke handelingen moeten foutloos kunnen, ook door vervanging of buiten kantoortijd?
3. Wat moet je kunnen aantonen? (AVG, onderhoud, instructie, bevoegd beheer)

Pas daarna kies je een platform. Voor veel organisaties is een bestaande omgeving (bijvoorbeeld SharePoint/Teams of Confluence) al voldoende, zolang je rechten en versiebeheer goed inricht.

De minimale structuur: 6 onderdelen die altijd werken

Als je klein wilt starten, houd het simpel. Deze zes rubrieken leveren meestal direct waarde:

1) Rollen, verantwoordelijkheden en contactketen

Leg vast wie eigenaar is van beveiliging, wie keyholders zijn en wie beslissingsbevoegd is.

Praktische inhoud:

• Rollen (Security Manager, Facility, BHV, IT, locatieverantwoordelijke, receptie)
• Keyholderlijst inclusief back-up en bereikbaarheidsregels
• Escalatiepaden (meldkamer, mobiele surveillance, interne piketdienst)
• “Wie mag wat” (bijvoorbeeld: wie mag zones bypassen, wie mag gebruikers aanmaken)

2) Incident playbooks (draaiboeken)

Maak korte, uitvoerbare pagina’s die je onder stress kunt gebruiken. Eén playbook per scenario.

Voorbeelden:

• Inbraakmelding buiten openingstijden
• Sabotage- of storingsmelding
• Brandmelding (met link naar BHV-proces)
• Verdachte situatie op cameratoezicht
• Sleutel kwijt of tag verloren

Tip: sluit aan op je totale beveiligingsaanpak. Een goede basis hiervoor vind je in Inbraak beveiliging voor bedrijven: van risicoanalyse tot opvolging.

3) Systeemoverzicht per locatie (wat hangt waar?)

Dit is je “kaart” van de omgeving. Niet te technisch, wel precies genoeg om fouten te voorkomen.

Inhoud die vaak mist in organisaties:

• Plattegrond of zonestructuur (zone-namen die overeenkomen met meldingen)
• Overzicht van deuren en toegangen (hoofdtoegang, roldeur, nooddeuren)
• Camera-overzicht (posities, doelen, wie kijkt mee, wie exporteert beelden)
• Kritieke assets (serverruimte, magazijn met high-value, medicijnopslag)

4) Bevoegd beheer en wijzigingsprocedure

Veel gedoe ontstaat door ad hoc wijzigingen. Leg een mini change-proces vast:

• Hoe vraag je wijzigingen aan (nieuwe gebruiker, nieuwe tag, aanpassing camera)
• Wie keurt goed
• Hoe documenteer je de wijziging (datum, reden, impact)
• Hoe test je na wijziging

Dit sluit aan op het veilig uitvoeren van werkzaamheden. Zie ook: Alarmsysteem uitschakelen: veilig stappenplan voor beheer.

5) Compliance, beleid en “bewijslast”

Hier bundel je wat je moet kunnen laten zien.

Denk aan:

• Camerabeleid (doel, grondslag, bewaartermijn, inzageverzoeken)
• Verwerkersafspraken en interne procedures rondom beeldmateriaal
• Onderhouds- en testlogboeken
• Opleverdossiers, certificaten, inspectierapporten

Voor cameratoezicht is de lijn van de toezichthouder leidend. Gebruik als startpunt de informatie van de Autoriteit Persoonsgegevens over cameratoezicht.

Voor praktische uitleg in begrijpelijke taal kun je intern linken naar: Regelgeving camerabewaking, AVG, privacy en openbare weg.

6) Onderhoud, storingen en leveranciers

Een wiki voorkomt dat onderhoud “tussen wal en schip” valt.

Leg vast:

• Onderhoudsfrequentie en afspraken (wie belt wie, responstijden, storingsnummers)
• Waar storingen geregistreerd worden en hoe je herhaling analyseert
• Leverancierslijst met scope (wat beheren zij wel en niet)

Wil je leveranciers objectiever vergelijken of herselecteren, gebruik dan een vaste aanpak zoals in Be Secure beveiliging: checklist voor leverancierselectie.

Governance: zo voorkom je dat de wiki veroudert

Een kenniscentrum is alleen nuttig als het actueel is. Dat vraagt lichte governance, geen bureaucratie.

Werk met drie rollen

• Owner (inhoudseigenaar): meestal Security of Facility, verantwoordelijk voor actualiteit.
• Contributors (inhoudsleveranciers): BHV, IT, receptie, operations, externe partner.
• Approver (goedkeuring): iemand die wijzigingen fiatteert bij kritieke procedures.

Stel reviewmomenten in

Kies vaste momenten, bijvoorbeeld:

• Kwartaalreview voor contactlijsten, keyholders, leveranciers
• Halfjaarlijks voor incident playbooks
• Jaarlijks voor camerabeleid, bewaartermijnen en trainingen

Houd versiebeheer en audit trail simpel

Zorg dat je altijd kunt terugzien:

• Wat is gewijzigd
• Door wie
• Wanneer
• Waarom

Dat helpt ook bij gesprekken met verzekeraar, auditor of directie.

Templates die je direct kunt kopiëren (praktisch en kort)

Onderstaande opzet werkt goed omdat hij mensen dwingt om concreet te zijn.

Template 1: Incident playbook (één pagina)

• Doel en scope (wanneer gebruik je dit?)
• Eerste 3 acties (wat binnen 2 minuten?)
• Verificatie (wat check je, wat is “voldoende”?)
• Contactketen en escalatie
• Veiligheidsregels voor medewerkers
• Registratie (waar log je dit, welke velden?)
• Herstel en nazorg (reset, reparatie, lessons learned)

Template 2: Locatiepagina

• Adres, openingstijden, risicomomenten
• Plattegrond/zonekaart
• Kritieke toegangen en assets
• Camera-overzicht en exportprocedure
• Keyholderlijst locatie-specifiek
• “Bekende zwakke plekken” en mitigerende maatregelen

Template 3: Wijzigingsverzoek (change)

• Aanvraagdatum en aanvrager
• Wat verandert er, en waarom?
• Impact (veiligheid, privacy, bedrijfscontinuïteit)
• Goedkeuring door
• Uitgevoerd door
• Testresultaat en datum

Zorg dat je wiki aansluit op de praktijk van je systemen

In veel omgevingen werken alarm, camera en toegangscontrole naast elkaar. Je wiki is de plek waar je de samenhang beschrijft, bijvoorbeeld:

• Welke camera’s gebruik je voor verificatie bij alarmmeldingen
• Welke deuren worden automatisch geblokkeerd bij een incident
• Welke zones horen bij welke afdelingen en sleutelhouders

Ook kleine dingen maken groot verschil, zoals eenduidige benamingen. Als een monteur “Zone 12” zegt en je team kent alleen “Magazijn achter”, dan verlies je tijd.

Een nuttig intern naslagstuk is een uitleg van iconen en statusmeldingen. Je kunt daarvoor verwijzen naar: Symbolen alarminstallatie: complete uitleg per icoon.

Beveiliging van de wiki zelf (vaak vergeten)

Een beveiligingswiki bevat gevoelige informatie. Behandel het als een kritisch systeem.

Praktische maatregelen:

• Least privilege (niet iedereen hoeft alles te zien)
• Multifactor-authenticatie op de omgeving
• Geen alarmcodes, mastercodes of exacte camera-blinde hoeken in breed toegankelijke pagina’s
• Logische scheiding tussen “operationeel” (voor uitvoer) en “technisch detail” (beperkt)
• Logging van toegang en wijzigingen

Als je meerdere locaties hebt of met externe partijen werkt, is het slim om per locatie aparte rechten te gebruiken.

Welke KPI’s tonen dat je kenniscentrum werkt?

Meet niet alleen of pagina’s bestaan, maar of ze helpen bij risicoreductie en continuïteit. Deze indicatoren zijn in de praktijk bruikbaar:

KPI	Wat je meet	Waarom het relevant is
Tijd tot juiste procedure	Hoe snel iemand het juiste playbook vindt	Direct effect op incidentrespons
Aantal valse alarmen met herhaaloorzaak	Herkomst en categorie	Laat zien of instructies en instellingen kloppen
Tijd tot herstel na incident	Van melding tot “bedrijf weer normaal”	Business continuity in cijfers
Actualiteit contactketen	Percentage contactgegevens up-to-date	Minder vertraging bij escalatie
Aantal ongeautoriseerde wijzigingen	Changes zonder goedkeuring	Indicator voor risico op misconfiguratie

Implementatie-aanpak: klein beginnen, snel waarde

Een werkbare aanpak is:

Week 1-2: inventariseren

Verzamel wat je al hebt: opleverdocumenten, contactlijsten, procedures, contracten, plattegronden.

Week 3-4: bouwen van de basis

Richt de 6 rubrieken in, maak 3 incident playbooks (de meest waarschijnlijke scenario’s) en publiceer locatiepagina’s voor je top 1-2 locaties.

Daarna: uitbreiden op basis van incidenten en wijzigingen

Elke echte storing, verbouwing of incident is input om de wiki te verbeteren. Zo groeit het zonder “projectmoeheid”.

Veelgestelde vragen over kenniscentrum beveiliging: zo bouw je een interne wiki

Wat is het verschil tussen een kenniscentrum beveiliging en een beveiligingsplan? Een beveiligingsplan beschrijft doelen, risico’s en gekozen maatregelen. Het kenniscentrum (wiki) vertaalt dat naar dagelijkse uitvoering: procedures, verantwoordelijkheden, systeemoverzicht en bewijslast.

Welke informatie mag ik wel en niet in een interne beveiligingswiki zetten? Zet vooral procedures, rollen, contactketens en algemene systeeminformatie erin. Beperk gevoelige details zoals mastercodes, volledige technische configuraties en informatie die misbruik faciliteert. Werk met strikte toegangsrechten.

Hoe houd ik de wiki up-to-date zonder extra werkdruk? Koppel updates aan bestaande momenten: onderhoud, maandrapportages, changes en incident-evaluaties. Maak één eigenaar verantwoordelijk en werk met vaste reviewmomenten per rubriek.

Is een interne wiki ook nuttig als we al een meldkamer en externe beveiligingspartner hebben? Ja, juist dan. Een meldkamer of partner werkt beter als je interne afspraken helder zijn, zoals keyholders, escalatie, bevoegdheden en locatie-informatie.

Hoe helpt dit bij AVG en cameratoezicht? Door beleid, bewaartermijnen, inzageprocedures en verantwoordelijkheden centraal vast te leggen. Dat maakt het makkelijker om consistent te handelen en vragen van medewerkers of betrokkenen correct af te handelen.

Wil je dit snel goed neerzetten, zonder gedoe?

Locked Safe Holland (LSH Security) helpt organisaties met het vertalen van risico’s naar werkbare beveiliging, inclusief duidelijke procedures, opvolging en beheer. Als je wilt, kunnen we ook meedenken over de inhoudsstructuur van je kenniscentrum beveiliging, zodat die aansluit op je locaties, processen en techniek.

Neem contact op via lockedsafe.nl voor een praktische risico- en beheerscan, of om te sparren over een wiki die je team echt gebruikt.