Op veel bedrijfslocaties werken meerdere technische leveranciers naast elkaar: een IT-partner, een netwerkleverancier, een beveiligingsinstallateur, een partij voor gebouwtechniek en een telecomaanbieder. Dat werkt prima, zolang iemand de raakvlakken bewaakt. Het gaat vaak mis bij overdrachten, wijzigingen en storingen die meerdere domeinen raken. Elke partij controleert dan haar eigen deel, en het probleem blijft tussen de partijen in liggen.

Hieronder lees je waarom een verdeling over specialisten kan werken, waar het knelpunt meestal zit en hoe je regie organiseert zonder alles bij één partij onder te brengen. Daarvoor heb je een risico-eigenaar nodig, een afhankelijkhedenkaart, duidelijke contractafspraken en een vaste route voor wijzigingen. Ook lees je wat de Cyberbeveiligingswet hierover van je vraagt.

Specialisten zijn niet het probleem

Een netwerkspecialist weet meer van switches en wifi dan een beveiligingsinstallateur, en andersom. Logisch dus dat je per domein een partij kiest die er echt verstand van heeft. Vaak is die verdeling ook zo gegroeid: de beveiliger zit er al jaren, de IT-partner kwam later en de netwerkleverancier kwam mee met een verbouwing.

Zolang elke partij binnen haar eigen grenzen blijft, gaat dat goed. Lastig wordt het zodra systemen van elkaar afhangen. En dat gebeurt steeds vaker, nu camera's, toegangscontrole en gebouwtechniek over hetzelfde netwerk lopen als de werkplekken. Hoe zo'n keten eruitziet, lees je in het artikel over camera's als IT-systeem.

Waar overdrachten misgaan

Problemen tussen leveranciers ontstaan meestal op een van deze momenten:

  • Bij oplevering. Elke partij test haar eigen onderdeel, maar niemand test de keten als geheel.
  • Bij een wijziging. Een leverancier past iets aan binnen het eigen domein en weet niet dat een ander systeem ervan afhangt.
  • Bij een storing. Elke partij controleert het eigen deel, ziet dat het werkt en wijst naar de volgende.

Steeds ontbreekt hetzelfde: een gedeeld beeld van de afhankelijkheden en iemand die over de grenzen heen mag besluiten. Hoe je die afhankelijkheden in het netwerk afbakent, lees je in netwerksegmentatie voor camera's en IoT.

Praktijkinzicht: de storing die van niemand was

Een illustratief scenario: op een kantoorlocatie werkt de intercom bij de hoofdingang ineens niet meer. Bezoekers kunnen niet aanbellen, en de receptie merkt het pas als iemand belt.

De beveiligingsinstallateur ziet dat de intercom stroom heeft en geen fout geeft. De netwerkleverancier ziet een werkende poort. De IT-partner wijst erop dat het telefonieplatform is gemigreerd, maar dat de intercom niet in het overzicht stond. De telecomaanbieder heeft geen storing.

Uiteindelijk zoekt de facilitair manager het zelf uit, met vier partijen aan de lijn. Achteraf was de oplossing eenvoudig. De intercom hing af van het telefonieplatform, en die afhankelijkheid stond nergens beschreven. Met een afhankelijkhedenkaart en een vaste eerste aanspreekpartner voor de toegangsketen was de migratie vooraf afgestemd.

Het risico blijft bij jou

Het NCSC is daar duidelijk over. Onder het motto jouw probleem, jouw risico beschrijft het dat een organisatie verantwoordelijk blijft voor haar eigen risico's, ook als het bij een leverancier misgaat. Juridisch kan de aansprakelijkheid elders liggen, maar een incident raakt in de praktijk toch je eigen bedrijfsvoering.

Het NCSC adviseert daarom om per leveranciersrelatie een risico-eigenaar aan te wijzen: de functie die het meeste baat heeft bij het product of de dienst. Met een RACI-model leg je vast wie verantwoordelijk is, wie beslist, wie je raadpleegt en wie je informeert.

Valt je organisatie onder de Cyberbeveiligingswet, dan is dit sinds 15 augustus 2026 geen vrije keuze meer. De zorgplicht in artikel 21 omvat de beveiliging van de toeleveringsketen, inclusief je relaties met rechtstreekse leveranciers en dienstverleners. Een risico-eigenaar per leverancier en een overzicht van de raakvlakken helpen je om dat aantoonbaar te maken. Of de wet voor jouw organisatie geldt, lees je bij de Rijksoverheid.

Regie voeren betekent dat je weet wie wat doet en wie beslist als iets tussen twee partijen in valt. Het werk zelf hoef je niet te doen.

Die rol kun je intern beleggen, bij een facilitair of IT-manager, of laten ondersteunen door een partij die de disciplines overziet. Zorg in elk geval dat de rol bestaat en mandaat heeft.

Regie organiseren zonder te centraliseren

Je hoeft niet terug naar één leverancier om de raakvlakken onder controle te krijgen. Met een paar bouwstenen kom je al een heel eind.

Een afhankelijkhedenkaart. Breng per locatie in kaart welke systemen er zijn, welke leverancier ze beheert en waarvan ze afhangen. Bij de voorbereiding op ketenbeveiliging noemt het NCSC als eerste stap dat je processen, applicaties en datastromen in kaart brengt en onder meer inkoop, IT en de operatie erbij betrekt.

Heldere contractafspraken. In Afspraken maken met een IT-leverancier somt het NCSC op wat je vastlegt: welke diensten en apparatuur de leverancier levert en welke onderdelen je zelf beheert, wie onderhoud uitvoert, hoe incidenten gemeld worden, welke beschikbaarheid geldt en hoe een exit verloopt. Leg je die afspraken van alle leveranciers naast elkaar, dan zie je snel waar gaten of overlap zitten.

Een vaste route voor wijzigingen. Spreek af dat wijzigingen die een ander domein kunnen raken vooraf gedeeld worden. Een zwaar proces is niet nodig: een kort gezamenlijk overleg of een gedeelde wijzigingskalender werkt vaak al.

Eén escalatieroute per keten. Bepaal per keten, bijvoorbeeld camerabeelden of toegang tot het pand, wie als eerste aanspreekpunt optreedt en wie de andere partijen erbij haalt.

Binnen All Data Secure helpt Jeito met strategische IT-regie. Jeito brengt je IT-landschap en de afhankelijkheden tussen systemen en leveranciers in kaart, werkt keuzes uit in een architectuur en roadmap en kan ook de technische uitvoering oppakken. Welke andere specialisten meedoen, hangt af van je locatie en je vraag.

Veelgestelde vragen

Wat is technische regie op een bedrijfslocatie?

Bij technische regie bewaakt iemand de samenhang tussen systemen en leveranciers. Die persoon houdt overzicht over de afhankelijkheden, zorgt voor afstemming bij wijzigingen en bewaakt de route bij storingen die meerdere domeinen raken.

Wat leg je vast in afspraken met een technische leverancier?

Denk aan welke diensten en apparatuur de leverancier levert, wat je zelf beheert en wie onderhoud uitvoert. Leg ook vast hoe incidenten gemeld en opgelost worden, welke beschikbaarheid geldt en hoe een overstap naar een andere partij verloopt.

Wie is risico-eigenaar bij een uitbestede technische dienst?

Volgens het NCSC is dat de functie die het meeste baat heeft bij het product of de dienst. Die persoon blijft aanspreekbaar op het risico, ook als een leverancier het werk uitvoert.

Helpt een RACI-model als je met meerdere leveranciers werkt?

Ja. Met een RACI-model leg je per taak vast wie uitvoert, wie beslist, wie je raadpleegt en wie je informeert. Zo zie je vooral de grijze zones tussen leveranciers.

Hoe vaak werk je een afhankelijkhedenkaart bij?

Werk de kaart bij na elke wijziging die een ander domein raakt en bij elke wissel van leverancier. Loop hem daarnaast minstens eens per jaar met alle partijen door. Een kaart die een jaar oud is, mist vaak juist de koppelingen die later zijn toegevoegd.

Wat doe je als een leverancier de configuratie niet wil delen?

Leg in het contract vast welke documentatie de leverancier oplevert, zoals instellingen, koppelingen en beheeraccounts, en dat jij daarover beschikt. Loopt er al een contract zonder die afspraak, neem het punt dan mee bij de eerstvolgende verlenging. Zonder die gegevens kun je een storing of een overstap niet zelf overzien.

Bronnen

Deel dit artikel

Bespreek je vraagstukMeer in de kennisbank