Cologne Presentation

Good afternoon, ladies and gentlemen, and thank you very much to AXA Audit
NORCEE management for inviting me here to speak to you.

Let me introduce my self – my name is Christian KAZADI and I am an IT

Auditor of AXA Belgium.
My objective today is to present a concept used by AXA Belgium IT auditors to generate
automatically an audit program for application review.

I have divided my presentation into six parts.

First I’ll tell you a little about why we need to generate automatically an audit program
for application review, then I’ll show you the scope, the constraints, the application
selection, the audit program structure, the generation process, and finally I’ll deal with
the presentation of the tool.

My presentation will take around thirty minutes, and if you have any questions I’ll
be pleased to answer them at the end.

Okay, let’s start by looking at why we need to generate automatically an audit

program for application review.
Why do we need to generate automatically an audit program for application review?
As you already know, Operational audit regularly perform business processes review and
one or many IT Applications support those business processes.
Operational Auditors need to perform applications review during and complementary to
business processes review.
This intellectual exercise is repeated for each operational audit and for more than one
application during the audit.
The repeatability of this exercise makes it a good candidate for automation.

What is the approach?

The approach is to build a tool that will be capable to generate an audit program for
Application review.

Well moving onto scope.

What is the scope of this proof concept?

First of all, as the title show it and as I mentioned it in the introduction, the focus is
application review.
So the main asset is applications that support business process. Project and Infrastructure
are out of scope.
Next, I know many of you are familiar with the NORCEE Step-by-Step approach
and the audit program is one of the deliverable of the planning phase in the Step-by-Step
approach.
May I focus your attention on this figure.
You’ll notice that this figure show all the activities in the planning phase, in which you
have 1.4 audit program activity.

Right, I’ll talk now about constraints.

As you may be aware, we have to be compliance with standard.

What standards in our case?
- The first one is the AXA NORCEE Audit Universe, our audit subjects’ provider.
- The second one is COBIT 4.1 which provides us with Risks, Controls and Work
Steps to put into audit program.
- The third one is AXA NORCEE Step-by-Step approach: As I mentioned it in the
scope, all activities for building an audit program are in the Step-by-Step
approach.

But the compliance with standards is not the only constraints we have. Budget,
time and efficiency are also constraints.
The consequences are: the definition of criteria which help us not only to select
application to be audited but also work steps to put into audit program.

The last constraint is TeamMate: I am sure, you are all familiar with Teammate.
The structure of audit program have to be the same of the audit program in TeamMate
and the type of file which contains audit program must be imported into Teammate.

So I’ll move onto Application Selection.

The question is: What are the criteria to select application to be audited?
Keep in mind that the most important criteria is the risk profile of application and I’ll talk
about it after.
- One of the criteria are given by the Audit Universe Component. The Audit
Universe Component provides us with the component to be audited. When one or
more components are selected to be audited, they provide us with a list of all
applications which support these universe components. However, in this list we
can select only the applications for which this business process is primary.
Moreover, audit scope can force us to choose other applications for which this
business process is not primary, it depends on risk.

- The second criteria is application’s status. Application can have one of the
following statuses:
1. In Production
2. In Phase out
3. In Deactivation
4. In Decommissioned
5. Under Construction
 Our focus is on applications which are in production.

- The third criteria is the frequency: It is not important for us to audit the
application which was audited last year.

- Now, let us move onto the risk profile which is the most important criteria. In the
risk profile, the residual risk gives us the appropriate value to compare a lot of
applications.

How can we calculate the value of residual risk for an application?

Firstly, it is necessary to calculate value of the gross risk for this application
before having the value of the residual risk.

The value of the gross risk for an application results on the following equation:

Where, on the left of the equal sign, the value of the gross risk for application i
and on the right side of the equal sign, the first term is the weight of parameter j
and the last term is the value of this parameter for the application i.

Now, we have the value of the gross risk of application, we can deduct the value
of the residual risk of the application by using this equation:

Where, on the left of the equal sign, the value of the residual risk for application i,
On the right side of the equal sign, the first term is the gross risk of the
application i, the second term is the weight of parameter k and the last term is the
value of this parameter for the application i.

Have in mind that the sum of the weight of all gross risk parameters equal 1. It is
the same for the sum of the weight of all residual risk parameters.

The gross risk parameters are different from the residual risk parameters.

Here is an example of gross risk parameters: For each parameter, we have the
rationale, the possible value and the reference of where we can find this
parameter.

The possible values of these parameters are incomparable. Wee need a converter
to convert those possible values into intermediate values which are comparable.

The next slide shows the example of residual risk parameters. We have the same
remark as in the case of gross risk parameters.
 As seen previously, the possible values of parameters (residual or gross) are
uncomparable.
Due to this reason, we have chosen the following intermediate value: Very High,
High, Medium, Low, and Neutral.
So we have to convert the original value into the intermediate value and in trun
into the design value.

Let’s go on to the next point: Audit Program Structure.

The Structure of the audit program is coming from Teammate and the contents (Risks,
Controls and Work Steps) are coming from COBIT.

The basic element is the work step.

What is the problem here?

- First, all work steps in COBIT 4.1 are not applicable to the application review.
- Second, all applicable work steps do not have the same importance.
- Third, we have to customize all applicable work steps to AXA realities.

So, only 122 work steps are applicable to application review.

Those 122 work steps are customizing to AXA Belgium realities.

The only thing which remains to do is to give a ranking for each work steps.

The ranking gives the importance of each work step.

The ranking of a work steps k for application i results on the following equation:

Where, on left of the equal sign, the ranking of a work step k for application i and on the
right side of the equal sign, the first term is the influence of parameter j on the application
i and the last term is the influence of parameter j on the work step k.

The possible values of influence of parameter on application or on work steps are:

- V for Very High
- H for High
- M for Medium
- L for Low
- N for Neutral

Where can we select or eliminate a work step?

- First, we must define a reference ranking

- Second, the condition is that all work step which have a ranking greater than or
equal to the reference ranking are selected.
- The others one are eliminated.