Als auditor wil je dat elke stap in je controle herleidbaar, reproduceerbaar en uitlegbaar is. In traditionele auditdocumentatie leg je vast wat je hebt gedaan; met Git leg je ook vast hoe je het hebt gedaan. Python-scripts veranderen immers: je voegt nieuwe analyses toe, past filters aan of corrigeert berekeningen. Zonder goed versiebeheer is het lastig om te reconstrueren wat de versie was op het moment van controle. Git biedt hiervoor een oplossing, omdat elke wijziging aan je scripts wordt vastgelegd met datum, auteur en toelichting.
Het is wel belangrijk om te benadrukken dat Git niet automatisch bepaalt welke versie in het auditdossier is gebruikt. Dat blijft de verantwoordelijkheid van de auditor. In de dossiervorming kun je opnemen welke commit of tag hoort bij de gebruikte versie. Voorwaarde is dan wel dat iedere relevante wijziging daadwerkelijk wordt gecommit, zodat de historie volledig is.
Wat is Git en waarom relevant voor auditors?
Git is een versiebeheersysteem dat elke wijziging aan bestanden opslaat. Je kunt altijd terugzien wie iets heeft aangepast, wanneer dat gebeurde en wat er veranderde. Voor auditors klinkt dat bekend: audit trail – wie heeft wat gedaan, wanneer en waarom; reproduceerbaarheid – dezelfde analyse kunnen herhalen; en het vierogenprincipe – wijzigingen laten reviewen.
Een paar basisbegrippen vertaald naar audit-taal:
| Git-term | Audit-vergelijking | Betekenis |
|---|---|---|
| Repository | Dossiermap | De verzameling van al je scripts en documentatie |
| Commit | Werkdocument met handtekening | Een momentopname met beschrijving van wat je hebt gedaan |
| Branch | Conceptversie | Een tijdelijke kopie voor experimenten of alternatieven |
| Merge | Goedkeuring na review | Het samenvoegen van gecontroleerde wijzigingen |
Voorbeeld:
git init
git add analyse_inkoopprijzen.py
git commit -m "Eerste versie controle inkoopprijzen toegevoegd"
Git gebruiken in auditprojecten
Een goed Git-proces voorkomt onduidelijkheid over welke versie geldig is. Hieronder een simpele structuur die goed past bij audits:
/audit-python/
│
├── data/ # (geen gevoelige data in Git)
├── scripts/ # Python-scripts
├── output/ # Resultaten en logbestanden
└── README.md # Beschrijving van analyses en parameters
Elke wijziging leg je vast met een commit:
git commit -m "Toegevoegd: controle op dubbele leveranciers"
git commit -m "Fix: fout in datumfilter opgelost"
Zo ontstaat een logboek waarin precies te zien is welke controles zijn toegevoegd, wanneer ze zijn gewijzigd en waarom dat nodig was. In het auditdossier kun je vervolgens expliciet opnemen: “Scriptversie gebruikt in de controle: commit 7c4d2a4 (FY2024-Final).”
Wanneer Git wel en niet nodig is
Niet elke analyse vereist een uitgebreid versiebeheerproces. Bij een enkel script of een eenvoudig controlebestand kun je het script zelf opnemen in het auditdossier, inclusief toelichting en output. Git wordt vooral waardevol bij grotere of opgesplitste analyses, waarbij meerdere scripts samenwerken of verschillende personen eraan bijdragen. Ook bij analyses die worden gereviewd door een technisch specialist, die geen directe toegang tot het dossier heeft, biedt Git een praktische manier om wijzigingen te delen en te beoordelen zonder dat de volledige auditomgeving toegankelijk hoeft te zijn.
Samenwerken en reviewen
Git ondersteunt ook het vierogenprincipe binnen data-analyse. Door met branches en pull requests te werken, kunnen collega’s wijzigingen beoordelen voordat ze in de hoofdversie terechtkomen. Een branch is een aparte werkversie waarin je iets nieuws probeert. Een pull request is een verzoek om die wijziging samen te voegen met review. In plaats van “ik heb versie 3 aangepast” in een mail, ziet de reviewer direct in Git wat er veranderd is. Hij of zij kan commentaar toevoegen en de wijziging goedkeuren, net als een handtekening in het auditdossier.
Vastlegging in de audittrail
Git maakt de codegeschiedenis zichtbaar. Met één commando kun je zien wie wat heeft aangepast:
git log --oneline --graph --decorate
Het resultaat lijkt sterk op een audit trail uit een financieel systeem: een lijst met gebruikers, data, toelichtingen en versies. Je kunt commits exporteren naar PDF of markdown voor dossieropname en eventueel een tag plaatsen voor belangrijke versies:
git tag -a "FY2024-Final" -m "Versie gebruikt in de audit van 2024"
Zo kun je vastleggen welke versie van het script in de controle is gebruikt en aantonen dat de historie volledig is.
Best practices
- Commit messages: schrijf kort maar duidelijk wat er is veranderd, bijvoorbeeld “Toegevoegd: check op negatieve factuurbedragen.”
- Commit elke relevante wijziging, zodat de historie compleet blijft.
- Geen ruwe data in Git. Bewaar alleen scripts, documentatie en geanonimiseerde voorbeelddata.
- Gebruik .gitignore om lokale of gevoelige bestanden uit te sluiten.
- Gebruik tags voor belangrijke releases of afgeronde audits.
- Voeg een README toe met toelichting: doel, gebruikte bestanden en afhankelijkheden.
## GitHub, GitLab en DevOps in de auditpraktijk
Binnen auditteams is een centrale omgeving voor versiebeheer onmisbaar. Platformen als GitHub, GitLab en Azure DevOps combineren opslag, review en toegangsbeheer, waardoor scripts en analyses veilig en herleidbaar worden beheerd. Elke wijziging is gekoppeld aan een auteur, datum en toelichting, en via pull requests kunnen collega’s wijzigingen beoordelen voordat ze worden samengevoegd. In DevOps-omgevingen kun je bovendien kwaliteitscontroles automatiseren, zoals het afdwingen van reviews of het testen van scripts voordat ze worden goedgekeurd. Zo ontstaat een transparant en controleerbaar proces dat perfect past bij de eisen van een auditdossier.
## Conclusie
Git is niet alleen voor programmeurs. Voor auditors biedt het precies wat we zoeken: controle, herleidbaarheid en betrouwbaarheid. Met Git kun je aantonen wie iets heeft gewijzigd, waarom dat gebeurde en welke versie uiteindelijk in de audit is gebruikt. Door consequent te committen en de gebruikte versie in het dossier vast te leggen, ontstaat een robuuste en controleerbare audit trail voor data-analyses.
