![](bg2.png)
and invites applying the proposed extension for exis-
ting frameworks for future work.
2 RELATED WORK
2.1 Process Mining
Process mining is defined as the activity of discove-
ring, monitoring and improving real processes by ex-
tracting knowledge from event logs that are present in
Information Systems (van der Aalst, 2012).
Central to process mining is an event log, which
contains log entries of events that are captured by an
information system.
Each entry of a log presents an event and consists
of at least the following information: (case designa-
tion, activity label, time stamp). In practice, logs may
contain more information; so an event can be presen-
ted as an instance of a tuple (case designation, acti-
vity label, time stamp, resource, performer, product
description, order size...).
An event log of a process can be seen as a record
of all events of all cases of the process within a certain
time interval. Each case is a sequence of events.
There are different types of process mi-
ning (van der Aalst, 2011):
• Process mining may be organized as a process dis-
covery from a log. “For example, well-known al-
gorithms such as the Alpha algorithm can auto-
matically extract a Petri net that gives a concise
model of the behavior seen in the event log. This
gives the auditor an unbiased view on what has ac-
tually happened” (van der Aalst et al., 2010). The
model extracted from a log may be too detailed
for the level of abstraction needed to the auditor.
• Process mining may be organized as model con-
formance checking that uses a predefined process
model and compares this model with the data in
the event log. By doing this, one can answer que-
stions regarding conformance of a real-world pro-
cess as recorded in the event log to the model of
the process as it should be. A predefined model is
a prerequisite for conformance checking.
• Process mining may validate the compliance of a
logged process with the rules specified for a gi-
ven business process. Compliance with various
laws, regulations and standards is a well known
problem in business process development and ma-
nagement. The compliance can be checked at the
design time (Awad et al., 2009) and at run-time
(Barnawi et al., 2016).
2.2 Process Audit, Audit Statements
Such process mining types as process discovery and
conformance checking do not completely correspond
to the process audit in its traditional sense.
Process audit in practice is defined as obtaining
evidence that a process is in compliance with predefi-
ned rules called audit statements. Practical audit usu-
ally does not demand the existence of a given busi-
ness process model, as some adhocracy and adaptivity
are considered acceptable (Mintzberg and McHugh,
1985). Practical audit is executed unexpectedly or pe-
riodically. It’s major goal is to find evidence of viola-
tions of predefined rules and possibly find the reasons
of violations (Karapetrovic and Willborn, 2000). The
audit evidence is often obtained manually, by con-
ducting interviews with user about the process they
follow, or taking samples of cases that are executed
in the system. This evidence must then be compa-
red against documented procedures. The documented
procedures can be presented as a number of written
rules and regulations called audit criteria that pertain
to the business process and should be observed while
executing it (Karapetrovic and Willborn, 2000). In ot-
her words, the whole business process is usually not
specified in the documented procedures of audit.
Process audit risk influences the scope of audit
statements. The auditor focuses his or her effort on
formulating audit statements in the areas where most
risk is perceived. The risk is calculated as a function
depending upon the number of cases (process instan-
ces) that non-compliant with the audit statement, and
as the financial loss associated with all non-compliant
cases.
Audit statements specify the important rules as
principles which are not ready for process mining as
they do not name the process activities and data items
in the log structure.
For example, a simple ordering based rule is spe-
cified as ”no change to a request can be made after it
is approved” (van der Aalst, 2011). In order to auto-
mate the compliance checks to this rule, the auditor
needs some knowledge or assumption about the bu-
siness process activities that can be found in the log.
She can assume that there are activities ”Order Ap-
proved” and ”Request Order Change”. The auditor
should see a case as a sequence of events where the
activities have ordering relations, say one activity can
follow another. If these assumptions are made, then
the audit statement can be formulated as: ”Activity
Order Approved must never be followed by activity
Request Order Change (for the same Order)”.
A Practical Extension of Frameworks for Auditing with Process Mining
407