Het wordt geen gezelligheidsbezoek, als uw leverancier komt controleren of u voor het gebruik van zijn software wel betaalt waar hij recht op heeft. Inventarisatietools zijn een noodzakelijke voorwaarde voor het succesvol doorstaan van een audit. Maar een plan­matige voorbereiding nog voordat u een aanzegging in de bus krijgt, is minstens zo belangrijk.

57 procent van de organisaties die de afgelopen twee jaar een soft­wareaudit meemaakten, kreeg een naheffing van zijn leverancier. Dat bleek onlangs uit een onderzoek van Express Metrix naar software-audits. En de bedragen waar het bij die naheffingen om ging, waren vaak niet misselijk. 15 procent kreeg een naheffing onder de 50.000 dollar, 24 procent tussen de 50.000 en 250.00 dollar, en de rest zat daar (soms ver) boven.

Maar ook als de software naar de letter van de licentievoorwaarden gebruikt blijkt te worden en een naheffing dus achterwege blijft, heeft een audit repercussies voor de betrokkenen. Vooral het tijdsbeslag wordt door de respondenten als ‘uitdagend’ ervaren. Men is er in de regel ook geruime tijd zoet mee. Bij 45 procent van de bedrijven duurde het onderzoek langer dan twee maanden. Een software-audit is, met andere woorden, een ingrijpende gebeurtenis met potentieel grote financiële consequenties.

Gartner-analist Jo An Rosenberger zou die conclusie volmondig onderschrijven. “Een audit lijkt op een wervelwind, ook wat de potentiële schade betreft. En het is niet de vraag of u een audit krijgt, maar wanneer. Niet voorbereid zijn is dus geen optie”, zei Rosenberger tijdens een presentatie van het C9-model dat Gartner ontwikkelde als leidraad voor het verminderen van de risico’s van audits door leveranciers. Van de klanten van Gartner heeft bijvoorbeeld 62 procent de laatste jaren een audit meegemaakt.

Het begint met inventariseren

Voorbereid zijn op een software-audit betekent om te beginnen weten wat u aan software in huis heeft en welke regels daarvoor gelden. Software asset management moet nauwgezet uitgevoerd worden. Dat betekent per product alle gegevens van de software en de functionaliteit vastleggen, maar ook het helder vastleggen wat de gebruiksrechten en –beperkingen, toegestane verwerkingen, toegangsrechten e.d. zijn. Dat laatste vindt Gartner zo belangrijk, dat het er een aparte stap van heeft gemaakt: het ophelderen van dubbelzinnigheden en misvattingen in het contract. Wat is een gebruiker in de visie van de leverancier? Een persoon, een apparaat? Hoe telt de leverancier processors? Per socket, per kern, met een eigen metriek? Wat is toegang eigenlijk, is dat overal ter wereld, mogen ook filialen de software gebruiken, mag ingehuurde derden toegang verleend worden?

Dat impliceert dat voorbereiding op een audit eigenlijk al eerder dient te beginnen: tijdens de aanschaf. Iedere term in een softwarecontract moet nauwkeurig gewogen worden tegen het beoogde gebruik, met een schuin oog naar de toekomst, en met in het achterhoofd dat iedere leverancier zijn eigen interpretatie aan termen kan geven. “Indirect access kan in SAP’s voorwaarden slaan op sensoren in een apparaat in het Internet of Things!”, noemt Rosenberg als voorbeeld. Wat tijdens een audit vervelende verrassingen kan opleveren voor bedrijven die zich daar niet van bewust zijn.

Een ander waarschuwing van praktijken waarmee men onbedoeld in de problemen kan raken – ook met betrekking tot SAP-licenties, wat echter niet wil zeggen dat dit soort situaties alleen bij SAP speelt – kwam anderhalf jaar terug van UpperEdge. Feitelijk verbieden SAP’s licentievoorwaarden namelijk het inlezen van gegevens die in zijn ERP-systeem zijn vastgelegd, door een niet door SAP geleverde applicatie als daarvoor geen aparte licentie is aangeschaft. Het verwerken van verkoopgegevens uit SAP’s ERP-systeem in een Excel-spreadsheet kan dus zomaar een overtreding van de licentievoorwaarden zijn. Nauwkeurig formuleren en bij het contract vastleggen van voorbeelden van wat wel en niet is toegestaan, kan veel problemen op dit vlak voorkomen.

Bij aanschaf van software moet men er ook op letten of de gebruiksvoorwaarden in het contract opgenomen zijn, of dat de leverancier verwijst naar zijn website. “Houd er rekening mee dat leveranciers die verwijzen naar voorwaarden op internet, die voorwaarden makkelijk kunnen wijzigen zonder dat u daar erg in heeft”, waarschuwt Rosenberger. “Print op het web gepubliceerde voorwaarden daarom, en hecht de uitdraai aan het contract. Probeer daarbij te bedingen dat geen eenzijdige wijzigingen mogelijk zijn. En probeer anders met een eventuele wederverkoper contractueel vast te leggen, dat die als onderdeel van de overeenkomst eens per maand doorgeeft of er wijzigingen zijn opgetreden in de licentievoorwaarden.”

Het is volgens Rosenberg ook aan te raden om heel specifiek vast te leggen, hoe de leverancier bij een eventuele audit zal tellen, en daarvan praktijkvoorbeelden te vragen; zelf moeten bedrijven dan met de contracten en de voorbeelden in de hand liefst eens per kwartaal inventariseren of het gebruik dat ze van de software maken nog in overeenstemming is met de gesloten licenties.

Team moet klaarstaan

Maar voorbereid zijn op een audit is meer dan de contracten goed op orde hebben en goed begrijpen, stelt Rosenberger. Voorbereid zijn betekent ook dat uw organisatie meteen in actie kan komen wanneer de aanzegging van een software-audit van één van uw leveranciers op de deurmat dwarrelt. En dat kan alleen wanneer duidelijk vastgelegd is en aan de betrokkenen gecommuniceerd is, welke medewerkers betrokken zijn bij een eventuele audit, vanaf de functionarissen die op de hoogte moeten worden gehouden tot en met de personen die verantwoordelijk zijn voor het traject. Met het samenstellen van zo’n team hoeft men niet te wachten totdat het verzoek tot een audit een feit is; het is zelfs niet wenselijk om daarop te wachten. Datzelfde geldt voor het vooraf vastleggen van het procesverloop, en het testen of de stappen verlopen zoals gedacht.

Van cruciaal belang bij het inrichten van het proces is, te voorkomen dat de audit van start gaat voordat aan een aantal voorwaarden is voldaan, adviseert Rosenberger. Een eerste belangrijke stap daarbij – na het informeren van betrokkenen dat een audit is aangezegd en het nalezen van de contractbepalingen – is het opstellen van een Non-Disclosure Agreement; het is namelijk heel goed mogelijk dat een software-audit tot situaties leidt waarin de wettelijke bepalingen of regels van toezichthouders rond vertrouwelijkheid van gegevens of privacy van klanten in het geding komen. Voordat men ook maar een medewerker of vertegenwoordiger van een softwareleverancier binnenlaat, moet men met de leveranciers contractueel vastleggen hoe daarmee om te gaan en welke beperkingen dat op kan leggen aan de manier van auditen, stelt Rosenberger.

Vooraf gegevens leverancier opvragen

Het is ook zaak van tevoren bij de leverancier die een audit wil houden op te vragen, welke gegevens hij van u heeft; zo kunt u die gegevens vergelijken met de eigen gegevens. Dat vormt vervolgens de basis van een overeenkomst waarin reikwijdte en methodologie van de audit worden vastgelegd. “Dat geeft niet alleen duidelijkheid, dat voorkomt ook dat de leverancier gaat zitten vissen. Een leverancier moet van tevoren duidelijk aangeven, wat hij wil controleren”, zegt Rosenberger.

Als onderdeel van de voorbereidingen op een audit moet de software gebruikende organisatie zich ook al beraden op de documenten die aan het eind van de audit getekend moeten worden, en liefst ook voorbeelden klaar hebben liggen van dergelijke documenten. Een belangrijk element daarbij is dat de leverancier aangeeft – eventueel nadat een geconstateerde overtreding rechtgetrokken is middels een naheffing – dat het gebruik op dat moment in overeenstemming met zijn licentievoorwaarden is. En er moet natuurlijk een plan liggen, hoe men na afloop lering trekt uit de ervaringen met een software-audit, en hoe men die ervaringen zodanig vastlegt dat de organisatie daar bij een volgende audit wat aan heeft, aldus Rosenberger.