This is the fourth in our review of the top 10 most used reports which are ERP agnostic, and sharing why they should be in all of our customer's toolkits.
Useful Report #4: Security Changes
For example, a line might show that Zach Wear made employee Rocky Balboa active in on July 27 at 7:44 am. In this case, the field is named Inactive and the before value is “T” for true, to indicate that the inactive flag was selected. The new value is “F” for false because the user is now active. The specifics vary based on how a specific ERP describes its security elements, and it’s usually easy to figure out. But what about that “context” thing I mentioned?
There’s another field on the Security Changes report labeled Context and it shows what mechanism was used to grant security. In this case the role was added via the User Interface and that’s what shows on the report. For cloud products, the change could have been made via a script, integration, or other mechanism. For an on-premise application, that change could have made directly in the database. Regardless of the mechanism, the report indicates that security was set via code rather than a human being. Knowing what mechanism was used to make security changes can help identify where a change may have been made inappropriately.
Reporting on security changes is typically used to regularly review security changes for appropriateness and to identify changes that may need additional research. Additionally, there are options to connect these changes to Jira or Zendesk tickets to provide evidence that an authorized change was properly completely.
It’s fun to see the response when people see a list of security changes for the first time. The report displays data commonly requested by auditors and getting all of this security information in one report with minimal effort is incredibly powerful for users.