#118 | ITGC- System Change (Audit) Log Review

Hello, everyone! In this session, I’m going to be reviewing how to document a system change for audit log review. For those familiar with Change Management, you know that we need to monitor what changes have made to the database or to an ERP system in an audit or change log.

I’m going to walk you through how to do that review and save the documentation.

Here is the summary of what you will be learning this week.

What to write when doing this review
- Specific essential information is that needs to be written down and documented.
Change log system extraction
- Extracting the Change log into an Excel file along with the description, tab label, and essential information of the contents that was extracted.
Adding additional fields and description to the Change log
- Additional fields need to be added on the documentation to help the reviewers know what, when, and who made the changes in the ticket connected to the Help Desk Ticket.
Documenting steps that were made
- List all the necessary actions or step to finish the task along with the conclusion.

I suggest you watch the video. It’s easier to understand if you are a visual/audio learner. The content below is the same as the video. It’s for those who learn by reading.

Good Example of Documented System Change Log Review

I’m going to look at it from the doer’s (IT person’s) perspective and show you a good example of evidence to save.

Write down what you’re doing to review this Change log

Here is an example from one of our clients who had great documentation.

First, they wrote down just bullet points a Word document that said they extracted the unfiltered list of AXChangeLogs by running a query on the database.

Next, they created a new tab to show what the query results are, and then they created another tab by copying it, so it became two tabs.

Good Example of Documented System Change Log Review

Let me show what that does.

What this IT person did was to save the query. Above is the query they wrote, and you’ll notice that they’ve identified and save a copy of the scripts to run to get the report including the fields that they are pulling from such as the create date and time and the modified date and time.

Other details identified are the min and max values that defined the thresholds. One other important detail included is the date range of the script. For example, when reviewing changes to your system during the 1^st quarter, we want to ensure we are reviewing data between January 1^st and March 31^st, 2017. That helps us know the report that’s being pulled from the query is for the right date range. Normally, “Is it the right date range?” is one of the questions to ask when reviewing but in this case, we’re confirming it here.

You can see the change query settings for the date ranges and the various fields that we need. This is a good example of evidence.

Example of Resulting Change Log Extracted from System

Change log system extraction

Above is an example of a data extraction. The IT person said, “I extracted this, and I saved it into Excel.” This is what it looks like. What they’ve also done is name the tab, so it answers the question, “What is this content?” In this case, this file is very big, and we cut a bunch of things just so that you have an idea what it looks like when it comes out of the system. This is important.

Change Log Extracted from System – ITGC

Adding additional fields and descriptions of the changes

Now, the next thing that the person did was to add some additional fields, so that they could do this review. One of the fields added was the Ticket ID field, which was mapped to a Help Desk Ticket. Another field added was for the ticket description.

Here, you can see the date range for the time that we are reviewing. You can see who made the change in the system under the field called Modify. Indicated also were the initials or names of people who made that modification, which makes it good to track. When we do our audit, these details help us know who to look for or to direct our questions.

Now, you know the ticketing system. The goal is to have every change made to the system correspond to a Ticket ID. Having the ticket description is helpful so that we can say, “Ticket Number 00 is to adjust the roles in the AX. Ticket 657 was the ledger grouping mandatory condition for expense reports.”

The ticket descriptions help us understand the changes made and as I mentioned, we should have a ticket. We verify completeness of all the requested changes if there is a change without a corresponding Help Desk ticket. That’s where you start to research to answer the question, “could an unauthorized change been made to our system?”

That is why the Change log review is done…to make sure that all system changes were properly authorized and documented.

Good Example of Documented System Change Log Review – Identify Steps Performed with Report

Documenting steps that were made

Finally, you’re going to see here the rest of the steps that were done. The IT person did a great job. He said, “Mapped all the events associated with the changes by taking the following approach.”

They looked at the code deployments, and they also based the review on the time stamps that they observed.

Again, this is a good example of documentation to say what changes have been made to your system database, to the root database, and how we know that everything has been accounted for.

I hope this was helpful. This is really skipping through the process quickly because I’m sure that for the IT person doing this, it took a long time. Now, you know what a good documentation example looks like.

So to recap: