Bij de selectie van softwaresystemen wordt door de gebruiker meestal uitgebreid aandacht besteed aan functionele eisen en wensen. Nu cloud-computing meer regel dan uitzondering is moet ook aandacht besteed worden aan beveiligingsaspecten in relatie tot internet. Daarnaast spelen audit aspecten een belangrijke rol. Een en ander samengevat onder Assuring (zekerheid). ZIe ook het thema "GRC en Assuring" op deze website.

Hierna wordt ingegaan op beveiligingsaspecten die te maken hebben met het gebruik van de software.

Voor meer (onder andere technische beveiligingsaspecten m.b.t. IT-ontwikkeling en organisatie) wordt verwezen naar het thema "cybersecurity" op deze website. 

De volgende beveiliging- en auditapecten zijn van toepassing:

• Op welke wijze hebben gebruikers toegang tot de applicatie?
  Er wordt in de praktijk steeds meer gewerkt met 2-factor authenticatie. Het gaat hierbij om een combinatie van kennis en bezit. Naast gebruikersnaam en wachtwoord is dan sprake van bijvoorbeeld het ontvangen van een eenmalig te gebruiken SMS-code die door de gebruiker wordt ontvangen op een smartphone. 
  
  
• Welke voorwaarden worden gesteld aan gebruikersnaam en wachtwoord? Met eigenschappen als:
  - Minimale lengte gebruikersnaam;
  - Minimale lengte wachtwoord;
  - Comninatie van kleine- en hoofdletters, cijfers en leestekens bij het wachtwoord verplicht stellen;
  - Wachtwoord niet zichtbaar opgeven;
  - Wachtwoord versleuteld opslaan.
  
  
• Wordt inloggen geblokkeerd na enkele foutieve pogingen en is er een logging van alle inlogpogingen?
  Als het inloggen na bijvoorbeeld 3 pogingen wordt geblokkeerd, bijvoorbeeld gedurende een half uur, dan wordt voorkomen dat continu ongewenst wordt geprobeerd om in te loggen. 
  
  
• Is er een logging van alle gebruikersactiviteiten?
  Hiervoor hebben we het gehad van een logging van inlogpogingen. Daarop volgend is een logging van alle gebruikersactiviteiten interessant. Dan is ook zichtbaar welke gebrukers, wanneer welke functies hebben gekozen en hoe lang. In dit kader is ook Process mining interessant. 
  
  
• Zijn er meerdere gebruikersniveaus in te stellen met verschillende rechten en rollen (zo ja, welke en op welk niveau)?
  Van belang voor de wat uitgebreidere administratieve softwaresystemen die gebruikt worden door meerdere personen in een organisatie. Ook van belang voor een accountants- of administratiekantoor dat online samenwerkt met cliënt. 
  
  Het principe is dat er gebruikersniveaus (funcies) wordt vastgelegd en dat elke gebruiker een niveau krijgt toegewezen. Vervolgens worden rollen vastgesteld die weer gekoppeld worden aan de gebruikersniveaus. En tot slot krijgen rollen rechten toegewezen om bepaalde programma's (of geavanceerder bepaalde programma onderdelen) te kunnen gebruiken. Het voordeel van het werken op deze wijze is dat niet aan elke individuele gebruiker (programma)rechten toegewezen hoeven worden. Naast het toewijzen van programma's aan rechten kan bijvoorbeeld ook vastgelegd worden of mutaties zijn toegestaan of bijvoorbeeld alleen raadplegen. Het beheer van rechten en rollen moet zeker niet onderschat worden en periodiek (bijvoorbeeld jaarlijks) gecontroleerd moeten worden op actualiteit.   
  
  
• Wordt bij alle mutaties de gebruiker bijgehouden? Zodat achteraf de gebruiker van een bepaalde mutatie eenvoudig getraceerd kan worden. Het klink misschien logisch, maar we komen dit zeker niet tegen bij alle standaard softwaresystemen. In elk geval tonen niet alle softwaresystemen de gebruiker per mutatie. Denk aan het vastleggen van een order of het wijzigen van een bestaande inkoopfactuur). Naast het bijhouden van de gebruker is het gebruikelijk ook de mutatiedatum (jjjj-mm-dd) en -tijdstip (uu:mm:ss) bij te houden.
  
  
• Zijn voorloopgegevens duidelijk zichtbaar op rapporten? Tegenwoordig wordt veel informatie, al dan niet via een dashboardfunctie, online geraadpleegd, waarbij ingezoomd kan worden op onderliggende gegevens tot aan de oorspronkelijke transactie en het onderliggende boekingsdocument toe. Een boekhoudpakket zal ook een balans- en resultatenrekening opleveren die bijvoorbeeld in PDF-formaat aan derden verstrekt kan worden. Het is dan van belang dat naast de juiste rubricering en bedragen ook zichtbaar is welke selectiecriteria zijn gebruikt bij het opvragen van de informatie. Dat begint als bij de geselecteerde periode op boekstukdatum van t/m. Zo is duidelijk of sprake is van gegevens over een heel boekjaar of alleen een deel daarvan.
  
  En als een systeem concept- en definitieve boekingen kent (wat we in de praktijk door een ontwikkeling als Robotic accounting steeds minder tegenkomen) is het goed om te weten of de conceptboekingen ook zijn meegenomen. Dit laatste in de wetenschap dat deze boekingen nog kunnen wijzigen en dus de rapportage kunnen beïnvloeden. 
  
  
• Is er een audittrail van alle mutaties? Zoals het wijzigen en verwijderen van instellingen, basisgegevens en transacties.
  Hiervoor is al aan de orde geweest het bijhouden van de gebruiker bij alle mutaties. Een audittail wil zeggen dat alle individuele mutaties gelogd worden. Als een inkooporderregel wordt vastgelegd en daarna 3 keer gewijzigd is ook sprake van 3 mutaties in de audittrail. En als betreffende inkooporderregel daarna wordt verwijderd is sprake van een 4e mutatie. Een interessant voorbeeld in het kader van fraudepreventie is het wijzigen van de IBAN bij een debiteur. Als dit laatste duidelijk wordt vastgelegd in een audittrail kan bij een latere controle eenvoudig achterhaald worden wie de IBAN heeft gewijzigd.
  
  Zwakke schakel is de gebruiker zelf
  Bovenstaande kan tot in de puntjes geregeld zijn, maar valt en staat bij een adequaat toegangsbeheer in relatie tot het softwaresysteem. Als toegangsgegevens op een Yellow-paper zijn geplakt op een scherm of als meerdere gebruikers dezelfde dezelfde toegangsgegevens delen, dan betekent dit dan een audittrail van alle mutaties opeens minder tot geen waarde heeft. En geloof het of niet: meerdere personen die gebruik maken van dezelfde toegangsgegevens is beslist geen uitzondering in de praktijk. Al is het maar omdat er met veel verschillende systemen wordt gewerkt met elk hun eigen toegangsgegevens. De hiervoor genoemde 2-factor authenticatie kan hier (deels) uitkomst bieden.
  
  
• Welke auditrapportages zijn opgenomen in het pakket? Deze vraag valt niet generiek te beantwoorden. Natuurlijk hebben we de hiervoor genoemde logging van gebruikersactiviteiten en de audittrail van alle mutaties. Daarnaast kent iedere pakketsoort eigen auditrapportages. Zo gaat de WIKI Boekhoudsoftware uitgebreid in op "Data-analyses voor audits binnen boekhoudsoftware". Bij logistieke-, handels- en productiesystemen zulle specifieke audits uitgevoerd worden op de voorraad. Zo moet de geplande voorraad in de tijd gelijk zijn aan de huidige voorraad, het aantal in bestelling (inkoop), het aantal gereserveerd (verkoop) of onderhanden in productie.
  
  We verwijzen specifiek naar het thema "Audit en data analyse" als onderdeel van het omvangrijkere "GRC en Assuring" op deze website. 
  
  
• Is er een beveiliging dat geen (basis)gegevens verwijderd worden waarop (financiële) transacties zijn geboekt?
  Een klassiek voorbeeld is het kunnen verwijderen van een grootboekrekening als er al op geboekt is, maar de boeking is tegengeboekt. Het saldo is dan wellicht NUL, maar toch hebben er boekingen plaatsgevonden op deze grootboekrekening en mag deze dus niet verwijderd worden. Wat betreft administraties moet ook rekening gehouden worden met een fiscale bewaarplicht van 7 jaar. 
  
  
• Zijn rapportages dermate beveiligd dat er geen gegevens beïnvloed kunnen worden? Dit laatste is bijvoorbeeld het geval als rapportages via Excel of Word aangemaakt worden. Een boekhoud- of andersoortig administratiesysteem kan volledig dichtgespijkerd zijn, maar als de financiële rapportage uiteindelijk via Excel (of een doortgelijke spreadsheet tool) wordt samengesteld kunnen alle cijfers alsnog aangepast worden. Een export naar een (zo mogelijk beveiligd) PDF-document ligt dan meer voor de hand. Of de inzet van professionele rapportagesoftware voor het maken van interne management rapportages of externe rapportages. Het het laatste geval moet er dan dan wel een geautomatiseerde controle zijn dat de gegevens uit de onderliggende administratie blijven aansluiten met de rapportages of dat in elk geval mutaties in de rapportagesoftware achteraf zichtbaar zijn. Voor boekhoudsoftware in het MKB is de XML Auditfile Financieel (meer over de XML Auditfiles) een veel gebruikt middel om cijfers uit het boekhoudpakket uit te wisselen met rapportagesoftware met behoud van de onderliggende (grootboek)mutaties. Vanuit de rapportagesoftware kan dan ingezoomd worden op deze mutaties. Meer over de XML Auditfiles... 
  
  
• Kan de gebruiker zelf een backup maken?
  Bij een lokaal geïnstalleerde toepassing (al dan niet op basis van outsourcing) is het meestal de systeembeheerder die een backup maken maken van zowel de programmatuur als van de database met gegevens. Bij systemen voor kleinere organisaties (ZZP/Klein MKB) kan de gebruiker in de regel zelf zorgen voor een backup van programmatuur en gegevens. 
  
  Bij cloud-computing via het SAAS-model ligt het allemaal net even anders. De aanbieder van de SAAS-dienst (kan de producent van betreffende software zijn, zeker als het gaat om toepassingen voor kleinere organisaties) is degene die standaard zal zorgen voor een backup van programmatuur en gegevens. Zeker als de omgeving wordt gedeeld met andere cliënten is het de vraag of gegevens eventueel voor een individuele cliënt teruggezet kunnen worden. En het zelf maken van een backup (voor bijvoorbeeld lokaal gebruik of export van gegevens) is zeker niet standaard. 
  
  Een punt om vooraf goed af te stemmen met betreffende softwareleverancier.