The Ultimate ITGC Documentation Checklist
Clarity with Chinmay - Edition 64
Want to read my audit deep-dives before anyone else? Get early access by subscribing on Substack. Every edition, straight to your inbox!
Summary Snapshot
If you only have two minutes:
- Documentation isn’t paperwork — it’s your thinking on paper.
- Every screenshot and sentence should tell the story of how the control works.
- Use this checklist to build audit files that are review-proof and professional.
When I first started reviewing ITGC documentation, I used to think of it as a mechanical task.
Open the workpaper. Check if the evidence is there. Tick the box. Move on.
But over time and through enough review comments to last a lifetime, I realized something simple but profound:
Documentation is not a formality. It’s a reflection of your thinking.
Every line you write, every screenshot you capture, and every word you choose tells a story. The story of how well you understand the control, its purpose, and the risk it’s designed to address.
This edition is not just a checklist.
It’s the complete blueprint of how to document and review an ITGC with depth, accuracy, and clarity using one of the most common yet misunderstood examples: Change Review.
The Control: Change Review
Control Description
“On a monthly basis, the Senior IT Manager for Enterprise Systems reviews all changes deployed to the production environment to confirm that each change followed the defined change management process, including documented approvals, testing evidence, and segregation of duties.”
Objective To ensure that only authorized, tested, and approved changes are moved to production.
Risk Addressed Unauthorized or untested changes could be moved into production, impacting data integrity, system stability, or financial reporting accuracy.
1. Start with the Story, Not the Screenshot
Before touching evidence, pause and ask:
- What is this control trying to achieve?
- What risk is it addressing?
- Where does it fit in the overall change management process?
You can’t review what you don’t understand. Let your documentation read like a walkthrough from request to approval to migration to review.
2. Structure the Documentation Logically
Your workpaper should flow like a story:
- Control summary – objective, frequency, control owner.
- Procedure performed – what you actually did.
- Evidence reviewed – list with consistent naming (01_Change_Listing_Jan2025.pdf).
- Results – factual conclusions.
Pro tip: Logical order = fewer review comments.
3. Keep Screenshots Clean and Consistent
- Keep sizes uniform and margins aligned.
- Highlight only what matters (approver name, date, ticket ID).
- Avoid circles and arrows unless essential.
Professional visuals build subconscious trust.
Recommended by LinkedIn
4. Write Like a Reviewer
Weak phrasing: “We ensured all changes were approved.” Better: “Reviewed March 2025 change log and verified approvals matched the defined process.”
Avoid absolute words like ensure, confirm, or guarantee they imply certainty auditors never have. Use reviewed, verified, inspected, compared, evaluated.
5. Validate the Period and Population
Always check that the review covers changes deployed within the audit period. System-generated listings reduce manipulation risk document the source.
6. Confirm Evidence Authenticity
All screenshots must come from production. Look for environment indicators (URLs, headers, timestamps). Anything from test or dev invalidates your result.
7. Check Completeness
For a Change Review, complete evidence includes:
- Change listing
- Review log or checklist
- Approval evidence
- Testing and migration proof
- Reviewer’s summary
If any piece is missing, flag it early don’t wait for final review.
8. Polish the Language
A strong workpaper reads smoothly. Watch for:
- Inconsistent capitalization
- Random punctuation
- Mixed tenses
- Over-nesting of bullets
Clarity = confidence.
9. Trace Evidence to the Source
Every file should tie back to a request. Create an Evidence Reference Index so reviewers can cross-link without opening ten files.
10. Document as if You Won’t Be There
If you left tomorrow, could someone else read your work and reach the same conclusion? That’s the gold standard.
A good workpaper tells the full story. A great one tells it without you in the room.
Why This Matters
Audit quality isn’t built in meetings. It’s built in the quiet discipline of documentation.
When your work is structured, consistent, and written with purpose, it speaks before you do and everyone around you feels it.
Key Reminders
- Start with the control, not the evidence.
- Document the story, not the steps.
- Keep formatting clean.
- Avoid weak audit jargon.
- Write as if someone new will read your work.
If this helped you: Share it with your team or save it as your new documentation checklist.
Audit with clarity,
Chinmay
Hi Chinmay, that's amazing.
These editions are quite helpful. 👍