Informatiebeveiliging bij verstoringen

Dit document is het continuïteitsplan van YipYip: welke verstoringen we voorzien en wat we dan doen. De technische uitwerking staat in 5.30.

Uitgangspunten

• Live applicaties draaien op GCP met de continuïteitsvoorzieningen van het platform
• Het team kan volledig remote werken; niet afhankelijk van het pand
• SLA’s met klanten bevatten alleen responstijden; geen uptime-garantie en geen RTO/RPO (zie 5.30)

Scenario’s en maatregelen

1. Groot incident bij GCP (uitval leverancier)

Leunt op de redundantie van GCP (managed databases, meerdere zones) en op back-ups (8.13). RTO en RPO zijn interne streefwaarden per project, geen contractuele afspraak; ze worden vastgesteld in de BIA (zie 5.30).

2. Verlies aan vertrouwen in Amerikaanse cloudproviders

Dit scenario ontwikkelt zich geleidelijk (bijv. door wetgeving als de Cloud Act). Acties:

• Directie besluit over overstap naar een vergelijkbare Europese leverancier
• Alternatieve leverancier moet voldoen aan vergelijkbare beveiligingseisen (5.19)
• Alle informatiebeveiligingsmaatregelen blijven van kracht tijdens migratie
• EU-regio’s hebben nu al de voorkeur (zie 8.20)

3. Faillissement van YipYip B.V.

Alle bronbestanden die tijdens projecten zijn vervaardigd blijven eigendom van YipYip. Bij faillissement:

• Bronbestanden worden volledig overgedragen aan de klant zonder bijkomende kosten
• Overdracht in andere situaties is bespreekbaar
• Na overdracht vervalt iedere garantie op het geleverde eindproduct en de werking

4. Uitval of vertrek van een groot deel van het personeel

Medewerkers zijn langere tijd niet beschikbaar, ongeacht de oorzaak. Acties:

1. Tot ca. de helft niet beschikbaar: opvangen met overwerk, klanten informeren over mogelijke vertraging
2. Als overwerk niet meer houdbaar is: tijdelijke inhuur overwegen, eerst binnen het netwerk van YipYip; tijdelijk personeel doorloopt de screening uit 6.01
3. Afhandeling van beveiligingsmeldingen en beheer van GCP krijgen voorrang

5. Wegvallen netwerk of internet in het pand

1. Oorzaak onderzoeken en mogelijkheid tot oplossen
2. Werkzaamheden voortzetten via 4G-hotspot (smartphones) of alternatieve werklocatie
3. Productie is niet afhankelijk van het pand (geen intern netwerk, zie 6.07)

6. Beveiligingsfout in ontwikkelde software

In uitgerolde productiesoftware zit een beveiligingsfout waardoor (persoons)gegevens onbevoegd ingezien of aangepast kunnen worden. Acties:

1. Direct maatregelen nemen om verdere schade te stoppen (bijv. dienst uitschakelen)
2. Oorzaak achterhalen voor corrigerende en preventieve maatregelen
3. Communicatie richting klant en andere benadeelden
4. Eventueel terugkeren naar een oudere productieversie via Git en de pipeline
5. Impact beoordelen en vastleggen in Jira IMS (5.24–5.28)
6. Logs en bewijs veiligstellen (5.28)
7. Melding bij de Autoriteit Persoonsgegevens bij een meldplichtig datalek (< 72 uur) en bij de verwerkingsverantwoordelijke

Verantwoordelijkheden

• Directie: beslist over activering van het plan, jaarlijkse review en test, beoordelen of het plan is gebruikt en vergelijken met opgetreden gebeurtenissen
• Alle medewerkers: verstoringen melden, herstelacties uitvoeren

Testplan

De directie plant jaarlijks een test (tabletop exercise of walk-through) van minimaal één scenario (controleprogramma C.12): voorbereiding, uitvoering, evaluatie, verwerken van verbeterpunten in dit plan.

NEN7510 zorgspecifiek

• Z8 — Continuïteit zorgprocessen: continuïteit specifiek voor zorgsystemen

Gaps

• De jaarlijkse test is voor het laatst uitgevoerd in juli 2022 (ISMS-177); daarna niet meer (ISMS-257 open). De volgende ronde loopt via C.12.
• RTO/RPO per project zijn nog niet vastgesteld (zie 5.30, ISMS-371).

Bewijs

• SLA’s en contractuele afspraken per klant: Sheet OUD 02.03.c
• GCP-console: configuratie per project
• Continuïteitstest: Jira ISMS C.12 (laatste: ISMS-177, juli 2022)