As an auditor, you want every step in your work to be traceable, reproducible, and explainable. Traditional audit documentation records what you did; Git also records how you did it. Python scripts evolve over time — new tests are added, filters are modified, or calculations are corrected. Without proper version control, it’s hard to reconstruct which version was used during the audit. Git solves this by recording every change with a timestamp, author, and description.
It’s important to note that Git doesn’t automatically define which version is used in the audit file — that remains the auditor’s responsibility. You can document which commit or tag corresponds to the used version. The key is that every relevant change is committed so that the history remains complete.
What is Git, and why is it relevant for the audit?
Git is a version control system that stores every change to your files. You can always see who changed what, when, and why. For auditors, this sounds familiar: audit trail – who did what, when, and why; reproducibility – being able to repeat the same analysis; and the four-eyes principle – having changes reviewed.
A few core Git concepts translated into audit language:
| Git term | Audit equivalent | Meaning |
|---|---|---|
| Repository | Audit file folder | The collection of all your scripts and documentation |
| Commit | Work document with signature | A snapshot describing what was changed |
| Branch | Draft version | A temporary copy for testing or exploring alternatives |
| Merge | Approval after review | Combining reviewed and approved changes |
Example:
git init
git add analyse_purchase_prices.py
git commit -m "Added initial version of purchase price control"
Using Git in audit projects
A clear Git process prevents confusion about which version is valid. Below is a structure that works well for audit projects:
/audit-python/
│
├── data/ # (no sensitive data in Git)
├── scripts/ # Python scripts
├── output/ # Results and logs
└── README.md # Description of analyses and parameters
Each change is documented through a commit:
git commit -m "Added: duplicate vendor check"
git commit -m "Fix: corrected date filter error"
This creates a detailed log showing exactly which tests were added, when they changed, and why. In your audit file, you can record: “Script version used during the audit: commit 7c4d2a4 (FY2024-Final).”
When Git is (and isn’t) necessary
Not every analysis needs an elaborate version control setup. For a single script or basic control file, you can include the script itself in the audit documentation, along with explanations and output. Git becomes valuable for larger or modular analyses involving multiple scripts or team members. It’s also useful when technical reviewers don’t have direct access to the full audit environment but still need to review the scripts.
Collaboration and review
Git supports the four-eyes principle in data analytics. Using branches and pull requests, colleagues can review changes before they’re merged into the main version. A branch is a separate working copy for experimentation, while a pull request is a formal request for review and approval. Instead of emailing “I’ve updated version 3,” the reviewer can directly see what changed in Git, comment on specific lines, and approve the change—like signing off in an audit file.
Recording in the audit trail
Git makes the history of your code visible. With one command, you can see who made changes and when:
git log --oneline --graph --decorate
The result resembles an audit trail from a financial system: a list of users, timestamps, descriptions, and versions. You can export commits to PDF or markdown for documentation and tag key versions for reference:
git tag -a "FY2024-Final" -m "Version used in the 2024 audit"
This allows you to prove which version of a script was used during the audit and that the full change history is preserved.
Best practices
- Write clear commit messages: briefly describe the change, e.g., “Added: check for negative invoice amounts.”
- Commit every relevant change, so the history stays complete.
- Never store raw data in Git – keep only scripts, documentation, and anonymized examples.
- Use
.gitignoreto exclude local or sensitive files. - Tag important versions (for example, when an audit phase is finalized).
- Add a
READMEfile describing the purpose, key files, and dependencies.
GitHub, GitLab, and DevOps in audit practice
Within audit teams, a central environment for version control is essential. Platforms like GitHub, GitLab, and Azure DevOps combine storage, review, and access management, ensuring that scripts and analyses are managed securely and traceably. Each change is linked to an author, date, and description. Pull requests allow colleagues to review and approve changes before they’re merged. In DevOps environments, you can even automate quality checks—such as requiring reviews or automated script tests before approval. This creates a transparent, auditable process that aligns perfectly with the requirements of an audit file.
Conclusion
Git isn’t just for programmers. For auditors, it delivers exactly what we need: control, traceability, and reliability. With Git, you can demonstrate who made a change, why it happened, and which version was ultimately used in the audit. By consistently committing and documenting the version used in your file, you create a robust, verifiable audit trail for your data analyses.
