Wanneer gebruik je dit?
- Bij selectie of ingebruikname van een clouddienst.
- Bij onduidelijke beheerafspraken, incidenten of contractwijzigingen.
Wat heb je nodig?
Dienst, workload, omgeving en contractversie.
Een voorbeeld uit de praktijk
Fictieve casus: Noordhaven Servicebureau
Noordhaven onderzoekt een beheerde clouddienst voor aanvragen. De fictieve taakverdeling stelt voor dat de klant toegang beheert en de provider het platform onderhoudt. De precieze leverancierstaak moet nog in het contract worden bevestigd.
Een herstelproef vraagt samenwerking: de provider stelt de herstelvoorziening beschikbaar, klantbeheer start de proef en applicatiebeheer controleert gegevens en verwerking. De diensteigenaar beoordeelt of de uitkomst acceptabel is.
Het contract, de hersteldoelen en het controlebewijs staan nog open. De matrix maakt daarom onderscheid tussen een voorstel, een gemaakte afspraak en een getoetste uitkomst. De casus geeft nog geen akkoord voor ingebruikname.
Bekijk de visuele samenvatting
Open op volledig formaat (nieuw tabblad)Aan de slag
- Kies één dienst, workload en contractversie.
- Splits taken naar leverancier en eigen organisatie.
- Benoem uitvoering, besluitverantwoordelijkheid en controle.
- Leg bewijs, escalatie en herbeoordeling vast.
Controleer je resultaat
- Elke taak hoort bij een benoemde dienst en scope.
- Uitvoeren, beslissen en controleren zijn afzonderlijk vastgelegd.
- Leveranciersverplichtingen verwijzen naar concrete afspraken.
- Onbekende of gedeelde taken krijgen een eigenaar en vervolgactie.
Verdieping en begrippen
- EAW-codes
- Lokale verwijzingen die kaart, register, scenario en besluit met elkaar verbinden.
Wat beschrijft dit model?
Het EAW Cloud Responsibility Model legt per taak en clouddienst vast wie de taak uitvoert, wie een besluit of risico accepteert, wie controleert en welk bewijs die controle ondersteunt. Het model verbindt architectuur met dienstafspraken.
Afbakening
Dit is een productspecifieke uitwerking van verantwoordelijkheid. Een algemeen IaaS-, PaaS- of SaaS-label bepaalt niet vanzelf alle taken. De verdeling moet worden gecontroleerd tegen de gekozen dienst en overeenkomst. Een interne eigenaar kan geen leverancierstaak als contractueel afgesproken verklaren zonder bewijs.
Zo lees je de werkbladen
De codes zijn EAW-werkafspraken. Gebruik dezelfde codes in de kaart, registers en besluiten. De template bevat vier werkbladen; het voorbeeld vult precies dezelfde velden in.
Taken en verantwoordelijkheden
Dienst, workload, omgeving en contractversie. Maak onderscheid tussen uitvoeren, besluiten en controleren. Markeer voorstel, afgesproken, getoetst of onbekend.
Dienst- en contractgrens
Dienst, leverancier, klant en expliciete technische grens. Gegevenscategorieën en toegestaan gebruik. Exacte dienstbeschrijving, contractversie en relevante passage. Wat blijft aantoonbaar bij de klant? Hoe worden wijzigingen beoordeeld en wie beslist?
Controlecontract voor T-03
Taakcode, afgebakende activiteit en aanleiding. Welke partij doet precies welk deel? Wie accepteert de uitkomst en wie controleert het bewijs? Vereiste inhoud, vindplaats en geldigheid. Wat moet vooraf zijn afgesproken om een oordeel te kunnen geven?
Open punten en herbeoordeling
Ontbrekende afspraak, gevolg en eigenaar. Ontbrekende afspraak, gevolg en eigenaar. Wie krijgt welk probleem en wanneer? Akkoord, voorwaarde of uitstel met rationale. Gebeurtenis die herbeoordeling van de matrix veroorzaakt.
Fictief voorbeeld: Noordhaven
Alle toewijzingen en maatregelen zijn voorstellen binnen een verzonnen oefencasus. Zij zijn geen bewezen productiegedrag.
Taken en verantwoordelijkheden
Scope — Fictieve dienst C-01: beheerde aanvragenomgeving voor Noordhaven. Productie. Contractversie nog te bepalen.
Legenda — Uitvoering verricht het werk. Diensteigenaar accepteert namens de klant. Controlebewijs onderbouwt de beoordeling.
Bewijsstatus — Alle bovenstaande toewijzingen zijn fictieve voorstellen. Geen bestaande providerverplichtingen verondersteld.
Dienst- en contractgrens
C-01 — Fictieve provider beheert het platform. Noordhaven beheert gebruikers en eigen applicatieconfiguratie.
Gegevens en gebruik — Aanvragen en bijlagen. Classificatie en bewaartermijn moeten door de informatie-eigenaar worden vastgesteld.
Leveranciersbron — Nog geen contractbron. Leveranciersmanager verzamelt dienstbeschrijving en onderhoudsafspraken.
Eigen verplichtingen — Voorgesteld: gebruikersautorisatie, configuratiebeoordeling en functionele acceptatie van herstel.
Wijzigingsmelding — Voorgesteld: leveranciersmanager ontvangt melding; team Beheer beoordeelt impact; diensteigenaar beslist over acceptatie.
Controlecontract voor T-03
Taak en aanleiding — T-03: herstelproef voor C-01 vóór ingebruikname en na een wijziging die herstel beïnvloedt.
Uitvoering — Provider stelt herstelvoorziening beschikbaar; klantbeheer start de proef; applicatiebeheer controleert gegevens en verwerking. Voorstel.
Besluit en toetsing — Diensteigenaar beslist. Applicatiebeheer controleert het verslag. Escalatie naar leveranciersmanager bij ontbrekend bewijs.
Bewijs — Verslag met gekozen herstelpunt, feitelijke hersteltijd, controles en afwijkingen. Vindplaats en bewaartermijn nog afspreken.
Acceptatiecriterium — Hersteldoel en gegevensverliesgrens ontbreken nog. Zonder die afspraken geen conclusie dat het resultaat voldoende is.
Open punten en herbeoordeling
O-01 — Platformpatchverplichting T-02 nog niet bewezen. Leveranciersmanager verifieert contract en uitzonderingen.
O-02 — Hersteldoelen T-03 onbekend. Diensteigenaar bepaalt ze met proceseigenaar vóór de proef.
Escalatie — Klantbeheer meldt ontbrekend herstelbewijs aan diensteigenaar. Leveranciersmanager behandelt contractuele onduidelijkheid.
Besluit — Ingebruiknamebesluit uitgesteld totdat O-01 en O-02 zijn behandeld en de herstelproef is beoordeeld. Fictief casusbesluit.
Herijking — Wijziging van dienst, leverancier, contract, gegevensgebruik of herstelvoorziening. Diensteigenaar organiseert de review.
Gebruik het resultaat
Controleer de kwaliteitscriteria. Bespreek ontbrekend bewijs met de genoemde eigenaar en leg vast wanneer het model opnieuw wordt beoordeeld. Een ingevulde template is nog geen goedgekeurd ontwerp.
Verder werken
Gebruik een verwant onderwerp om een volgend deel van je vraag uit te werken.
Ook bij EAW
Je accountvoorkeuren worden geladen.
Achtergrond en bronnen
EAW-werkwijze en werktemplate. Voorbeeldcasussen zijn fictief.
Codes en modelstructuur zijn EAW-werkafspraken; geen formele notatiestandaard.
Versie 1.0 · Gepubliceerd
AWS Shared Responsibility Model
Parafrase: AWS beschrijft gedeelde verantwoordelijkheid waarvan de verdeling afhangt van de gekozen dienst. Dit is een leveranciersvoorbeeld, geen universeel contract voor andere providers.