November 7, 2022

Haastige spoed is zelden goed. Zeker bij compliance.

Compliancy is regelmatig een onderwerp van gesprek, eigenlijk zou ik moeten zeggen; ‘onderwerp van discussie’ want in veel gevallen gaat het pas over compliance als er iets aan de hand is. Bijvoorbeeld als een organisatie op de vingers getikt wordt omdat de aanbestedingsregels niet (correct) gevolgd zijn, er niet op een goede manier is omgegaan met gegevens van (voormalig) medewerkers of er niet voldaan is aan eisen om de ‘license to operate’ te mogen behouden.

Het implementeren van alle voorschriften vanuit wet- en regelgeving en de toezichthouders is een belangrijke eerste stap, maar geen garantie dat er ook in de toekomst aan wordt voldaan. IT in het algemeen, en voor bedrijfskritische applicaties in het bijzonder, is zo'n snel veranderende wetenschap dat het regelgevingsproces het niet altijd bij kan houden. Het is slechts een ‘backstop’, om ervoor te zorgen dat het minimum wordt gedaan. Op het moment dat u vaststelt dat er aan alle eisen omtrent compliance voldaan wordt, is het dus goed mogelijk dat er alweer nieuwe wet- en regelgeving in de maak is. Voor IT-professionals is compliance daarom een continu proces. Download hier de template: Risk Assessment Framework en controleer zelf of jouw organisatie voldoet aan de richtlijnen die zijn opgesteld vanuit De Nederlandsche Bank (DNB).

Zo is het voor elk softwareontwikkelteam belangrijk om inzicht te hebben in hoe de applicatie exact toegepast wordt en of er speciale vereisten aan de data gesteld worden om de compliance te waarborgen. De ontwikkelmethodiek, het OTAP-proces (ontwikkel, test, acceptatie, productie) en audits dienen perfect op elkaar afgestemd te zijn. Aannemen dat het wel goed zit is niet goed genoeg meer. Een mooi voorbeeld hiervan is de scope van een ISAE 3402 type II verklaring. Dat de inhoudelijke correctheid door een geaccrediteerde IT-auditor is vastgesteld is natuurlijk heel goed. Echter, de ‘scope’ van de verklaring is hierbij een groot aandachtspunt, omdat het niet vanzelfsprekend is dat de specifieke onderdelen die voor uw situatie van belang zijn hier onderdeel van uitmaken. Denk bijvoorbeeld aan de bescherming van persoonsgegevens, dit is geen onderdeel dat standaard opgenomen wordt.

Naleving van compliance criteria wordt helaas vaak gezien als een rem op de softwareontwikkeling, waardoor creativiteit en verandering worden onderdrukt. Dat is niet juist in mijn optiek. Compliance dient de aandacht te krijgen die het verdient en wel in een zo vroeg mogelijk stadium van het softwareontwikkelproces. Dus niet als sluitpost aan het einde van het proces, maar als onderdeel van het fundament.

Het risico van het niet beleggen van een complianceverantwoordelijke binnen de organisatie resulteert in compliancereparaties aan het einde van het ontwikkelproces. Met niet of te laat opleveren als logisch gevolg. Kortom; financiële schade en daarnaast natuurlijk de hiermee samenhangende imagoschade.

Het klinkt zo voor de hand liggend. Echter, aannemen dat operations, security en compliancy-werkzaamheden altijd adequaat door het softwareontwikkelteam opgepakt worden blijkt in de praktijk tot teleurstellingen te leiden. Het is hetzelfde als verwachten dat de verkoopafdeling na een deal ook het project vlekkeloos oplevert én de administratie foutloos afhandelt. Begrijpelijk dus dat het niet altijd vanzelf goedkomt, want operations, security en compliance is nu eenmaal niet de core business (en vaak al helemaal niet de passie) van een softwareontwikkelaar.

Veel organisaties laten hiermee de kans om het volledige proces te automatiseren liggen. En automatiseren voegt juist zoveel waarde toe, omdat compliance regels dan maar op één plek ingeregeld hoeven te worden en daarna automatisch het gehele ontwikkelproces volgen. De implementatie is daarmee constant en voorspelbaar, hetgeen verassingen in de productieomgeving tot een absoluut minimum beperkt. En hoe beter geautomatiseerd, hoe meer tijd er voor softwareontwikkelaars over blijft zich te focussen op de deliverables van de sprints en binnen hetzelfde tijdsbestek meer functionaliteiten aan de applicatie toe te voegen. Kortom, maximaal automatiseren betekent maximaal compliant software, minimale kans op fouten, blije developers met als gevolg blije gebruikers en een betere concurrentiepositie.  

Graag een keer sparren over jullie specifieke compliance vereisten en hoe daarin zoveel mogelijk geautomatiseerd kan worden? Stuur mij een DM of bel ons op 088 099 00 00.

Deel deze post
Marijn Lergner
Marijn is Lead Engineer en tevens Partner bij ACC ICT. Marijn is vanaf 2010 werkzaam bij ACC ICT in verschillende rollen en begeleidt met veel enthousiasme en precisie zeer technische en complexe klantprojecten. Marijn schrijft graag over technische onderwerpen binnen de IT-branche.