Prolegomena of a modelling method in support of audit risk ... · Prolegomena of a modelling method in support of audit risk assessment 3 accounting information systems literature

Enterprise Modelling and Information Systems ArchitecturesVol. 0, No. 0, month 0000Prolegomena of a modelling method in support of audit risk assessment 1

Stefan Strecker, David Heise, Ulrich Frank

Prolegomena of a modelling method in support ofaudit risk assessment

Outline of a domain-specific modelling language for internal controlsand internal control systems

Internal controls constitute a key concept in the auditing domain. In the audit risk assessment process,auditors evaluate a firm’s internal control system to provide reasonable assurance regarding the achievementof the entity’s objectives. The present work reflects upon the design of a domain-specific modelling languagefor internal controls modelling. It investigates the potentials of an enterprise modelling approach to audit riskassessment, reconstructs technical terminology in the auditing domain, and discusses design decisions anddesign alternatives by means of tentative language specifications.

1 IntroductionSection 404 of the Sarbanes-Oxley-Act of 2002(SOX) and both the Directives 2006/43/EC and2008/30/EC of the European Parliament and ofthe European Council (‘EuroSOX’) mandate theestablishment, documentation and managementof internal control systems and their subsequentauditing as part of audit risk assessment (Ramos2004; Dunn et al. 2005, p. 433). Present audit-ing standards and guidelines commit auditorsto gain an in-depth understanding of a firm’sbusiness, its operations and processes, associ-ated risks and internal controls when assessingthe risk of material misstatement (Sutton andHampton 2003). As relevant risks pervade theenterprise from operations to corporate strate-gising (Westerman and Hunter 2007), it needs tobe questioned ‘[w]hy limit the analysis to thebusiness process level?’ (Dunn 2006, p. 207)—when legal regulations and auditing standardsprescribe assessing risks at all relevant levelsof the organisation (COSO 1992; ISACA 2009).Audit risk assessment thus pertains to any riskof not achieving business objectives; not onlyrisks related to financial reporting (Crawford andStein 2002). Hence, auditing standards ‘empha-size the importance of auditors gaining a broader

understanding of an organization’ (Carnaghan2006, p. 171). Hence, auditors are confronted withthe remarkable complexity of present day en-terprises (Rikhardsson et al. 2006). They are re-quired to understand a firm’s business, its risksand controls in place to treat risk exposure atall relevant organisational levels which impliesan understanding of entity objectives, businessprocesses, organisational resources, structures,roles, and responsibilities (Elder et al. 2010). Au-ditors also have to deal with the complexity ofinternal control systems themselves: Controlsoccur for multiple organisational levels, refer toa multitude of different entities and address avariety of risks—apart from the sheer number ofcontrols and their possible interactions (Maijoor2000). Moreover, auditing internal control sys-tems requires the participation of stakeholderswith different professional backgrounds and per-spectives on internal control matters includingexecutives, line managers, process owners, riskmanagers, internal and external auditors (Spiraand Page 2002). In this respect, the complexitychallenge is intensified by different technical lan-guages, differing mindsets, and resulting barriersto communicate—hampering in particular thecooperation between auditor and auditee.

Enterprise Modelling and Information Systems ArchitecturesVol. 0, No. 0, month 0000

2 Stefan Strecker, David Heise, Ulrich Frank

The auditing literature recognises the potentialsof supporting audit risk assessment through con-ceptual models (e.g., Bradford et al. 2007), in par-ticular business process models in the context ofprocess-level audit risk assessment (e.g., ISACA2009, p. 132). It is, however, acknowledged thatpresent generic approaches to business processmodelling do not provide adequate modellingconstructs required for representing internal con-trol systems with regard to effectively and effi-ciently supporting auditors when performing au-dit risk assessment (Carnaghan 2006). In particu-lar, it is criticised that present approaches focuson the business process level and do not pro-vide support for appropriately representing fur-ther relevant organisational context such as busi-ness objectives, organisational resources, rolesand their responsibilities (Dunn 2006). Such mod-elling concepts are, however, common to enter-prise modelling approaches such as ARIS (Scheer1992), SOM (Ferstl and Sinz 1998) and MEMO(Frank 1994, 2008) which supplement businessprocess models with further abstractions of theenterprise and its organisational action systems(i.e., conceptual models of organisational goalsand strategies, structures, roles and resources).While current enterprise modelling approachesthus provide support for necessary organisationalcontext, they do not, to our best knowledge,entail elaborate domain-specific modelling con-cepts for representing internal controls and in-ternal control systems.

The present work reflects upon the design of adomain-specific modelling language for internalcontrols modelling. It investigates the potentialsof an enterprise modelling approach to audit riskassessment, reconstructs technical terminologyin the auditing domain, and discusses design de-cisions and design alternatives by means of tenta-tive language specifications. This work is part ofan ongoing design research project whose overallpurpose is to effectively and efficiently supportauditors when performing audit risk assessment.More specifically, the project is aimed at develop-ing a comprehensive modelling method support-

ing auditors in understanding a firm’s business,its operations and processes, associated risks andinternal controls when assessing the risk of mate-rial misstatement Strecker et al. 2010. Given thatthe auditors’ understanding is educed in groupprocesses (Damianides 2005, p. 79), its purposeis to support group processes by reducing thecomplexity inherent in internal control systemsand by providing abstractions tailored to the per-spectives of stakeholders involved. In particular,the method comprises domain-specific modellinglanguages in support of dedicated analyses. Eachlanguage provides modelling concepts that fosterthe reduction of complexity by providing appro-priate abstractions and a corresponding graphi-cal notation; that allow for structuring the com-plex subject in a purposeful way. Hence, theypromote transparency of internal control mat-ters, specifically by visually representing inter-nal controls as part of the organisational actionsystems, and by improving traceability of thecontrols in place to treat risk exposure. Thus,the language application viz. type level modelsprovide an elaborate medium to fostering andfacilitating communication among stakeholdersinvolved in audit risk assessment—with a dedi-cated focus on auditor and auditee interaction.Moreover, they serve as a conceptual foundationfor developing corresponding software tools formodelling, analysis, and decision-making.

The next section reviews related work. Section 3reconstructs technical terminology in the audit-ing domain. It also refines the design goals andreasons about requirements a method aimed atsupporting audit risk assessment should satisfy.The general prospects of an enterprise modellingapproach to audit risk assessment are investi-gated in Section 4. In Section 5, we reflect uponthe design of domain-specific modelling con-structs and discuss key design issues. Section 6summarises findings and discusses paths for fur-ther research.

2 Related workSince McCarthy (1979, 1982)’s work on the REA(resources, events, agents) model, auditing and


accounting information systems literature recog-nises the use of conceptual models of the enter-prise for supporting accountants and auditors inunderstanding a firm’s business (e.g., Dunn et al.2005; Gelinas et al. 2004). Behaviorist researchindicates that graphical representations of theenterprise advance the understanding of audi-tors over text-based documentation (Alencar etal. 2004; Amer et al. 2002; Dunn and Gerad 2001).Studies on the actual use of graphical represen-tations in audit risk assessment processes sup-port anecdotal evidence that system flowcharts(cf. Fig. 1 on the next page) and data flow dia-grams are still the predominant means of graphi-cal representation used in audit reviews (Gelinaset al. 2004, p. 24). A recent study shows, how-ever, that business process modelling approachessuch as the Business Process Model and Notation(BPMN) or the extended Event-driven ProcessChain (EPC) approaches are gaining increasingacceptance in the auditing domain (Alencar et al.2008).

Carnaghan (2006) reviews different business pro-cess modelling notations with regard to theirsupport for process-level audit risk assessment.She concludes that present approaches do notallow for adequately expressing the semantics ofinternal controls and, consequently, further mod-elling constructs are required. Dunn, in a reviewof the study, supports her conclusion by statingthat ‘these tools were not designed with auditrisk assessment suitability in mind but that is notto say that we couldn’t develop one’ (Dunn 2006,p. 207). Their assessment, however, ignores con-tributions from the conceptual modelling com-munity to the auditing domain.

Petri nets have for long been discussed as ameans to document business processes and corre-sponding internal controls aimed at algorithmicverification of compliance (Chen and Lee 2003;Pitthan and Philipp 1997). Sadiq et al. (2007) in-terpret internal controls in terms of rules andtarget rule-based compliance checking based onautomated reasoning (for related approaches, seee.g., Governatori et al. 2006, 2008; Lu et al. 2009).

Another rule-based approach to modelling inter-nal control systems is described by Bailey, Jr. Etal. (2000) based on a PROLOG implementation.Conceptualising internal controls as formal rulesmay complement domain-specific modelling con-structs for internal controls modelling to enablecompliance checking based on graphical modelsof the internal control system.

The work by Karagiannis et al. (2007) is amongthe first to consider domain-specific modellingconcepts dedicated to internal controls modelling.Three SOX-related domain-specific modellingconcepts, Control, Risk, and Account, are men-tioned as an extension to an enterprise modellingapproach and a corresponding modelling tool.Language concepts are specified as a metamodel(see also Karagiannis 2008, p. 1164) and relatedto further concepts for risk management such asEvent and Action. Interpretation of the seman-tics of modelling concepts is, however, partlyleft to the language user, since the metamodeldoes not show attributes and the accompanyingdocumentation remains silent on further details.Moreover, important aspects of the design ofa domain-specific modelling language are onlybriefly discussed, for instance, a notation andcorresponding diagram types for representinginternal control systems. In a series of relatedpapers, Namiri and Stojanovic (2007a,b) identifyadditional domain concepts (e.g., ControlObjec-tive, RiskAssessment, Authority), and visualiseconceptual relationships in a UML class diagramnotation (Namiri and Stojanovic 2007b, p. 63).Their ‘domain model’ structures the technicalterminology in the auditing domain with theintention to ‘formulate logical statements repre-senting the controls constraining the behaviorof a Business Process’ (Namiri and Stojanovic2007b, p. 62). However, the domain model doesnot specify syntax and semantics of a domain-specific modelling language. Though it informsthe domain analysis in the next section.

3 Domain analysisDesigning domain-specific modelling conceptspresupposes reconstructing key terms and their


4 Stefan Strecker, David Heise, Ulrich FrankAppendices

pwc Page 104

Example of a Level 2 Flowchart: Cash Application Sub-process Showing Transactions and Controls

Process Flow & Controls Map Description

CustomerCheck

1.4.1

Logging intocheck Register

Accounting

1.4.2

entry of paymentdetails

Accounting

Customer MasterDate

Accounts/Receivable

Error/Permission

1.4.3

Accounting

1.4.4

selection ofapplicable invoices

for payments

Accounting

AccountsReceivable File

1.4.5

Cash applied tocustomer

balance and a/ris relieved

Accounting


AccountsReceivable

System

1.4.6

Accounting

total amount?

CustomerCheck

supportingdocument

1.4.7

selection ofadditional invoices toapply for payments

to

Accounting

1.4.8

Cash ApplicationHeader tosupportingdocument

Accounting

supportingdocument

Cash applicationheader

1.4.9

reconciliation ofinfo to CR

Accounting

Error/Permission

No

Yes

Copy of Check

SupportingDocumentation

Copy of Check

SupportingDocumentation


CustomerCheck

supportingdocument


Check Register(CR) Error/

Permission

edit of entrydetails

validate if totalamount of

check applied

1.4.1 The checks are forwarded to the Accounting Supervisor who logs them in a Check Register. The information recorded includes date of check, check number, check amount, customer name/number, and invoices that payment relates to. 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.

1.4.2 A representative of the Cash Application Department (representative) enters the customer number into the Cash Application screen within the Accounts Receivable system. The system validates the customer number against the Customer Master (Standing Data) file within the system.

1.4.3 If the system does not find the number, an error message is displayed indicating the number is invalid. The representative has the option of entering the customer last name and first name into a search screen to locate the customer number. If the system locates the customer master record for the customer number entered, a list of open invoices is generated on to the screen.

1.4.4 The next screen is for the first invoice number selected to apply payment to.

1.4.5 The representative is prompted to enter the amount of payment being applied to the invoice on a field at the top of the screen. The amount will typically match the total invoice amount (listed on the bottom of the screen), but there are times that only partial payment is applied to a particular invoice.

1.4.6 The invoice amount entered must be numeric and cannot be for an amount greater than the amount left to apply from the payment.

The representative scrolls through each invoice and applies cash to each applicable one. The system keeps a running total of the total amount of payment (per the check) and the amount left to be applied.

1.4.7 The representative cannot close out of the Cash Application screen without applying the total check amount to the open invoices.

1.4.8 The representative is responsible for printing out the Cash Application Header screen showing the high-level details of the cash application payment including check number, check amount, and check date. The representative staples the Cash Application Header screen printout to the check copy and supporting documentation. This information is forwarded back to the Accounting Supervisor at the end of the day.

1.4.9 The Accounting Supervisor reconciles the documentation back to the Check Register to ensure all checks were applied.

Figure 1: Illustration of how business processes and internal controls are commonly documented in auditing practice:‘Example of a Level 2 Flowchart: Cash Application Sub-process Showing Transactions and Controls’ (Pricewaterhouse-Coopers 2004, p. 104).


semantics in the targeted domain (Ortner 2008).Reconstruction of a technical terminology is aniterative process involving more than the iden-tification of candidate (meta) concepts, their at-tributes and relations. Instead it requires, for in-stance, the identification and resolution of termi-nological ambiguity and truncation, which mayimply the introduction of additional abstractions.That in turn may require the shaping of theirsemantics. This implies the (re-)interpretationof observed terms and concepts and leads to de-sign abstractions appropriate for specific analy-ses and applications. The method engineeringapproach underlying the present work is there-fore driven by analyzing application scenariosdescribing, among others, model-based analyses,and by interpreting pertinent literature in thefield under consideration (Frank 2010). This sec-tion summarises key findings from the concep-tual reconstruction of the technical terminologyin the auditing domain.

3.1 Terminological analysis

In auditing literature and practice, ‘control’, ‘in-ternal control’, and ‘internal control system’ arecommonly used terms (Moeller 2008). Despitetheir proliferation, a lack of precise definitionand understanding of even these key domainconcepts has repeatedly been criticised (Maijoor2000). The term ‘control’ is in fact subject to aconsiderable diversity of disciplines, for exam-ple, ‘management control, organisational control,internal controls, operational control and finan-cial control, which all seem to revolve aroundthe same concept’ (Rikhardsson et al. 2006). Theauditing perspective on internal control is deci-sively influenced by the Committee of Sponsor-ing Organizations of the Treadway Commission(COSO) (COSO 1992, 2004) and subsequent au-diting standards such as the Public CompanyAccounting Oversight Board (PCAOB) AuditingStandard No. 5 (for a discussion see Rikhards-son et al. 2006 and Maijoor 2000): ‘COSO definesinternal control as a process, effected by an en-tity’s board of directors, management and other

personnel. This process is designed to providereasonable assurance regarding the achievementof objectives in effectiveness and efficiency ofoperations, reliability of financial reporting, andcompliance with applicable laws and regulations.[. . . ] Internal control is not merely documentedby policy manuals and forms. Rather, it is put inby people at every level of an organisation. [. . . ]’(COSO 2010; adapted from COSO 1992).

While this very broad conceptualisation providesinsights into essential domain-specific concepts(e.g., objectives, policy, reasonable assurance), italso points to (necessary?) terminological am-biguity: Internal control obviously denotes notonly a process but covers both procedural aspects(i.e., business processes, auditing and monitor-ing processes) and structural aspects (e.g., poli-cies, organisational structures, organisationalroles). Surprisingly, neither risk nor control ob-jectives are mentioned—yet both constitute es-sential concepts in the frameworks provided byCOSO and by the Information Systems Audit andControl Association (ISACA). In a later frame-work, COSO consequently adapts the internalcontrol definition to the broader context of riskmanagement: ‘Enterprise risk management isa process, [. . . ] designed to identify potentialevents that may affect the entity, [. . . ] to providereasonable assurance regarding the achievementof entity objectives’ (COSO 2004). The COSOframework, in fact, breaks down internal controlto five interrelated components: Control Envi-ronment, Risk Assessment, Control Activities,Information and Communication as well as Mon-itoring (Gelinas and Dull 2010, pp. 224–225).

A first conclusion from this brief terminologi-cal analysis pertains to the very conception of‘internal control’: Internal control cannot be con-ceived as a singular concept as such, but rather asan abstraction over various other concepts whichin turn constitute an internal control. An initialreconstruction of the constituent concepts of ‘in-ternal control’ is shown in Fig. 2. It is mainlybased on an analysis of the reviewed prior work,



Figure 2: Initial reconstruction of essential domain terminology: Domain-specific concepts visualised as a semantic net.

the mentioned COSO documentation, four text-books (Dunn et al. 2005; Elder et al. 2010; Geli-nas and Dull 2010; Gelinas et al. 2004) as wellas anonymised audit documents received from aBig Four auditor.

A key domain concept is control objective, some-times also denoted as control goal (Gelinas et al.2004, p. 249). It represents a desired state of an en-terprise (‘Prevent unauthorised refunds’) with re-spect to achieving an entity objective (‘Minimiseerror rate of incorrect refunds’) that is threatenedby a risk (‘Internal fraud due to fraudulent behav-ior of employees’). A control objective is associ-ated with a recommended course of action thatshould be taken to provide reasonable assurancethat entity objectives will be met and, thus, corre-sponding risks of not achieving it are mitigated.The course of action can involve policies, pro-cedures, practices, or organisational structuresas concrete measures or means of control imple-mented to ensure effectiveness of a control (El-der et al. 2010). An important means to preventfraud is ‘segregation of duties’ (Gelinas and Dull2010, p. 255). Segregation of duties is aimed atpreventing unauthorised transactions in a givenorganisational context (e.g., a refund returnedgoods process). Such a control means is aimedat achieving the control objective. It representsan abstraction over static means of control suchas written policies or organisational structuresand dynamic means of control such as activitiesand procedures. Alternative denominators to thecontrol means concept could have been ‘control

activity’ (IT Governance Institute 2007) and ‘con-trol plan’ (Gelinas et al. 2004, p. 249). Both, how-ever, entail a significant risk of misinterpreta-tion: The term ‘activity’ raises associations withdynamic abstractions neglecting static aspectswhile the term ‘plan’ emphasises a perspectivedifferent from the intended means-end associa-tion. Examples for general control means givenin COSO publications include the authorisationof transactions as well as adequate safeguards ofassets and records. The achievement of the de-sired outcome of a control objective is measuredby an indicator (e.g., ‘Percentage of fraudulentrefund transactions’) as is the severity of risk.Responsibilities (as in the RACI conceptualisa-tion: ‘Responsible’, ‘Accountable’, ‘Consulted’,‘Informed’) are defined typically for more thanone organisational role (‘executive’, ‘business pro-cess owner’, etc.) with respect to a control ob-jective. It is important to note that monitoringand auditing an internal control system (e.g., per-formed as audit risk assessment by an externalauditor) constitute processes detached from theactual internal control system in that the systemitself becomes subject to the audit (COSO 2009).

Figure 3 on the next page illustrates further de-scriptives of internal controls. It shows a sam-ple control matrix as used in auditing practice(Gelinas and Dull 2010, p. 227). A (process and)control matrix matches control objectives withrelevant control means grouped by business pro-cesses (Gelinas and Dull 2010, p. 649).


Appendices

pwc Page 105

Appendix VI ― Sample Control Matrix

1. Financial-statement area (F/S area)

2. Completeness (C), accuracy (A), validity (V), and restricted access (R)

3. Completeness (CO); existence or occurrence (EO); rights and obligations (RO); valuation or allocation (VA); and presentation and disclosure (PD)

4. Preventive (P) or detective (D) control

5. Automated (A) or manual (M) control

Sub-Process

Control Objective

Description and Frequency of Control Activity

Financial Statement

Area (1)

Information Processing Objectives (C,A,V, R)

(2)

Assertions (CO, EO, RO, VA, PD) – (3)

P or D(4)

A or M (5)

Invoicing

Sales invoices are accurate.

The billing system receives shipped items from the shipping system and compares, line by line, the shipped items to the original order, making changes to the original order to reflect actual quantities shipped. (Multiple times a day)

Sales C, A, V CO, EO, VA P A

Invoicing

A sales invoice is generated for every shipment or work order.

Before an invoice is processed, shipment information is matched to customer-order information to ensure the information’s accuracy and validity. (Multiple times a day)

Sales A,V A,C,E/O P A

G/L Posting

Sales are recorded in the proper period.

Management monitors sales and margins to ensure that they are aligned with expectations. (Monthly)

Sales C, A, V C,E/O D M

G/L Posting

Sales are recorded in the proper period. Postings that are made to cost of sales and/or inventory in the general ledger are appropriate.

The finance department reconciles sales in the general ledger with shipments on a weekly basis and follows up any reconciling items. This reconciliation is signed and filed. (Weekly)

Sales C, A, V C,E/O D M

Figure 3: Illustration of how internal controls are commonly documented as part of audit evidence: ‘Sample ControlMatrix’ (PricewaterhouseCoopers 2004, p. 105) showing further descriptives of internal controls (e.g., operation modedifferentiation between automated and manual control).



3.2 Requirements analysis

The principal design goals stated in the intro-ductory section—reducing complexity, fosteringcommunication and collaboration, and improv-ing transparency—are refined to establish fivedomain-specific requirements a domain-specificmodelling language aimed at supporting internalcontrols modelling should satisfy. The require-ments analysis is informed by discussions withauditors at a Big Four auditing firm and is basedon the prior terminological analysis includingthe reviewed body of literature. Both the re-quirements and the identified domain conceptsguide the following reflection on the design of adomain-specific modelling language (DSML) forinternal controls modelling.

Requirement 1—Organisational context: A DSMLshould link internal controls to the surroundingorganisational action system composed of all or-ganisational entities relevant to audit risk assess-ment. This organisational context is providedby (at least) entity objectives, business processes,business risks, performance measures, organisa-tional resources, structures, roles and their re-sponsibilities (Carnaghan 2006, p. 177).

Rationale. The organisational context in whichan internal control is designed to be used is ofparticular importance to its accurate interpreta-tion (Spira and Page 2002; Sutton and Hampton2003), especially since legal regulations and au-diting standards prescribe assessing risks at allrelevant levels of the organisation (COSO 1992;ISACA 2009). Providing explicit and qualified re-lationships between controls and organisationalcontext as part of a DSML is seen as both a con-tribution to reducing the complexity inherentto internal control systems, and to improvingtransparency of internal control matters.

Requirement 2—Multiplicity of control means: ADSML should account for the multiplicity of ac-tual means to achieve control objectives and ofthe resulting variety of internal control imple-mentation.

Rationale. A wide spectrum of ways to achievecontrol objectives is discussed employing a mul-titude of different organisational measures in-cluding policies and procedures, manual and au-tomated controls (Elder et al. 2010; Gelinas andDull 2010). Providing appropriate abstractions ofcontrol means as part of a DSML is seen as a con-tribution to improving transparency of internalcontrol matters, and to reducing the complexityof internal control systems.

Requirement 3—System of internal controls: ADSML should account for relationships amonginternal controls on different organisational lev-els, from IT operations to business processes tovalue chains to the organisation as whole.

Rationale. PCAOB Auditing Standard No. 5 andother regulations assume relationships betweeninternal controls as expressed, for instance, by acontrol hierarchy (Gelinas and Dull 2010, p. 241).Relations between internal controls need not,however, be strictly subordinate. Rather, controlsrelate to each other in often unspecified ways as,for example, exemplified by common typifica-tions of controls (Dunn et al. 2005, p. 455). Pro-viding explicit and qualified relationships amongcontrols as part of a DSML is seen as a contri-bution to reducing the complexity of internalcontrol systems, and to improving transparencyof internal control matters.

Requirement 4—Justification and assumptions: ADSML should provide means for justifying theexistence and importance of an internal controland for revealing assumptions underlying inter-nal control justification.

Rationale. It has repeatedly been suggested tofoster communication and collaboration on in-ternal control matters by annotating assertionsunderlying the control specification and its in-tended usage (Carnaghan 2006, p. 177). It is as-sumed that by providing a traceable rationale ofan internal control, accurate interpretation byauditors is fostered and communication barriersare lowered.


Requirement 5—Support for multiple perspectives:A DSML should provide perspectives specific to(groups of) stakeholders involved in the groupprocess. A perspective should, as far as possi-ble, correspond with the abstractions, conceptsand (visual) representations known and mean-ingful to the targeted (group of) stakeholders. Allperspectives should, on the other hand, be inte-grated with each other to foster cross-perspectivecommunication and cooperation.

Rationale. Audit risk assessment as a group pro-cess involves stakeholders with different profes-sional backgrounds and responsibilities as wellas specific sentiments about internal controlsand their effects (Spira and Page 2002). To fos-ter communication among these stakeholders, aDSML in support of audit risk assessment needsto take the perspectives of stakeholders with dif-ferent backgrounds—from senior managementto IT operations—into account.

4 Analysis of the potentials of anenterprise modelling approach

This section illustrates the prospects of support-ing audit risk assessment with domain-specificmodelling concepts integrated with an enterprisemodelling approach. The analysis is based ontwo presuppositions: First, it is assumed thatthe enterprise modelling method is based ona language architecture that allows for reuseof existing modelling concepts (for an exam-ple, see Frank 2008). Second, the following sce-nario presupposes that the enterprise modellingmethod provides language concepts for repre-senting control flows, goals, roles, and organisa-tional structures as is the case, for instance, withARIS (Scheer 1992, 2000) and MEMO (Frank 1994,2002)—thereby providing concepts to representthe organisational context required for internalcontrols. The MEMO approach has been chosento illustrate the application scenario in Fig. 4, be-cause it fulfills both assumptions and integratesfurther concepts essential to audit risk assess-ment, in particular risk (Strecker et al. 2010),performance measures (Frank et al. 2009) and

IT resources (Kirchner 2005). It is important tonote that the shown diagram is not intended topredetermine a notation or to preconceptualiselanguage concepts. Instead, it serves as an il-lustration of principle applications of enterprisemodels in the context of audit risk assessment.

The scenario is based on and inspired by a re-funding returned goods process drawn on byCarnaghan (2006, p. 200). The original case studydescribes a ‘refund returned goods’ process of afood manufacturer incorporating four internalcontrols: (1) ‘The sales account manager mustauthorise returns by completing a “return mer-chandise authorisation” (RMA) paper form thatis sent to customer service’; (2) ‘The informationsystem restricts the ability to create, change, ordelete sales order return and credit requests toauthorised personnel’; (3) ‘Credit notes must beapproved by the A/R manager before being ap-plied to a customer account’; and (4) ‘The systemonly allows A/R personnel to enter credit/debitmemos or receivables write-offs’. The scenarioin Fig. 4 reconstructs Carnaghan (2006)’s casestudy using the MEMO enterprise modelling ap-proach: It shows a goal model (top left) that rep-resents (an excerpt of) a hierarchy of the enter-prise’s strategic goals and subsequent businessobjectives; a business process model for ‘refund-ing returned goods’ at three different levels ofabstraction (i.e., an aggregated process and itsdecompositions; bottom left); a model of the cor-responding organisational structure (includingorganisational roles and committees; top right)and a model of IT resources used in the pro-cess (showing an information system abstractionof an ERP system; bottom right). Further mod-els such as corresponding object models are notshown in the diagram for the sake of clarity. Re-lationships between concepts in different modelsare explicitly modeled by associations (e.g., theERP system used in the business process ‘Au-thorise credit’) or by shared concepts (e.g., theorganisational role ‘A/R manager’ in both theprocess ‘Authorise credit’ and in the organisa-tional structure model).



Goo

ds

retu

rned

Goo

ds

refu

nded

Ref

und

retu

rned

go

ods

< A

/R d

epar

tmen

t >

Aut

horis

e re

turn

of

good

s

< S

ales

Acc

ount

M

anag

er >

Link

to p

rior s

ale

< In

vent

ory

cler

k >

Cre

dit c

usto

mer

ac

coun

tE

RP

Sys

tem

Goa

l: P

roce

ss 9

9% o

f al

l ref

unds

in u

nder

1 W

eek

Goa

l: M

inim

ise

erro

r ra

te o

f in

corr

ect

refu

nds

(max

. 1.5

%)

Pre

pare

cre

dit

< S

ales

Acc

ount

M

anag

er >

Aut

horis

e cr

edit

< A

/R M

anag

er >

Goo

ds li

nked

to

sal

eG

oods

re

fund

ed

IT A

rchi

tect

ure

Boar

d

Exec

utiv

e B

oard

Sal

es

...

...

uses

uses

affects

affe

cts

Inte

rnal

Con

trol

s

acco

unta

ble

resp

onsi

ble

Lege

nd

IT Landscape

com

pris

esB

usin

ess

Pro

cess

assu

res

achi

evem

ent o

f

refe

rs to

Agg

rega

ted

Bus

ines

s P

roce

ss

Goa

l

Con

trol

Obj

ectiv

e

Com

mitt

ee

Org

anis

atio

nal

Rol

e

Softw

are

IT h

ardw

are

reso

urce

dire

cts

dire

cts

#Fr

eque

ncy

of

mee

tings

[#

/mon

th]

#

IT

Ris

k: In

tern

al fr

aud

Visi

bilit

y: h

igh

Unc

erta

inty

:med

ium

‐? A/

R M

anag

erSa

les

Acco

unt

Man

ager

info

rmed

Con

trol

Obj

ecti

ve:

Prev

ent

unau

thor

ised

tra

nsac

tions

Rec

omm

ende

d A

ctio

n:En

sure

diff

eren

t us

er a

cces

s rig

hts

for

refu

nd t

rans

actio

nsis

Pre

vent

ive:

true

Cat

egor

y:IT

Con

trol

Aud

it re

fund

tra

nsac

tions

and

de

tect

irre

gula

rity

mitigates

Con

trol

Obj

ecti

ve:

Opt

imis

e IT

infr

astr

uctu

reR

ecom

men

ded

Act

ion

:Es

tabl

ish

an I

T ar

chite

ctur

e bo

ard

to g

uide

arc

hite

ctur

eis

Pre

vent

ive:

true

Cat

egor

y:IT

Con

trol

, Reg

ulat

ion:

COBI

T, P

O 3

.5

?

Indi

cato

r

Ris

k

Strategies & Goals

Organisational Structure

Business Process

refe

rs to

Goa

l: I

ncre

ase

in

cust

omer

sat

isfa

ctio

n by

5%

ITA

ccou

ntin

gSa

les

refe

rs to

ER

P S

oftw

are

Dat

abas

eS

erve

rA

pplic

atio

nS

erve

r

requ

ires

Bac

kup

mea

sure

s

#Fr

audu

lent

ref

und

tran

sact

ions

[%

]ITIT mea

sure

s

supe

rvis

es

Fina

ncia

l Off

icer

Con

trol

Obj

ecti

ve:

Prev

ent

unau

thor

ised

ref

unds

Rec

omm

ende

d A

ctio

n:Se

greg

atio

n of

dut

ies

isP

reve

nti

ve:

true

Cat

egor

y:Bu

sine

ss C

ontr

ol

Figure 4: Illustration of an enterprise modelling approach to internal controls modelling


Provided such an infrastructure exists, internalcontrols modelling can be supported by exten-sions to existing concepts and by introduction ofadditional abstractions. The latter is illustratedfirst. The scenario shown in Fig. 4 assumes thatsome constituent concepts of internal controlsare represented by additionalmodelling concepts.In particular, the control objective concept rep-resents such an addition. The control objective‘Prevent unauthorised refunds’ recommends asegregation of duties in the aggregated process‘Refund returned goods’. The internal controlsemantics is further specified by the IT control‘Prevent unauthorised transactions’, by the risk‘Internal fraud’ it aims to mitigate, by the au-dit activity ‘Audit refund transactions and detectirregularity’, and by the indicator ‘Percentageof fraudulent refund transactions’ to measureachievement of the control objective. An exten-sion to existing modelling concepts is shown asa visual overlay (a red triangle), which servesto highlight all those model elements that arerelated to an internal control. In Fig. 4, for in-stance, the process ‘Authorise credit’ is enrichedwith an overlay, as the process realises a signifi-cant part of the segregation of duties. Similarly,overlays are attached to the information systemsymbol ‘ERP system’ in the IT landscape modeland some of the organisational units in the struc-ture model, since these elements all relate to theinternal control(s).

Figure 4 also demonstrates how the control ob-jectives can be associated with concepts thatrepresent the organisational action system theyare embedded in (cf. Req. 1). First, they canbe associated to the entity objectives they areaimed at assuring the achievement of (i.e., thegoal ‘Minimise error rate of incorrect refunds’in the goal model). Second, control objectivescan be linked to static and dynamic abstractionsrepresenting means of control (cf. Req. 2). Forexample, the above mentioned control objectiverefers to the business process ‘Refund returnedgoods’, whereas the actual realisation of the rec-ommended action ‘segregation of duties’ is de-

picted at the most detailed level of the processmodel. Third, the IT control refers to an IT as-set in the IT resource model (‘ERP system’) thatrealises the segregation at the information sys-tem level by authorisation and system accesspolicies. Linking the two control objectives alsodemonstrates how associations between controlsaid in visualising internal control systems (cf.Req. 3). Associating a control objective with acorresponding risk (‘Internal fraud’) provides animplicitly rationale for the existence of a con-trol objective (cf. Req. 4) possibly indicated by aperformance measure (‘Fraudulent refund trans-actions in %’) . Finally, the integration with anorganisational structure model emphasises differ-ent types of involvement of organisational rolesas a support for multiple perspectives (cf. Req. 5).For instance, the two roles participating in the‘Credit customer account’ process – ‘Sales Ac-count Manager’ and ‘A/R Manager’ – are linkedto the control objective specifying their type ofinvolvement (i.e., ‘accountable’ respectively ‘re-sponsible’), whereas a ‘Financial Officer’ is regu-larly informed but not explicitly modeled as partof the business process.

With respect to the intended purpose of effec-tively and efficiently supporting auditors in un-derstanding a firm’s business, its risks, and con-trols, such integrated models of the enterpriseand its internal control system promise to pro-vide an intuitive access and a comprehensibleconceptual foundation for differentiated anal-ysis of the internal control system. By asso-ciating internal controls with further models(e.g., of business processes or IT landscapes) andby tagging affected reference objects with anoverlay symbol, this approach facilitates inter-nal control-related communication and collabo-ration between groups of stakeholders with dif-ferent professional backgrounds. By focusing ontypes (of controls, risks, processes etc.) ratherthan instances such an approach purposefullyreduces complexity and contributes to focusingon aspects relevant to the audit analysis.



Besides documentation, and thus queries on whatcontrols exist in an enterprise, such integratedmodels support further analyses. On the onehand, they allow for analysing controls in re-spect to the organisational context they affect.For instance, in Fig. 4, the ‘business’ control ob-jective is associated to one of the firm’s businessobjectives, a business process, and an IT resource.For auditing purposes, this allows for comparingthe current implementation of a control with, forinstance, reference models of internal controlsor check lists of prescribed control means. Onthe other hand, it allows for analyzing variousorganisational concepts with regard to whetherthey are affected by controls. Especially in organ-isational settings that experience rapid changessuch an analysis can assist in preventing fail-ure to comply with regulations. In Fig. 4, forinstance, an analysis of the committee ‘IT archi-tecture board’ reveals a relationship to a controlobjective, so that eliminating this organisationalunit from the model (e.g., as a result of a reorgan-isation project) raises an exception and notifiesstakeholders of a likely compliance violation.

We conclude that the outlined enterprise mod-elling approach promises a number of advan-tages over textual representations, simple con-ceptual models or even present business processmodelling approaches:

1. As a general prospect of enterprise modelling,the purposeful abstractions of the action sys-tem visualised by a descriptive graphical no-tation promise to reduce the complexity inanalyzing a company’s internal controls and,thus, announce support for internal and ex-ternal auditors. The syntax and semantics ofa domain-specific modelling language for in-ternal controls modelling fosters the integrityof type level models and thus the integrityof model-based analyses for audit risk assess-ment purposes.

2. The proposed reuse of existing modelling con-cepts increases the productivity of both lan-guage design and language application. Lan-guage designers benefit frommature modelling

concepts and notations and can focus on rel-evant additions and modifications. Modelersas language users benefit from the reuse ofexisting models (e.g., of business processes)and can focus on adding relevant contextualinformation (e.g., risks, indicators).

3. The partially formal specification of modellingconcepts allows for model transformationsinto other representations (e.g., to some extent,into source code), which provides a foundationfor developing corresponding information sys-tems based on a model-driven developmentapproach.

4. Reconstructing the technical terminology us-ing such an enterprise model-based approachalso carries the potential to contribute to a lessambiguous domain terminology (e.g., with re-spect to the term ‘internal control’) in that itoffers a conceptualisation of key domain con-cepts with a partially formal semantics.

Based on these considerations, we envision thatenterprise models enriched by dedicated internalcontrol concepts can be used in audit reviews asaudit evidence, i.e., as structured documentationof a firm’s internal control system—to facilitateinterpretation and assessment of controls by au-ditors. The feedback received from practicingauditors on the shown application scenario indi-cates at least partial confirmation of this work-ing hypothesis (as does Cendrowski et al. 2007,p. 208).

5 Considerations on language design

Based on the corroborative assessment of the po-tentials of an enterprise modelling approach toaudit risk assessment, this section outlines gen-eral considerations toward enhancing enterprisemodelling approaches with domain-specific mod-elling concepts for audit risk assessment, and dis-cusses essential decisions related to the designof these modelling constructs. In this section, wepresent preliminary specifications of modellingconstructs as metamodel excerpts. These specifi-cations are intended as a working draft for the


Figure 5: Tentative language design: Conceptualisation of ‘control objective’

following discourse and as a foundation for dis-cussions with and discursive evaluation by peersand domain experts.

5.1 Metamodelling foundation

The MEMO Meta Modelling Language (MEMOMML) and the corresponding language architec-ture (Frank 2008) serve as metamodelling foun-dation for the following considerations on a lan-guage design. Metamodels are specified usingthe MEMO MML defined at the meta-meta orM3 level. Using MEMO MML for defining lan-guage concepts (metatypes) at the meta level(M2) leads to integrated models at type level (M1),e.g., an organisation structure model integratedwith a business process model, a model of anIT landscape, and a model of internal controls.It also fosters reuse of existing language con-cepts shared among domain-specific modellinglanguages at the meta level (e.g., Organisation-alUnit). The reuse of modelling concepts fromexisting modelling languages in the MEMO lan-guage family is visualised by a colored rectangleattached to the metatype header indicating theconcept’s origin (cf. color legend in Fig. 8).

The application of language concepts specifiedat meta level (M2) results in models at type level(M1) representing particular types of items un-der consideration (e.g., business process types,resource types etc.). An instantiation of, for ex-ample, the metatype ControlMeans is a type, i.e.,an abstraction over all corresponding instancesin the real-world (at the instance or M0 level).

Hence, it abstracts from concrete instances suchas a concrete control activity performed by acertain representative at a certain date and time.Instead, the modelling concepts constitute ab-stractions over corresponding instance popula-tions.

5.2 Devising an infrastructure forinternal controls modelling

The initial design decision with respect to thetargeted domain pertains to the specification oflanguage concepts (metatypes) specifying an in-ternal control type. Following the results of theterminological analysis (cf. Sect. 3.1), it appearsjustified to represent an internal control by itscontrol objective and by the means of achiev-ing the control objective. Hence, two dedicatedmetatypes, ControlObjective and ControlMeans,are introduced (a similar kernel is proposed byKaragiannis 2008). To represent the semantics ofinternal controls, further refinements are, how-ever, necessary and detailed below. The rationaleof introducing those two metatypes is to enablededicated audit analyses based on respective con-ceptual models of control objectives and controlmeans.

ControlObjective

The ControlObjective concept serves to describethe intentions of an internal control. The presentlanguage specification conceptualises control ob-jective as a dedicated language concept, the Con-trolObjective metatype (cf. Fig. 5), to allow for



Figure 6: Tentative language design: Conceptualisation of ‘control means’

modeling its relations to entity objectives (Goal),risks (Risk) and organisational roles (Organisa-tionalRole) representing organisational contextimportant to proper control interpretation (Req. 1).The recursive RefersTo association between con-trol objective types allows to represent the in-ternal control system as a hierarchy or net ofcontrols (Req. 3). It enables further analyses suchas which IT controls impact which business con-trols.

The metatype Codification specifies a legal regu-lation the control objective is governed by and itsoriginating policy provider. Feedback from prac-ticing auditors revealed that it is recommendedto keep track of these codifications (e.g., a certainclause in an auditing standard) and of the orig-inating policy provider (e.g., PCAOB AuditingStandard No. 5) as a contribution to justifyingthe existence and importance of an internal con-trol (Req. 4). Associating a risk type to a controlobjective type also adds to a rationale for the ex-istence of a control objective. Moreover, the ex-plicit association of risks with control objectivesenables further analyses for auditing purposes,for instance, identifying risks without controlsand vice versa (Spira and Page 2002).

The ControlObjective modelling concept is fur-ther described by a natural language descriptionof the desired state of control by the attributeintendedState (‘Sales invoices are accurate’, ‘Pre-vent unauthorised refunds’) and by an expla-nation of the intended state, explanation (‘The

billing system receives shipping items from theshipping system [. . . ]’). In certain cases it maybe feasible to rephrase the natural language spec-ification as a formal rule to support automatedreasoning on internal controls (e.g., as an addi-tional attribute to ControlObjective). Annotatingthe financial statement area, areaFS, links a con-trol objective to financial reporting.

By associating a control objective with known vi-sual representations of business objectives, busi-ness risks, and organisational roles, the presentlanguage design supports taking on different per-spectives on internal control matters (Req. 5)where a perspective is conceptualised as a spe-cific cognitive predisposition in the context ofthe MEMO method (Frank 1994, p. 164).

Control Means

The ControlMeans language concept serves to de-scribe the static aspects of a means to achievereasonable assurance. It is detailed by the rec-ommended course of action provided in a natu-ral language specification, recommendedAction.Such a specification could mention written pol-icy and corresponding procedures (‘The Account-ing Supervisor makes copies of the checks andsends the check copies along with the invoicehard copy supporting documentation to the CashApplication Department’). The current conceptu-alisation (cf. Fig. 6) is aimed at providing flexibil-ity while, at the same time, maintaining a struc-ture for auditing purposes. The domain analysis


(a) Specification using associations

Indicator

description : StringinvolvementType : String

ControlInvolvement

RiskrecommendedAction : Stringassertion [0..*] : AssertionintendedEffect : {preventive,detective,corrective}isManual : Boolean

ControlMeans

OrganisationalRole

intendedState : Stringexplanation : StringareaFS : FinancialStatementArea

ControlObjective

Goal haspertains to

0..1

0..* 0..* 1..11..*

mon

itors

0..1

0..* 1..*measures

InformationSystem SoftwareBusinessProcess OrganisationalUnit

0..* 1..1

assures achievement of

mitigates

name : String

ControlCategorybelongs to

...


ControlInvolvement OrganisationalRoleControlObjective haspertains0..* 0..* 1..11..1

OrganizationalRoleControlObjective

responsible for1..10..* accountable

consultedinformed0..*

0..*

0..* 1..*

0..*

0..*

name : String 0..* 0..*g

ControlObjective

ApplicationControlObjectiveGeneralControlObjective ...

specification : Stringorigin : PolicyProvider

Codification governed by

1..*

0..*

occurrence : StringOccurrence

PolicyProvider

supports

refers to0..*

0..* 0..*

0..*

0..* 0..*

0..*

0..*

real

ised

by

0..*

kOrganisationalRole


ControlObjective

Goal

related to0..* 1..1

1..* 0..*


mitigates

ion : StringolicyProvider

fication governed by1..*

0..*

0..* 0..*

refers to

0..*0..*

IndicatorrecommendedAction : Stringassertion [0..*] : AssertionintendedEffect : {preventive,detective,corrective}isManual : Boolean

ControlMeans


ControlObjective

0..* 1..*measures

InformationSystem SoftwareBusinessProcess OrganisationalUnit ...

supports0..* 0..*

real

ised

by 0..*

assertionType : StringAssertion

FinancialStatementArea

0..*

C1

context ControlObjective inv: self.ControlObjective->excludes(self)C1

C1


0..* 0..* 0..* 0..*

0..* 0..* 0..* 0..*

(b) Specification using a metatype

Figure 7: Design alternatives for specification of the involvement of organisational roles.

indicates that (1) multiple means exist that can bedeployed to achieve a control objective; (2) thesame means can be reused by several controlobjectives; (3) a certain means can pertain to sev-eral structural and procedural elements and thusexhibit a ‘multidimensional’ characteristic (e.g.,a written policy corresponding with a process‘Authorise credit’). One design approach couldbe to introduce dedicated concepts to representthe intricacies of control means (e.g., modellingconcepts for policy and procedure). We havecurrently refrained from that option for two rea-sons: First, the multitude of control means (e.g.,Gelinas et al. 2004, pp. 253ff.) suggests the needfor a high degree of flexibility with respect torepresenting the spectrum of relevant measuresand the abstractions they refer to (cf. Req. 2). Sec-ond, by associating a control means with mod-elling concepts such as BusinessProcess, Organi-sationalUnit or InformationSystem, the semanticsof many control activities can be described interms of additional organisational context. Forinstance, a control means ‘Segregation of duties’can be associated with a business process ‘Au-thorise credit’ and with an information system‘ERP system’ to further describe its semanticsbeyond mentioning a written policy. The currentproposal, however, poses a number of notationalproblems, for example, how to visually identifyall elements constituting an internal control (andthus its means). Introducing overlay symbolson notation elements is a response to this issuebut relies on tool support and may, in practicalapplications, sacrifice clarity of the graphical no-tation. Further semantics is specified by assertion(Carnaghan 2006, p. 177) and intendedEffect toclassify control means into preventive, detectiveor corrective controls according to their effect

in time relative to the occurrence of a risk (Geli-nas et al. 2004, p. 253). Another characteristic iscaptured by a functional differentiation betweenmanual and automated control activities, isMan-ual. Control means may be linked to indicators,Indicator, measuring the outcome of actions asso-ciated with a particular control means (Frank etal. 2009). In the following, we discuss further de-sign issues with regard to the proposed languagedesign and outline potential paths for future re-search.

5.3 Design issues and options

Involvement of organisational roles

A main design issue relates to the different typesof involvement that organisational roles, i.e., stake-holders, can have in relation to a control objec-tive. The domain analysis suggests further dif-ferentiating the involvement of organisationalroles. For instance, the IT Governance Institutesuggests four types of involvement in the CO-BIT specification as RACI charts (IT GovernanceInstitute 2007): Responsible, Accountable, Con-sulted, and Informed. Thus, the conceptualisa-tion of the relation between roles and controlobjectives in Fig. 5 will probably not be suffi-cient for audit risk assessment purposes as itlacks elaborate semantics. Figure 7 illustratestwo design alternatives that are feasible to rep-resent different types of involvement: First, foreach identified type of involvement a particu-lar association between the metatypes represent-ing the organisational role and the control ob-jective could be specified (cf. Fig. 7a). The sec-ond option introduces a metatype as an ‘asso-ciation class’ between organisational role andcontrol objective and allows for instantiatingthese four—and further—involvement types as



Indicator


ControlInvolvement

RiskrecommendedAction : Stringassertion [0..*] : AssertionintendedEffect : {preventive,detective,corrective}isManual : Boolean

ControlMeans

OrganisationalRole


ControlObjective

Goal haspertains to

0..1

0..* 0..* 1..11..*

mon

itors

0..1

0..* 1..*measures

InformationSystem SoftwareBusinessProcess OrganisationalUnit

OrgML ITMLSMLSymbols for concepts reused from other MEMO languages: RiskML

0..* 1..1


mitigates

name : String

ControlCategorybelongs to

...specification : Stringorigin : PolicyProvider

Codification governed by

1..*

0..*

supports

MetricML

refers to0..*

0..* 0..*

0..*

0..* 0..*

0..*0..*

real

ised

by

0..*

0..*

C1


0..* 0..* 0..* 0..*

Figure 8: Tentative language design: Working draft of a DSML for internal controls modelling.

associations (cf. Fig. 7b). While the first alter-native restricts modelers to predefined types ofinvolvement and their predetermined min/max-multiplicities—and is thus likely to promote amore secure modelling, the second alternativeprovides more flexibility for language users toadd situation-specific relations (e.g., ‘supports’)without adapting the metamodel. At the stageof language design and regarding the lack of ex-periences with language use, a combination ofboth alternatives promises to account for bothsecure modelling and flexibility. The languagedesign then has to be revised at a later pointin time when repeated language application hasprovided feedback from prospective users—a gen-eral consideration pertaining to all design deci-sions discussed in the present work.

Control Categories

Another design issue pertains to representingcategories of controls and to assigning a con-trol to one or more categories, such as ‘General’,‘Application’ or ‘IT’ control. For the languagedesign, it has to be decided whether a fixed enu-meration of categories is built into the language(promoting safe and convenient modelling) or ifthe language user has to supply categories (pro-moting flexibility). The decision depends on theavailability of a generally accepted categorisa-tion of controls. Such a nomenclature currently

only seems to exist for broad categories such asgeneral controls and application controls (Elderet al. 2010, p. 372) while, at the same time, nu-merous further approaches to subcategorisingare being used (e.g., Dunn et al. 2005, pp. 441ff.).Thus, a fixed number of categories built into thelanguage is likely to fail in language applications.Moreover, a control objective can be associatedto several reference objects (via ControlMeans),which might entail an ambiguous categorisation.We therefore decided to provide a metatype, Con-trolCategory, which allows for creating and as-signing one or more categories to a control (cf.Fig. 8).

Monitoring and auditing processes

So far, we have abstracted from the monitoringand auditing processes associated with audit riskassessment (cf. Fig. 2). In principle, those pro-cesses combine characteristics of business pro-cesses and of projects: They consist of a set ofactivities following a control flow (e.g., sequence,concurrency and alternative) and are performedby organisational units (usually internal or ex-ternal auditors). However, an initial analysis ofsuch audit processes reveals a peculiar difference:While business processes are performed on a reg-ular basis, usually in high frequency each day,audit processes, in contrast, may have very differ-ent frequencies that range from an event-driven


instantiation to several instantiations per monthor year to a continuous (since automated) execu-tion. Also, audit processes differ from businessprocesses in that they are specifically designedto run ‘outside’ of a firm’s regular operationswith the intention to control a particular ‘auditobject’ such as a business process, a record oftransactions etc.

In a sense, audit processes are, therefore, associ-ated with the specific audit object(s). However,present process modelling approaches, to ourknowledge, do not provide modelling constructsto represent such qualified associations betweenprocesses (e.g., a process type ‘controls’ or ‘au-dits’ another business process type). Hence, weidentify this as an open design issue for futureresearch which may require further exchangewith domain experts. As a workaround, we pro-pose to utilise those business process modellingapproaches for modelling auditing and monitor-ing processes that provide time-related events.As the MEMO Organisation Modelling Language(MEMO OrgML) includes differentiated conceptsfor temporal events, it seems feasible to reuse theBusinessProcess concept as is indicated in Fig. 8by the role Auditing Process. The metamodel inFig. 8 consolidates the discussed design decisionsand provides a foundation for future work oninternal controls modeling.

6 ConclusionThis paper investigates the potentials of an en-terprise modelling approach to audit risk assess-ment and develops conceptualisations for mod-elling constructs as enhancements to enterprisemodelling to support audit risk assessment. Theapproach is based on the observation that en-terprise models provide a substantial foundationfor audit risk assessment in that they representthe organisational context (Req. 1) and supportmultiple perspectives (Req. 5).

Our contribution in this paper is threefold: First,we direct the discussion on supporting auditrisk assessment through conceptual models to in-clude further abstractions (i.e., goal models, role

models and (IT) resource models) common toenterprise modelling—beyond business processmodelling. Second, we refine and structure thetechnical terminology in the auditing domainby reconstructing key concepts. Third, we pre-pare for further research on a domain-specificmodelling language for audit risk assessment byreflecting key considerations and decisions per-taining to internal controls modelling.

In this paper, we focus on language concepts,especially with regard to the internal controlsystem, its justification, and implementation (cf.Req. 2–4). We discuss design alternatives forcorresponding modelling constructs as part ofa design research project to develop a compre-hensive enterprise modelling method for gover-nance, risk, and compliance. However, devel-oping a method requires further considerationsbesides language design. On the one hand, amethod has to account for a descriptive notationand corresponding diagram types targeted at theperspectives of stakeholders involved in auditrisk assessment (e.g., a dedicated internal con-trol diagram as indicated in Fig. 4). On the otherhand, a method demands for a process model thatguides auditors and stakeholders in applying andinterpreting the language concepts, for instance,for certain types of analyses. The effective andefficient use of such a method also presupposesthe availability of a modelling tool that imple-ments both the enterprise modelling method aswell as the control-related enhancements. Inthis regard, the prolegomena in the present workmark a further step toward an enterprise mod-elling method in support of audit risk assessment.Such a method and corresponding tool support(Gulden and Frank 2010) remains on our researchagenda.

References

Alencar P., Boritz J. E., Carnaghan C. (2004)The relative merits of diagrammatic versuestextual representations: a literature review oftheoretical and empirical perspectives. Work-ing Paper. University of Waterloo



Alencar P., Boritz J. E., Carnaghan C. (2008)Business Modeling to Improve Auditor RiskAssessment: An Investigation of AlternativeRepresentations. In: Proceedings of the 14thAnnual International Symposium on AuditResearch, ISAR 2008, Los Angeles, California,USA, May 30–31, 2008. American AccountingAssociation Los Angeles, CA

Amer T. S., Lucy R. F., Maris J. (2002) The ef-fects of system representation on the effi-ciency and effectiveness of control and main-tenance reviews. Northern Arizona Univer-sity, Flagstaff, AZ

Bailey, Jr. A. D., Han K. S., Stansifer R. D., Whin-ston A. B. (2000) The Intelligent Internal Ac-counting Control Model using a Logic Pro-gramming Approach. In: Vasarhelyi M. A.,O’Leary D. (eds.) Artificial Intelligence in Ac-counting and Auditing: Creating value withAI vol. 5. Rutgers Series in Accounting Infor-mation Systems. Markus Wiener Publishers,Princeton, NJ, pp. 66–93

Bradford M., Richtermeyer S. B., Roberts D. F.(2007) System Diagramming Techniques: AnAnalysis of Methods Used in Accounting Ed-ucation and Practice. In: Journal of Informa-tion Systems 21(1), pp. 173–212

Carnaghan C. (2006) Business process model-ing approaches in the context of process levelaudit risk assessment: An analysis and com-parison. In: Int J of Account Inf Syst 7(2),pp. 170–204

Cendrowski H., Martin J. P., Petro L. W. (eds.)The Handbook of Fraud Deterrence. John Wi-ley and Sons, Hoboken, New Jersey

Chen K. T., Lee R. M. (2003) Knowledge-basedevaluation of internal accounting control sys-tems — a pattern recognition approach. In:Proceedings of the American Accounting As-sociation Conference. Honolulu, HI

COSO (Sept. 1992) Internal Control — Inte-grated Framework. Last Access: The Com-mittee of Sponsoring Organizations of theTreadway Commission

COSO (Sept. 2004) Enterprise Risk Manage-ment – Integrated Framework (Executive

Summary)COSO (2009) Guidance on Monitoring Inter-

nal Control Systems: Introduction. http://www.coso.org. Last Access: The Committeeof Sponsoring Organizations of the TreadwayCommission

COSO (Sept. 2010) What is internal control?http://www.coso.org/resources.htm

Crawford M., Stein W. (2002) Auditing RiskManagement: Fine in Theory but who cando it in Practice? In: International Journal ofAuditing 6(2), pp. 119–131

Damianides M. (2005) Sarbanes-Oxley and ITGovernance: New Guidance on IT Controland Compliance. In: Inf. Sys. Manage. 22(1),pp. 77–85

Dunn C. L. (2006) Business Process ModelingApproaches in the Context of Process LevelAudit Risk Assessment: An Analysis andComparison : Discussion Comments. In: In-ternational Journal of Accounting Informa-tion Systems 7(2), pp. 205–207

Dunn C. L., Gerad G. J. (2001) Auditor efficiencyand effectiveness with diagrammatic and lin-guistic conceptual model representation. In:International Journal of Accounting Informa-tion Systems 2, pp. 223–248

Dunn C. L., Cherrington J. O., Hollander A.S. (2005) Enterprise Information Systems: APattern-Based Approach, 3. ed., internat. ed..McGraw-Hill Irwin, Boston, MA

Elder R. J., Beasley M. S., Arenes A. A. (2010)Auditing and Assurance Services: An Inte-grated Approach, 13th ed. Pearson, Bostonet al.

Ferstl O. K., Sinz E. J. (1998) SOM Modelingof Business Systems. In: Bernus P., MertinsK., Schmidt G. (eds.) Handbook on Archi-tectures of Information Systems. Springer,Berlin, pp. 339–358

Frank U. (1994) Multiperspektivische Un-ternehmensmodellierung: Theoretischer Hin-tergrund und Entwurf einer objektorien-tierten Entwicklungsumgebung. Oldenbourg,München

Frank U. (2002) Multi-Perspective Enterprise

http://www.coso.org

http://www.coso.org

http://www.coso.org/resources.htm


Modeling (MEMO): Conceptual frameworkand modeling languages. In: Proceedings ofthe 35th Annual Hawaii International Con-ference on System Sciences (HICSS). Honul-ulu, pp. 72–82

Frank U. (2008) The MEMO Meta ModellingLanguage (MML) and Language Architecture.ICB Research Report 24. Institute for Com-puter Science and Business Information Sys-tems (ICB), Duisburg-Essen University, Ger-many

Frank U. (2010) Outline of a Method for De-signing Modelling Languages. ICB ResearchReport 42. Institute for Computer Scienceand Business Information Systems, Duisburg-Essen University. Essen, Germany

Frank U., Heise D., Kattenstroth H. (2009) Useof a Domain Specific Modeling Language forRealizing Versatile Dashboards. In: TolvanenJ.-P., Rossi M., Gray J., Sprinkle J. (eds.) Pro-ceedings of the 9th OOPSLA workshop onDomain-Specific Modeling (DSM). HelsinkiBusiness School, Helsinki

Gelinas U. J., Dull R. B. (2010) Accounting In-formation Systems, 8th ed. South-WesternCengage Learning, Mason, OH

Gelinas U. J., Sutton S. G., Fedorowicz J. (2004)Business processes and information technol-ogy. South-Western Thomson Learning, Ma-son, Ohio

Governatori G., Milosevic Z., Sadiq S. (2006)Compliance checking between business pro-cess and business contracts. In: Proceedingsof the 10th IEEE International EnterpriseDistributed Object Computing Conference(EDOC’06), Hong Kong, China, Oct 16, 2006.IEEE Computer Society, Los Alamitos, CA,USA, pp. 16–20

Governatori G., Hoffmann J., Sadiq S. W., WeberI. (2008) Detecting Regulatory Compliancefor Business Process Models through Seman-tic Annotations. In: Ardagna D., Mecella M.,Yang J. (eds.) Business Process ManagementWorkshops. vol. 17. Lecture Notes in Busi-ness Information Processing Springer, pp. 5–17

Gulden J., Frank U. (2010) MEMOCenterNG –A Full-featured Modeling Environment forOrganization Modeling and Model-drivenSoftware Development. In: Soffer P., ProperE. (eds.) Proceedings of the CAiSE Forum(Short Papers and Tool Demonstrations) ofthe 22nd International Conference on Ad-vanced Information Systems Engineering(CAiSE’10), Hammamet, Tunisia, June 7–11,2010. vol. 592. CEUR Workshop ProceedingsSpringer, Berlin, pp. 76–83

ISACA (2009) IS Standards, Guidelines and Pro-cedures for Auditing and Control Profession-als Information Systems Audit and ControlAssociation Rolling Meadows

IT Governance Institute (ed.) CobiT 4.1:Framework, Control Objectives, Manage-ment Guidelines, Maturity Models. IT Gov-ernance Institute of the Information SystemsAudit and Control Association, Rolling Mead-ows

Karagiannis D. (2008) A Business process BasedModelling Extension for Regulatory Com-pliance. In: Multikonferenz Wirtschaftsinfor-matik., pp. 1159–1173

Karagiannis D., Mylopoulos J., Schwab M. (2007)Business Process-Based Regulation Compli-ance: The Case of the Sarbanes-Oxley Act.In: Requirements Engineering. IEEE, pp. 315–321

Kirchner L. (2005) Cost Oriented Modelling ofIT-Landscapes: Generic Language Conceptsof a Domain Specific Language. In: DeselJ., Frank U. (eds.) Proceedings of the Work-shop on Enterprise Modelling and Informa-tion Systems Architectures (EMISA 2005).,pp. 166–179

Lu R., Sadiq S. W., Governatori G. (Apr. 19,2009) Measurement of Compliance Distancein Business Processes. In: Inf. Sys. Manag.25(4), pp. 344–355

Maijoor S. (2000) The Internal Control Explo-sion. In: International Journal of Auditing (4),pp. 101–109

McCarthy W. E (1979) An entity-relationshipview of accounting models. In: The Account-



ing Review 54(4), pp. 667–686McCarthy W. E (1982) The REA accounting

model: A generalized framework for account-ing systems in a shared data environment. In:The Accounting Review 57(3), pp. 554–578

Moeller R. R. (2008) Sarbanes-Oxley InternalControls : Effective Auditing with AS5, CobiTand ITIL. John Wiley & Sons, Hoboken, NJ

Namiri K., Stojanovic N. (2007a) A formal ap-proach for internal controls compliance inbusiness processes. In: 8th Workshop onBusiness Process Modeling, Development,and Support, BPMDS 2007 in conjunctionwith CAiSE 2007. Trondheim, Norway

Namiri K., Stojanovic N. (2007b) Pattern-baseddesign and validation of business processcompliance. In: Proceedings of the 2007 OTMConfederated International Conference onOn the move to meaningful internet sys-tems: CoopIS, DOA, ODBASE, GADA, andIS-Volume Part I. Springer, pp. 59–76

Ortner E. (2008) Language-critical Enterpriseand Software Engineering. In: Proceedingsof the Fourteenth Americas Conference ofInformation Systems, AMCIS 2008, Toronto,ON, Canada, Aug 14–17, 2008.

Pitthan J., Philipp M. (Mar. 1997) Einsatz vonPetri-Netzen für die Aufnahme, Dokumenta-tion und Analyse Interner Kontrollsystemeim Rahmen der Jahresabschlußprüfung. In:Stucky W., Winand U. (eds.) Petri-Netzezur Modellierung verteilter DV-Systeme. 350.Universität Karlsruhe, Karlsruhe, Germany,pp. 87–104

PricewaterhouseCoopers (July 2004) Sarbanes-Oxley Act: Section 404 — Practical Guidancefor Management

Ramos M. (Oct. 2004) Section 404 Compliancein the Annual Report. In: Journal of Accoun-tancy (10), pp. 43–48

Rikhardsson P., Best P., Green P., RosemannM. (2006) Business Process Risk Manage-ment, Compliance, and Internal Control: AResearch Agenda. Department of BusinessStudies, Management Accounting ResearchGroup, Aarhus School of Business. Aarhus,

DenmarkSadiq S. W., Governatori G., Namiri K. (2007)

Modeling Control Objectives for BusinessProcess Compliance. In: Alonso G., DadamP., Rosemann M. (eds.) BPM 2007. vol. 4714.Lecture Notes in Computer Science Springer,Berlin, pp. 149–164

Scheer A.-W. (1992) Architecture of IntegratedInformation Systems : Foundations of Enter-prise Modelling. Springer, Berlin

Scheer A.-W. (2000) ARIS : Business ProcessModeling, 3rd ed. Springer, Berlin, Heidel-berg

Spira L. F., Page M. (2002) Risk Management —The reinvention of internal control and thechanging role of internal audit. In: Account-ing, Auditing & Accountability Journal 16(4),pp. 640–661

Strecker S., Heise D., Frank U. (2010) RiskM:A multi-perspective modeling method forIT risk assessment. In: Information SystemsFrontiers. Accepted for publication in theSpecial Issue on Governance, Risk and Com-pliance Applications in Information Systems

Sutton S. G., Hampton C. (2003) Risk assess-ment in an extended enterprise environment:Redefining the audit model. In: InternationalJournal of Accounting Information Systems4(1), pp. 57–73

Westerman G., Hunter R. (2007) IT Risk: Turn-ing Business Threats into Competitive Ad-vantage. Harvard Business School Press,Cambridge

Stefan Strecker, David Heise, Ulrich FrankInformation Systems and Enterprise ModellingResearch Group, Institute for Computer Scienceand Business Information Systems (ICB)University of Duisburg-EssenUniversitaetsstr. 9, 45141 Essen, Germany<firstname>.<lastname>@uni-due.de

Documents

Prolegomena of a modelling method in support of audit risk ... · Prolegomena of a modelling method in support of audit risk assessment 3 accounting information systems literature