Does the following dialog ring a bell?
|Auditor:||How in the world was activity FS02 (Change G/L Account) not marked as high risk?!|
|Risk Manager:||Well… it was marked… but then John told me to remove it…|
|Auditor:||Can you show me the email from John?|
|Risk Manager:||Well… it should be here somewhere… let me try and find it…|
How about this one?
|Auditor:||How in the world is the activity Create Vendor not included in Vendor-Master group?|
|Risk Manager:||Well… it was included, but I took it out because you told me to…|
|Auditor:||Me? Can’t be!|
If these types of conversations sound familiar to you, you’re not alone. Across the globe, employees perform actions without documenting them. Then, when asked about the change (which apparently wasn’t supposed to be made…) they simply don’t remember or can’t find the appropriate evidence. This is definitely not ok when dealing with systems that can affect financial reports or other sensitive areas.
If you want to put an end to conversations with your auditor that begin with “how in the world”; and if you wish to answer the auditor without having to mumble “well…”; then my advice to you is: do not make any change that can be questioned by the auditor without documenting it first.
Documentation should answer (at least) the following questions:
- Who made the change?
- When was the change made?
- What was changed?
- Why was the change made?
- Who approved/required the change?
When your auditor arrives, be prepared with all the changes neatly and clearly documented. This way you will find required answers quickly and your auditor will trust you even more, as you have proven to reliably manage audit-related processes in your company.
Is your software sensitive?
This advice (do not make any change without documenting it first) also applies to software. Software tools that control important data or configurations should include a mechanism for recording user changes and documenting them for later inspection. In other words, sensitive software must include an audit-trail of any and all changes made to the software itself, including: recording of the change, the person who performed the change, the time of change and where the change was made.
Changes can be (and are) made to software. Here are some of my favorite examples (all true):
- Removing an activity from being marked as sensitive.
- Adding/removing an activity to/from an activity group.
- Approving a Segregation of Duties conflict.
- Setting a Segregation of Duties rule as inactive.
The more automated the software is in documenting changes, the less unanswered questions are left for your auditor. This equation will keep both you and your auditor confident and happy.