Lange tijd werd Operational Technology (OT) gewoon met rust gelaten. Een PLC deed zijn werk, een SCADA-systeem draaide al tien jaar zonder patch, en niemand van IT kwam in de buurt — laat staan een service management platform dat IT-assets beheert. OT en IT leefden in strikt gescheiden werelden, met een letterlijke muur (en vaak een letterlijke luchtspleet of air-gap) ertussen.

Die tijd is voorbij. En dat is precies waarom OTSM — Operational Technology Service Management — de afgelopen jaren van een curiositeit naar een absolute noodzaak is verschoven voor organisaties met kritieke infrastructuur. Bovendien wordt dit specialisme nu ook meer en meer ondersteund door platforms, zoals ServiceNow, die van oudsher voor IT-management worden ingezet.

Waarom nu ineens?

In de markt komen drie belangrijke ontwikkelingen samen die elkaar versterken:

• Het cyberaanvalsoppervlak groeit: OT-omgevingen zijn niet langer eilanden. Sensoren met SIM-connectiviteit praten met de cloud, onderhoudspartijen loggen op afstand in, en operationele data stroomt richting dashboards die business managers op hun ipad bekijken. Elke verbinding is functioneel waardevol — en elke verbinding is ook een deur die kwaadwillenden proberen te openen. Metingen laten zien dat het aantal aanvallen drastisch blijft toenemen. Het platleggen van kritieke infrastructuur en processen (zoals onze stroomvoorziening, dijkbewaking of betaalsystemen) is immers een aantrekkelijk doelwit. Het creëert chaos en erger…
• De wetgever kijkt mee vanuit de EU: Met de komst van de NIS2-richtlijn, de Nederlandse vertaling daarvan in de Cyberbeveiligingswet (Cbw), en de complementaire Wet weerbaarheid kritieke entiteiten (Wwke), is cybersecurity in de kritieke infrastructuur geen ‘nice to have’ meer. Het is een wettelijke verplichting waarbij de directie persoonlijk aansprakelijk kan worden gehouden. Incidentregistratie, asset-inzicht en risicobeheer: je moet het aantoonbaar kunnen laten zien, niet alleen beweren.
• De business verwacht dezelfde volwassenheid van OT als van IT: Storingen moeten sneller worden opgelost, wijzigingen beter worden beheerst en assets overzichtelijk in kaart worden gebracht. Dit is precies de discipline die ITSM de afgelopen twintig jaar in de IT-wereld heeft gebracht.

Het gevolg? Organisaties die kritieke infrastructuur en processen beheren — zoals energienetten, gasopslag, havens, luchthavens en industriële productie — kunnen niet meer om een gestructureerde en herziene aanpak van OT-servicemanagement heen.

De valkuil: OTSM als kopie van ITSM

Een veelgemaakte fout in de praktijk is OTSM behandelen als ‘ITSM, maar dan met een andere tabel en wat aangepaste labels’. Dat werkt niet echt, en wel om een fundamentele reden: de risico’s en kaders zijn totaal anders.

In de IT-wereld is een patch die faalt erg vervelend. In de OT-wereld kan een verkeerd getimede wijziging aan een besturingssysteem een complete productielijn stilleggen, of erger nog: een levensbedreigend veiligheidsrisico creëren. Beschikbaarheid en fysieke veiligheid (Safety) wegen in OT vele malen zwaarder dan vertrouwelijkheid (Confidentiality), terwijl dat in de klassieke IT vaak omgekeerd is. Dit is geen theoretische discussie; het staat letterlijk verankerd in standaarden zoals ISA-95 en IEC 62443, die de laag-voor-laag scheiding tussen bedrijfsvoering en procesbesturing beschrijven. En die scheiding is er niet voor niets.

Dus nee, je plakt niet simpelweg een OTSM-module op je bestaande ITSM-inrichting om het af te vinken. Je ontwerpt m.i. beter een architectuur die de eigenheid van OT respecteert én de volwassenheid van ITSM benut waar dat zinvol is en waarde toevoegt.

De strategie: gericht integreren, niet klakkeloos kopiëren

Als architect ben ik een voorstander van een gerichte integratie van ITSM- en OTSM-elementen — iets wat ik in de praktijk ook actief bouw en test in mijn R&D lab. Niet omdat het technisch kan, maar omdat het concrete businesswaarde oplevert:

Strategisch element	Inrichting in de praktijk
Eén CMDB-taal, twee snelheden	Een centrale, betrouwbare CMDB die zowel IT- als OT-assets in samenhang toont, geeft voor het eerst echt inzicht in de afhankelijkheden tussen (kantoor) IT-systemen en procesinstallaties. Tegelijkertijd moet je de discovery, wijzigingsfrequentie en autorisatie voor OT-assets fundamenteel anders inrichten dan voor IT. Een asset in een procesomgeving verander je niet ‘even snel’ omdat een vulnerability-scan dat aanraadt.
Contextbewuste incident- en changeprocessen	Een storingsmelding vanuit de fabriekshal mag m.i. nooit in dezelfde wachtrij belanden als een IT wachtwoord-reset. Prioritering, escalatiepaden en autorisatiematrices verdienen een OT-specifieke inrichting, ook al draaien ze op hetzelfde onderliggende ServiceNow-platform.
Eén rapportagelaag voor compliance	Voor NIS2- en Cbw-rapportages is het enorm waardevol als je vanuit één centrale omgeving kunt aantonen welke assets kritiek zijn, welke incidenten daarop van invloed waren en welke mitigerende maatregelen zijn genomen — in plaats van dit na een auditverzoek handmatig uit losse silo’s te moeten reconstrueren.

En dan die air-gap…

Hier wringt in de praktijk vaak de schoen. Veel OT-omgevingen zijn — terecht — air-gapped of ten minste sterk gesegmenteerd. Er is geen directe lijn naar de cloud en je kunt niet ‘even een (discovery) agent installeren’. Dit is geen ongemakkelijk obstakel dat je moet omzeilen; het is een bewuste veiligheidsmaatregel en een harde randvoorwaarde die je moet respecteren. Binnen de context van ServiceNow zijn de volgende punten daarbij cruciaal:

Een MID Server is geen data-diode: Een ServiceNow MID Server zorgt voor een logisch gescheiden, uitgaande verbinding (HTTPS via poort 443). Dat is niet hetzelfde als een fysieke, unidirectionele verbinding. Als je dat verwart, creëer je al snel schijnveiligheid. Voor echt kritieke netwerksegmenten hoort een fysieke data-diode thuis in de architectuur, niet enkel een slim geconfigureerde MID Server.

Discovery is geen vanzelfsprekendheid: Actieve IP-scanning in een procesomgeving kan letterlijk een PLC laten haperen. Oudere PLC’s en specifieke industriële protocollen kunnen vaak niet omgaan met netwerkverzoeken waarvoor ze nooit zijn ontworpen. Passieve netwerkdetectie (bijvoorbeeld via OT-securitytools die feeds aanleveren aan ServiceNow) is in veel gevallen de enige verantwoorde weg om asset-inzicht op te bouwen zonder het operationele proces te verstoren.

Digitale soevereiniteit is bittere ernst: Waar draait je OTSM-platform en onder welk rechtsgebied vallen de OT-topologiegegevens die je erin opslaat? Voor organisaties met een vitale rol is dit geen abstracte discussie. De Amerikaanse CLOUD Act kan in potentie reikwijdte hebben over data die feitelijk in Europa staat, simpelweg omdat de softwareleverancier een Amerikaanse moederorganisatie heeft. Dit vraagt om bewuste keuzes en risicoacceptatie: denk aan encryptie van gevoelige data (ie. GPS-locatie data van OT assets) waarbij je zelf de sleutels beheert (Customer Managed Keys), het selectief bepalen welke gevoelige attributen je wél en niet centraal opslaat, en heldere contractuele garanties. Geen paniekvoetbal, wel een volwassen risicodialoog voordat je live gaat. En uiteraard: een uitgewerkt Plan B.

Waarom ik hier zo voor pleit

Ik werk inmiddels ruim zestien jaar met ServiceNow aan opdrachten bij grote, complexe organisaties. Wat mij het meest is bijgebleven, zijn de projecten waar IT en OT elkaar raakten: het assetmanagement rondom een grootschalige gasopslag, vergaande robotisering in de logistiek en de monitoring van kritieke processen op een luchthaven. Op die plekken leer je snel dat een architectuurkeuze die in een kantooromgeving vanzelfsprekend is, in een procesomgeving desastreuze gevolgen kan hebben.

Die ervaring is ook de reden waarom ik niet passief afwacht tot een klant met een kant-en-klare vraag komt. In mijn eigen labomgeving bouw en test ik werkende simulaties — van een gecontroleerde migratiepijplijn en een gecombineerd IT/OT-CMDB-model tot integratiepatronen met systemen als IBM Maximo en Keycloak. Ik wil vooraf ervaren wat wel en niet werkt, in plaats van daar pas tijdens een live implementatie achter te komen. Zo kun je een architectuurkeuze onderbouwen met een werkend bewijs, niet alleen met een mooie PowerPoint-slide of architectuur plaatje.

Kortom

OTSM is geen hype en absoluut geen kopie van ITSM. Het is een serieus en zelfstandig vakgebied dat vraagt om begrip en respect voor de wetten van de operationele techniek, gecombineerd met de procesdiscipline die IT-servicemanagement te bieden heeft. En dat alles strak binnen de kaders van gesegmenteerde netwerken, NIS2-verplichtingen en Europese digitale soevereiniteit.

Door die werelden gericht samen te brengen, bouwen we niet alleen een mooier CMDB-plaatje. We leggen het fundament waarmee een organisatie daadwerkelijk kan aantonen dat zij haar kritieke infrastructuur en processen van a tot z in de hand heeft.

Disclaimer: Dit artikel is uitsluitend bedoeld voor informatieve en educatieve doeleinden. De gedeelde inzichten en architectuurprincipes weerspiegelen de persoonlijke expertise en praktijkervaring van de auteur en dienen als conceptuele richtlijnen. Omdat elke operationele technologie-omgeving (OT) unieke veiligheids- en netwerkkarakteristieken kent, is dit artikel geen vervanging voor specifiek, professioneel architectuuradvies op maat. De genoemde platformen en integraties (zoals ServiceNow en IBM Maximo) dienen ter illustratie van de besproken concepten; de auteur opereert onafhankelijk. Dit artikel is tot stand gekomen vanuit eigen OTSM onderzoek, pragmatische simulatie in mijn R&D Lab én met functionele assistentie van een AI-systeem, waarbij de technische inhoud, strategische keuzes, praktijkervaringen en eindredactie volledig toebehoren aan de auteur.

Photo by Matthew Henry on Unsplash