ControlML: A domain-specific modeling language in support of assessing
internal controls and the internal control system
David Heisea,∗, Stefan Streckerb , Ulrich Franka
a Enterprise
b Information
Modelling Research Group, University of Duisburg-Essen, 45141 Essen, Germany
Systems Development Research Group, University of Hagen, 58084 Hagen, Germany
Abstract
In this paper, we refine and extend an earlier language design to introduce a domain-specific modeling
language (DSML) for internal controls modeling as an extension to an enterprise modeling method. The
language is aimed at supporting the assessment of a firm’s internal control system through the use of
conceptual models of internal controls. In the paper, we report on the design of the modeling language, on
its integration with the enterprise modeling method, present the language specification, and discuss language
applications in the context of the assessment of an internal control system.
Keywords: Internal control, Internal Control System, Assessment of Internal Controls, Conceptual
Modeling, Enterprise Modeling, Language Design, Domain-Specific Modeling Language, Design Science
Research
1. Introduction
The task of assessing a firm’s internal control system is beset by remarkable challenges: In addition to
the challenges posed by the sheer number of controls and their possible interactions, internal controls affect
the organization at different levels, refer to a multitude of resources and assets, and address a variety of risks
(Maijoor, 2000; Crawford and Stein, 2002). Hence, an assessment of the internal control system requires an
in-depth understanding of a firm’s business, the risks it faces and the controls it has put in place to treat risk
exposure at all relevant organizational levels. That understanding in turn implies an understanding of entity
objectives, business processes, organizational resources, structures, roles, and responsibilities (Rikhardsson
et al., 2006; Elder et al., 2010). Accordingly, the assessment task involves stakeholders with different professional backgrounds and perspectives on internal control matters including executives, line managers, process
owners, risk managers, internal and external auditors (Spira and Page, 2002). In this respect, the inherent
complexity is intensified by differing mindsets, diverging professional languages, and the resulting barriers
to communication.
∗ Corresponding
author: phone +49 201 183-2719; fax +49 201 183-4011
Email addresses: david.heise@uni-duisburg-essen.de (David Heise), stefan.strecker@fernuni-hagen.de (Stefan
Strecker), ulrich.frank@uni-duisburg-essen.de (Ulrich Frank)
Preprint submitted to International Journal of Accounting Information Systems
July 19, 2013
To cope with these challenges, methods and instruments are required that purposefully reduce the complexity inherent in the assessment of an internal control system and that facilitate communication about
internal control matters among diverse groups of stakeholders. Although business process models have long
been used to support the task, it has repeatedly been established that present business process modeling
approaches provide only limited support for assessing the internal control system. A comparative evaluation
study reviews prevalent business process modeling notations in the light of key domain requirements and
concepts and concludes that the studied approaches do not provide the required modeling constructs for the
assessment and raises the demand for constructs that specifically express the semantics of internal controls
(Carnaghan, 2006). Dunn (2006) in a commentary on the last study adds that present approaches do not
provide support for the appropriate representation of the relevant organizational context of internal controls
(i. e., entity objectives, business processes, organizational resources, structures, roles, and responsibilities).
Such concepts are, however, common to enterprise modeling approaches such as ARIS (Scheer, 1992), SOM
(Ferstl and Sinz, 1998) and MEMO (Frank, 2012) which provide further abstractions of the enterprise and
its organizational action systems (i. e., modeling constructs to create conceptual models representing, for
example, organizational resources, structures, roles, and responsibilities). While current enterprise modeling
approaches do provide support for aspects of the enterprise in demand when supporting the assessment of
internal controls, research on domain-specific modeling languages (DSMLs) for representing internal controls and internal control systems in the context of enterprise modeling approaches has—as far as we are
aware—been limited to early language design prototypes yet.
These observations have inspired our research on a dedicated DSML for internal controls modeling. The
present work follows a design science research process to develop such a DSML, ControlML, as extension
to an enterprise modeling method. In the paper, we refine and extend an earlier language design, report
on its integration with the enterprise modeling method, present the language specification, and apply the
language to demonstrate its practical use for assessing internal control systems.
The next section relates the present research to prior work on internal controls modeling. Section 3 comments on the research method. Design objectives, requirements, and essential assumptions are established in
Section 4. Section 5 outlines the theoretical and conceptual background informing the language design. The
structural specification of the language, its meta model, is discussed in Section 6. A prototypical language
application is devised in Section 7. The paper concludes with a discussion and an outlook on paths for
future research in Section 8.
2. Related work
Among the first research on internal controls modeling is that of Karagiannis et al. (2007). In their approach, three SOX-related modeling concepts—Control, Risk, and Account—are introduced as an extension
2
to an enterprise modeling approach and a corresponding modeling tool. Language concepts are specified
by a meta model (see also Karagiannis, 2008, p. 1164) and related to further concepts for risk management
such as Event and Action. Interpretation of the semantics of modeling concepts is, however, partly left to
the language user, as the meta model does not show attributes and the accompanying documentation does
not offer further details. Moreover, important aspects of the design of a DSML are only briefly discussed,
for instance, a notation and corresponding diagram types. In a series of papers, Namiri and Stojanovic
(2007a,b) identify additional domain concepts (e. g., Control Objective, Risk Assessment, Authority), and
visualize conceptual relationships in a UML class diagram notation (Namiri and Stojanovic, 2007b, p. 63).
Their “domain model” structures the technical terminology in the auditing domain with the intention to
“formulate logical statements representing the controls constraining the behavior of a Business Process”
(Namiri and Stojanovic, 2007b, p. 62). However, the domain model does not specify the details (i. e., syntax and semantics) of a DSML and nor does it account for further modeling concepts pertaining to the
organizational action system surrounding internal controls.
With a different focus on internal controls modeling, Sadiq et al. (2007) interpret controls in terms of
rules and target rule-based compliance checking based on automated reasoning (for related approaches,
see e. g., Governatori et al., 2006, 2008). In contrast to the present work, models of controls and business
process models are kept separate for pragmatic reasons: “prematurely load[ing] business process models
with compliance controls will be highly problematic from a practical standpoint” (Sadiq et al., 2007, p. 151).
Their approach starts from textual descriptions of controls in terms of normative statements such as “The
creation and approval of purchase orders must be undertaken by two separate purchase officers”. The
textual descriptions of internal controls are transformed into formal representations based on a modal logic
to be used to reason on compliance violation (Lu et al., 2007, 2008). A procedure to link the logic-based
statements about internal controls to process models is described, so that clauses appear as annotations of a
process model. Further rule-based approaches to modeling internal controls include the work on a PROLOG
implementation by Bailey, Jr. et al. (2000) and on a Petri net-based online auditing tool aimed at rule-based
compliance verification (van der Aalst et al., 2011). Petri nets have earlier been discussed as a means to
document business processes and corresponding internal controls also aiming at algorithmic verification of
compliance (Pitthan and Philipp, 1997; Chen and Lee, 2003). In a related approach, Weigand and Elsas
(2012) propose to derive internal controls from REA models based on an axiomatic foundation.
In summary, a rich body of literature contributes to modeling internal controls. However, prior work has
not closely examined the syntax and semantics of domain-specific modeling concepts for internal controls
modeling. Nor does any previous research deal with the intricacies of the reuse of concepts in the context of
enterprise modeling and of extending present enterprise modeling approaches with domain-specific concepts
for internal controls modeling. Based on the preliminary results of this ongoing research project (Strecker
et al., 2010, 2011a), the present work refines and extends an earlier tentative language design to introduce a
3
DSML for internal controls modeling as extension to an enterprise modeling method. Present rule-based and
formal approaches complement the conceptual modeling approach presented in this work with conceptual
models seen as a prerequisite to further automation. This brief analysis of the current state-of-the-art guides
our research on domain-specific modeling constructs in support of the assessment of internal controls.
3. Research method
The artifact designed in this research is a (domain-specific) modeling language; a linguistic artifact
consisting of an abstract syntax (represented as a meta model), a concrete syntax (a corresponding graphical
notation) as well as explanations of the intended semantics of language concepts in natural language (Wand
et al., 1995; Wand and Weber, 2002; Frank, 2002). The present work is based on a research method
configured for the epistemological particularity of research on modeling languages (Frank, 2006b). The
method is informed by fundamental thoughts rooted in the philosophy of language, such as the dilemmas
arising when attempting to evaluate an (artificial) language (Frank, 2006a). It has been refined over the
past 15 years (see Frank, 1998, for further historical context) and constitutes the methodological foundation
for long running design science research projects of which the present work is part (see Frank, 2012, for an
overview of projects and Strecker et al., 2011b, 2012, for recent research results). In the light of idealized
design science research processes (e. g., Verschuren and Hartog, 2005; Peffers et al., 2007; Geerts, 2011),
the present work reports on the activities of defining design objectives (Section 4), design and development
(Sections 5 and 6), and demonstration (Section 7) besides the previous problem identification and motivation.
The concluding section addresses further research activities, for example, those relating to the evaluation of
the artifact.
This work targets integration with an enterprise modeling method to benefit from reuse of existing and
mature modeling concepts and procedural guidelines. Developing a DSML in this context presupposes reconstructing technical terms of the targeted domain and their (perceivable) semantics (Ortner, 2008; Frank,
2010). One widespread approach to conceptual reconstruction—and that followed here—is to review, analyze, and interpret pertinent literature in the field under consideration (e. g., Gelinas et al., 2004; Dunn et al.,
2005a; Davis et al., 2007; Moeller, 2008; Elder et al., 2010). Reconstruction of a professional terminology is
an iterative process involving more than the identification of candidate (meta) concepts, their attributes and
relations. Instead it requires the identification and resolution of terminological ambiguity and truncation,
for instance, which may imply the introduction of additional abstractions. That in turn requires the shaping
of their intended semantics, and leads to designing abstractions (i. e., language concepts) appropriate for
domain-specific analyses and applications based on deliberate design decisions. The underlying research
method is therefore driven by devising and analyzing domain-specific use scenarios describing, among other
things, prototypical model-based analyses in the intended use context (Frank, 2013).
4
4. Design objectives, requirements and assumptions
The overarching objective of the design science research project in which ControlML and further
DSMLs were developed is to devise a comprehensive modeling method for governance, risk, and compliance
(GRC). The primary objective of the design of ControlML is to effectively and efficiently support stakeholders when performing an assessment of the internal control system. More specifically, this research is
aimed at supporting stakeholders interpreting internal controls and the surrounding organizational action
system when assessing the internal control system. Given that an understanding of the internal control
system is educed in group processes (Damianides, 2005, p. 79), its purpose is to support group processes by
reducing the complexity inherent in internal control systems and by providing abstractions tailored to the
perspectives of stakeholders involved. Consequently, this work is aimed at fostering and facilitating communication and collaboration among stakeholders participating in the assessment, and particularly addressing
interaction between auditor and auditee. It also aims to increase the transparency of internal control matters, specifically by visually representing internal controls as part of the organizational action systems, and
by improving traceability of the controls in place to treat risk exposure. These high-level requirements—
reducing complexity, fostering communication and collaboration, and improving transparency of internal
control matters—are refined to establish the subsequent requirements a DSML aimed at supporting internal
controls modeling should satisfy (see also Strecker et al., 2011b):
R1 A DSML should link internal controls to the surrounding organizational action system composed of all
organizational entities relevant to the assessment. This organizational context is provided by (at least)
entity objectives, business processes, business risks, performance measures, organizational resources,
structures, roles and their responsibilities (Carnaghan, 2006, p. 177). Rationale: The organizational
context in which an internal control is designed to be used is of particular importance to its accurate
interpretation (Sutton and Hampton, 2003; Spira and Page, 2002). Providing explicit and qualified
relationships between controls and organizational context by way of a DSML is seen as both contributing
to reducing complexity, and improving transparency of internal control matters.
R2 A DSML should account for relationships among internal controls on different organizational levels,
from IT operations to business processes to value chains to the organization as whole. Rationale:
PCAOB Auditing Standard No. 5 and other regulations assume relationships between internal controls
as expressed, for instance, by a control hierarchy (Gelinas and Dull, 2010, p. 241). Relations between
internal controls need not, however, be strictly subordinate. Rather, controls relate to each other in often
case-specific ways as exemplified, for example, by diverse taxonomies of controls (Dunn et al., 2005a,
p. 455). Explicit and qualified relationships among controls as part of a DSML promise to improve the
transparency of internal control systems and, specifically, the interrelations between internal controls.
R3 A DSML should account for the multiplicity of means to achieve control objectives and of the resulting
5
variety of internal control implementation. Rationale: A wide spectrum of ways to achieve control
objectives employing a multitude of different organizational measures including policies and procedures,
manual and automated controls is discussed (Gelinas and Dull, 2010; Elder et al., 2010). Providing
appropriate abstractions of control means by means of a DSML is seen as a contribution to improving
the transparency of internal control matters, and to reducing the complexity of internal control systems.
R4 A DSML should provide means for justifying the existence and relative importance of an internal control
and for revealing assumptions underlying internal control justification. Rationale: It has repeatedly been
suggested to foster communication and collaboration on internal control matters by annotating assertions
underlying the control specification and its intended usage (Carnaghan, 2006, p. 177). It is assumed
that by providing a traceable rationale of an internal control, accurate interpretation of internal controls
will be fostered and communication barriers among stakeholders lowered.
R5 A DSML should provide meaningful representations of internal controls and internal control systems
to satisfy the needs of affected groups of prospective users. To foster an intuitive use, representations
should, as far as possible, correspond with abstractions, concepts and (visual) representations known and
meaningful to the targeted group of stakeholders. Moreover, a DSML should provide means to integrate
the various perspectives with each other. Rationale: The assessment process involves stakeholders with
different professional backgrounds. To foster communication among these stakeholders, a DSML needs
to support the perspectives of different (groups of ) stakeholders into account.
It is assumed that satisfying these requirements will ensure the high-level requirements and the design
objective will be met. That in turn implies that hypotheses underlie the relationships between higher and
lower level requirements. It is, for example, assumed that if a modeling language supports integrated perspectives tailored to the needs of stakeholders involved in the assessment of internal controls, communication
barriers are lowered and collaboration among stakeholders with different professional backgrounds is facilitated. In other words, the language positively contributes to approaching the primary design objective.
In this regard, the identified requirements and the design goals guide the design of the modeling language,
ControlML.
5. Theoretical and conceptual background
Research on ControlML builds on a method for enterprise modeling, the “Multi-Perspective Enterprise
Modeling” (MEMO) method researched and applied since the early 1990s (Frank, 1994). The rationale for
choosing the MEMO method (subsequently referred to as MEMO) over other enterprise modeling approaches
such as, for example, ARIS (Scheer, 1992) is based on several considerations: (1) MEMO provides an
extensive set of modeling constructs relevant to designing a language for internal controls modeling, including
the modeling of organizational goals, units, roles, responsibilities, and resources; (2) MEMO is based on a
6
Meta Level / M2
Type Level / M1
Business Process
name : String
organisationalUnit : String
Server
name : String
type : {application, database, file}
< A/R Manager >
Financial eTransaction
Application Server
Authorize Credit
Instance Level / M0
< Smith, John D. >
Internal Control
designator : String
description : String
isPreventive : Boolean
Internal Control: „IO 3.3: Prevent unauthorized refund“
Description: Demands a segregation of duties in the
refund business process, i.e., a separate
authorization of the refund
isPreventive: true
Conducted at: ...
Responsible person: ...
< Miller, J.-A. >
Meta Type
Type
Instance
< Smith, John D. >
started: ...
completed: ...
Conducted at: 2012-09-24 13:45
Responsible person: Smith, John D.
Appl. Server #01
Authorize Credit
#6110840A4
Authorize Credit #....
Authorize Credit
#7781085C9
started: ...
completed: ...
Serial-No.: ...
Installed: ...
Appl. Server #02
Serial-No.: PX118D-07D
Installed: 2007-07-15
started: 2012-09-24 09:45
completed: 2012-09-24 10:04
Conducted at: ...
Responsible person: ...
instance of
Figure 1: Essential levels of abstraction in the MEMO language architecture: Instance, Type and Meta Type [@Publisher:
Please use colored figures for web and black/white-figures for print (the latter are provided in separate files marked with the
extension “bw”)]
meta modeling approach whose language architecture is extensible through DSMLs (Frank, 2011d) and
is complemented by guidelines and a process model aimed at the design of the respective DSML (Frank,
2010); and (3) in contrast to proprietary approaches, the specification of the MEMO method—especially
its language architecture, meta modeling language, and most language specifications—are publicly available
(Frank, 2012).
In MEMO, DSMLs are specified by a meta model, a corresponding graphical notation and accompanying
descriptions of language concepts and of intended semantics of modeling concepts in natural language. Thus,
a language specification is semi-formal as it comprises formalisms (i. e., the meta model and visual language)
and informally specified artifacts (i. e., verbal descriptions for those aspects of the language design that
should not or cannot be expressed (solely) through formal means based on a deliberate design decision).
The MEMO Meta Modeling Language (MEMO MML) and the MEMO language architecture serve as meta
modeling foundation for the design of ControlML. The language designer specifies modeling concepts of
the DSML (i. e., meta types) at the meta level—referred to as the M2 level in OMG terminology (see Fig. 1).
These meta types (e. g., Business Process) are instantiated by the language user (modeler) to types at the
type level (M1 ). Note that the MEMO MML is defined at the meta-meta or M3 level omitted from Fig. 1
(Frank, 2011d).
Building on the MEMO MML for defining language concepts of a DSML fosters the integration of
modeling languages. DSMLs are specified using the same meta modeling language, which enables the
7
language designer to reuse meta types already specified in a MEMO modeling language. Sharing common
concepts at the meta level (e.g., Business Process) leads to integrated models at type level, for example,
a business process model integrated with an organization structure model, with a model of IT assets, and
with a model of internal controls. Moreover, the reuse of existing modeling concepts promises to increase
the productivity of both language design and language application: Language designers benefit from mature
language concepts and notations and can focus on relevant additions and modifications at the meta level;
modelers and language users benefit from the reuse of existing models at type level (e. g., reuse of business
process models) and can focus on extending or refering to these models. Figure 2 illustrates the integration
of type level models in MEMO and shows diagram types provided by MEMO for different perspectives on an
organization from a strategic management perspective (a strategy net, goal system or value chain diagram)
to a business operations perspective (business process map, business process diagram, organization chart
diagram) to an IT operations perspective (an IT resource diagram or an object model). Each modeling
language in MEMO provides a set of language concepts for the aspects the language focuses on and that can
be reused in other MEMO modeling languages. Of particular importance for internal controls modeling are
(1) concepts for modeling organizational structure (to assess internal control scope); (2) business processes
and organizational resources (to determine the organizational action system surrounding an internal control);
(3) organizational goals, objectives and performance indicators (to analyze internal controls with respect to
entity objectives); (4) risk and impact in case of risk occurrence (to provide a rationale for control existence).
In this regard, a kernel of DSMLs and concepts is provided by MEMO: The organization modeling language (MEMO OrgML; Frank, 2011c) specifies concepts for modeling business processes and organizational
structures (e. g., Process, Event, and Organisational Unit) and dedicated diagram types (e. g., a business
process diagram detailing the control flow of a process) (Frank, 2011a,b,c). The goal modeling language
(MEMO GoalML; Köhling, 2012) provides concepts for modeling organizational goal systems (e. g., Abstract Goal, Accountability Relation). The strategy modeling language (MEMO SML) provides high-level
abstractions commonly referred to at the senior management level, for example, concepts for creating value
chain diagrams (e. g., Value Chain Activity). The IT modeling language (MEMO ITML; Frank et al., 2009)
allows the modeling of IT assets (e. g., Information System) and associations to the business processes they
are used in, among others.
The MEMO kernel of languages has been extended by DSMLs to support further analyses in various
application domains. Two extensions to the kernel are indicated at the right-hand side of Figure 2: The risk
modeling language (MEMO RiskML) provides concepts such as Risk and Effect Specification and diagram
types like the shown risk diagram which accounts for interrelations among risks (Strecker et al., 2011b).
The performance measurement language (MEMO MetricML) introduces concepts such as Indicator and
an indicator system diagram type in support of the reflective design and use of performance measurement
8
IT Resource Diagram
Strategy Net
Business Process Diagram
Business Process Map
Goal System Diagram
0 ..1
0 ..*
1 ..*
Figure 2: Integration of DSMLs in the MEMO method
0 ..*
u p d a t e ()
0 ..1
0 ..*
0 ..*
In t er fa c e
d e s c r ip tio n : S tr in g
s o u r c e ID : S t r in g
p r o t o c o l: S tr in g
0 ..1 in p u t P a r a m L is t: X M L S tr in g
r e s u lt : X M L S t rin g
o b ta in s d a ta f r o m
0 ..1
C h a p t e rS lid e
Text
c o n te n t: X M L S t r in g
g e tC o n t e n t()
V id e o
v id e o : V id e o
d e s c r ip tio n
g e t V id e o ( )
G ra p h ic s
c a p tio n : S tr in g
0 ..1
T itle S lid e
v a r ia n t o f
v a r ia n t o f
g e t T it le () : S tr in g
C o m p o s e d F ig u re
D ia g ra m
G ra p h ic s
fig u r e : G r a p h ic s
g e tG ra p h ic s()
0 ..*
F o rm u la
C irc le
R e c t a n g le
1 ..1
M o d e llin g L a n g u a g e
n a m e : S t r in g
0 ..*
C o n c ep t u a lD ia g ra m
M odel
st a tic R e p r e se n t a tio n : G r a p h ic s v ie w o n
n a m e : S tr in g
ty p e : D ia g r a m
0 ..* 1 ..*
D a t a D ia g ra m
v isu a lis a tio n T y p e : D ia g r a m
g e tD ia g r a m ()
L in e
st a r tP o sit io n : C o o r d in a t e
e n d P o s it io n : C o o r d in a te
R e g io n
fillC o lo u r: C o lo u r
r e lW id t h : P e r c e n t a g e
r e lH e ig h t : P e r c e n t a g e
r e lP o sit io n : C o o rd in a te
P u b lica t io n
tit le : S tr in g
...
d e fin e s la y o u t o f
C h o ic e
0 ..1
A ss ig n m e n t F ra m e S ty le
...
In h e r it s fr o m
0 ..1
O p e n Q u e st io n
G ra p h ic sO b je c t
lin e C o lo u r: C o lo u r
A d v ic e
w a r n in g : B o o le a n
e m p h a sis : In t e g e r
C it a t io n
A s sig n m e n t
g r o u p W o r k : B o o le a n
tim e F r a m e : In te g e r
0 ..*
Q u e s t io n
0 ..1
Q u e s t io n F ra m e S t y le
...
F ra m e S t y le
ic o n : G r a p h ic s
0 ..* ...
d e f in e s la y o u t o f
S lid e S ty le
h e a d lin e F o n t: F o n t
0 ..* f o o tlin e F o n t: F o n t
0 ..1
...
C h a p te r S t y le
0 ..*
c r e a t e d : D a te
c h a p te r F o n t: F o n t
S ty le
h e a d lin e F o n t: F o n t
cre ate d : D ate
f o o tlin e F o n t: F o n t
r e g u la r B a c k g r o u n d : C o lo u r
fo n t: F o n t
0 ..1 ...
fo n t C o lo u r: C o lo u r
P r e se n ta t io n S t y le
t itle B a c k g r o u n d : C o lo u r
c h a p te r B a c k g o u n d : C o lo u r
t itle F o n t: F o n t
r e g u la r F o n t: F o n t
0 ..1
h e a d lin e F o n t: F o n t
f o o tlin e F o n t: F o n t
...
d e f in e s la y o u t o f
0 ..1
R e g u la rS lid e
0 ..* t itle : S t rin g
0 ..*
1 ..1
1 ..1
d e f in e s la y o u t o f
1 ..1
0 ..*
d e fin e s la y o u t o f
r e p r e se n ts
T a b le
n u m b e r O f R o w s : In te g e r
n u m b e r O f C o ls : In t e ge r
g e t A r r a y ()
Lo go
0 ..1
0 ..* g e tT itle () : S t r in g
0 ..*
A b st ra c t F ra m e
r e lW id t h : P e r c e n ta g
r e lH e ig h t: P e r c e n ta g e
r e lP o sitio n : C o o rd in a te
F o o t lin e
A n im a tio n
e f fe c t: A n im a t io n T y p e
0 ..1 o n E v e n t: E v e n t T y p e
1 ..*
r e p r e s e n ts t itle o f
0 ..*
S lid e
t itle : S tr in g
c r e a te d : D a te
sid e R a tio : R a t io
F ra m e
M a s t e rF ra m e
H e a d lin e
in c lu d e s
in c lu d e s
0 ..1
1 ..1
0 ..*
r e p r e se n ts title o f
0 ..*
S im p le P re se n t a t io n
1 ..1
0 ..*
0 ..*
1 ..1
C h ap ter
P r o x y S lid e
sta r ts w it h
t it le : S t r in g
0 ..*
1 ..1 g e t S lid e N o ( ) : In te g e r 0 ..1
g e t C h a p te r N o ( ) : In t e g e r
0 ..1
0 ..1
1 ..1
su c c e s so r
su c c e sso r o f
of
v a r ia n t o f
0 ..*
S t ru c t u re d P r e se n ta t io n
P re se n t a t io n
d e sc r ip t io n : S t rin g
c r e a te d
cre ate d : D ate
0 ..*
1 ..* t it le : S t r in g
su b T itle : S t r in g
Object Model
A u th o r
la st N a m e : S t rin g
fir st N a m e : S tr in g
0 ..1
Value Chain Diagram
Organizational Chart
starts with
includes
Diagrams of core MEMO languages
starts with
instance of
9
inherits from
includes
inherits from
Indicator System Diagram
Risk Diagram
Diagrams of extensions to MEMO
Meta Type – abstracts over a set of similar types
and describes their structure in terms of attributes
(Abstract Meta Type – The italic header
characterizes the Meta Type as abstract, i.e., it
cannot be instantiated)
Language – The colored rectangle serves as unique identifier for the modeling
language this meta types origins from; hence the specification of the meta type
can be found in the specification of the originating modeling language.
<EntityName>
Meta-Association – describes a relation between the
two connected meta types; is further qualified by a
designator, multiplicities and (optional) roles
Generalization/Specialization
Attributes – Attributes are initialized upon
instantiation of the meta type, i.e., they
are assigned a value; can (optional) have
a multiplicity that describes the amount of
initializations
Role – describes the participation of
this meta type in the association
further
<EntityName>
<role>
<Designator>
<AttributeName> ':' <EntityName>|<TypeName>
<AttributeName><AMultiplicity> ':' <EntityName>|<TypeName> <Multiplicity>
<Multiplicity>
i <AttributeName> ':' <EntityName>|<TypeName>
Intrinsic Attribute – are not initialized
upon instantiation of the meta type like
regular attributes, but one level further
down
<#>
Surrogate – serves as a surrogate for various other meta
types and, thereby, aims to reduce the complexity in the
visual represenation of the meta model (e.g., by reducing
the amount of meta-associations in the meta model); a
surrogate should always be used with exemplary meta
types the surrogate serves to abstract over
<String>
<EntityName>
Multiplicity (also: Cardinality) – describes to how
much instances of this meta type one instance of the
distant meta type is at minimum/at maximum is
connected to
Constraint – describes particular constraints that have
to be valid for all instances of the meta type; can be
described in natural language or, e.g., using the OCL
‘<<surrogate>>‘
<EntityName>
<EntityName>
<EntityName>
<EntityName>
Surrogate Relation – serves to describe exemplary meta
types the surrogate serves to abstract over; note that the list
of meta types is always exemplary, that is, not complete
Figure 3: Overview of key concepts and notation elements of the MEMO Meta Modeling Language (MEMO MML)
systems (Strecker et al., 2012). These modeling languages are integrated with each other through common
concepts at the meta level. For example, the concept of Process defined by the MEMO OrgML is reused in
the GoalML (which goals does a business process pursue?), in the ITML (where is an information system
used?), and in the RiskML (which business processes are affected by a certain risk type?). In Figure 2, the
integration of the modeling languages by sharing meta types is exemplarily indicated by the edges drawn
between the diagrams. In the meta models, the reuse of a concept originally specified in another MEMO
modeling language is indicated by a color-coded language identifier attached to the meta type. Figure 3
offers an overview of key concepts and notation elements of the meta modeling language, MEMO MML.
While at first, the MEMO MML looks similar to the UML MOF and UML class diagrams, it differs in
three respects (for a detailed comparision of MEMO MML and UML MOF, see Frank, 2011d): First, the
MEMO MML focuses on concepts necessary for meta modeling and, thus, does not come with the complexity
of a multi-purpose approach as, for instance, UML MOF. Second, as a dedicated meta modeling language,
the MEMO MML contains concepts which specifically provide possible solutions to known challenges in
meta modeling. And third, it has a specific graphical notation to support a clear visual distinction between
meta models on the one hand and models at type level (and, specifically, UML class diagrams) on the other.
10
6. Language Design: The MEMO Control Modeling Language (MEMO ControlML)
6.1. Terminological analysis
In auditing literature and practice, the terms “control”, “internal control”, and “internal control system”
are commonly used (Moeller, 2008). Despite their proliferation, the lack of a precise definition has repeatedly
been commented upon (Maijoor, 2000). The term “control” is subject to a considerable diversity of uses
and disciplines, for example, “management control, organisational control, internal controls, operational
control and financial control, which all seem to revolve around the same concept” (Rikhardsson et al., 2005,
p. 5). The auditing perspective on internal control is decisively influenced by the Committee of Sponsoring
Organizations of the Treadway Commission (COSO) (COSO, 1992, 2004) and subsequent auditing standards
such as the PCAOB Auditing Standard No. 5 (for a discussion see Maijoor 2000 and Rikhardsson et al.
2006): “COSO defines internal control as a process, effected by an entity’s board of directors, management
and other personnel. This process is designed to provide reasonable assurance regarding the achievement
of objectives in effectiveness and efficiency of operations, reliability of financial reporting, and compliance
with applicable laws and regulations. [. . . ] Internal control is not merely documented by policy manuals
and forms. Rather, it is put in by people at every level of an organisation. [. . . ]” (COSO 2010; adapted
from COSO 1992).
While this very broad conceptualization provides insights into essential domain-specific concepts (e. g.,
objectives, policy, reasonable assurance), it also points to terminological ambiguity: The concept of “internal
control” includes both, procedural (i. e., dynamic) aspects (i. e., business processes, auditing and monitoring
processes) and structural (i. e., static) aspects (e. g., policies, organizational structures, organizational roles).
It also links to other concepts such as risk or control objectives: “Enterprise risk management is a process,
[. . . ] designed to identify potential events that may affect the entity, [. . . ] to provide reasonable assurance
regarding the achievement of entity objectives” (COSO, 2004, p. 2). In fact, the COSO framework breaks
down “internal control” into five interrelated components: Control Environment, Risk Assessment, Control
Activities, Information and Communication as well as Monitoring (Gelinas and Dull, 2010, pp. 224–225). A
prevalent representation of “internal control” in auditing practice is the “control matrix” (Gelinas and Dull,
2010, p. 227) and its variants, for example, a (process and) control matrix which maps control objectives to
relevant control means grouped by business processes (Gelinas and Dull, 2010, p. 649).
A key domain concept is the control objective, sometimes also termed the control goal (Gelinas et al.,
2004, p. 249). It represents a desired state of an enterprise (e. g., “Prevent unauthorized refunds”) with
respect to achieving an entity objective (e. g., “Minimize error rate of incorrect refunds”) that is threatened
by a risk (e. g., “Internal fraud due to fraudulent behavior of employees”). A control objective is associated
with a recommended course of action that should be taken to provide reasonable assurance that entity objectives will be met and, thus, corresponding risks of not achieving it are mitigated. The course of action can
11
involve policies, procedures, practices, or organizational structures as concrete measures or means of control
implemented to ensure effectiveness of a control (Elder et al., 2010). An important means to prevent fraud
is “segregation of duties” (Gelinas and Dull, 2010, p. 255). This means of control is intended to achieve
the control objective and represents an abstraction over static means of control such as written policies
or organizational structures and dynamic means of control such as activities and processes. Alternative
denominators for the control means concept include “control activity” (IT Governance Institute, 2007) and
“control plan” (Gelinas et al., 2004, p. 249). Both terms, however, carry a significant risk of misinterpretation: The term “activity” raises associations with dynamic abstractions neglecting static aspects while the
term “plan” emphasizes a perspective other than the intended means-end association.
Examples of general control means given in COSO publications include the authorization of transactions
and adequate safeguarding of assets and records. The achievement of the desired outcome of a control
objective is measured by an indicator (e. g., “Percentage of fraudulent refund transactions”) as is the severity
of risk. Responsibilities, as in the RACI (responsible, accountable, consulted, informed)-conceptualization
suggested, e. g., by the IT Governance Institute (2007), are typically defined for more than one organizational
role (“executive”, “business process owner”, etc.) with respect to a control objective. It is important to
note that the monitoring and auditing of an internal control system (e. g., performed as internal control
assessment by an external auditor) are processes detached from the actual internal control system, in that
the system itself becomes subject to the audit (COSO, 2009).
These interpretations of domain terminology represent intermediate results of the conceptual reconstruction process which inform the subsequent language design. Further intermediate results of the reconstruction
process including a semantic net are discussed in Strecker et al. (2010, 2011a).
6.2. Specification of the ControlML
The language specification of the MEMO ControlML is composed of a meta model represented in
the MEMO MML, a respective graphical notation, and explanations of the intended semantics of language
concepts. The diagrammatic representation of the meta model is split into two figures to focus on different
aspects of the language design. In the following sections, we focus on the key elements of the modeling
language ControlML and discuss extensions to the earlier tentative language design (for a discussion of
alternative designs and a more elaborate rationale of design decisions see Strecker et al., 2011a, pp. 17ff.).
Fig. 4 presents the corresponding meta model excerpt of the ControlML with a focus on the language
kernel; a focus on integration of ControlML with the MEMO family of modeling languages is illustrated
in the meta model excerpt in Fig. 6 and discussed in Section 6.3.
The initial design decision with respect to the targeted domain pertains to the specification of language
concepts specifying an internal control type. It follows from the terminological analysis that the very
conception of “internal control” cannot be conceptualized as a singular concept as such, but rather as
12
Control Involvement
pertains to
0..*
belongs to
0..*
0..*
intendedState : String
0..* explanation : String
areaFS : FinancialStatementArea 0..*
1..*
Codification
targets
0..*
supports
C1
governed by
specification : String
origin : PolicyProvider
1..1
recommendedAction : String
1..* assertion [0..*] : Assertion
intendedEffect : {preventive,detective,corrective}
isManual : Boolean
0..*
realised by
Control Category
Organisational Unit
has
Control Means
1..1
Control Objective
name : String
description : String
0..*
involvementType : String
0..*
0..*
C1
Reference Object
context Control Objective inv: self.ControlObjective->excludes(self)
Figure 4: Meta model of the MEMO ControlML with a focus on the language kernel (revised from Strecker et al., 2011a,
p. 20)
an abstraction over various concepts which in turn constitute an internal control. An essential design
decision has therefore been to represent an internal control by its control objective and by the means of
achieving the control objective. Hence, two dedicated meta types, Control Objective and Control Means,
are introduced (a similar kernel is proposed by Namiri and Stojanovic, 2007a; Karagiannis, 2008). The
rationale for introducing those two meta types is to enable dedicated model-based audit analyses based on
respective conceptual models of control objectives and control means. To account for essential requirements
(see Section 4), further refinements are, however, necessary and are detailed below. Three constituents
are central to the language specification (the meta model is shown in Fig. 4): (1) The Control Objective
language concept and the ancillary concepts Codification and Control Category; (2) the Control Means
modeling concept; (3) the Control Involvement meta type.
Ad (1) Control Objective. The meta type Control Objective serves to describe the intentions connected with
an internal control. It is described by a natural language description of the desired state of control by
the attribute intendedState (“Prevent unauthorized refunds”) and by an explanation of the intended state,
explanation (“The billing system receives shipping items from the shipping system [. . . ]”). Annotating the
financial statement area, areaFS, links a control objective to financial reporting. The recursive supports
association between respective types allows to represent the internal control system as a hierarchy or net of
controls (see Fig. 5 for an example). Thus, it enables further analyses such as which IT controls relate to
which business controls. The ancillary language concept Codification specifies a legal regulation the control
objective is governed by and its originating policy provider. Feedback from practicing auditors advised
keeping track of these codifications (e. g., a certain clause in an auditing standard) and of the originating
policy provider (e. g., “PCAOB Auditing Standard No. 5”) as a contribution to justifying the existence
and importance of an internal control. The meta type Control Category allows the creation of customized
control taxonomies and the assignment of one or more categories to a control objective to support a flexible
13
categorization of internal controls, since in auditing practice there are different approaches to structuring
control objectives (e. g., Dunn et al., 2005b, pp. 441ff.).
Ad (2) Control Means. The Control Means language concept serves to describe the means to achieve reasonable assurance. It is determined by the recommended course of action provided in a natural language
specification, recommendedAction. Such a specification might mention a written policy and corresponding
procedures (e. g., “The Accounting Supervisor makes copies of the checks and sends the check copies along
with the invoice hard copy supporting documentation to the Cash Application Department”). The current
conceptualization as shown in Fig. 4 aims to offer flexibility while, at the same time, maintaining a structure
for assessment purposes. The terminological analysis indicates that (1) multiple means exist that can be
deployed to achieve a control objective; (2) the same means can be reused by several control objectives; and
(3) a certain means can pertain to several structural and procedural elements and thus exhibit a “multidimensional” characteristic (e. g., a written policy connected with a process “Authorize credit”). Due to the
chosen cardinality of the targets-relationship between the meta types Control Objective and Control Means,
it is possible to assign a multitude of means to one control objective; similarly, a control mean can be used
to support the achievement of different control objectives, thereby promoting the management and reuse
of control means in an organization. Following suggestions elicited from the literature, further semantics
is specified by assertion (what are assumptions underlying the function of a control means and what is its
rationale?) (Carnaghan, 2006, p. 177) and by classifying control means into preventive, detective or corrective controls according to their effect in time relative to the occurrence of a risk, intendedEffect (Gelinas
et al., 2004, p. 253). Another characteristic is captured by a functional differentiation between manual and
automated control activities in isManual attribute.
Ad (3) Control Involvement. The Control Involvement modeling concept serves to describe the relation
between a control objective and an organizational unit. Since further types of involvement beyond RACI
are conceivable and to be expected (e. g., a “supports” involvement), Control Involvement is not limited to
these four types of involvement but allows organizations to define their own types of involvement—by means
of an involvementType and a description.
Figure 5 drafts a graphical notation of the ControlML and illustrates the internal control diagram
type. The diagram is based on the refund returned goods process drawn on by Carnaghan (2006, p. 200) and
is further enriched with exemplary controls reconstructed from the COBIT documentation (IT Governance
Institute, 2007). Different from other notational mappings, multiple meta types, Control Objective, Control
Means, Control Category, and Codification, map to a single graphical symbol (a rectangle with an “auditor’s
eye” attached). The rationale for this design decision is to provide a visual overview of (selected) internal
controls with this diagram type. Given respective tool support, the model user (e. g., an auditor) could then
14
Internal Control Diagram
Control Objective: Segregation of duties
Intended State: Prevent unauthorized refunds
Recommended Action: Separate authorization process for
refunds above 500 €, signed by some different actor
Intended Effect: preventive
is Manual: true
Category: Business Control
supports
Recommended Action: Ensure different user
access rights for refund transactions
Intended Effect: preventive
is Manual: false
Control Means
Control Means
supports
Control Objective: User Account Management
Intended State: No user has privileges that are not required for his current tasks.
Explanation: Address requesting, establishing, issuing, suspending, modifying, and
closing user accounts and […]
Category: IT Control, Codification: COBIT, DS5.4
Recommended Action: With each change in the organizational
structure and in the staffing, check for necessary modifications in the
user accounts.
Intended Effect: Preventive
is Manual: true
Control Means
supports
Control Objective: Segregation of duties
Intended State: Prevent unauthorized transactions
Category: IT Control
Control Objective: Network Security
Intended State: No unauthorized information flows to and
fromObjective:
networks are
possible. of IT Security
Control
Management
Explanation:
Use
security
techniqueswith
and business
related
Intended
State: IT
security
is consistent
management
procedures,
e.g., firewalls, […]
requirements.
Control
Objective: Identity
Management
Regulation:
COBIT,
Explanation:
Manage
security
at the highest
appropriate
Intended
State: Every
userITDS5.10
can
be uniquely
identified.
organisational
level,
management
[…]
Explanation:
Ensure
thatsoallthe
users
(internal, external,
and
Regulation:
DS5.1 on IT systems […]
temporary)
and COBIT,
their activity
Category: IT Control, Codification: COBIT, DS5.3
Recommended Action: After each software update it has to be
checked, if the user accounts and their privileges are still valid
Intended Effect: Preventive
is Manual: true
Meta Type Control Objective
Meta Types Control Category
& Codification
Meta Type Control Means
Figure 5: An internal control diagram showing internal controls and their interrelations as a visual system of internal controls
(based on the refund returned goods process drawn on by Carnaghan, 2006, 200 and further enriched with exemplary controls
reconstructed from the COBIT documentation).
navigate from such a high-level overview to viewing specific control objectives and have their control means
shown in another diagram type. Note that other graphical notations and diagram types are conceivable, for
instance, a tabular representation or a diagram type focusing on control means rather than control objectives
(showing which control objectives a control mean addresses). In particular, ControlML is designed to
assign different notational elements to the same modeling concept (e. g., to address specific perspectives of
particular groups of stakeholders) and to offer various diagram types for the same model (each with, e. g.,
different foci). Moreover, the formal foundation of the DSML allows for transforming the internal control
model into different forms of representation (e. g., a spreadsheet or a check list) to accommodate the specific
needs of groups of stakeholders.
6.3. Integration with the MEMO family of modeling languages with extensions for assessment of internal
controls
The ControlML is integrated with the MEMO family of modeling languages through reuse of common
language concepts (see Section 5). Figure 6 presents another aspect of the meta model showing how key
concepts of the ControlML integrate with concepts of other MEMO languages (marked by a colored
rectangle attached to a meta type).
The semantics of the Control Objective language concept is further refined by links to the entity objectives
that are the target of the control objective (Goal) and to indicators providing measurements related to the
control objective (Indicator). The Control Involvement modeling concept is refined to refer to organizational
roles (Organisational Role), so that roles defined in an organizational structure model can be reused for
15
measures
assures achievement of
Control Involvement
pertains to
0..*
Indicator
0..*
0..*
0..1
1..*
C3
C2
I
affectedEntity
0..*
affects
monitors
Control Means riskMeasure
0..*
targets
0..*
0..*
Business Process
Risk
mitigates
0..*
0..* 0..*
0..*
<<surrogate>>
Reference Object
Organisational Unit
Information System
Software
...
type : {manual, semi-autom., autom.}
II
II
Explanation of ControlML-specific attribute types
frequencyType : {per instance, on demand, event driven, <timeUnit>}
scopeType : {total, partial, sample}
Audit Process
frequency : FrequencyType
0..1 scope : ScopeType
isExternal : Boolean
Symbols for concepts reused from other MEMO languages:
GoalML
C2
1..1
1..1
Control Objective
measures
Organisational Role
has
0..*
0..*
1..*
realised by
Goal
C3
context Control Objective inv:
self.ControlMeans.ReferenceObject->excludes( self.affectedEntity )
OrgML
ITML
RiskML
MetricML
context Control Means inv:
self.ReferenceObject.BusinessProcess->notEmpty() implies
self.ReferenceObject.BusinessProcess->forAll( b : BusinessProcess |
b->isOclTypeOf(AuditProcess).isEmpty() )
Figure 6: Meta model of the MEMO ControlML with a focus on integration with the MEMO family of modeling languages
(revised from Strecker et al., 2011a, p. 20; Rectangles “I” and “II” mark extensions discussed in Section 6.3)
internal controls modeling. The explicit association of risks (Risk) with control means enables further
analyses for auditing purposes. For instance, identifying risks without controls and vice versa (as proposed
by Spira and Page, 2002). Likewise, control means may be linked to indicators, Indicator, measuring the
outcome of actions associated with a particular control means.
Furthermore, the organizational context of an internal control is introduced by associating the Control
Means modeling concepts with those organizational entities (e. g., Business Process, Organisational Unit, Information System) that may participate in implementing (or realizing) an internal control—thereby shaping
the semantics of control activities in terms of describing the organizational context the activity is executed
in. For this purpose, the surrogate concept Reference Object represents all modeling constructs relevant to
internal control assessment—with the intention of providing the necessary flexibility in modeling the means
of internal control (see Section 6.1). The present language specification allows, for example, to represent
the realization of a control means to achieve segregation of duties by referencing the two relevant business
processes (“Prepare credit” and “Authorize credit”) as well as the two organizational roles involved (“Sales
Account Manager” and “A/R Manager”).
Extending the earlier language design, the affects relation is introduced between Control Objective and
Reference Object. Besides representing the various organizational elements that realize a control means,
16
the meta type Reference Object is also used to represent the organizational entities that are affected by
an internal control (see Rectangle “I” in Fig. 6). For example, a business processes type affected by the
“segregation of duties” control or a server type affected by a “ensure correct user access rights” control.
Note that affected and realizing reference objects may coincide. Although this seems confusing at first,
the differentiation is necessary, since it enables analyses such as “which organizational elements are subject
to internal control?” (affects-association), “does an organizational element contribute to the realization of
an internal control?” (realised by-association) or “which organizational elements are affected by a control
objective but are missing a respective control means?” (comparison of affects- and realised by-association).
An example for this differentiation into affected and realizing reference objects is provided in Figure 7 in
Section 7: The control objective “Segregration of duties” (at the center of the diagram) affects the “Refund
returned goods” and, at the same time, is realized by the process “Authorize credit”.
A further extension pertains to the support for the modeling of auditing and monitoring processes. Audit
processes differ from business processes in that they are specifically designed to run outside of a firm’s regular
operations with the intention to control a particular audit object such as a business process, a record of
transactions etc. From a modeling perspective, however, audit processes exhibit characteristics of business
processes in that a certain regularity can be assumed as well as a temporal order of tasks producing events.
Hence, auditing and monitoring processes can, in principle, be represented using a business process modeling
language such as BPMN or, in context of enterprise modeling, the MEMO OrgML. We, therefore, propose
reusing and extending—that is, specializing—the Business Process concept specified in the MEMO OrgML
to an audit process subtype (see Rectangle “II” in Fig. 6). The semantics of the Audit Process modeling
concepts are further detailed by the particular frequency of process instantiation (i. e., at which intervals
is the process triggered?), the scope of its analysis (e. g., are all, only a part or a specific sample of the
instances of the audit object inspected?) and whether it is an external audit process. Specializing the generic
Business Process meta type leads to a particular advantage: Current diagram types, modeling techniques,
and implementations in modeling tools—optionally even the graphical notation—can be reused for modeling
audit processes. An example is shown in Fig. 7 where the audit process “Audit refund transactions and
detect irregularities” is represented using the regular business process notation symbol defined by the MEMO
OrgML. This reuse of familiar modeling concepts is assumed to foster the acceptance of audit process
modeling. The two OCL-constraints in Fig. 6 ensure that reference objects cannot realize a control means
and, at the same time, be affected by a control objective this control means targets (C2); and that audit
processes cannot realize a control mean (C3).
17
7. Language application: Applying MEMO ControlML to support the assessment of internal
controls
We now apply the MEMO ControlML to an application scenario to demonstrate how to utilize language concepts for the assessment of internal controls. The scenario is based on and inspired by a refund
returned goods process drawn on by Carnaghan (2006, p. 200) for which internal controls are described in
natural language. For example, “[t]he sales account manager must authorize returns by completing a ‘return merchandise authorization’ (RMA) paper form that is sent to customer service” and “[t]he information
system restricts the ability to create, change, or delete sales order return and credit requests to authorized
personnel” (quoted in Carnaghan, 2006). Note how these sentences refer to relevant organizational roles
(“sales account manager”, “authorized personnel”), responsibilities (“must authorize”), resources such as
documents (“RMA”) and IT artifacts (“information system”). Figure 7 reconstructs the description of the
scenario in Carnaghan (2006, pp. 191ff.) using the MEMO ControlML and further languages from the
MEMO family of modeling languages: It shows a goal model (top left) that represents (an excerpt of) a
hierarchy of the enterprise’s strategic goals and subsequent business objectives; a business process model
for “refunding returned goods” at three levels of detail (i. e., an aggregated process and its decompositions;
bottom left); a model of the corresponding organizational structure (including organizational roles and committees; top right) and a model of IT assets used in the process (showing an information system abstraction
of an ERP system; bottom right). Relationships between concepts in different models are explicitly modeled by associations (e. g., the ERP system used in the business process “Authorize credit”) or by shared
concepts (e. g., the organizational role “A/R manager” in both the process “Authorize credit” and in the
organizational structure model). Further abstractions provided by MEMO such as corresponding object
models are omitted for the sake of clarity.
The enterprise model shown supports dedicated analyses for the assessment of internal control systems
based on the conceptual models of internal controls: The control objective “Prevent unauthorized refunds”
recommends a segregation of duties in the aggregated process “Refund returned goods”. The internal control
semantics is further specified by the IT control “Prevent unauthorized transactions”, by the risk “Internal
fraud” it aims to mitigate, by the audit activity “Audit refund transactions and detect irregularity”, and by
the indicator “Percentage of fraudulent refund transactions” to measure achievement of the control objective.
Figure 7 also demonstrates how the control objectives can be associated with concepts that represent the
organizational action system they are embedded in. First, they can be associated with the entity objectives
they are aimed at assuring the achievement of (i. e., the goal “Minimize error rate of incorrect refunds” in
the goal model). Second, control objectives can be linked to static and dynamic abstractions representing
means of control. For example, the above mentioned control objective affects the business process “Refund returned goods”, whereas the actual realization of the recommended action “segregation of duties”
18
19
Legend
Goods
returned
ec
ts
Control
Objective
Aggregated
Business Process
uses
res a
chie
v em
ent o
f
Organizational
Role
Committee
Goods
refunded
Goods
refunded
refers to
assu
uses
Authorize credit
< A/R Manager >
Goal
Prepare credit
< Sales Account
Manager >
Link to prior sale
< Inventory clerk >
Refund returned
goods
< A/R department >
Credit customer
account
Goal: Minimize error
rate of incorrect
refunds (max. 1.5%)
Business
Process
Goods linked
to sale
Authorize return of
goods
< Sales Account
Manager >
aff
Goal: Process 99% of
all refunds in under
1 Week
affects
Goal System
Business Process
by
d
ali
ze
re
?
‐
Fraudulent refund
transactions [%]
IT
me
as
ur
es
#
measures
Software
comprises
?
#
IT
Risk
Indicator
Control Objective: Segregation of duties
Intended State: Prevent unauthorized
transactions […]
Category: IT Control
IT hardware
resource
Risk: Internal fraud
Visibility: high
Uncertainty: medium
monitors
to
refers to
responsible
accountable
informed
Audit refund
transactions and
detect irregularity
refers
Control Objective: Optimize IT infrastructure
Recommended Action: Establish an IT
architecture board to guide architecture […]
Category: IT Control, Regulation: COBIT, PO 3.5
Internal Control Diagram
Control Objective: Segregation of duties
Intended State: Prevent unauthorized refunds
[…] Category: Business Control
Frequency of
meetings [#/month]
IT
#
s
ate
mitig
Goal: Increase in
customer satisfaction
by 5%
ERP Software
...
Accounting
Application
Server
ERP System
A/R Manager
Financial Officer
Database
Server
IT Architecture
Board
IT
directs
Executive
Board
requires
...
Sales
Backup
Sales Account
Manager
directs
Organizational Structure
IT Landscape
Figure 7: Application scenario: Return refund goods process drawn on by Carnaghan (2006, 200) as a reconstruction using the
MEMO ControlML and MEMO family of modeling languages (revised from Strecker et al., 2011a).
is depicted at the most detailed level of the process model. Third, the IT control refers to an IT asset in
the IT landscape model (“ERP system”) that realizes the segregation at the information system level by
authorization and system access policies. Linking the two control objectives also demonstrates how associations between controls aid in analyzing internal control systems. Associating a control objective with a
corresponding risk (“Internal fraud”) provides an implicit rationale for the existence of a control objective
possibly indicated by a performance measure (“Fraudulent refund transactions in %”). Finally, the integration with an organizational structure model emphasizes different types of involvement of organizational
roles. For instance, the two roles participating in the “Credit customer account” process—“Sales Account
Manager” and “A/R Manager”—are linked to the control objective specifying their type of involvement (i. e.,
“accountable” and “responsible”, respectively), whereas a “Financial Officer” is one regularly informed but
not explicitly modeled as part of the business process.
Such integrated models of the enterprise and its internal control system promise to provide intuitive
access to internal control matters and a comprehensible conceptual foundation for differentiated analyses
during the assessment of internal control systems. By associating internal controls with further abstractions
(e. g., of organizational goals or IT landscapes) and by providing dedicated diagram types for specific types
of analyses—deliberately omitting confounding details—such an approach facilitates internal control-related
communication and collaboration between groups of stakeholders with different professional backgrounds.
Additionally, such enterprise models can serve as foundation for auditing purposes in that they support
the comparison of internal controls in place with the likes of prescribed internal controls as defined by, for
instance, COBIT (IT Governance Institute, 2007).
ControlML can also be applied to reconstruct prescribed internal controls as reference models, that
is, reusable conceptual models of internal controls associated with the promise to be applicable to a large
class of prospective use contexts, and to improve the productivity of language users. Figure 8 illustrates
how ControlML is applied to reconstruct controls defined by the COBIT 4.1 framework: Internal controls
defined by the framework (e. g., COBIT PO 4.11) are reconstructed using the ControlML once (upper
right quadrant) and stored in a repository (i. e., a model database) accessible by prospective language users
(bottom right quadrant). Language users select those reference models from the repository they consider
relevant for their own modeling purposes and import the reference models into their modeling tool (upper
left quadrant). Given the inevitably imprecise specification of internal controls in respective frameworks
(being applicable to a wide range of use contexts demands sacrifices to their level of detail), corresponding reference models of internal controls will remain underspecified in certain regards. For instance, the
“Management of IT Security” control objective defined by COBIT demands involvement of “the highest
appropriate organizational management” (IT Governance Institute, 2007). Since organizational structures
vary to a great extent in organizations, it is not feasible to preconceptualize reference models with precise
organizational roles (conceivable roles include the CIO or any other IT executive) with respect to control
20
Relevant Control Objectives for the Enterprise
realized by
<CIO/
IT executive>
realized by
Control Objective: Management of IT Security
Intended State: IT security is consistent with business
requirements.
Explanation: Manage IT security at the highest appropriate
organizational level, so the management […]
Regulation: COBIT, DS5.1
Control Objective: IT Strategy Committee
Control Objective: Data and System
Ownership
Control
Objective: Supervision
Control Objective: Technology Standards
selection of
relevant
Control
Objectives
Control Objective: Network Security
Intended State: No unauthorized information flows to and
from networks are possible.
Explanation: Use security techniques and related
management procedures, e.g., firewalls, […]
Regulation: COBIT, DS5.10
Control Objective: IT Architecture Board
Intended State: The IT architecture conforms to […]
Explanation: Establish an IT architecture board to […]
Regulation: COBIT, PO3.5
Control Objective: IT Steering Committee
Intended State: An IT steering committee is established
Explanation: Establish an IT steering commitee […]
Regulation: COBIT, PO4.3
Control Objective: Segregation of Duties
Intended State: Prevent unauthorized financial operations.
Explanation: Implement a division of roles and […]
Regulation: COBIT, PO4.11
IT Architecture Board
realized by
IT Steering
Committee
< OrgUnit >
realized by
Approve Financial
Transaction
Enriched Enterprise Model
loaded from
Repository for Reference Models
adaption &
integration
realized by
Reference Models for Control Objectives
realized by
<Information
System>
...
ASU SIC Internal Controls
Cobit 4.1: IT General Controls
Control Objective: Identity Management
Intended State: Every user can be uniquely identified.
Explanation: Ensure that all users (internal, external, and
temporary) and their activity on IT systems […]
Regulation: COBIT, DS5.3
Figure 8: Reconstructing COBIT 4.1 control objectives as reference models using MEMO ControlML
involvement. Hence, the reference models will, in most cases, have to be adapted to the specific organizational use context in a modeling project for internal controls (lower left quadrant). Yet, the overall modeling
effort is reduced and, at the same time, compliance with auditing standards and guidelines is fostered due
to the reuse of proven artifacts.
8. Conclusion
The present work directs the discussion on supporting the assessment of internal control systems through
conceptual models to include further abstractions common to enterprise modeling that go beyond business
process modeling (i. e., modeling constructs representing internal controls and the corresponding organizational action system). In this context, a DSML for the modeling of internal controls is specified and
applied to demonstrate its practical use. The DSML addresses five essential domain-specific requirements:
It accounts for the organizational context important to internal control interpretation (R1); explicit and
qualified relationships among internal controls (R2); and the multiplicity of control means (R3). The language aids in the perception of a traceable rationale of an internal control by way of explicit (assertion) and
implicit (association with risk types) modeling concepts (R4). Further research is required with respect to
constructing tailored visual representations meaningful to groups of prospective users (i. e., diagram types
and notation elements) (R5).
The language’s meta model-based specification and corresponding graphical notation provides abstract
21
and concrete syntax and formal semantics of dedicated modeling constructs for key domain-specific concepts.
The demonstration indicates that the ControlML allows for modeling of coherent and consistent conceptual models of internal controls that promise to facilitate interpretation and assessment of internal control
systems. In particular, the design artifact contributes to existing work in that it adds essential concepts to
internal controls modeling and semantics to key modeling concepts.
However, the present conceptualizations in ControlML assume that the precise semantics of concepts
promote comprehension by language users. Further research has to study the effects of the presented conceptualizations on prospective users, that is, whether the proposed concepts do indeed lower communication
barriers and increase transparency of internal control matters. The number of concepts and the diversity
of relations in ControlML suggests that the language itself may initially increase complexity in practice,
before complexity is reduced after mastering the language. At present, it is therefore not feasible to predict
the effects of MEMO ControlML on the complexity-reducing effects of using a DSML in the assessment
of internal control systems and the complexity-increasing effects of the language itself.
With regard to auditing practice, enterprise models created with ControlML provide an instrument for
audit reviews and function as audit evidence (i. e., as a structured documentation of a firm’s internal control
system) to facilitate interpretation and assessment of controls by stakeholders. The feedback received from
practicing auditors on the use scenario described in Section 7 indicates at least partial confirmation of this
working hypothesis (as does Cendrowski et al., 2007, p. 208). In this respect, the present work addresses
the suggested lack of research on internal control assessment methods (Mock et al., 2009, p. 66), and opens
paths for future research on such methods: A method based on ControlML requires a corresponding
process model to guide the application of language concepts to the assessment of the internal control system.
While the application scenario in Section 7 illustrates the principle use of essential language concepts, a
corresponding process model should provide more detailed guidelines on how to use the language for specific
model-based analyses and assessments. The development of such a process model is on our research agenda.
References
Bailey, Jr., A. D., Han, K. S., Stansifer, R. D., Whinston, A. B., 2000. The Intelligent Internal Accounting Control Model
using a Logic Programming Approach. In: Vasarhelyi, M. A., O’Leary, D. (Eds.), Artificial Intelligence in Accounting and
Auditing: Creating value with AI. Vol. 5 of Rutgers Series in Accounting Information Systems. Markus Wiener Publishers,
Princeton, NJ, pp. 66–93.
Carnaghan, C., 2006. Business process modeling approaches in the context of process level audit risk assessment: An analysis
and comparison. International Journal of Accounting Information Systems 7 (2), 170–204.
Cendrowski, H., Martin, J. P., Petro, L. W. (Eds.), 2007. The Handbook of Fraud Deterrence. John Wiley and Sons, Hoboken,
New Jersey.
Chen, K. T., Lee, R. M., 2003. Knowledge-based evaluation of internal accounting control systems — a pattern recognition
approach. In: Proceedings of the American Accounting Association Conference. Honolulu, HI.
22
COSO, Sep. 1992. Internal Control — Integrated Framework. The Committee of Sponsoring Organizations of the Treadway
Commission.
COSO, Sep. 2004. Enterprise Risk Management – Integrated Framework (Executive Summary). The Committee of Sponsoring
Organizations of the Treadway Commission.
COSO, 2009. Guidance on Monitoring Internal Control Systems: Introduction. The Committee of Sponsoring Organizations
of the Treadway Commission.
COSO, Sep. 2010. What is internal control? http://www.coso.org/resources.htm, The Committee of Sponsoring Organizations of the Treadway Commission.
Crawford, M., Stein, W., 2002. Auditing Risk Management: Fine in Theory but who can do it in Practice? International
Journal of Auditing 6 (2), 119–131.
Damianides, M., 2005. Sarbanes-Oxley and IT Governance: New Guidance on IT Control and Compliance. Inf. Sys. Manage.
22 (1), 77–85.
Davis, C., Schiller, M., Wheeler, K., 2007. IT Auditing : Using Controls to Protect Information Assets. McGraw-Hill.
Dunn, C. L., 2006. Business Process Modeling Approaches in the Context of Process Level Audit Risk Assessment: An Analysis
and Comparison : Discussion Comments. International Journal of Accounting Information Systems 7 (2), 205–207.
Dunn, C. L., Cherrington, J. O., Hollander, A. S., 2005a. Enterprise Information Systems: A Pattern-Based Approach, 3rd
Edition. McGraw-Hill Irwin, Boston, MA.
Dunn, C. L., Gerard, G. J., Grabski, S. V., 2005b. Critical evaluation of conceptual data models. International Journal of
Accounting Information Systems 6 (2), 83–106.
Elder, R. J., Beasley, M. S., Arenes, A. A., 2010. Auditing and Assurance Services: An Integrated Approach, 13th Edition.
Pearson, Boston et al.
Ferstl, O. K., Sinz, E. J., 1998. SOM Modeling of Business Systems. In: Bernus, P., Mertins, K., Schmidt, G. (Eds.), Handbook
on Architectures of Information Systems. Springer, Berlin, pp. 339–358.
Frank, U., 1994. Multiperspektivische Unternehmensmodellierung: Theoretischer Hintergrund und Entwurf einer objektorientierten Entwicklungsumgebung. Oldenbourg, München.
Frank, U., 1998. Essential Research Strategies in the Information Systems Discipline—Reflections on Formalisation, Contingency and the Social Construction of Reality. The Systemist 20, 98–113.
Frank, U., 2002. Multi-Perspective Enterprise Modeling (MEMO): Conceptual framework and modeling languages. In: Proceedings of the 35th Annual Hawaii International Conference on System Sciences (HICSS). Honululu, pp. 72–82.
Frank, U., 2006a. Evaluation of Reference Models. In: Fettke, P., Loos, P. (Eds.), Reference Modeling for Business Systems
Analysis. Idea Group, Hershey, PA, pp. 118–140.
Frank, U., 2006b. Towards a Pluralistic Conception of Research Methods in Information Systems Research. ICB Research
Report 7, Institute for Computer Science and Business Information Systems (ICB), University of Duisburg-Essen, Germany.
Frank, U., 2010. Outline of a Method for Designing Modelling Languages. ICB Research Report 42, Institute for Computer
Science and Business Information Systems (ICB), University of Duisburg-Essen, Essen, Germany.
URL http://www.icb.uni-due.de/fileadmin/ICB/research/research_reports/ICB-Report-No42.pdf
Frank, U., 2011a. MEMO Organisation Modelling Language: Focus on Business Processes. ICB-Research Report 49, Institute
for Computer Science and Business Information Systems (ICB), University of Duisburg-Essen, Essen, Germany.
URL http://www.icb.uni-due.de/fileadmin/ICB/research/research\_reports/ICB-Report-No49.pdf
Frank, U., 2011b. MEMO Organisation Modelling Language: Focus on Organisational Structure. ICB-Research Report 48,
Institute for Computer Science and Business Information Systems (ICB), University of Duisburg-Essen, Essen, Germany.
URL http://www.icb.uni-due.de/fileadmin/ICB/research/research\_reports/ICB-Report-No48.pdf
Frank, U., 2011c. MEMO Organisation Modelling Language (OrgML) – Requirements and Core Diagram Types. ICB-Research
23
Report 47, Institute for Computer Science and Business Information Systems (ICB), University of Duisburg-Essen, Essen,
Germany.
URL http://www.icb.uni-due.de/fileadmin/ICB/research/research\_reports/ICB-Report-No47.pdf
Frank, U., 2011d. The MEMO Meta Modelling Language (MML) and Language Architecture. 2nd Edition. ICB-Research
Report 43, Institute for Computer Science and Business Information Systems (ICB), University of Duisburg-Essen, Essen,
Germany.
URL http://www.icb.uni-due.de/fileadmin/ICB/research/research_reports/ICB-Report_No43.pdf
Frank, U., 2012. Multi-Perspective Enterprise Modeling: Foundational Concepts, Prospects and Future Research Challenges.
Software and Systems Modeling, available online first, DOI 10.1007/s10270-012-0273-9.
Frank, U., 2013. Domain-Specific Modeling Languages - Requirements Analysis and Design Guidelines. In: Reinhartz-Berger,
I., Sturm, A., Clark, T., Wand, Y., Cohen, S., Bettin, J. (Eds.), Domain Engineering: Product Lines, Conceptual Models,
and Languages. Springer.
Frank, U., Heise, D., Kattenstroth, H., Ferguson, D., Hadar, E., Waschke, M., 2009. ITML: A Domain-Specific Modeling
Language for Supporting Business Driven IT Management. In: Rossi, M., Gray, J., Sprinkle, J., Tolvanen, J.-P. (Eds.),
Proceedings of the 9th OOPSLA workshop on domain-specific modeling (DSM).
Geerts, G. L., 2011. A design science research methodology and its application to accounting information systems research.
International Journal of Accounting Information Systems 12, 142–151.
Gelinas, U. J., Dull, R. B., 2010. Accounting Information Systems, 8th Edition. South-Western Cengage Learning, Mason, OH.
Gelinas, U. J., Sutton, S. G., Fedorowicz, J., 2004. Business processes and information technology. South-Western Thomson
Learning, Mason, Ohio.
Governatori, G., Hoffmann, J., Sadiq, S. W., Weber, I., 2008. Detecting Regulatory Compliance for Business Process Models
through Semantic Annotations. In: Ardagna, D., Mecella, M., Yang, J. (Eds.), Business Process Management Workshops.
Vol. 17 of Lecture Notes in Business Information Processing. Springer, pp. 5–17.
Governatori, G., Milosevic, Z., Sadiq, S., October 2006. Compliance checking between business process and business contracts.
In: Proceedings of the 10th IEEE International Enterprise Distributed Object Computing Conference (EDOC’06), Hong
Kong, China, Oct 16, 2006. IEEE Computer Society, Los Alamitos, CA, USA, pp. 16–20.
IT Governance Institute (Ed.), 2007. CobiT 4.1: Framework, Control Objectives, Management Guidelines, Maturity Models.
IT Governance Institute of the Information Systems Audit and Control Association, Rolling Meadows.
Karagiannis, D., 2008. A Business process Based Modelling Extension for Regulatory Compliance. In: Bichler, M. et al. (Ed.),
Multikonferenz Wirtschaftsinformatik. pp. 1159–1173.
Karagiannis, D., Mylopoulos, J., Schwab, M., 2007. Business Process-Based Regulation Compliance: The Case of the SarbanesOxley Act. In: Requirements Engineering : 15th IEEE International Requirements Engineering Conference, RE 2007,
October 15-19th, 2007, New Delhi, India. IEEE, pp. 315–321.
Köhling, C., 2012. Entwurf einer konzeptuellen Modellierungsmethode zur Unterstützung rationaler Zielplanungsprozesse in
Unternehmen. Doctoral dissertation, University of Duisburg-Essen, Institute for Computer Science and Business Information
Systems (ICB), Essen, Germany.
Lu, R., Sadiq, S. W., Governatori, G., 2007. Compliance Aware Business Process Design. In: ter Hofstede, A. H. M., Benatallah,
B., Paik, H.-Y. (Eds.), Business Process Management Workshops. Vol. 4928 of Lecture Notes in Computer Science. Springer,
pp. 120–131.
Lu, R., Sadiq, S. W., Governatori, G., 2008. Measurement of Compliance Distance in Business Processes. Inf. Sys. Manag.
25 (4), 344–355.
Maijoor, S., 2000. The Internal Control Explosion. International Journal of Auditing 4 (1), 101–109.
Mock, T. J., Sun, L., Srivastava, R. P., Vasarhelyi, M., 2009. An evidential reasoning approach to Sarbanes-Oxley mandated
24
internal control risk assessment. International Journal of Accounting Information Systems 10 (2), 65–78.
Moeller, R. R., 2008. Sarbanes-Oxley Internal Controls : Effective Auditing with AS5, CobiT and ITIL. John Wiley & Sons,
Hoboken, NJ.
Namiri, K., Stojanovic, N., 2007a. A formal approach for internal controls compliance in business processes. In: 8th Workshop
on Business Process Modeling, Development, and Support, BPMDS 2007 in conjunction with CAiSE 2007. Trondheim,
Norway.
Namiri, K., Stojanovic, N., 2007b. Pattern-based design and validation of business process compliance. In: Proceedings of
the 2007 OTM Confederated International Conference on On the move to meaningful internet systems: CoopIS, DOA,
ODBASE, GADA, and IS-Volume Part I. Springer, pp. 59–76.
Ortner, E., 2008. Language-critical Enterprise and Software Engineering. In: Proceedings of the Fourteenth Americas Conference of Information Systems, AMCIS 2008, Toronto, ON, Canada, Aug 14–17, 2008.
Peffers, K., Tuunanen, T., Rothenberger, M. A., Chatterjee, S., 2007. A design science research methodology for information
systems research. Journal of Management Information Systems 24 (3), 45–77.
Pitthan, J., Philipp, M., 1997. Einsatz von Petri-Netzen fuer die Aufnahme, Dokumentation und Analyse Interner Kontrollsysteme im Rahmen der Jahresabschlusspruefung. In: Stucky, W., Winand, U. (Eds.), Petri-Netze zur Modellierung verteilter
DV-Systeme. No. 350. Universitaet Karlsruhe, Karlsruhe, Germany, pp. 87–104.
Rikhardsson, P., Best, P., Green, P., Rosemann, M., 2006. Business Process Risk Management, Compliance, and Internal
Control: A Research Agenda. Tech. rep., Department of Business Studies, Management Accounting Research Group, Aarhus
School of Business, Aarhus, Denmark.
Rikhardsson, P., Rohde, C., Rom, A., 2005. Exploring Enterprise Systems and Management Control in the Information Society:
Developing a Conceptual Framework. Management Accounting Research Group Working Papers M-2005-05, University of
Aarhus, Aarhus School of Business, Department of Business Studies, Aarhus, Denmark.
Sadiq, S. W., Governatori, G., Namiri, K., 2007. Modeling Control Objectives for Business Process Compliance. In: Alonso,
G., Dadam, P., Rosemann, M. (Eds.), BPM 2007. Springer, Berlin, pp. 149–164.
Scheer, A.-W., 1992. Architecture of Integrated Information Systems : Foundations of Enterprise Modelling. Springer, Berlin.
Spira, L. F., Page, M., 2002. Risk Management — The reinvention of internal control and the changing role of internal audit.
Accounting, Auditing & Accountability Journal 16 (4), 640–661.
Strecker, S., Frank, U., Heise, D., Kattenstroth, H., 2012. MetricM: A modeling method in support of the reflective design
and use of performance measurement systems. Information Systems and e-Business Management (ISeB) 10 (2), 241–276.
Strecker, S., Heise, D., Frank, U., 2010. Toward modeling constructs for audit risk assessment: Reflections on internal controls
modeling. In: Esswein, W., Turowski, K., Juhrisch, M. (Eds.), Modellierung betrieblicher Informationssysteme (MobIS
2010). GI, Bonn, pp. 131–148.
Strecker, S., Heise, D., Frank, U., 2011a. Prolegomena of a modelling method in support of audit risk assessment: Outline of a
domain-specific modelling language for internal controls and internal control systems. Enterprise Modelling and Information
Systems Architectures: An International Journal 6 (3), 5–24.
Strecker, S., Heise, D., Frank, U., 2011b. RiskM: A multi-perspective modeling method for IT risk assessment. Information
Systems Frontiers (ISF). Special Issue on Governance, Risk and Compliance Applications in Information Systems 13 (4),
595–611.
Sutton, S. G., Hampton, C., 2003. Risk assessment in an extended enterprise environment: Redefining the audit model.
International Journal of Accounting Information Systems 4 (1), 57–73.
van der Aalst, W., van Hee, K., van der Werft, J. M., Kumar, A., Verdonk, M., 2011. Conceptual model for online auditing.
Decision Support Systems 50, 636–647.
Verschuren, P., Hartog, R., 2005. Evaluation in Design-Oriented Research. Qual Quant 39 (6), 733–762.
25
Wand, Y., Monarchi, D. E., Parsons, J., Woo, C. C., 1995. Theoretical foundations for conceptual modelling in information
systems development. Dec. Supp. Syst. 15 (4), 285–304.
Wand, Y., Weber, R., 2002. Research commentary: information systems and conceptual modeling — A research agenda. Inf.
Syst. Res. 13 (4), 363–376.
Weigand, H., Elsas, P., 2012. Model-based auditing using REA. International Journal of Accounting Information Systems 13,
287–310.
26