Kwaliteitsprofessionals en AVG

Voor een internationale financiële instelling heb ik het afgelopen jaar de AVG (Algemene Verordening Gegevensbescherming) impact analyse uitgevoerd en de oplossingsrichting gespecificeerd. AVG is overigens de Nederlandse interpretatie van het Europese GDPR (General Data Protection Regulation). Als Business Analist werkte ik voor de IT-organisatie; regelmatig werd mij de vraag gesteld: “Wat moeten we aan de IT-systemen doen om AVG-compliant te zijn?”

Impact

AVG-compliancy wordt alleen bereikt als de gehele organisatie eraan voldoet maar start bij de business / de lijn. De business processen en de bijbehorende gegevens moeten eerst in kaart gebracht worden. Data eigenaarschap moet aan de business toegekend worden en het gegevensverwerkingsregister, het middel om proces, doel en gegevens aan elkaar te koppelen, moet opgesteld worden. Dit vraagt inzicht in de gehele informatie- / gegevensketen. In het geval van een internationale organisatie moet er rekening gehouden worden met verschillende GDPR-interpretaties per land. Maak je gebruik van ketenpartners moet je ook weten wat zij met de gegevens doen. Hoe groter de organisatie, hoe complexer, hoe uitdagender.

Leerpunten

Voldoen aan de AVG zal voor elke organisatie een uniek traject zijn. Toch heb ik een aantal leerpunten verzameld die generiek zijn;

De business heeft de lead, niet IT. Ondanks dat business en IT inmiddels niet meer los gezien kan worden ligt de verantwoordelijkheid bij de business.
Ken je ketenpartners en maak afspraken met hen. Als data-eigenaar blijf je verantwoordelijk voor de gegevens, ook bij je ketenpartner. Zorg dat er goede afspraken zijn over gebruik, beveiliging en retentie.
Blijf in control van je gegevens, het is een continu proces. Zorgen dat organisatie per 25 mei 2018 voldoet aan AVG moet geen momentopname zijn. Organisaties moeten periodiek bewijzen compliant te zijn. Plan (dus) een ritme in waarin je met regelmaat monitort.
Voer de regie over de ketenpartners bij de uitvoering van de rechten van de (ex-) klanten en prospects. De data-eigenaar is verantwoordelijk voor de uitvoering van bijvoorbeeld het ‘recht vergeten te worden’. Ook bij ketenpartners!
Stem de eisen van verschillende organisatie onderdelen op elkaar af. Definieer generieke oplossingen om aan lokale (landelijke) GDPR-regelgeving te voldoen. De nuance zit vaak in de retentieperiode en lokale wetgeving.
Kijk ook verder dan de GDPR-eisen. Als organisatie moet je ook voldoen aan andere wet- en regelgevingen. Gegevens verwijderen kan strijdig zijn met bijvoorbeeld de belastingdienst of branche specifieke regelgeving.
Indien er gebruik wordt gemaakt van (internationale) softwareleveranciers, betrek hen tijdig om te voorkomen dat ze een generieke oplossing creëren die niet voldoet aan de lokale regelgeving.

De bovenstaande leerpunten zijn niet komen aanwaaien. AVG is nieuw, kennis is schaars, de rol van Functionaris Gegevensbescherming (FG) is nieuw en concrete richtlijnen ontbreken (lees de wettekst er maar eens op na). Door samen te werken in de keten, kennis en leerpunten te delen en elkaar te helpen verbeteren zijn we tot concrete eisen voor Business en IT gekomen. Dat is een gezamenlijke inspanning geweest.

Terugkijkend kan ik stellen dat mijn rol meer aspecten had dan alleen business analyse. De keten afstemming is een regierol geweest waar het bijeenbrengen van de verschillende belangen de focus had. Want uiteindelijk moet iedereen in de keten voldoen.

AVG/GDPR heeft impact op de gehele organisatie, 25 mei 2018 gaat de regelgeving definitief in en komt er een einde aan de voorbereidingsperiode van twee jaar. Ik verwacht dat het nog jaren duurt voordat organisaties de AVG-regelgeving in de genen heeft zitten. Kwaliteitsprofessionals die in staat zijn om proces en (IT) middelen aan elkaar te koppelen, liefst met AVG kennis, zullen het voorlopig druk hebben.

Identify kan u helpen om AVG-compliancy binnen uw organisatie te borgen door;

Procesverbetering / -optimalisatie;
Business Analyse Privacy by Design;
Herijking van de kwaliteitseisen IT systemen;
Kwaliteitsregie in de keten.

Pakketten en testen; een vertragende factor?!

Pakketten en testen. Is dat een logische combinatie? Is het inderdaad een vertragende factor of kan het elkaar juist versterken.

Pakketten kies je om bepaalde redenen. Het gebruik maken van generieke oplossingen of standaarden vanuit de markt, onvoldoende capaciteit om zelf te kunnen ontwikkelen etc. Zo zijn vele redenen te bedenken om te werken met (standaard) pakketten. Een pakket staat niet op zich maar is geïntegreerd in het totale landschap binnen een organisatie. Het pakket vult een onderdeel van de keten in. Daarbij is het natuurlijk van belang dat de keten goed functioneert en er voor zorgt dat de klanten tevreden zijn en blijven.

Zoals bij maatwerk systemen het geval is krijg je ook bij pakketten te maken met updates t.a.v. het pakket of bijvoorbeeld andere wensen t.a.v. de inrichting door bijvoorbeeld veranderende business omstandigheden. Deze wijzigingen moeten gevalideerd worden om te voorkomen dat er allerlei ongewenste neveneffecten gaan ontstaan. De benodigde inspanning kan flink oplopen en heeft wellicht ook een repeterend karakter bij meerdere releases per jaar. Vooral als er (nog) handmatig getest wordt. De benodigde inspanning wordt mede bepaald door de omvang van een regressietest. Uiteraard is deze omvang afhankelijk van de aard van de wijzigingen.

Handmatig testen heeft een grote waarde maar is niet toereikend meer gezien de hoeveelheid updates die beschikbaar zijn, de snelheid waarmee deze geïmplementeerd moeten worden en de tijd die nodig is voor de testuitvoering.

Dan is het toepassen van geautomatiseerd testen een absolute must om het ontwikkeltempo bij te kunnen houden. Zeker gezien als je richting een DevOps situatie gaat bewegen.

Echter, bij de introductie van testautomatisering worden nieuwe uitdagingen geïntroduceerd. Testautomatisering moet herhaalbaar, herbruikbaar en overdraagbaar zijn. Het opvoeren van een bijvoorbeeld een pensioen polis met ingangsdatum vandaag is mooi en de gedefinieerde testgevallen kun je vandaag perfect uitvoeren. Alleen morgen is vandaag niet meer en dan werken je gedefinieerde testgevallen niet meer. Kortom, je testgevallen zijn niet herbruikbaar en herhaalbaar.

Wat kun je er aan doen? De oplossing is voorhanden. Zoals je een informatiesysteem bouwt op basis van een architectuur moet je testautomatisering ook opzetten onder architectuur. We noemen dat testautomatiserings-architectuur waarmee je o.a. herbruikbaarheid en herhaalbaarheid van je geautomatiseerde testen bereikt.

Door deze aanpak kun je snel en gedegen een wijziging, fix, release etc. valideren waarmee de doorlooptijd van de test en daardoor de doorlooptijd van een release aanzienlijk kunt verkorten. Je bereikt dan de situatie dat testen geen vertragende factor meer is maar een katalysator om wijzigingen snel in productie te kunnen zetten.

Wil je meer weten over het opzetten van een toekomstvaste testautomatiserings-architectuur? Kijk dan in het boek: testautomatisering wendbaar organiseren of de website https://mailchi.mp/a6bc6ba0b694/testautomatisering.

Heb je naar aanleiding van dit artikel vragen?

Heb je een vraag of wil je met ons sparren? Neem gerust contact op met Martijn. Hij denkt graag met je mee!