Onderwerp
Nog niet bevestigd door een mens. Eigenaar: vdo89. Bron in de atlas
Het aanbod is een product voor interne afnemers, ontwikkeld en onderhouden door platformbeheer, met per dienst een eigenaar. Dit onderwerp legt vast hoe dat aanbod wordt gestuurd en wie waarvoor verantwoordelijk is, welke beheerafspraken de diensten dragen, hoe kosten en keuzeruimte zichtbaar worden en onder welke voorwaarden RWS SaaS afneemt, ook voor gevoelige gegevens en sleutels.
Standaardisatie is doelmatig als dezelfde investering vaker wordt gebruikt en er minder varianten te onderhouden zijn, maar zelfservice laat het gebruik ook groeien. Daarom staan kosten per dienst en totale kosten naast elkaar, en telt een besparing pas als de uitgaven dalen. Beveiliging blijft een verantwoordelijkheid van de lijn, met een vaste verdeling voor vrijgave en restrisico.
Eigen regie over kritieke onderdelen vraagt eigen mensen en kennis; SaaS kan werk overnemen, maar verplaatst de verantwoordelijkheid niet. Daarom vraagt iedere afname buiten het eigen platform een afweging per toepassing, afspraken over gegevens, sleutels, continuïteit en vertrek, en een beproefd exitplan. De concrete termijnen zijn een voorstel.
Platformbeheer ontwikkelt en onderhoudt het aanbod als een product voor interne afnemers: investeringen volgen de waarde voor hen, en teams kiezen het aanbod omdat het hun werk lichter maakt. Iedere dienst heeft een eigenaar die aanspreekbaar is op het resultaat voor de afnemer, binnen de bestaande RWS-sturing en mandaten.
Gebruik en feedback van de afnemers sturen de verbeterplanning.
Het platform wordt op drie niveaus gestuurd, van strategie tot dagelijks beheer, elk met eigen onderwerpen en de informatie die daarvoor nodig is.
| Niveau | Waarop wordt gestuurd | Benodigde informatie |
|---|---|---|
| Strategisch: directie en portfolio | Prioriteit van diensten, meerjarige middelen, afbouw van bestaande voorzieningen en restrisico boven de RWS-tolerantie. | Bijdrage aan het werk, totale kosten, restrisico’s en afhankelijkheden. |
| Tactisch: diensteigenaren en architectuur | Samenhang van het aanbod, dienstprofielen, vrijgave naar productie, uitzonderingen, capaciteit, onderhoud en migratie. | Gebruik, kwaliteit, uitzonderingen en gevolgen van voorgenomen wijzigingen. |
| Operationeel: platformbeheer en beheerdomeinen | Dagelijkse levering, wijzigingen, bewaking, incidenten en herstel. | Actuele inrichting en werking, achterstanden en beproefde procedures. |
De proceseigenaar en de gegevenseigenaar bepalen waarvoor een toepassing wordt gebruikt, welke gegevens zij mag verwerken en welke onderbreking aanvaardbaar is. Het applicatieteam onderhoudt de software en beoordeelt de werking. Bij een storing coördineert de diensteigenaar de betrokken beheerteams, zodat de afnemer één aanspreekpunt heeft voor het onderzoek naar de oorzaak.
Netwerk-, beveiligings-, identiteits- en infrastructuurspecialisten ontwerpen samen de veelvoorkomende dienstvarianten, met de toegestane keuzes en de controles. Hun kennis blijft nodig om het aanbod te onderhouden, nieuwe risico’s te verwerken en afwijkende vragen te beoordelen, en zij begeleiden afnemers en hun ontwikkelpartners.
Een standaardwijziging binnen zo’n variant vraagt geen nieuwe beoordeling door een specialist; zie geen herhaalde beoordeling. Een knelpunt dat bij de begeleiding steeds terugkeert, wordt via de verbeterplanning van de dienst in de standaard opgelost. Gemeten wordt of het kleinere aantal losse leveringen tijd vrijmaakt, en nieuwe diensten worden afgewogen tegen de tijd die het onderhoud van de bestaande vraagt. Afgewezen: iedere wijziging opnieuw langs alle specialisten, waardoor hun kennis opgaat aan herhaling in plaats van aan nieuwe risico’s.
Beveiliging blijft een lijnverantwoordelijkheid: het lijnmanagement is verantwoordelijk voor de risico’s van de dienst, en de CISO-functie en het SOC ondersteunen zonder die verantwoordelijkheid over te nemen. De naleving van de eisen wordt beoordeeld over de hele dienst: techniek, mensen, afspraken en dagelijks gebruik.
Technische controles ondersteunen die beoordeling; zie de belofte Voortgang op de hele dienst beoordelen.
De diensteigenaar treft maatregelen en tekent voor de vrijgave naar reguliere of bedrijfskritische productie. De CISO-functie adviseert en tekent mee voor het restrisico; ligt dat boven de RWS-tolerantie, dan besluit de directie. Iedere rol heeft een aangewezen plaatsvervanger.
De bevoegde verantwoordelijke is de functionaris die volgens deze verdeling het restrisico mag aanvaarden.
De Cyberbeveiligingswet maakt het bestuur eindverantwoordelijk voor de beheersing van cyberrisico’s en verplicht bestuurders tot passende scholing; de voortgangsrapportage geeft het bestuur daarvoor de informatie. RWS valt onder de sector overheid van deze wet, waarvoor BIO2 de wettelijke zorgplicht uitwerkt; een belangrijk deel van BIO2 is daarmee voor RWS wettelijk verankerd.
Voor iedere gemeenschappelijke voorziening waarop afnemers vertrouwen, liggen eigenaar, onderhoud, ondersteuning en herstel vast voordat een dienst ervan afhankelijk wordt. Levert een bestaande RWS-dienst de voorziening, dan is dat een afspraak met die dienst, niet alleen een productnaam.
Voor iedere gemeenschappelijke functie worden verantwoordelijkheid, ondersteuning en herstel uitgewerkt en beproefd. Iedere functie levert een afnamedienst, ondersteunt een gemeenschappelijke functie of sluit aan op bestaande RWS-dienstverlening; virtuele werkplekken horen bijvoorbeeld niet bij de standaarddiensten, maar blijven zichtbaar als aanvullende functie in het portfolio.
Platformafname sluit aan op de bestaande bronnen voor medewerkers, rollen en rechten. Het identiteitsbeheer verwerkt instroom, functiewijziging en vertrek en levert de rollen aan de toegangsvoorziening, zodat wijzigingen in alle aangesloten diensten doorwerken. Eigenaren beoordelen periodiek of verleende rechten nog nodig zijn.
Voor intrekking, tijdelijk verhoogde rechten van beheerders en noodtoegang gelden de regels van het domein Identiteit & beheertoegang. De toets Beheertoegang en noodtoegang toont aan dat toegang en identiteitsbeheer als werkende dienst zijn overgedragen.
De gegevens blijven onder verantwoordelijkheid van RWS: de gegevenseigenaar bepaalt classificatie, toegestaan gebruik en bewaartermijn volgens het classificatieschema van RWS, en het platform vertaalt dat naar toegang, opslag, herstel en verwijdering. De bescherming van de inhoud zelf tegen lekken en ongewenst kopiëren (DLP, IRM) is geërfd van de werkplekdienst.
De metadatavoorziening van het RWS-datastelsel, die het platform erft, houdt betekenis en herkomst van gegevens beschikbaar voor de teams die ze gebruiken. Technisch bruikbare gegevens mogen niet vanzelf voor ieder doel worden gebruikt, ook niet bij gegevensuitwisseling met SaaS en bij AI.
De technische basis houdt een eigen levenscyclus: naam- en tijdvoorziening, netwerk, hardware, firmware en besturingssystemen worden als onderdeel van het platform onderhouden, met de capaciteit en ondersteuning die afhankelijke diensten vragen. Netwerkbeheer levert de naamvoorziening en de tijdbronnen en de Linux-updatedienst de updates, elk op grond van een dienstafspraak.
Licenties en gebruiksrechten worden bij uitgifte en afbouw bijgehouden. De bewaking koppelt technische signalen aan het effect voor de afnemer, zodat beheer ook de dienst als geheel beoordeelt.
Kosten en capaciteit worden zichtbaar: de afnemer ziet wat zijn keuze betekent, het management de totale uitgaven. Vastgelegd wordt welke kosten aan een dienst worden toegerekend, welke gedeeld blijven en hoe vaak wordt gerapporteerd; vanaf groeipadstap 3 rekent het kostenbeheer toe op basis van de metingen van de bewaking.
Standaardisatie is doelmatig als RWS dezelfde investering vaker gebruikt en minder varianten hoeft te onderhouden. Zelfservice maakt afname eenvoudiger, waardoor het totale gebruik kan groeien: een dalende prijs per levering maakt het platform niet vanzelf goedkoper. Afgewezen: een vaste bijdrage per team, die niet laat zien wat een continuïteitskeuze kost; zie de ontwerpkeuze Kosten en gebruik per dienst zichtbaar.
De prijs volgt de volledige dienst. Een database voor bedrijfskritische productie vraagt meer dan opslag: een tweede exemplaar in de andere cel, voortdurende gegevensuitwisseling tussen beide, reservecapaciteit om het werk over te nemen en herstelproeven. Een tijdelijke testdatabase krijgt daarentegen een beperkter quotum en een einddatum.
Dat verschil wordt zichtbaar, zodat afnemers hun continuïteitsbehoefte kunnen afwegen tegen de benodigde middelen.
Het kostenbeeld per dienst bestaat uit de blijvende basis, het gebruik, de overgang en de beëindiging.
| Onderdeel | Wat wordt meegenomen |
|---|---|
| Blijvende basis | Infrastructuur, energie, ondersteuning, deskundig beheer en reserve voor continuïteit. |
| Gebruik | Rekenkracht, opslag, gegevensverkeer en bijzondere capaciteit, voor zover toe te rekenen. |
| Overgang | Migratie en testen, opleiding, tijdelijk dubbel beheer en lopende contracten. |
| Beëindiging | Gegevens overdragen of archiveren, voorzieningen verwijderen en verplichtingen afsluiten. |
De rapportage toont gebruik, kosten per dienst en totale kosten naast elkaar, met apart de ongebruikte en de voor herstel gereserveerde capaciteit. Bij uitbreiding tellen ook de grenzen aan energie en vermogen in de datacenters mee.
De toets Kosten en gebruik per dienst toont de rapportage aan.
Een financiële besparing ontstaat pas als de werkelijke uitgaven dalen. De organisatiebrede ambitie om de productiviteit te verhogen is geen raming van de opbrengst van het platform; minder handmatig werk kan medewerkers wel ruimte geven voor andere taken. Daarom blijven kosten per dienst en totale kosten naast de bereikte resultaten zichtbaar.
Planning, begroting en toestemming voor gebruik worden afzonderlijk verantwoord; eerdere planningen en ramingen zijn geen actuele begroting voor het platform.
Een eigen platform vraagt mensen en kennis. De omvang van het aanbod en de afgesproken ondersteuning bepalen mede hoeveel mensen het platform nodig heeft.
Keuzeruimte vraagt overdraagbare gegevens en configuraties én een uitvoerbaar alternatief. Contractafspraken worden daarom verbonden aan een proef waarin een representatieve dienst wordt geëxporteerd en elders hersteld; die maakt conversiewerk, ontbrekende informatie en afhankelijkheid van specialistische kennis zichtbaar voordat een overstap nodig is.
Open standaarden houden configuraties ook buiten de eigen voorziening leesbaar, maar leveranciersspecifieke uitbreidingen, de betekenis van gegevens, geheimen en licentierechten gaan niet vanzelf mee. De proef is de toets Overdraagbaarheid en afbouw.
SaaS wordt per toepassing afgewogen en alleen afgenomen als de afweging op alle onderdelen voordelig uitvalt; anders draait de toepassing op het eigen platform. Voldoet zij ook daar niet aan de eisen, dan gaat zij pas in productie na aanpassing van ontwerp of afspraken.
| Onderdeel | Wat ten minste wordt afgewogen |
|---|---|
| Soort gegevens | De classificatie, eventuele persoonsgegevens met de AVG-eisen aan verwerking en doorgifte, en de duur van de vertrouwelijkheid. Gegevens die buiten eigen beheer niet voldoende te beschermen zijn, blijven op het eigen platform. |
| Toepassingsgebied | Algemene functionaliteit die veel organisaties op dezelfde manier gebruiken, komt eerder in aanmerking dan werk dat de kerntaak raakt. Missiekritieke informatievoorziening blijft onafhankelijk van clouddiensten. |
| Businesscase | De kosten over de hele levensduur, inclusief koppelingen, beheer aan RWS-zijde, exitplan en vertrek, afgezet tegen het eigen platform op hetzelfde dienstprofiel en tegen de meerwaarde voor het werk. |
| Soevereiniteit | Zeggenschap over gegevens en sleutels, de beheertoegang van de leverancier, de verwerkingslocatie en het toepasselijke recht, en een uitvoerbaar vertrek. |
| Beveiliging, continuïteit en aansluiting | Aantoonbaar voldoen aan BIO2 en het cloudbeleid, herstelafspraken die bij het dienstprofiel passen, en aansluiting op het RWS-identiteitsbeheer en de koppelingen van het platform. |
SaaS kan onderhoud overnemen en nieuwe functionaliteit sneller beschikbaar maken, maar legt ook een deel van de zeggenschap over gegevens, beveiliging, continuïteit en vertrek bij een leverancier. De afweging volgt de ICT-strategie. Afgewezen: alles standaard in de publieke cloud, wat het beheer verplaatst maar niet de verantwoordelijkheid; zie de ontwerpkeuze Regie over kritieke onderdelen en een bewuste landingsplek.
Afweging en besluit worden per toepassing vastgelegd. Een toegelaten SaaS-dienst komt in de catalogus, met een eigenaar en afspraken over gebruik en ondersteuning.
Voor SaaS op een publieke cloud past RWS het Rijkscloudbeleid 2026 in de volledige lezing toe: vooraf een integrale risicobeoordeling op basis van de gegevensclassificatie en een exitplan dat RWS zelf beproeft. Opslag en verwerking blijven binnen de Europese Economische Ruimte en Zwitserland. Bij materieel gebruik, voor de kerntaak of grootschalige verwerking van persoonsgegevens, gelden extra eisen en meldt RWS het gebruik vooraf aan de CISO Rijk.
RWS houdt zeggenschap over het doel van de verwerking, de toegestane gegevensstromen en de beëindiging van de dienst. De leverancier beheert zijn software binnen een per dienst vastgelegde verdeling van verantwoordelijkheden; de RWS-diensteigenaar bewaakt de werking voor het eigen proces en de afhankelijkheid van de leverancier.
Voor gegevensuitwisseling gelden dezelfde aansluitafspraken als voor interne diensten, en voor AI en SaaS dezelfde doelen voor toegang, gegevensbescherming en continuïteit, met een uitvoering die bij de dienst past. Het toezicht op niet-toegelaten clouddiensten en de gegevensstromen daarheen (CASB, DLP) is geërfd van de werkplekdienst.
BIO2 verbindt cloudgebruik aan een doorlopende beoordeling én een geregelde beëindiging. Daarom liggen ook verwerkingslocatie, beheertoegang, bijwerken en kwetsbaarheidsbeheer, loggegevens, herstel, export en verwijdering vast, en beschrijft het exitplan twee scenario’s: een geplande overstap, met een toegestane onderbreking volgens het dienstprofiel, en een onverwachte onderbreking bij de leverancier, met vooraf geregelde noodmaatregelen en herstelstappen voor kritieke processen.
Voordat RWS afhankelijk wordt van de dienst, tonen de toetsen SaaS aansluiten en kunnen beëindigen en Gevoelige verwerking en sleutelvrijgave de gegevensoverdracht bij vertrek en de gevolgen van een geweigerde sleutelvrijgave aan.
Voor SaaS gelden een overgangstermijn voor bestaand gebruik en een vaste termijn voor herbeoordeling.
| Termijn | Waarde |
|---|---|
| Overgangstermijn voor bestaand gebruik op een publieke cloud | Vier jaar |
| Herbeoordeling van de afspraken en het exitplan | Jaarlijks |
De overgangstermijn komt uit het Rijkscloudbeleid 2026; de herbeoordeling geldt voor de afspraken over verwerkingslocatie, beheertoegang, bijwerken, loggegevens, herstel, export en verwijdering, en voor het exitplan.
Gevoelige gegevens moeten tijdens de verwerking leesbaar zijn, en versleuteling van opslag en verbindingen dekt dat moment niet volledig af. Daarvoor wordt een afgeschermde uitvoeromgeving beoordeeld die inzage vanuit de onderliggende infrastructuur beperkt. De sleutels komen pas vrij na attestatie op afstand, op voorwaarden die RWS bepaalt, en de controle daarop steunt op een vertrouwensbasis buiten de gecontroleerde omgeving.
Die omgeving kan haar eigen betrouwbaarheid niet verklaren. De beveiligde verbinding met de toepassing eindigt pas binnen de afgeschermde omgeving, zodat de infrastructuur van de leverancier het verkeer niet kan inzien; tegen welke dreigingen dat werkt, beschrijft het dreigingsmodel van de leverancier, die de inrichting moet ondersteunen. De inrichting begrenst niet wat de toepassing en haar gebruikers met de gegevens mogen doen; daarvoor blijven contractafspraken over gegevensgebruik, beheertoegang en vertrek nodig. Afgewezen: alleen versleuteling van opslag en verbindingen. De toets Gevoelige verwerking en sleutelvrijgave toont de werking per dienst aan.
Bij uitbesteding wordt versleuteld met sleutels die RWS zelf genereert, zoals het SAK Cryptografie Management vraagt. De afname- en beheerafspraken leggen die eis vast, en ook wie de sleutels bewaart en gebruikt: zelf genereren geeft nog geen exclusieve zeggenschap.
Ook het cloudbeleid verkiest voor vertrouwelijke gegevens sleutelbeheer in eigen beheer boven dat bij de leverancier.
Gegevens die lang vertrouwelijk moeten blijven, krijgen ook quantumveilige cryptografie (PQC). RWS volgt het PQC-migratiehandboek: inventariseren, risico beoordelen en een migratieplan maken, waarin de gegevens die het langst vertrouwelijk moeten blijven en het grootste risico lopen als eerste overgaan. De inventaris legt per dienst en per pad de gebruikte cryptografie vast, volgens de cryptografietabel van RWS, en bij nieuwe aansluitingen blijven de algoritmen vervangbaar.
Verkeer dat nu wordt onderschept en bewaard, kan later worden ontsleuteld zodra een quantumcomputer de gebruikte sleuteluitwisseling breekt. De technische invulling, zoals hybride quantumveilige sleuteluitwisseling, staat in het domein Geheimen, sleutels & certificaten.
De overgang naar quantumveilige cryptografie volgt de Europese routekaart: beginnen vóór eind 2026, toepassingen met een hoog risico uiterlijk eind 2030 overzetten en de overgang in 2035 zo volledig als praktisch haalbaar afronden.
De routekaart is een aanbeveling; wettelijk verplicht is de overgang niet.