De Sociale Verzekeringsbank (SVB) had dossiers per ongeluk gekoppeld aan verkeerde zorgverleners. Hierdoor konden mensen met een persoonsgebonden budget (pgb) soms persoonlijke gegevens inzien van zorgverleners die voor andere patiënten werkten. Dat heeft de SVB bevestigd aan de NOS.
De SVB bevestigde aan de NOS dat pgb-houders in Mijnpgb persoonlijke gegevens van zorgverleners kunnen inzien. Het gaat om adresgegevens, BSN-nummer, bankrekening, uurtarieven, betalingen, het type zorg dat wordt verleend en soms zelfs zorgovereenkomsten. Het zou niet om medische gegevens gaan, omdat deze niet in het systeem staan. De zorgverleners waarvan de persoonlijke gegevens worden getoond worden niet geïnformeerd door de SVB.
De SVB zegt de fouten te herstellen. Voor een klein aantal gevallen kan de foutieve koppeling niet direct ongedaan worden gemaakt. Dit blijkt uit de verhalen van (anonieme) bronnen van de NOS. Zo zegt iemand als sinds januari gegevens van een onbekend persoon te zien. Na verschillende meldingen via de telefoon en mail heeft de SVB gereageerd dat ze deze fout niet kunnen oplossen, waardoor de persoonlijke gegevens nog steeds zichtbaar zijn.
Ik ben benieuwd welke boete de SVB van het Cbp krijgt opgelegd voor deze datalek.
Hm, dit wijst op een groot aantal structurele fouten en zwakheden:
1. niet goed kunnen onderhouden van masterdata
met alle gevolgen van dien
2. “niet kunnen herstellen”… het gaat toch om een basisregistratie?
Dus daar hoort een correctie mogelijkheid in te zitten
3. security beheer zeer zwak [sic]
en het ergste:
4. niet kunnen koppelen in logische audit van posities:
Aanmelding/Registratie ZorgVerlener aan> Verplichting aan>
Faktuur aan> Betalingen aan> Correcties…
Dit zijn killer-factoren voor een dergelijke grote basis registratie!
Hoe lang duurt het tot de bom verder barst?
Waarom kunnen centrale overheden wereldwijd wel redelijk goed dergelijk grootschalig ContractAccounting uitvoeren en SVB niet?
Omdat het maatwerk in oracle en informatica is?
Zou de fouten binnen 30 minuten wel vinden!
Boetes helpen niet, daar het een uitvoeringsorganisatie is van onze fantastische rijksoverheid Het zou dus belastinggeld zijn waarmee ze een eventuele boete gaan betalen.
Ik denk niet dat de bestuurder van het SVB opdracht gegeven heeft aan een stel projectmedewerkers koppel dit aan dat. Wat mij betreft is hier gewoon niet getest. De vraag bij mij is om hoeveel mensen het hier gaat?
Als het er 10 zijn, vraag ik mij terdege af hoe de ICT/proces in elkaar steekt. Zijn het er daadwerkelijk duizenden, dan degene die het testen achterwege heeft gelaten (vaak door druk of geldgebrek van bovenaf) op het matje roepen.
Of gaat het hier om testen, testen, testen,,??
Dus een degelijke inspanning VOOR het in productie nemen.
Ook in deze situatie gaat het in ieder geval om (het ontbreken van) vakmanschap.
Waar gewerkt wordt vallen spaanders en morgen is het geen nieuws meer. Dat is het huidige arbeidsethos. Ze komen er gewoon mee weg.
@Walter: Het gaat er in eerste instantie om of SVB het datalek tijdig heeft gemeld aan CBP en aansluitend een gedegen risico- en impactanalyse heeft uitgevoerd en een verbeterplan heeft opgesteld en geëffectueerd.
Op basis daarvan kan pas een conclusie worden getrokken of er een boete moet worden uitgedeeld. Daarbij moet bovendien aantoonbaar zijn dat SVB de beveiligingsmaatregelen op orde had. Dus @Norman ook gedegen wijzigingsbeheer, testen voor in productie en OTAP. Bovendien moeten ook kritische acties van Functioneel Beheer en gebruikers aan het vier-ogenprincipe zijn onderworpen, waardoor in casu verkeerde koppeling van gegevens tijdig wordt gedetecteerd. Is aantoonbaar een PIA uitgevoerd? Heeft de organisatie of de systeemeigenaar de restrisico’s geaccepteerd? Kortom, is voldoende in informatieveiligheid geïnvesteerd?
Een uitdaging voor CBP, waarbij ik mag aannemen dat de besluitvorming van het CBP met het oog op de jurisprudentie openbaar zal zijn. Waar ligt de grens? De eigen risicoanalyse van de organisatie en uiteraard of de daaruit voorgestelde maatregelen ook daadwerkelijk getroffen zijn of een best practice. Ik denk dat in dit geval de BIR wordt gehanteerd. Het CBP kan zich in dat geval ook moeten uitspreken of de BIR toereikend is, dan wel aanvullende maatregelen getroffen zouden moeten worden.
Een interessante casus. In hoeverre heeft CBP compassie met “Onder druk wordt het treffen van adequate maatregelen op het gebied van informatieveiligheid en privacy vloeibaar”. Zal CBP zich uitspreken dat SVB een te zware last op de schouders werd gelegd door de snelle wijzigingen in het dossier PGB?
onzepgb, wel zo sociaal.
bsn, naam, adres, bankrekening, uurtarieven, betalingen.
Precies wat je nodig hebt om fraude te plegen.
Daarom worden de betrokkenen niet geinformeerd.
Ze gaan het wel herstellen, maar niet oplossen. Zo bleek kennelijk bij navraag 🙂
Waarschijnlijk om u nog beter van dienst te zijn.
“Het zou niet om medische gegevens gaan, omdat deze niet in het systeem staan”. Dat belooft wat met bigdata.
1. Plannetje op de achterkant van een bierviltje
2. Politieke can do houding bij staatssecretaris
3. Politieke invoeringsdatum
4. Politieke businesscase
5. Hebberige leveranciers
6. Bange ambtenaren
7. Geen commitment
8. Geen goede masterdata
9. Slecht testen wegens te weinig tijd
10. Doofpotcultuur bij Raad van Bestuur SVB
11. Verdonkeremanen van auditgegevens
12. Lapmiddel na lapmiddel
13. Overzicht wordt minder
14. Staatssecretaris wordt op politieke gronden in het zadel gehouden met 1 stem meer
15. Dit kan op termijn alleen door de 1e kamer gestopt worden
16. Wachten op de volgende klap
Fouten kunnen altijd en door iedereen gemaakt worden, maar dit soort rampen ontstaan alleen als er een keten van fouten ontstaat door slecht management tot aan de minister.
Oftewel een heel interessante case voor een ICT-projectmanagement opleiding.
Testen testen?
In een review van de architectuur en het design van het systeem had je dit soort problemen veel eerder en ruim voor de ingebruikname kunnen signaleren of, nog beter, voorkomen.
Ik ben echter bang dat er niet of nauwelijks een architectuur en design is, en als die er al zijn, de implementatie het design niet heeft gevolgd.
Dit soort dingen kunnen en moeten ‘by design’ voorkomen worden. Testen kan hoogstens aantonen dat het niet juist is uitgevoerd.
Dit is een goed voorbeeld van een ontwerpfout en ook een niet goed geteste functionaliteit die ook nog niet makkelijk ongedaan kan worden.