Xpandion Blog

  • Home
    Blog Home This is where you can find all the blog posts throughout the site.
  • Tags
    Tags Displays a list of tags that have been used in the blog.

Are We Human or Are We Software

  • Font size: Larger Smaller
  • Hits: 6113
  • Print
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…

iStock 000016727717XSmall


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.

My advice?

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:

  1. Who made the change?
  2. When was the change made?
  3. What was changed?
  4. Why was the change made?
  5. 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. 

Yoav Michaeli joined Xpandion in 2008 as a team leader, and in 2010 Mr. Michaeli began managing the entire Research & Development group of the company. Prior to joining Xpandion, Mr. Michaeli served in an elite technological unit of the Israeli Defense Forces as a team leader for various key military projects. Among other achievements, he was instrumental in pioneering the use of advanced .NET technologies for large scale distributed systems. Mr. Michaeli is an expert in programming, agile development, application security and specialized programming techniques.


  • No comments made yet. Be the first to submit a comment

Leave your comment

Guest 24/06/2017


in XpandionPosted by Yoav Michaeli

Optimize Licensing Costs. Increase Security

These are amongst some of the most worrying words that enterprises and managers can hear.  And, yet, they are a part of day to day terminology- whether whispered behind  soundproof board room doors, discussed openly by upper management or colleagues addressing them casually over the wate...
in Security & AuthorizationsPosted by Dror Aviv

SUIM: The Pitfalls of Analyzing SAP Authorizations During an Audit

    37 inShare (This is the short version of an article regarding the most popular T-Code used to analyze SAP Authorizations. Download the full SUIM article including examples and screenshots). When it comes to SAP audit time, audi...
in Security & AuthorizationsPosted by Dror Aviv

How to Understand SAP Authorizations in 10 Minutes or Less

If you’re like most CIOs, CISOs or internal auditors that work in a company that has implemented SAP, every day you have to contend with overloaded terms like “Profile,” “Authorization Role” and “Authorization Object” and quotes such as “This person can't access the company code because he doesn’t h...
in Security & AuthorizationsPosted by Yoav Michaeli

Who Authorized It?!

"Who authorized it?" is definitely the most asked question following a fraud event or leakage of information.  

in Security & AuthorizationsPosted by Dror Aviv

Get Rid of Power Users Once and For All

Organizations have Power Users in all systems (at least I have not yet come across an organization without them). Power Users hold a vast amount of authorizations, or even full authorizations in specific applications.



157 Yigal Alon Street,

Tel Aviv 67443, Israel


US Office


33 West 19th Street, New York,

NY 10011, USA


India Office


C 103, Akruti Orchid Park, Andheri-Kurla Road,

Andheri East, Mumbai, India