Auteur mr. dr. Mathieu Paapst (Bureau Forum Standaardisatie en Rijksuniversiteit Groningen) laat zien hoe je van vendor lock-in naar digitale autonomie komt, met concrete eisen en voorbeeldclausules die je in een aanbesteding kunt gebruiken.
In dit blog vatten we de kern van het boek samen, vertalen we het naar streamingdiensten, en geven we je de vragen die je bij een tender en in je eigen organisatie moet stellen.
De kernproblemen: afhankelijkheid koop je zelf in
Paapst definieert vendor lock-in scherp: overstappen is niet onmogelijk, maar de drempels zijn zo hoog dat alternatieven feitelijk buiten bereik raken. Die drempels worden elk jaar hoger, want hoe langer je een systeem gebruikt, hoe meer data, processen en kennis eraan vastgroeien. Hij onderscheidt vier soorten barrières:
- Technisch: gesloten standaarden en dataformaten, slecht gedocumenteerde of afgeschermde API's, en geïntegreerde suites waarin je geen onderdeel los kunt vervangen.
- Financieel: overstapkosten, investeringen die je niet wilt "weggooien" (sunk costs), collectieve licentiedeals en bundels waar achteraf nog AI of videobellen aan wordt toegevoegd. Opvallend: de kosten van een overstap worden bijna altijd toegerekend aan het alternatief, terwijl ze veroorzaakt worden door de zittende leverancier.
- Contractueel: je koopt geen eigendom maar een gebruiksrecht, zonder broncode, zonder exportrechten en vaak onder de algemene voorwaarden van de leverancier. Daarbij komen parallelle contracten met verschillende looptijden, stilzwijgende verlenging en ontbrekende exit-afspraken.
- Organisatorisch: gebruikers en beheerders zijn gewend aan "hun" product, de kennis zit bij de leverancier, werkprocessen zijn aangepast aan het systeem, en een langdurige relatie voelt veilig.
In cloud- en SaaS-diensten komen deze vier samen en versterken ze elkaar. Denk aan egress fees, de kosten om je eigen data weer naar buiten te halen. Uit onderzoek blijkt dat rond 2016, toen veel organisaties naar de cloud gingen, slechts 3% goed op de hoogte was van het lock-in-risico.
Maar nog belangrijker: volgens Paapst ligt de oorzaak vooral bij de inkoop zelf. Aanbestedingen draaien om "ontzorgd worden", om korte termijn en integratie bij één leverancier. Er wordt op merknaam uitgevraagd, wat aanbestedingsrechtelijk meestal niet eens mag. Eisen als open standaarden staan wel in het bestek, maar na gunning controleert vrijwel niemand of de leverancier ze naleeft. En de populaire strategie "eerst alles naar één grote leverancier, daarna weer weg" blijkt in de praktijk het eindstation.
Tot slot prikt het boek een veelgehoorde misvatting door: dat je soeverein bent zodra je leverancier in de EU zit en je data in een Europees datacenter staan. Paapst vergelijkt dat met een dakkapel bouwen terwijl de fundering verzakt. Je kunt dan net zo goed vastzitten, alleen bij een Europese partij, en de technologie onder de motorkap komt vaak alsnog van buiten Europa.
De kernoplossingen: autonomie ontwerp en contracteer je
Het boek blijft niet hangen in analyse. Paapst geeft oplossingen op vier niveaus.
1. Loskomen: een gefaseerde break-out
Begin met een integrale analyse van je afhankelijkheden, technisch, financieel, contractueel en organisatorisch, en kijk ook hoe de huidige keuze ooit tot stand kwam. Pak daarna eerst de meest beperkende afhankelijkheden aan. De volgorde is meestal: grip op je data, systemen opknippen in vervangbare onderdelen, oud en nieuw tijdelijk naast elkaar draaien, en werken met meerdere leveranciers in plaats van één.
Voor bestuurders zit hier een belangrijke les: de kosten van een break-out vallen nu, de baten vaak pas bij je opvolger. Registreer afhankelijkheid daarom als financieel risico, reserveer een transitiebudget, en stel niet alleen de vraag wat overstappen kost, maar ook wat het kost om de huidige afhankelijkheid nog tien jaar in stand te houden. Vaak is de businesscase van nu ingrijpen veel positiever.
Juridisch heb je meer in handen dan je denkt. Eisen uit de oorspronkelijke aanbesteding zijn vaak gewoon afdwingbaar. De Data Act geeft je sinds 2025 het recht om van cloud- en SaaS-aanbieder te wisselen, met een opzegtermijn van maximaal twee maanden en verplichte medewerking, en vanaf 12 januari 2027 zonder overstapkosten. Belangrijk detail: wie de lock-in zelf heeft laten ontstaan, mag zich volgens het Europese Hof (2025) niet op "technische exclusiviteit" beroepen om een vervolgopdracht onderhands te gunnen.
2. Voorkomen: leveranciersonafhankelijkheid als ontwerpprincipe
Leveranciersonafhankelijkheid moet van "nice to have" naar "absoluut vereist". Concreet:
- Interoperabiliteit specifiek eisen, met de standaard erbij, en niet alleen "de oplossing is interoperabel".
- Dataportabiliteit gedurende de hele looptijd, in open en machineleesbare formaten, inclusief metadata en configuratie.
- Open standaarden van de "pas toe of leg uit"-lijst van Forum Standaardisatie, en voor cloud de ISO-normen voor portabiliteit (19941), SLA's (19086) en beveiliging (27001, 27017, 27018).
- Een exitplan bij de start, jaarlijks bijgewerkt en getest met een "exit drill": een oefening waarin je simuleert dat je vertrekt.
- Documentatie en transparantie, zoals API-beschrijvingen volgens OpenAPI en een Software Bill of Materials (SBOM): een lijst van alle onderdelen waar de software uit bestaat.
- Rechten op software, bij voorkeur via een open source-licentie in plaats van een overdracht van auteursrechten die daarna in een la verdwijnt.
3. Beschermen: soevereiniteit als toetsbare eis
Niet de herkomst van een leverancier is beslissend, maar wie feitelijk zeggenschap heeft: juridisch, economisch, organisatorisch en technisch. Een voorkeur voor Europese leveranciers mag in een aanbesteding meestal niet, maar functionele eisen wel. Het sterkste voorbeeld uit het boek: sluit verwerkers uit die onder buitenlandse wetgeving vallen die een andere overheid ongecontroleerd toegang geeft tot de gegevens. Daarnaast: change of control-clausules (wat als je leverancier wordt overgenomen?), grip op de hele keten van onderaannemers via de AVG en de Data Act, en het Cloud Sovereignty Framework van de Europese Commissie. Dat kader beoordeelt acht soevereiniteitsdoelen en kent SEAL-niveaus van 0 tot en met 4, waarbij het zwakste onderdeel het niveau bepaalt.
4. Samen sterker: collectief handelen
Organisaties die elk afzonderlijk inkopen bij dezelfde leverancier vergroten diens marktmacht. Gezamenlijk ontwikkelen en inkopen, bij voorkeur op open source, keert dat om. Paapst noemt Pleio als voorbeeld: een open source samenwerkingsplatform dat inmiddels door ruim 120 overheden wordt gedeeld.
Toegepast op streaming: een keten vol stekkers
Het boek gaat over ICT in het algemeen. Streaming is een bijzonder geval, want een videodienst is altijd een keten: intake, transcoding, packaging, opslag, CDN, player en analytics. Elke schakel is een plek waar je vast kunt komen te zitten, en wie de hele keten bij één partij onderbrengt, heeft geen leverancier meer maar een landlord. Bovendien is live genadeloos: een database migreer je in een weekend, een live-uitzending krijgt geen tweede kans.
Platform als geheel
- Waar de lock-in zit
- Een gesloten suite of een platform bovenop een hyperscaler
- Hoe wij dat al jaren oplossen
- Eigen software op eigen infrastructuur, modulaire pipelines waarin klanten onderdelen vervangen door hun eigen stack
Encoding en packaging
- Waar de lock-in zit
- Ongedocumenteerde afhankelijkheden, niet compliant encoding en packaging, niet migreerbare formaten
- Hoe wij dat al jaren oplossen
- Open architectuur, encoding en packaging volgens open standaarden, gedocumenteerd en migreerbaar
DRM
- Waar de lock-in zit
- De drie grote DRM-systemen zijn van Amerikaanse techbedrijven en zitten diep in browsers en apparaten
- Hoe wij dat al jaren oplossen
- Per content bewust afwegen of DRM echt nodig is, token based access control als alternatief
CDN
- Waar de lock-in zit
- Eén CDN is één stekker, met egress-kosten en een eigen keten van onderaannemers
- Hoe wij dat al jaren oplossen
- Multi-CDN voor overflow en fallback, switching en geografische optimalisatie
Player
- Waar de lock-in zit
- Een ingesloten player van een groot platform stuurt kijkgedrag naar een derde, vaak buiten Europa
- Hoe wij dat al jaren oplossen
- Privacy Player zonder trackers, eigen players mogelijk
Advertenties
- Waar de lock-in zit
- Gebruik van één grote ad-leverancier, invasieve tracking en profiling door tientallen, soms honderden partijen
- Hoe wij dat al jaren oplossen
- Contextual advertising en de optie om tracking based ads aan en uit te zetten
Analytics
- Waar de lock-in zit
- Kijkdata bij de leverancier, niet mee te nemen, opgeslagen in proprietary dataformaat
- Hoe wij dat al jaren oplossen
- Server-side gestandaardiseerde analytics in onze eigen groene Europese cloud, gepseudonimiseerd, de data is van de klant
Exit
- Waar de lock-in zit
- Content, metadata en configuratie zitten vast in het platform
- Hoe wij dat al jaren oplossen
- Import en export geregeld, en overstapbaarheid zit in de architectuur: onderdelen parallel draaien en omzetten zonder dat de kijker iets merkt
Daar zijn we ook transparant over. Wij hebben onszelf beoordeeld tegen het Cloud Sovereignty Framework. Op zeven van de acht doelen komen we uit op SEAL-4. Op beveiliging en compliance staan we op SEAL-3, omdat onze ISO 27001-certificering voor onze nieuwe platforms nog loopt, en omdat het laagste doel telt, is dat vooralsnog ons totaalniveau. Een keurmerk is het niet, want het kader kent geen certificering: een officieel niveau stelt alleen de aanbestedende dienst vast. Daarom ligt bij elke claim het bewijsstuk klaar.
De basis van onze dienst is software-encoding op standaardservers, zonder binding aan één merk of chiparchitectuur. Wie kiest voor hardwareversnelling of DRM, neemt bewust niet-Europese technologie op, want daarvoor bestaat (nog) geen Europees alternatief. Dat maken we expliciet, in plaats van het ongemerkt in het basisproduct te stoppen. Zo moet jij ook jouw leveranciers toetsen.
Dat de markt hier nog veel te winnen heeft, bleek dit voorjaar. Bij de eigen cloudaanbesteding van de Europese Commissie haalden drie Europese aanbieders SEAL-3, en het consortium met de "soevereine" Google-dienst S3NS bleef op SEAL-2 steken (Europese Commissie). Een sticker "soeverein" is dus geen garantie. Sterker nog, er zijn te veel voorbeelden van soevereiniteitswashing, waarbij een leverancier zegt compliant te zijn terwijl de keten dat niet waarmaakt. Zo word je in de waan gelaten dat je veilig bent, terwijl de risico's bij jou liggen. Vaak volstaan een paar DNS-opvragingen om te zien dat de kijkstatistieken of het beheerplatform toch bij een Amerikaanse hyperscaler draaien, en ook al draaien die in Europa, dat is dus een schijnveiligheid.
Een sticker "soeverein" is geen garantie. Vraag bij elke eis om bewijs.
Bij de tender: de vragen die je elke leverancier moet stellen
Vraag functioneel uit, dus wat de dienst moet kunnen, en nooit een merk of platform bij naam. Vraag bij elke eis om bewijs, en zorg dat de antwoorden uit de inschrijving onderdeel worden van het contract, want anders blijven het beloftes. Valideer ook zelf: vraag de bewijsstukken op, en controleer met DNS-opvragingen en netwerkmetingen waar streams, beheer en statistieken werkelijk draaien.
Architectuur en standaarden
- Welke open standaarden gebruikt de dienst voor ingest, streaming, packaging en metadata, en welke onderdelen zijn eigen (proprietary) formaten?
- Kan ik een eigen CDN, encoder, packager, player, analytics of opslag aansluiten, of is de dienst een gesloten geheel, of zijn er specifieke afhankelijkheden?
- Zijn de API's volledig gedocumenteerd, en hoe lang van tevoren worden wijzigingen aangekondigd?
Data en exit
- Kan ik content, metadata, configuraties, logs en kijkcijfers exporteren, in welke formaten, en tegen welke kosten?
- Is er bij de start een exitplan, met doorlooptijden, medewerkingsplicht en een kostenplafond, en mag ik dat jaarlijks testen?
- Hoe voldoet de dienst aan de overstapverplichtingen uit de Data Act?
Keten en soevereiniteit
- Welke onderaannemers, CDN's, hostingpartijen en subverwerkers zijn betrokken, en waar zitten die juridisch?
- Vallen jij of een van je ketenpartners onder wetgeving die een buitenlandse overheid toegang geeft tot data, of de dienst kan laten stoppen via sancties of exportcontrole?
- Op welke soevereiniteitsdoelen haal je SEAL-3 niet, en waarom? Welk niveau haal je per doel, met welk bewijs, en wil je dat niveau als contractueel minimum vastleggen?
- Wat gebeurt er als je bedrijf wordt overgenomen? Is er een change of control-clausule met meldplicht en opzegrecht?
- Hebben al je medewerkers, en die van je onderaannemers met toegang tot systemen of data, een VOG?
Privacy en kijkers
- Bevat de player trackers of code van derden, en welke kijkdata gaan waarheen?
- Van wie zijn de kijkdata, en mag de leverancier ze voor eigen doeleinden gebruiken?
- Voldoet de player aan WCAG, en zijn ondertiteling en audiodescriptie te ondersteunen?
Kosten
- Wat zijn de totale kosten over de hele looptijd, inclusief egress, opslag, extra modules, export en exit?
- Welke kosten zijn afhankelijk van volume, en wat gebeurt er met de prijs bij een piek, zoals een drukbezochte live-uitzending?
Twee tips. Maak een voorkeur voor privacybescherming en soevereiniteit hard met punten of een knock-out-eis, want een zin als "Europees heeft de voorkeur" doet in de beoordeling niets. Stel bovendien een minimaal SEAL-niveau als knock-out, en vergelijk pas daarna op prijs en kwaliteit.
In je eigen organisatie: de audit die je zelf moet doen
De beste tender helpt niet als je niet weet waar je nu staat. Begin daarom bij jezelf, met de vraag die elke bestuurder zou moeten kunnen beantwoorden: wat gebeurt er als onze streamingdienst morgen wordt uitgezet, omdat een leverancier failliet gaat, wordt overgenomen of een buitenlandse overheid ingrijpt? Dan staat je raadsvergadering, je persconferentie of je crisiscommunicatie op zwart, wellicht voor langere tijd.
- Breng je keten in kaart. Welke diensten gebruik je voor live, on-demand, player, opslag en analytics, wie levert ze, welke onderaannemers zitten erachter, en onder welk recht vallen ze? Leg dat vast in een afhankelijkhedenregister.
- Leg je contracten ernaast. Looptijden, stilzwijgende verlenging, opzegtermijnen, exportrechten, exit-afspraken, en onder wiens algemene voorwaarden je hebt getekend.
- Haal de oude aanbestedingsstukken erbij. Wat beloofde de leverancier destijds, bijvoorbeeld over open standaarden of medewerking bij exit? Die beloftes zijn vaak afdwingbaar, maar niemand heeft ze gecontroleerd.
- Doe een testexport. Probeer echt je content, metadata en kijkdata eruit te halen en elders af te spelen. Wat niet lukt, is je werkelijke lock-in.
- Doe een benchmark. Hoe compliant zijn je huidige streams en livestreams met open standaarden? Dan weet je of je door eigenzinnige encoding en packaging vastzit aan één leverancier, en of je bij een migratie je hele bibliotheek opnieuw moet encoderen.
- Scan je player en website. Welke trackers en code van derden draaien er mee, en waar gaan de gegevens van jouw kijkers naartoe? Onder welke jurisdictie?
- Bepaal per dienst het benodigde soevereiniteitsniveau. Een interne training vraagt iets anders dan crisiscommunicatie of besluitvorming in de gemeenteraad. Scoor je huidige leveranciers daar eerlijk tegen.
- Reken blijven én vertrekken door. Wat kost de huidige situatie over tien jaar, inclusief prijsstijgingen en risico's, en wat kost een gefaseerde overstap?
- Maak het een bestuursonderwerp. Registreer digitale afhankelijkheid als risico, reserveer een transitiebudget, en herhaal deze audit jaarlijks, want afhankelijkheden groeien ongemerkt mee met elke nieuwe dienst die je afneemt.
Lees het boek, en toets ons
We raden iedere IT-manager, inkoper en bestuurder aan om het boek van Paapst te downloaden. Het helpt organisaties weerbaar te worden, want het vertaalt mooie beleidswoorden naar eisen die je in een aanbesteding en een contract kunt afdwingen. De voorbeeldclausules in de bijlage mag je vrij hergebruiken.
Wij zijn blij dat dit nu zo helder op papier staat bij Forum Standaardisatie. Wil je weten hoe jouw streamingketen scoort, of hoe je dit vertaalt naar je volgende aanbesteding? Neem contact op voor een kennismaking. Dan lopen we samen jouw keten door, van camera tot kijker. Stel ons gerust alle vragen uit deze blog: zo hoor je ons ook te toetsen. Dan laten we je meteen zien waar wij nu staan en naartoe gaan, met nieuwe techniek, en met compliance.