Exit-strategie en digitale soevereiniteit

Digitale soevereiniteit gaat over zeggenschap: weten onder welk recht je software en data vallen en kunnen overstappen zonder dat processen stilvallen. Die zeggenschap staat of valt met een uitvoerbare exit-strategie. Op deze pagina: wat een exit-strategie is, waarom escrow die uitvoerbaar maakt en de vraag die vaak wordt overgeslagen: hoe soeverein is het vangnet zelf?

Wat is een exit-strategie?

Een exit-strategie legt vooraf vast hoe je processen en data blijven draaien als een leverancier wegvalt of de dienstverlening staakt. Het is geen losse noodprocedure. Het is ook geen onderwerp dat pas opkomt zodra digitale soevereiniteit op de agenda staat. Een exit-strategie hoort bij de architectuur van een oplossing, net als beveiliging: een fundament dat je bij het ontwerp en de inkoop meeneemt. Welke afhankelijkheden ontstaan er? Hoe migreer je weg? En wat heb je daarvoor nodig aan broncode, data, documentatie en kennis?

Toezichthouders vragen er inmiddels expliciet om. DORA verplicht financiële entiteiten tot exitstrategieën voor kritieke ICT-diensten (artikel 28). NIS2 vereist continuïteitsmaatregelen voor kritieke afhankelijkheden. ISO 22301 benoemt softwareafhankelijkheden als bedrijfscontinuïteitsrisico.

Escrow en compliance: per framework →

Zonder depot blijft een exit-strategie papier

Het lastigste moment om een exit uit te voeren is precies het moment waarvoor je hem schrijft: een leverancier die failliet is of de dienstverlening staakt. Wie dan geen toegang heeft tot broncode, data en een beschrijving van de omgeving, heeft een plan maar geen middelen. De broncode is intellectueel eigendom van de leverancier en valt bij een faillissement in de boedel; zelf iets regelen met oud-medewerkers maakt inbreuk op dat eigendom.

Escrow lost dit vooraf op, in termen van beschikbaarheid. De leverancier deponeert broncode en data bij een onafhankelijke escrow agent. Onder de afgesproken afgiftevoorwaarden komt een depot direct beschikbaar voor de begunstigde, met bijbehorend gebruiksrecht. Doordat een depot bij faillissement automatisch overgaat in bewaarneming, is voor de curator meteen glashelder dat het buiten de boedel valt.

• Software Escrow: broncode en documentatie, actueel gehouden via periodieke full deposits
• SaaS Escrow: broncode én data, actueel gehouden via incrementele snapshots
• CloudSecure®: continuïteit van de volledige clouddienst via juridische ringfencing

Ook de overdraagbaarheid van kennis, vaak het zwakste punt van een exit-plan, is te regelen. De depotspecificatie beschrijft de inhoud van een depot. Een stapsgewijze compilatiehandleiding hoort bij de aanlevering. Met een verificatie-onderzoek bouwt de leverancier onder toezicht van een onafhankelijke NOREA Register IT-auditor een werkende omgeving op uit het depot. Het rapport van bevindingen geeft aan of uit het depot een werkende applicatie kan worden gecompileerd.

Vergelijk de drie diensten → Verificatie-onderzoek →

Een applicatie is steeds vaker een verzameling clouddiensten

Vendor lock-in speelt op meerdere niveaus. Het bekendste is het applicatieniveau: de afhankelijkheid van de leverancier zelf, zijn licenties en dataformaten. Daar is escrow het klassieke antwoord op. Onder de applicatie ligt het platform waarop hij is gebouwd. Daaronder het besturingssysteem, met zijn eigen licenties en binding. En wie zelf host, kent ook de virtualisatielaag; de recente licentiewijzigingen in de hypervisormarkt lieten zien hoe diep die binding kan zitten. Zo kent elke laag zijn eigen keuzes die binden, tot en met de hardware.

In de praktijk zien we steeds vaker dat een softwareoplossing geen op zichzelf staand pakket meer is, maar een verzameling clouddiensten die aan elkaar zijn geknoopt. Leveranciers bouwen hun applicatie op met kant-en-klare bouwstenen van één cloudplatform, bijvoorbeeld Microsoft Azure. Ze combineren PaaS-diensten (de leverancier levert alleen nog code en data) met IaaS-componenten voor netwerk en opslag.

Dat werkt uitstekend zolang alles goed gaat. Maar de oplossing is dan niet meer los te zien van het platform waarop hij draait. De broncode alleen is onvoldoende om de dienst voort te zetten. Zonder de bijbehorende clouddiensten, configuratie en identiteitsvoorziening is die code niet meer dan een halffabricaat. Bij een faillissement of het wegvallen van de leverancier is de vraag niet óf je de code hebt, maar of je de omgeving kunt reconstrueren waarin die code kan draaien.

Bij een inventarisatie spelen daarom twee vragen. Welke platformspecifieke diensten zijn in gebruik? En welke daarvan kennen een reëel alternatief buiten dat platform? Ter illustratie een greep uit de populairste Azure-componenten:

De zwaarste afhankelijkheden zitten in de regel bij Cosmos DB, Logic Apps, Entra ID en Bicep/ARM. Die hebben geen praktisch equivalent elders, of het overzetten komt neer op herbouwen in plaats van verhuizen. Hetzelfde patroon zie je bij AWS en Google Cloud. De volledige tabellen voor de drie platforms staan op de referentiepagina:

Platformafhankelijkheden: Azure, AWS en Google Cloud →

Vendor lock-in is daarmee niet per definitie slecht. Propriëtaire diensten bestaan omdat ze iets bieden: snelheid, functionaliteit, minder eigen beheer. De keuze voor een zware platformbinding kan een prima afweging zijn. Het verschil zit in bewustzijn. Een lock-in die je kent en waar een vangnet onder ligt, is een ontwerpkeuze. Een lock-in die pas zichtbaar wordt op het moment dat een leverancier wegvalt, is een risico.

De tabel werkt overigens twee kanten op. Er zijn ook organisaties die bewust kiezen voor het comfort van één platform, maar daarbinnen alleen componenten selecteren met een reëel alternatief buiten dat platform. Denk aan een applicatie op Azure die is opgebouwd uit App Service, Azure SQL en Blob Storage: elk van die componenten heeft een gangbaar alternatief, en desnoods draait de hele oplossing op een Linux-VM bij een willekeurige hoster. Interoperabiliteit als ontwerpkeuze. Zo zit de exit-strategie al in de architectuur voordat er iets misgaat.

Voor dit soort platformgebonden oplossingen is een broncodedepot alleen niet genoeg. Een depot wordt pas compleet wanneer naast de code ook de infrastructuurdefinities, de configuratie en een beschrijving van de gebruikte platformdiensten zijn vastgelegd, in het depot en de depotspecificatie. Nog sterker is een geautomatiseerde opbouw: configuration management (bijvoorbeeld Ansible of vergelijkbare scripting) die de omgeving binnen het platform kan opbouwen. Dat is een draaiboek dat zichzelf uitvoert, in plaats van een beschrijving die iemand moet naspelen. Voor de volledige draaiende clouddienst, inclusief hostingcontracten en gebruikerslicenties, bestaat CloudSecure.

Cloud escrow of CloudSecure? →

Export-first: het verkoopargument voor de leverancier

Dezelfde ontwerpvraag geldt voor leveranciers, maar dan door de bril van je klant. Veel SaaS-applicaties zijn niet export-first gebouwd: data is er wel in te krijgen, maar niet op elk moment bruikbaar uit te halen. Voor je klant is dat een afhankelijkheid die steeds vaker expliciet wordt gewogen bij inkoop.

Wie zijn applicatie wél export-first bouwt, geeft klanten een deel van hun exit-strategie cadeau. Dat hoeft geen bedreiging voor een businessmodel te zijn; het kan net zo goed een verkoopargument zijn: concurreren op vertrouwen in plaats van op vergrendeling. Het is hetzelfde principe waarmee wij ons eigen vangnet inrichten, zonder vendor lock-in: een depot is bij afgifte te openen met standaardtooling.

Eén kanttekening: een exportfunctie leeft en sterft met de dienst zelf. Bij een faillissement of het staken van de dienstverlening is de exportknop er niet meer. Export-first en escrow vullen elkaar daarom aan: export-first dekt de periode dat de dienst draait, een depot dekt het moment dat de dienst stopt.

SaaS Escrow →

De vergeten vraag: hoe soeverein is het vangnet zelf?

Wie digitale soevereiniteit serieus neemt, toetst leveranciers op jurisdictie, eigendomsstructuur en uitstapbaarheid. Opvallend vaak wordt die toets op één plek overgeslagen: bij het vangnet zelf. Een escrowdepot bevat het meest kritieke bezit van een organisatie: broncode, data en configuraties. Valt de opslag van de escrow agent onder de Amerikaanse CLOUD Act of USA PATRIOT Act, dan heeft de exit-strategie precies op het kritieke punt een gat. Het depot dat je soevereiniteit moet borgen, is dan zelf via een buitenlands rechtsstelsel bereikbaar.

Vier toetsvragen voor elke escrow aanbieder:

• Jurisdictie van de opslag: staat een depot, inclusief de back-ups, volledig binnen de EU of bij een Amerikaanse aanbieder of een Europese dochter daarvan?
• Eigendomsstructuur van de aanbieder: is er een Amerikaanse moedermaatschappij of incorporatie waarlangs een buitenlands bevel kan worden doorgeleid?
• Toegang tot de inhoud: kan de aanbieder zelf bij de inhoud van een depot? Of is de opslag zero-knowledge en bereikt de encryptiesleutel de aanbieder nooit?
• Continuïteit van de aanbieder zelf: wat gebeurt er met een depot als de escrow aanbieder wegvalt?

Hoe Softcrow dit invult

• Soevereine opslag: SecureStorage, de opslaginfrastructuur onder al onze diensten, is 100% EU-gehost en valt buiten Amerikaanse rechtsmacht: CLOUD- en USA PATRIOT Act-vrij
• Zero-knowledge: de leverancier versleutelt client-side en Softcrow ontvangt de encryptiesleutel nooit; de inhoud van een depot is voor geen enkele tussenliggende partij toegankelijk
• Onafhankelijke Nederlandse vennootschap: escrowprovider sinds 1991, zonder buitenlandse moedermaatschappij of incorporatie
• Eigen continuïteit geborgd: via een onafhankelijke stichting blijven depots ook beschikbaar als Softcrow zelf wegvalt

Security by design → Neem contact op met Softcrow →