=Paper=
{{Paper
|id=Vol-459/paper-7
|storemode=property
|title=Compliance Management in Multi-actors Contexts
|pdfUrl=https://ceur-ws.org/Vol-459/paper7.pdf
|volume=Vol-459
}}
==Compliance Management in Multi-actors Contexts==
https://ceur-ws.org/Vol-459/paper7.pdf
Compliance Management in Multi-actor Contexts
Riccardo Bonazzi1, Yves Pigneur1
1
HEC Lausanne, Institut de Systèmes d’Information, Internef
CH-1015 Lausanne - Switzerland
{riccardo.bonazzi, yves.pigneur}@unil.ch
Abstract. The main contribution of this paper lays in the idea of considering
regulatory compliance management as a specific situation, where risks to
mitigate are sometimes opportunities and where ambiguous and constantly
changing requirements come from different stakeholders. We designed a
solution and developed an artifact, which supports different users (namely
business managers, compliance officers, and responsible of the Enterprise
information system) achieving a shared agreement concerning the alignment
between regulations and their information system. We will present how we are
planning the test our solution in an enterprise by means of three scenarios.
Keywords: Governance, Risk, Compliance, Requirement Engineering.
1 Introduction
In this paper we intend compliance as “the act of adhering - and demonstrating
adherence- to legal, regulatory and internal policies as well as of general market
standards” (adapted from [1]). Should these policies and standards not be observed,
“compliance risk” arises as, described by the main global regulator, the Basel
Committee on Banking Supervision [2].
In recent years regulatory compliance has been seen worldwide by most enterprises
as an increasing cost burden. The regulatory risk has even topped the list of business
threats perceived by managers [3] although some studies (e.g. [4]) report an increase
of performance for those who excel in compliance management.
The main challenge comes when an enterprise is subjected to multiple regulations,
which have ambiguous, constantly evolving and sometime conflicting requirements.
To give an example, one could mention the dilemma of a Swiss bank that has
branches in United States. The Patriot Act is an American law that requires the Swiss
bank to share data about its customers with American authorities to prevent terrorism;
yet the Swiss bank has also to comply with the Swiss regulations concerning privacy.
This re-regulation movement is expected to grow in amplitude in the following years,
and compliance will increase its importance accordingly. In what concerns Enterprise
Information Systems (EIS), there is a growing need for a solution that provides
Proceedings of GRCIS 2009
automatic traceability for internal control, while assuring agility. To put in place a
compliance information system is a fixed cost, while adapting it with the evolving
regulations is a variable cost. Software is there to respond to different compliance
needs [5] but it is up to the enterprise to clearly define its requirements, knowing that
it does not exist yet a single Enterprise Governance, Risk and Compliance (GRC)
solution.
In this study we take the point of view of the IT compliance officers of a financial
institution. According to what we have been collected in our four-month internship,
IT compliance officers have to take group decisions concerning the most profitable
EIS under uncertainty in what concerns the evolution of regulations.
The current solutions to assure compliance against conflicting laws is to name
compliance officers with expertise in international compared right and audit. Existing
software helps IT compliance officers to monitor the processes of a company, yet it is
up to each compliance officer to define the controls and the rules he requires. In doing
so, the compliance officer is expected to have a clear understanding of law, business
and Information Technology (IT) domains, in order to master a situation of
negotiation between different stakeholders with different requirements. The expected
solution should be economically sustainable, technologically feasible and legally
compliant.
On top of that, a process analysis of the widely adopted quality-oriented approach
shows that it mostly takes a reactive stance, which we believe does not help achieving
efficiency and effectiveness. Indeed it requires too many controls and it acts only
once the problem already exists, which does not assure it will be contained. Recent
examples showed that society expects enterprise to adopt an ethical attitude, which
does not limit itself on trying to control risky events, but that rather avoids taking
risky paths.
We believe a quality management approach should be substituted by a risk
management one. This way enterprise should seek for prevention, it should consider
compliance as an issue while defining EIS requirements and it should collect opinions
from experts in the three domains (law, IT, business) to obtain forecasts of the future.
In this sense systems to support group decisions have been proposed in the past
years, yet they have missed integrating all the information coming from the EIS in
one tool.
Moreover there has been a growing interest in defining which is the best type of
relationship between regulator and the one who has to comply, the most recent
analysis being McKinsey’s Beardsley et al. [6]. Actor-Network theories (ANT) might
help to understand how to satisfy different stakeholders' expectations, but we are not
aware of any study in this sense being done in academic research on compliance
management.
Concerning the requirement engineering side, the specificity of compliance
management lays in the combination of ambiguous initial regulations, which have to
be transformed into requirements by a group of stakeholders with different
background and goals, in order to obtain a solution that assure efficiency and
effectiveness, i.e. a reasonable trade-off between control and allowance of the
business flow.
Proceedings of GRCIS 2009
The main research question of this study is:
How to achieve IS compliance in a multi-actor context, such as EIS compliance
to law in a financial institution?
That leads to the following sub-questions:
•What artifact would support the multi-actor and constantly evolving process
of IS compliance management facing ambiguity, traceability and efficiency?
•How to best align regulations and IS to assure long term profitability?
The rest of the article will proceed as it follows. In section 2 we will illustrate the
state of the art in compliance management support to identify which user's needs have
not been fully addressed yet. This will allow us to introduce in section 3 our proposed
artifact, which we have already developed. In section 4 we will propose three
scenarios we intend to use to evaluate our artifact. Theoretical and practical
contributions will be discussed in section 5, together with a presentation of our
directions of investigation.
2 Background Literature in Compliance Management
In this section we present some of the previous works we referred to, while designing
our artifact. We will start with the previous studies from literature and then we will
give an overview of existing software one could implement. At the end of this section
we will underline some holes in the existing research, which our solution is expected
to adress.
To assess the existing literature we will use the framework proposed in Bonazzi et al.
[7], which identifies the compliance function as composed of four steps:
identification, assessment, enforcement and feedback. We prefer it against the GRC
process proposed by Othersen et al. [8] as they refer to compliance only as a control
function.
For what concerns compliance risk identification (step number 4 in figure 2.1) new
ways to model regulations and retrieve them automatically have been proposed in the
recent years. Legal ontologies would allow the users to gain from knowledge
formalization and to allow access to multilingual and heterogeneous information
sources, and some authors managed to harmonize requirements of different laws to
assess the degree of compliance of a given situation. Yet there are methods that do not
rely mainly on ontologies and do not consider inconsistencies as something to be
avoided, like the Bagheri and Ghorbani’s [9] viewpoints integration game, through
which the inconsistencies of non-canonical requirement specifications are resolved.
The assessment step (step number 5 in figure 2.1) should follow the idea of holistic
compliance proposed by Volonino [10]. Different users coming from the law,
business and IT functions should gather and seek for a unique solution that satisfies
all. One can mention recent works on Goal Oriented Requirement Engineering by
means of i* based languages to express patterns to achieve compliance [11] and to
Proceedings of GRCIS 2009
perform gap analysis between compliance needs and existing solution in place [12],
the results of the gap analysis being the IS requirements. Otherwise the requirements
could be expressed under shape of actions to be performed, as suggested by Breaux
and Anton's [13] ontology-based extension of the Frame-Based Requirements
Analysis Method. In this case Cheng et al [14] proposed a hierarchy between control
activity objects.
On what concerns enforcement (step number 5 in figure 2.1) one could assume that
the highest compliance risk is within the interaction between software applications,
which could be seen as services. Hence compliance could then be enforced by means
of Service Oriented Architecture (SOA). According to our understanding there are
currently three major ways to ensure SOA policy management:
1. by means of business rules
2. by means of model driven methods
3. by formal methods like B-method or Alloy
Business Needs
Environment Threats
(1) Identification (2) Assessment
Governance Management Cycle
(12) Feedback (3) Enforcement
Policies
(4) Identification (5) Assessment
Compliance Management Cycle
(11) Feedback (6) Enforcement
GRC Process Maturity level
Requirements
(7) Identification (8) Assessment
Audit Risk Management Cycle
(10) Feedback (9) Enforcement
As-is model
Figure 2.1: IT GRC process (source: [7]): the four-step compliance management cycle is in
charge of aligning the Governance and the Risk Management cycles.
Finally the feedback step (step number 11 in figure 2.1) deals with visualization of the
gap-analysis, and to do so one can follow the suggestions of Bellamy et al. [15].
Existing software that fully support the compliance management life cycle falls under
two types:
Normative. GRC software, which seeks to enforce enterprise policies, that can be
classed by means of four technology areas described by Rasmussen [16]: Enterprise
Architecture, Enterprise Content Management, Business Intelligence and Business
Process Modeling.
Heuristic. Those applications implementing supports the initial rule-driven
approach by means of inference engines to allow adaptation to specific environments
(e.g. the Autonomy's IDOL suite).
Proceedings of GRCIS 2009
At the end we believe that the existing research has missed to spot three major issues,
which we experienced during our internship:
The “risk” in business management is a requirement. There might be not such a
thing as a “safe state” in an enterprise, as an enterprise that does not take risk might
not get any profit. This is a difference stance compared to the spread opinion that to
assure compliance we just need to add controls. The decision to comply with a
regulation should be rather seen as an option, which has a cost and that shall lead to
future profits.
Accountability is shared in a large enterprise, hence compliance should be
considered as a shared requirement. We do not share the idea of seeing the
compliance requirements engineering as a waterfall process, which starts with a law
expert and ends with the IT platform responsible. We believe that the alignment
between Law and IT should be done in a way that merges the viewpoints of business
managers, compliance officers and IT risk managers. Referring to Van de Ven and
Poole[17] we wish to extend the focus of GRC theories beyond the single entity (i.e.
one actor) towards the multiple entities (a business manager, a compliance officer,
and responsible of the Enterprise information system). This appears to us as a
situation where all actors gain by cooperating, even if they have different goals, as the
one described by Nalebuff and Branderburger [18].
Compliance should be rather seen as a question of alignment rather than a
simple matter of control. Many experts agree that a set of compliant processes does
not assure that the way business is conceived will be compliant. As previously
mentioned compliance is perceived by many enterprises as a strategic threat, hence
the alignment between law and IT should include the enterprise business model. We
also believe that a business model that complies with regulations should require fewer
controls at the process level, since most compliance risks are prevented by avoidance
while designing the processes themselves.
To address such issues one could deploy a system to support and trace shared
decisions between stakeholders, seeking a good balance between risk mitigation and
profitability, and representing it at the business model level.
3 Designing a Compliance Support System
In this section we will describe our designing goals and the analysis we performed
before creating the artifact.
3.1 Problem Analysis and Our Goals
Figure 3.1 illustrates the main concepts of the compliance problem and their
influences on each others. A plus on an arrow underlines a proportional relationship
between two concepts (if A increase, then B increases), while a minus implies an
Proceedings of GRCIS 2009
inverse relationship (when A increases, B decreases). Hence one can notice that
“regulations” like SOX are the consequences of “incidents”, e.g. the Enron scandal.
To increase “controls number” is the current solution to achieve a high “compliance
degree”, as it reduces the “risk” of incident while it increases the cost for the
enterprise. Too many regulations might increase “disagreements between
stakeholders” (e.g. how to put in place a sustainable solution to with SOX) which
increases the risk of a new accident, e.g. if they disagree and start each stakeholder
adopts ad-hoc solutions.
In designing our artifact we aim at obtaining an Integrated Decision Support
System for a set of coopetitve users. In its final stage it shall adopt semantic
technologies to assist compliance risk management, to automatically assess the
compliance degree of an Enterprise Information System (EIS) and to help enforcing
the required actions. Our artifact should diminish “disagreements between
stakeholders”. The results would be a proactive approach aiming at reducing “risk”
with a lower number of controls, which leads to a lower “cost” for the same
compliance degree. In the next section we will describe how we plan to evaluate these
achievements.
Figure 3.1: Problem analysis
3.2 The General Design of the Artifact
The figure in appendix represents the result of our time spent with the IT compliance
officer of the financial institution, whose data have been moved from the image to
respect confidentiality.
One can identify a list of boxes of different sizes. The big boxes are a sort of
“libraries”, i.e. a list of objects available. The user can draw the link between
components of different libraries (e.g. a regulation like SOX and the Business unit
USA) by adding a small box within a big one (e.g. by adding a small box called SOX
within the business unit USA's box). This way the traceability is assured while IT
issues are hidden to the most users, who can discuss mainly about the way to align IT
services and law/business requirements.
Proceedings of GRCIS 2009
The Top Part of the Figure. The business level of the company is represented, with
the collection of business entities, which are composed of business units. The small
squares refer to the regulations, which each business line and entity is submitted to. If
a business entity is submitted to a regulation, all its business units inherit the
compliance need. In the original design different colors of the square boxes represent
the level of compliance risk exposure after the gap analysis has been performed.
Hence a business unit in Japan might be submitted to J-SOX, the Japanese version of
SOX, and it might get a red box if it does not comply yet, while the business unit in
USA gets an orange box about SOX if a started project to comply with the law has not
finished yet.
The Middle Part of the Figure. A collection of regulations is presented. Each
regulation box shows an ID, the name of the regulation and the control activities
required.
The control activities have their own ID expressed in a circle. The color of the
circle tells if the control activity is conceived to reduce the risk by requiring a
preventing, proactive or reactive stance. This way Sarbanes-Oxley might have “SOX”
as ID, and it might require “assure internal control” as control activity, which is a
preventing/proactive activity. To define the control activities we referred to COSO
and CobiT.
The Bottom Part of the Figure. The IT solutions currently owned by the enterprise
find place. Each IT solution is conceived to support at least one control activity. Thus
Enterprise GRC software, like BWise, might support the activity “assure internal
control”.
3.3 The Data Objects
As previously mentioned, for the compliance risk identification we followed the idea
of compliance management as an alignment function between four domains, which
we represented as four different data sources. That led us to design a distributed
application, which allow different user to perform different kinds of actions while
sharing knowledge during the compliance management life cycle.
In our current stage of development, we have been focusing on the server side,
which will be described, hereby more in details. Each data type is associated with a
different data object. We refer to the problem analysis shown in figure 3.2 to illustrate
the data objects we used for the prototype. For simplicity we have been using so far
data coming from static text files, but we will switch now to data coming from data
streams. We assumed that data are coming from reliable sources, while the links
between data objects are subject of disagreement between stakeholders.
For the “Business unit” object, we considered as source the output delivered by the
business model computer aided design tool proposed by Fritscher [19].
For the “Regulation” object, we supposed to receive a source within the existing
regulatory and risk content feeds such as Complinet, Economist Intelligence Unit,
LexisNexis, and Thomson Reuters. Each regulation object refers to a written
Proceedings of GRCIS 2009
document, which is described by means of its name, the location where it is applied,
the enforcement date, and the cost of non-compliance.
For the “IT Solution” object, we supposed to receive one of the existing solutions
benchmarks (“Hype-cycle” or “Wave”) done by Gartner, Inc. and Forrester Research,
Inc. Each IT solution is associated with a cost object, which is the sum of fixed and
variable cost.
Figure 3.2: Data Objects
We have also defined another object, called “Control Activity”, which recalls the
idea of “patterns” of Compagna et al. [11], as well as the “legal annotation” of Breux
and Anton [13]. Control activities are rules, which we suppose will be given to
another system to perform inferences. An action is composed of a verb and an object,
which refers to an informal ontology that we have developed referring to COSO
Enterprise Risk Management framework and CobiT. Hence “store communication
data” is an action. Actions have parameters to express modes and time. This way
“store [WORM] (5 years) communication data” would require a Write-once Read-
many storage to retain for five years communication data. The novelty of our
approach concerning the actions extends the idea of hierarchy mentioned by Cheng et
al [14]. This way “store mail” is a subset of “store communication data”. Control
activities might lead to economic returns as a consequence of increased operational
quality, as suggested by [4].
The associations between data objects follow the viewpoints of the stakeholders.
Referring to Bagheri and Ghorbani’s [9] we expressed the subjective opinions of
stakeholders by three parameters (belief, disbelief and uncertainty), i.e. how much
they are sure the statement is correct, how much they are sure it is not correct and
how much they wonder whether the statement is correct of incorrect.
3.4 Functions of the System
The artifact has three main functions: it retrieves information from the four sources; it
presents it to the user; it collects new data from the users and updates the four sources
accordingly.
Proceedings of GRCIS 2009
The Data Retrieval. This is done periodically on the server side. Each data source is
composed of a body containing the data objects and a header with a summary of the
data objects contained. Thus in a regulation source containing information about
Sarbanes-Oxley, Patriot Act and Basel II in its body part, one shall retrieve from its
header a string “SOX-PA-Basel II”.
The Data Presentation. This is done on the client side. It starts when the client, who
has received the four headers, requests more information about a specific data object
(e.g. the business unit in USA). The client receives from the server the information
about the business unit, the regulations it has to comply with, the actions required by
the regulations and the IT solutions to enforce the actions. Data analyses (for example
those concerning the degree of compliance of the business unit) are then done on the
client side.
The Update Function. It starts when the user adds a link between two data objects
(e.g. Business Unit of USA with Basel II regulation). The user is asked to determine
his degree of certitude (sure, almost sure, what-if analysis) associated to the link he
added. The request to update is sent to server, which stores it in a log with the entire
requests for the same link. The degree of agreement between different positions is
then examined: if all position agrees on the existence of the link, the update is made
effective and all users are notified. If there no agreement between stakeholders an
issue is raised to the attention of the stakeholders involved and a possible solution is
proposed.
4 Evaluation with Case Studies
In this section we will present how we intend to perform the validation of our artifact.
We will present a set of evaluation criteria and few scenarios, which we believe a
compliance management support system should be able to address.
4.1 Our Evaluation Criteria
According to our research question, we defined the following set of evaluating
criteria, which we wanted to satisfy.
Agility. Regulations require a flexible approach to deal with their constant
evolution. Hence how does the artifact react when requirements change over time?
(We will measure it in terms of actions required for the user).
Conflicts resolution. Due to the ambiguity of regulation, different points of view of
users involved have to be harmonized. In addition to that, different laws might apply
to the same enterprise, which has to harmonize their requirements. How does the
artifact resolve such conflicts? (We will measure it in terms of conflicts resolved
against the overall viewpoints)
Proceedings of GRCIS 2009
A standard language. A common ground is required to assure common
understanding of all users involved. Which degree of standardization the artifact
adopts? (We will ask the users to define if they felt constrained by the terms used).
Automation. While seeking to increase cost efficiency a greater degree of control
automation reduces the risks linked to internal employees. Which degree of automatic
tasks is executed in the overall workflow? (We will measure it in terms of automatic
tasks executed against the overall number of task, together with the time required to
execute our process against the traditional way).
Accountability. A certain amount of decisions will have to be taken by users and
not by the artifact, to assure accountability in case of accident. How does the artifact
support such decisions and how does it assure accountability? (We will measure it in
terms of decisions, which we can assign to a specific user being accountable, against
the overall amount of decisions).
4.2 Scenario 1: Performing a Gap Analysis
A compliance officer usually needs to have a quick overview of the existing situation
concerning compliance in a determined business unit. Once the system has been
started, the compliance officer can select a business unit from the menu to have the
list of required IT solutions that are yet to be implemented, together with the expected
cost the enterprise will have to face. Table 4.1 illustrates how we expect the artifact to
react in this scenario.
Table 4.1: Performing a gap analysis
Goal To perform Gap Analysis
Preconditions Indexes already retrieved
Success End The user obtains the list of IT solutions required to comply with the existing
Condition regulations, which the business unit is submitted to
Failed End The user does not receive the list of IT solutions
Condition The list is not correct
Primary Actor User (Business manager; compliance officer; IT employee)
Trigger The user starts the Compliance Support System
DESCRIPTION 1 Server collects the headers from the data sources
2 Serve sends the header to the client
3 Client selects the business unit USA (BU1) from the business units list
4 Client Request data objects for (BU1)
5 Server sends data objects (Business Unit, Regulations, Actions, IT
solutions)
6 Client performs gap analysis
7 Client resents results (Cost)
Proceedings of GRCIS 2009
4.3 Scenario 2: Adapting Different Viewpoints of a Regulation Requirements
Once a New Interpretation of the Law Comes In
The user can affect a new regulation towards the business units, which he beliefs will
be concerned by the new law. An estimation of his degree of is required to help
harmonizing his assessment with the ones of the other users. The belief of the user is
stored in a log file and merged with belief of other users on the same matter. If the
sum of belief involves a compliance risk that is greater than the risk appetite of the
company, the regulation is added to the business unit, and a new gap analysis is
performed. The viewpoints inconsistent between users will be highlighted in the
dashboard of the interested users. Once the requirements are harmonized the set of
required tools that minimizes the cost will be proposed, together with the list of
expected profits coming from the introduction of new control actions. Table 4.2
illustrates how we expect the artifact to react in this scenario.
Table 4.2: Adapting regulations requirements
Goal To adapt requirements of a regulation
Preconditions Company risk appetite already defined.
Compliance officer has been informed of a new interpretation of SOX.
Success End The user updates the regulation requirements and the business units are
Condition automatically affected
Failed End The user cannot update the regulation requirements
Condition The business units are not automatically affected
Primary Actor Compliance officer
Trigger The user selects the business units USA and the regulation SOX
DESCRIPTION 1 Client defines his degree of certitude (Almost sure) for the link business
units USA - SOX
2 Server stores the information in a log
3 Server merges all the beliefs regarding the association business unit
USA with the regulation SOX
4 Server compares the overall belief (90% that the USA business line has
to comply with SOX) with the risk appetite of the company (1%)
5 Since 90%>1% server updates the information in the file of Business
Unit USA
6 Server sends updated data objects (Business Unit, Regulations, Actions,
IT solutions)
7 Client performs gap analysis
8 Client presents results (Cost, profit)
4.4 Scenario 3: Dealing with Future Regulation Requirements
Most strategic decision are done concerning the future, hence the users can add links,
which are yet to come. In this case their degree of certitude will be lower.
Thanks to the temporal dimension linked to the regulations, the system automatically
splits them into “existing” and “to come”. This way a compliance officer might add
today to the business unit USA a regulation that will apply in 2010. This way the IT
employee will have time to adapt the IS infrastructure, which has an impact on the
Proceedings of GRCIS 2009
installation cost, since it is not done under emergency. This type of forecast allows
what-if analysis, whose links are stored in the log with a low degree of certitude.
Table 4.3 illustrates how we expect the artifact to react in this scenario.
Table 4.3 Dealing with future regulations requirements
Goal To perform what-if analysis
Preconditions Compliance officer has intended a rumor of a new regulation for the USA.
Success End The user updates the regulation requirements adding a future date and the
Condition others users gets notified.
Failed End The user cannot update the regulation requirements by means of a future
Condition date
The others users do not get notified
Primary Compliance officer
Trigger The user adds a new law called X and sets the due time as “2010”
DESCRIPTION 1 Client defines his degree of certitude (Almost sure) for the link between
business units USA and regulation SOX
2 Server recognizes that it is in the future
3 Server updates log, merge beliefs and send updated data
4 Client recognizes that it is in the future
5 Client performs gap analysis (current)
6 Client performs gap analysis (“to come”)
7 Client presents results (Cost, profit)
5 Conclusions
We conclude this article with the discussion of findings and contributions before
moving towards limitations of the study together with hints for future works.
5.1 Discussion of Findings and Contributions
In this study we wanted to design a solution to support the multi-actor and constantly
evolving process of IS compliance management face ambiguity, traceability and
efficiency. The way we developed our artifact presented a new approach towards
compliance, which seeks at facilitating a proactive stance by introducing the temporal
dimension together with the uncertainties of multiple stakeholders.
Referring to [17] our theoretical contribution takes into consideration both the
“prescribed” and the “constructive” mode of change at the single entity level, i.e. the
life-cycle and the goal oriented approached, and extends towards the multiple entities
level by adding the “dialectic” mode of change, i.e. the negotiation between
stakeholders, which we believe should be considered as a strategic task. To make our
design falsifiable we develop a prototype and outlined how we are planning to
evaluate it by means of scenarios.
The propositions we aim at verifying with the validation are the following:
Proceedings of GRCIS 2009
Agility. A change in the environment automatically triggers a new analysis of the
overall information system architecture and delivers a new set of requirements which
maximizes the utility function (in our case the required expenses).
Conflicts resolution. Viewpoints allow merging the requirements of all
stakeholders. Conflicting regulations are analyzed on the base of the IT tools they
required, which allow us to do quantitative comparison (e.g. the overall cost of the IT
tools to buy, in each option).
A standard language. The use of viewpoints limits the needs of an ontology and
allows user to express their beliefs in the first stage. Users can add new objects, which
shall be used by all stakeholders. After each rounds of the merging game a common
language emerge between the users. This way only those new objects, which are
effectively used, will be kept in the server.
Automation. Referring to figure 2.1 our artifact supports the Identification,
Enforcement and Feedback steps. The Assessment part is left to be performed by the
user, since it requires decisions, while the system simply records the choices to assure
accountability.
Accountability. The viewpoints method allows us to obtain the solution, which will
reduce the risk of conflicting goals between stakeholders. Each viewpoint is recorded,
hence it is possible to define how decided what.
5.2 Limitations and Further Works
As previously mentioned in the current stage of software development our
assumptions are based on the data we collected during our internship. This is why we
have planned to test the artifact in the following months. Also, in this phase of
software development we focused on the best way to support and trace decisions in a
multi-actors context. In the following phases we plan to extend the functionalities of
the artifact in the following domains:
Distributed architecture. We plan to improve the way concurrent tasks are
handled, and how the server and the clients exchange data.
Data collection from real sources. Real data stream will be merged together
Use of semantic technologies. A meta-level will be needed to merge different data
stream, and we believe we could use the result of this operation to use a reasoner.
Decision support. The final artifact shall be able to optimize the utility function, as
presented by Muller and Supatgiat [20].
Automatic enforcement. A parallel study in our institute [21] is in charge of
developing the extension of our prototype towards an automated, predictive run-time
monitoring system that tells what is expected of an institution, given the regulations
and the current situation.
Improved usability. This will mainly regard the client side, but we expect it to have
consequences on the server side as well.
Proceedings of GRCIS 2009
References
1. McClean, C., Rasmussen, M.: Topic Overview: Governance, Risk And Compliance.
(2007). Available at http://www.forrester.com
2. Basel Committee on Banking Supervision: Compliance and the compliance function in
banks (2005), http://www.bis.org/publ/bcbs113.pdf
3. Economist Intelligence Unit: Regulatory Risk: Trends and Strategies for the CRO (2005).
4. IT Policy Compliance Group: Annual Report: IT Governance, Risk and Compliance –
Improving Business Results and Mitigating Financial Risk (IT Policy Compliance Group,
2008). Available at http://www.itpolicycompliance.com/research_reports/it_governance/.
5. McClean, C.: The GRC Technology Puzzle: Getting All The Pieces To Fit (2009).
Available at http://www.forrester.com
6. Beardsley, S., Enriquez, L., Nuttall, R.: Managing regulation in a new era. The McKinsey
Quarterly, 90--97 (2009).
7. Bonazzi, R., Hussami, L., Pigneur, Y.: Compliance management is becoming a major
issue in IS design. In: D’Atri, A., Saccà, D (eds.) Information Systems: People,
Organizations, Institutions, and Technologies, In press. Springer (2008). Available at:
http://tinyurl.com/grc-dss
8. Othersen, M.: Cutting Through The IT GRC Hype (2008). Available at
http://www.forrester.com
9. Bagheri, E. & Ghorbani, A.A.: The Analysis and Management of Non-Canonical
Requirement Specifications through a Belief Integration Game. Accepted Knowledge and
Information Systems: An International Journal (2009). Available at:
http://glass.cs.unb.ca/~ebrahim/papers/kais.pdf.
10. Volonino, L., Gessner, G.H. & Kermis, G.F.: Holistic Compliance with Sarbanes-Oxley.
The Communications of the Association for Information Systems, 12, 457--468 (2003).
11. Compagna, L., El Khoury, P., Krausová, A., Massacci, F., Zannone, N.: How to integrate
legal requirements into a requirements engineering methodology for the development of
security and privacy patterns. Artificial Intelligence and Law, 17, 1--30 (2009).
12. Rifaut, A. & Faltus, C. Improving Operational Risk Management System by Formalizing
the Basel II Regulation with Goal Models and the ISO/IEC 15504 Approach (2006).
13. Breaux, T.D. & Antón, A.I.: Managing Ambiguity and Traceability in Regulatory
Requirements: A Tool-supported Frame-based Approach, (2007). Available at
ftp://ftp.ncsu.edu/pub/unity/lockers/ftp/csc_anon/tech/2007/TR-2007-26.pdf
14. Cheng, C.P., Lau, G.T., Law, K.H., Pan, J., Jones, A.: Regulation Retrieval Using Industry
Specific Taxonomies, Artificial Intelligence and Law, 16, 277--303 (2008).
15. Bellamy, R.K.E. et al.: Seeing is believing: Designing visualizations for managing risk and
compliance. IBM Systems Journal, 46(2), 205--218 (2007).
16. Rasmussen, M.: Overcoming Risk And Compliance Myopia, (2006). Available at
http://www.forrester.com
17. Van de Ven, A.H. & Poole, M.S.: Explaining development and change in organizations.
Academy of management review, 520 (1995).
18. Nalebuff, B. & Brandenburger, A.: Co-opetition: Competitive and cooperative business
strategies for the digital economy. Strategy & Leadership, 25(6), 28--35 (1997).
19. Fritscher, B.: Business Model Designer From Sticky Note To Screen Interaction. (2008).
Available at: http://www.fritscher.ch/hec/projets
20. Muller, S. & Supatgiat, C.: A quantitative optimization model for dynamic risk-based
compliance management. IBM Journal of Research and Development, 51(3), 295--308
(2007).
21. Hussami, L: A decision-support system for IS compliance management (2009). Available
at: http://tinyurl.com/grc-dss1
Appendix: The design of the artifact’s interface
Business units
Regulations
Control
activities
IT Solutions