Skip to Content
Author's profile photo Rick Porter

Simplifying the SAP IT Change Management Audit

This post starts a new series of blogs on the topic of simplifying an SAP IT change management audit through change control automation. In this post I will discuss the general rationale and scope of an IT audit and introduce the key elements of an IT change management audit. Over the next few posts I will be drilling down into the detail within each key element and discuss the value change control automation in simplifying the audit process.

IT change management audit scope

Change management is the process by which SAP system changes are requested, planned, scheduled, developed, tested, accepted and finally applied. Since each change has the potential to disrupt a stable productive system, it is necessary that each change be controlled through its lifecycle in a repeatable, auditable manner. The reason behind this being an auditable (in many organisations a regulated) activity is because, any exceptions to the process may result in serious disruptions to production costing organisations many millions of dollars very quickly – in effect it is a risk management strategy.

To cover off all aspects of change management the scope of an audit will include the following:

  • Review of change management process documentation, policies and procedures;
  • Evaluation of the change management processes including change request application, development, build test and deploy process, change acceptance and authorisation to production; and
  • Security evaluation around who is authorised to do what – such as develop changes, approve testing of changes, authorise a change into production, classify changes (standard or emergency for example) or have access to systems to make changes.

Key elements included in an IT change management audit

There are a number of key elements included in an IT change management audit that we will be discussing in some detail over the coming issues. Each element is critical to effective change management and ensures changes are developed, tested and deployed in a controlled and authorised manner.

Element 1: Change management policies and procedures

Reviews formally documented change management processes and ensures the processes have been and are being followed for each change introduced into the system.

Element 2: Change initiation and approval

Reviews change request initiation and approval processes to ensure each change is initiated in a formal manner and effectively approved.

Element 3: Development policies

Reviews the policies governing modification or development of code to ensure the development or modification is initiated in a separate system –  away from QAS or Production.

Element 4: Testing and acceptance

Reviews testing procedures and testing processes to ensure changes are satisfactorily tested before being approved for migration into Production.

Element 5: Deployment

Reviews approval procedures for changes going into Production to ensure that only authorised changes are deployed.

Element 6: Change management process compliance

Reviews deployed changes relative to change management process to ensure all deployed changes have complied with predetermined change management process.

Element 7: Emergency change management

Reviews process around the categorisation deployment of emergency changes to ensure emergency changes are properly managed even in emergency situations.

Element 8: Security

Reviews security around the development and deployment of software changes to ensure only authorised personnel are making changes as per predetermined policy.

Additional considerations

One of the main objectives of the IT audit team is to make certain that changes actually made to the SAP systems do not differ from the changes as documented and so a clear link between the technical changes (SAP transports and object changes) and the change request detail must be demonstrable.

Next blog

In the next blog I will take a deeper look at the first few key SAP IT change management elements i.e. change management policies and procedures and change initiation and approval.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Tina Seale
      Tina Seale

      Thanks for this great article. Need some advice please.

      Who should typically review the changes made in PRD vs what was documented in the change request?

      Another developer (Peer review), Management (Who probably doesnt understand the code) ?

      "One of the main objectives of the IT audit team is to make certain that changes actually made to the SAP systems do not differ from the changes as documented and so a clear link between the technical changes (SAP transports and object changes) and the change request detail must be demonstrable.?"



      Author's profile photo Rick Porter
      Rick Porter
      Blog Post Author

      Hi Tina,

      What you are referring to could be documented as part of the post PRD delivery review process but ideally should take place long before the change hits PRD. Typically prior to promotion to QAS and certainly as part of the QA process when the change request is signed off as approved for PRD.

      As per your comment, this approval should ideally come from someone who understands the change and so in some cases a dual approval may make sense - a peer review plus a manager review.

      Where an Agile like development process is in use - it is most likely that a peer review would be part of the process.

      There is no hard fast rule - its simply what each team decides will work for them. If the process is reviewed regularly then any inefficiency  should reveal itself soon enough.

      Hope this helps.

      Regards, Rick


      Author's profile photo Tina Seale
      Tina Seale

      Hi Rick

      Thank you for your feedback. It definitely makes sense to have the review done prior to it hitting PRD.