Managed hosting door True
Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het gedachtegoed van de redactie.

Omgaan met het begrip compliance

 

Computable Expert

ir. Larik-Jan Verschuren-Parchomov
Ceo, FUNDAMENTS BV. Expert van Computable voor het topic Cloud Computing.

Als er een term is die aanleiding kan geven tot verwarring, is het wel compliance. Dat is niet zo vreemd, want achter compliance, compliant of compliancy, gaat een generieke term schuil. Een term die weliswaar is te verklaren met een korte en bondige definitie, maar die per sector een andere invulling heeft.

Bij it en helemaal in het geval van cloudcomputing is compliance een begrip dat vaak wordt gebruikt. De achtergrond van deze populariteit is eenvoudig te verklaren. Juist omdat cloudcomputing een hoge mate van abstractie kent, is er een extra noodzaak het ontastbare zichtbaar en beter controleerbaar te maken. Daarom is compliance in de betekenis van 'doe wat je zegt en zeg wat je doet' een manier om gebruikers van cloudcomputing en eindgebruikers gerust te stellen. Het is een manier om aan te tonen dat de leverancier van de dienst 'in control' is. Vandaar ook dat compliancy en internationale ISO- of nationale NEN-certificeringen zo vaak in één adem worden genoemd. Het door onafhankelijke auditors laten vaststellen dat je 'in control' bent en daarmee in staat je te houden aan regels en afspraken is bijna de facto standaard om op dit punt te overtuigen.

Bovenstaande schets betreft de directe relatie tussen aanbiedende (de cloudprovider) en vragende partij (de klant). Cloudcomputing is echter net iets anders dan een regulier it-proces. Denk alleen maar bij de opbouw van IaaS, via PaaS naar SaaS. Een bedrijf dat zaken doet met een IaaS provider en daar de vraag neerlegt 'toon me aan compliant te zijn', heeft daarmee wellicht een te beperkte scope op de waarde- of informatieketen. Als de IaaS-provider vervolgens een aantal ISO- en NEN-normen met als extra een ISAE3402 laat zien, is de klant gerustgesteld. Eigenlijk zouden beide partijen hier geen genoegen mee mogen nemen.

Kennis

In het voorbeeld zou het de IaaS provider namelijk sieren als hij de vragen die hem zijn voorgelegd ook vertaalt naar zijn eigen cloudpartners, dus de PaaS- en de SaaS-leveranciers. De eisen die voor hem gelden, de toezeggingen die hij doet, kunnen die wel vertaald worden naar de dienstverlening van de partners? De IaaS-provider in de rol van hoofdaannemer kan deze vraag alleen beantwoorden als hij beschikt over voldoende kennis om de processen van zijn partners en onderaannemers te kunnen duiden. Alleen met die kennis en uiteraard in goed overleg is het mogelijk de vragen van de opdrachtgever over 'in control' zijn te kunnen beantwoorden.

Een willekeurig voorbeeld daarvan is de ondersteuning. Als de afspraak tussen de opdrachtgever en de IaaS-provider uitgaat van 24/7 ondersteuning, maar een van de partners hanteert een 8-5 schema, dan is dat een mogelijke horde voor het handhaven van de claim compliant te zijn in relatie tot de verwachtingen die de klant heeft. Dat in dit voorbeeld een betrekkelijk eenvoudige oplossing voor de hand ligt is logisch. Zorg dat dit is vastgelegd in contracten en sla's en neem die ook samen goed door.

Een andere reden voorzichtig om te gaan met het begrip compliancy is dat wat er onder wordt verstaan niet alleen per sector maar ook nog eens per land verschilt. Het eerste is logisch. Wat voor een bank van belang is zal niet geheel overeenkomen met de aandachtspunten die gelden in de medische of automotive sector. Daarom zijn er normen per sector en is compliance zonder toevoeging ('wij zijn compliant') vooral een containerbegrip. Automotive is trouwens een goed voorbeeld van een sector die internationaal opereert. De eisen die gesteld worden in het ene land moeten wel vertaald kunnen worden naar de situatie in een ander land. En waar dit geldt voor de producten zelf geldt dit uiteraard ook voor de faciliterende it-processen.

Ruggegraat

Daarmee zijn we weer terug bij it en compliancy. It is de ruggengraat van bijna elk proces. Dat de vraag naar compliancy primair wordt gesteld door opdrachtgevers, wil niet zeggen dat de cloud-hoofdaannemer met een periodieke audit aan al zijn verplichtingen voldoet (de klassieke haal- en brengplicht). Om het vertrouwen in it en cloud te vergroten kan hij zelf actiever opereren en vragen stellen in zijn eigen partnernetwerk, de schakels waar zijn dienstverlening van afhankelijk is (de ontwikkeling van awareness). Dit kan in de vorm van een audit die hij verlangt, omdat indirect zijn opdrachtgevers dat verlangen. Niets weerhoudt hem er echter van hier frequenter en op andere manieren aandacht aan te besteden.

Wat deze omgang met het begrip compliance niet kan bereiken is dat het volledig de status van containerbegrip kwijtraakt. Het draagt er wel aan bij dat steeds meer bedrijven doorkrijgen dat zij onderdeel zijn van een waarde- of informatieketen, dat langs elk aspect van de dienstverlening een lat gelegd kan worden en dat die lat per situatie en partij kan verschillen. In de ideale situatie levert de algemene vraag 'bent u compliant?' dan ook als antwoord niet een verbaasde blik op, maar het krachtige 'Ja, mijn deel van de keten is compliant volgens xyz en de direct aangrenzende schakels zijn dat ook'.

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/5257429). © Jaarbeurs IT Media.

?


Lees meer over


 

Reacties

Wat een productiviteit, in één week twee 'kneiters' van opinies.

Nu had ik net reactie gegeven aangaande het begrip compliance, stelde daarin dat het ging om de geldende (gedrags)regels wat meer met integriteit dan techniek te maken heeft. Vanuit die optiek is IT vooral het onderste deel van de ruggengraat, vergeet in dat geval niet de uitwerpselen in de vorm van data. Of alle data bewerkingsovereenkomsten volstaan is twijfelachtig als we kijken naar de kwaliteitsloop waarbij het altijd goedkoper (en makkelijker) moet, zeg maar het fenomeen van de scope creep. Hierdoor is integriteit ondertussen ook een leeg containerbegrip verworden, de natte scheet in een sinaasappelnetje zoals Radar aantoonde.

Afhankelijkheden tussen XaaS leveranciers beschrijven in in partnerschap lijkt me nogal verwarrend. Wat wordt er nu bedoeld ?
Een klant doet zaken met een SaaS leverancier die weer op afhankelijk is van PaaS en die weer van IaaS als die niet zelf host, stack dus ? Of een Eindklant neemt diensten af met S/P/IaaS leveranciers voor bepaalde zaken en daarnaast voor andere zaken weer diensten van andere S/P/Iaas leveranciers. Wie is er dan de hoofdaannemer ? De IaaS provider zowiezo niet lijkt me overigens, die levert alleen.

Wellicht kan Ewout die vraag beantwoorden. Die is het allemaal duidelijk en geloof ik en is weer productief met reacties.

@Felix
Betreffende de verantwoordelijkheden gaat het niet om de wie maar de wat.
Eerder schreef ik al hoe de keten bij providers soms in elkaar steekt:

1. Eerste-lijns provider levert functionele service (SaaS)
2. Tweede-lijns provider levert technische service (PaaS)
3. Derde-lijns provider levert facilitaire service (IaaS)

...mijn deel van de keten is compliant...

Deze 'loket compliance' is dan ook als DigiD, iedereen wijst naar elkaar. GRC-framewerken besteden veel aandacht aan 'Segregation of Duties' vraag. Als je vanuit die optiek met je ontwerp begint voorkom je verrassingen achteraf. Noblesse oblige?

Ewout,

Je beschrijft een stack, volgens mij het artikel ook. In een stack heb je alleen te maken met het bovenste deel, m.a.w. voor de eindgebruiker is er geen keten. Er is een dienst die geleverd wordt die gegarandeerd is door een SLA. Of dat nou een solide of sinaasappelnetje SLA is. Overigens, als je maar genoeg failover netjes bij elkaar bindt, dan support het ook zwaardere SLA. Zolang netjes toevoegen dus, totdat je compliant bent.

Partners zijn gelijkwaardig en als ze al afhankelijk zijn, dan is het wederzijds. Anders spreek je over afnemers en leveranciers. Of pianoplayers, net als Karremans. Eerder Louzy dan kneiter artikel.

In mijn optiek is IT niet de ruggengraat van elk proces. Het proces zelf dient de ruggengraat te zijn; IT is het zenuwstelsel dat zorgt dat e.e.a. functioneert. Een krakkemikkig proces leidt onvermijdelijk tot krakkemikkige IT.

Overigens is compliance voor de afnemer alleen relevant inzake de overeenkomst die hij heeft met zijn primaire leverancier: levert hij zijn dienst overeenkomstig de gemaakte afspraken. Waar een leverancier zijn diensten vervolgens weer mee opbouwt zal de afnemer een zorg zijn; voor hem is er maar één afspraak, één leverancier, één loket. Hij moet het niet anders willen.

@Felix
Ik beschrijf inderdaad een stack, ketting, supply chain, enzovoort. De prijs van integriteit zijn de kosten van een Max Havelaar sticker in de rode zee van uitbesteding. Zeg maar zoiets als t-shirts in sweatshops laten produceren maar toch een goed gevoel hebben omdat je zo modieus bent;-)

Vacatures

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×