very good scalability, which can be implemented in large scale wireless communication networks. 4) We conduct plenty of diversified numerical experiments, and simulation results demonstrate that all advantages of the. AUFH-EXP3++ algorithm in our the
Feb 4, 2013 - not surprising that, after the invention of computers, artificial ... systems and neural networks, however the creation of creative A.I.s has had.
Session types and contracts are two formalisms used to study client/server protocols. Session types ... particular for business processes, where the notion of orchestration has been introduced and developed: â Orchestration: Refers to an executable
RECENT regulations, like Sarbanes-Oxley (SOX)  and Health Insurance Portability and Account- ability Act .... Quantity. Abstract. Communicate. Protect. Action. Obligation. (a). (b). Fig. 1. (A) COMPLIANCE CHECKING ARCHITECTURE (B) PARTIAL ONTOLOGY
Feb 9, 2016 - First, suppose that the patient population is homogeneous in their response to the treatment, and that patients ... The solution proposed in Bareinboim et al. (2015) is based on the regret deci ..... is, human lives) with 95% confidence
ABSTRACT. We believe that to fully support adaptive distributed applications, middleware must itself be adaptable, adaptive and policy-free. In this paper we present a new language-independent adaptable and adaptive policy framework suitable for inte
Nov 4, 2016 - In this study, three different adaptive strategies are introduced and investigated. (i) In the first adaptive strategy, the measured systematic and random error scenarios and their assigned probabilities are updated to guide the robust
Sep 13, 2018 - Department of Physics and Engineering, Benedict College ... Over the past years, applications like Cooperative Adaptive Cruise Control (CACC) cater- ... is also provided in the form of simulation results based on a road network with 16
There is no way, for example, for data to be passed by value ... The dimensions of flexibility represent adaptiveness requirements .... objects are placed. There are two related aspects: creation policy and migration policy. The first of these contro
over physical labs. For example, some physical labs have scarcity of resources (in equipment and staff), limiting the researcher's performance. Virtual labs have relatively low costs, ... properties and characteristics of adaptive behaviour, without
systems based on the distributed object model (DOM), and service- oriented systems. ..... service, field, object type, root object type, package. Thus in this ...
Feb 4, 2013 - comparison, a network for a full standard piano would require 88 nodes, requiring 7744 memristors to ... three distinct styles of musical melody, namely jazz standards, rock'n'roll as exemplified by Elvis (his ..... multiple connections
Dec 14, 2012 - tered indexes at job execution time? How to index big data incre- mentally in a disk-based system? How to minimise the impact of indexing on job execution times? How to efficiently interleave data processing with indexing? How to creat
Dec 14, 2012 - to users' workloads by creating clustered indexes on HDFS data blocks as a byproduct of executing MapReduce .... tered indexes at job execution time? How to index big data incre- mentally in a .... HAIL can store the physical data bloc
Jun 14, 2017 - With the current growth in computing capabilities of high performance computing (HPC) systems, Exascale1 ... The failure rate of HPC systems rapidly increases, such that, failures become the norm rather than the ... resilience, progres
very good scalability, which can be implemented in large scale wireless communication networks. 4) We conduct plenty of diversified numerical experiments, and simulation results demonstrate that all advantages of the. AUFH-EXP3++ algorithm in our the
Dec 14, 2012 - would have to move data across HDFS data blocks1 in sync with all their three physical data block replicas. ... tally combining such sorted partitions. Fourth, LIAH creates clus- tered indexes rather ..... factor of three, Alice decide
alcoholic solution and (ii) contacts of health-care workers provide an enhanced view of the risk of ... hand-hygiene compliance of health-care workers were collected by wearable sensors over 12 days in an ... Data were collected from Monday, July 7,
difference in genotype in the beginning of speciation process, according to the assumption (iv)'. Then, it would be quite ...... 10.2 An answer why low penetrance is frequent in mu- tants. In the process of speciation, the ..... Kaneko K. & Yomo T.,
tionship under competition. This mechanism is understood in terms of the. 'isologous diversification theory'(Kaneko & Yomo 1997,1999), according to which organisms with identical genotypes spontaneously split into distinct phenotypes and establish a
Keywords: Diagnostic fracture injection test (DFIT); Stress Determination; Closure Pressure; Hydraulic Fracture; Variable. Compliance; Pressure Transient. 1. .... attributed to abnormal leak-off behavior (such as pressure dependent leak-off, fracture
Aug 16, 2014 - four compliance classes that describe a subject's behavior under the encouragement and no encouragement .... several problems with applying the deterministic compliance class framework of Angrist et al. (1996). First, the ...... Guide
Apr 8, 2012 - Usually, the problem of the robot error compensation can be solved in two ways ... In industrial robotic controllers, the manipulator motions are usually generated us- .... and Khatib O.. eds âSpringer Handbook of Roboticsâ, pp.
that requirements should satisfy in order to be considered compliant; (ii) a formal definition of the compliance ... Suppose that a doctor in a hospital subject to the usa Health Insurance Portability and Accountability ... To describe a solution is
Towards Adaptive Compliance Jesús García-Galán1 , Liliana Pasquale1 , George Grispos1 , Bashar Nuseibeh1,2 1
arXiv:1611.05626v1 [cs.SE] 17 Nov 2016
Lero - The Irish Software Research Centre, University of Limerick, Ireland Department of Computing & Communications, The Open University, Milton Keynes, UK
ABSTRACT Mission critical software is often required to comply with multiple regulations, standards or policies. Recent paradigms, such as cloud computing, also require software to operate in heterogeneous, highly distributed, and changing environments. In these environments, compliance requirements can vary at runtime and traditional compliance management techniques, which are normally applied at design time, may no longer be sufficient. In this paper, we motivate the need for adaptive compliance by illustrating possible compliance concerns determined by runtime variability. We further motivate our work by means of a cloud computing scenario, and present two main contributions. First, we propose and justify a process to support adaptive compliance that extends the traditional compliance management lifecycle with the activities of the Monitor-Analyse-Plan-Execute (MAPE) loop, and enacts adaptation through re-configuration. Second, we explore the literature on software compliance and classify existing work in terms of the activities and concerns of adaptive compliance. In this way, we determine how the literature can support our proposal and what are the open research challenges that need to be addressed in order to fully support adaptive compliance.
CCS Concepts •General and reference → Surveys and overviews; •Social and professional topics → Technology audits; Governmental regulations;
Keywords adaptive compliance, challenges, compliance as a service, self-adaptation
With software becoming increasingly pervasive, ensuring compliance to regulations, standards or policies is also becoming increasingly important to foster its wider adoption Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than the author(s) must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from [email protected]
SEAMS’16, May 16-17 2016, Austin, TX, USA c 2016 Copyright held by the owner/author(s). Publication rights licensed to ACM.
ISBN 978-1-4503-4187-5/16/05. . . $15.00 DOI: http://dx.doi.org/10.1145/2897053.2897070
and acceptability by society and business. For example, in recent years, compliance with industrial regulations (e.g., Health Insurance Portability and Accountability Act (HIPAA)) and data security standards (e.g., Payment Card Industry Data Security Standard (PCI-DSS) and ISO/IEC 27000series) has become an essential requirement of some software systems. Non-compliance can result in loss of reputation, financial fines1 or even criminal prosecution. Within academia, compliance has been examined in the areas of requirements engineering , Service Oriented Architecture (SOA) , cloud computing  and Business Process Management (BPM) . Each of these has tackled compliance from different perspectives, including the interpretation of regulations into compliance requirements [4, 10], compliance checking [1, 23], and the definition of a reference process for compliance management [36, 20]. Ensuring compliance is more challenging in software systems that operate in heterogeneous, highly distributed and changing environments, such as cloud computing services. Cloud providers often deliver their services to clients from different geographical locations that have their own compliance requirements. Providing customised Compliance-as-aService could relieve clients of the compliance burden and give providers a significant competitive advantage. However, cloud providers may still face different and multi-jurisdictional compliance requirements. They must also comply with the regulations that apply where their physical infrastructure resides. In a multi-tenancy environment, in which different clients may share computational resources, this could also lead to overlaps and conflicts between different compliance requirements. All this variability may in turn lead to compliance violations. Although compliance at runtime has gained attention recently [2, 12, 19], as far as we are aware, existing techniques are normally applied at design time and are unable to deal with this kind of runtime variability. In this paper, we propose adaptive compliance as the capability of a software system to continue to satisfy its compliance requirements, even when runtime variability occurs. We motivate our work by using a Platform as a Service (PaaS) scenario and provide two main contributions. First, we propose and justify a process to support adaptive compliance that extends the traditional compliance management lifecycle with the activities of the Monitor-Analyse-PlanExecute (MAPE) loop, and achieves adaptation through reconfiguration. Second, we explore the literature on software compliance to identify which activities of our process are al1
In the context of information systems, compliance refers to “ensuring that an organisation’s software and system conform with multiple laws, regulations and policies” . From this definition we can distinguish two main elements in compliance: the system and the compliance sources that have to be conformed with. Moreover, the system runs in an operating environment, that may affect the compliance sources against which the system has to conform. Figure 1 shows these elements and their different dimensions. The type of compliance sources refers to the kind of rules specified in the source. In particular, a compliance source can include regulations such as HIPAA2 , Cybersecurity Information Sharing Act (CISA)3 , and General Data Protection Regulation (GDPR)4 ; standards such as PCI-DSS5 and ISO/IEC 27000 series6 ; good practices; and internal policies within a particular organisation. Mandate refers to the optional or mandatory character of the compliance source. For example, regulations are compulsory (e.g., HIPAA in the US) while standards and internal policies (e.g., ISO/IEC 27000 series) may not. The abstraction level denotes the level of interpretation necessary to enact the statements mandated by a compliance source in a system. Regulations are usually expressed at a higher level of abstraction than standards and internal policies. For example, GDPR requires companies to prove compliance without suggesting specific mechanisms, while an internal organisation policy may specifically state that rooted Android phones cannot connect to the company’s internal network. Compliance sources apply to particular jurisdictions, territories or 2
• System users • Physical / virtual infrastructure
ready supported and which present open research challenges. Our ambition is to motivate the need of adaptive compliance and encourage researchers from the adaptive systems community to address these challenges. The rest of the paper is organised as follows. Section 2 introduces the main concepts and terminology adopted in software compliance. Section 3 presents a motivating scenario that illustrates the concerns when handling runtime variability in compliance. Section 4 describes our adaptive compliance process and its existing support in the literature. Section 5 describes research challenges related to adaptive compliance. Finally, Section 6 concludes the paper.
spheres of activity. For example, HIPAA applies to US organisations dealing with personal healthcare information, while the GDPR is intended to apply to any organisation delivering services to EU citizens. A system executes compliance controls, which are implementations of the rules defined by a compliance source. For example, section 164.312(a)(2)(iii) within HIPAA mandates the implementation of procedures to log off from an electronic session after a predetermined time of inactivity. A compliance control to address this rule could involve forcing user sessions to expire after five minutes of inactivity. Compliance controls determine the compliance level of a system with regards to its compliance sources. Three de-facto levels of compliance are proposed in the literature : ‘full compliance’ when all rules are satisfied; ‘partial compliance’ when all mandatory rules are satisfied; and ‘non-compliance’ where one or more mandatory rules are not satisfied. Although the operating environment is highly dependent on the specific application domain, we distinguish two main characterising elements. First, the system users who can reside and/or operate in different geographical locations and/or spheres of activity may need to comply with different compliance sources. Second, the physical or virtual infrastructure where a system operates influences the applicable compliance sources and the compliance level that needs to be achieved. For example, IT systems in a US hospital have to comply with HIPAA and doctors who use personal devices to access patient records become part of the operating environment. Different reference processes have been proposed in the literature to support compliance management [5, 6, 27, 32]. Figure 2 presents a simplified compliance management lifecycle covering the main activities of these processes. Initially, compliance sources are discovered depending on the system and its operating environment. Compliance sources are then interpreted to extract compliance requirements, which are expressed as rules about actors and their rights and obligations on particular data objects . During development, the requirements are implemented in the system as compliance controls. Finally, compliance requirements and controls are evaluated to determine the compliance level they ensure and to assess how they can be improved, if necessary. 4
In this section we present a PaaS scenario, shown schematically in Figure 3, to motivate adaptive compliance and illustrate the main compliance concerns arising from runtime variability. The PaaS provider offers customers a technological stack offering Database Management Systems (DBMS), run-time environments and various frameworks. The stack is deployed on top of an infrastructure which is hosted in the United States. Customers can deploy their own software applications using the stack offered by the PaaS provider. The PaaS provider also aims to provide compliance-asa-service to its clients, that is the capability to satisfy ondemand the compliance needs of its clients. As shown in Figure 3, initially the provider has to satisfy the compliance requirements of two different clients (Client 1 and 2). Client 1 operates in the US and stores patient health records, which are accessed by other third-party organisations. Hence, Client 1 has to comply with HIPAA regulations. Client 2 is also located in the US and handles its client’s credit card information using the PaaS. Therefore, Client 2 has to comply with PCI-DSS. Client 1 and Client 2 have differing compliance requirements, which the PaaS provider must ensure are satisfied. Although some cloud providers guarantee compliance for particular regulations (e.g., HIPAA compliance by Catalyze7 and TrueVault8 ), they are usually unprepared to satisfy emergent differing and varying compliance requirements. New PaaS clients could introduce new compliance demands that need to be traded-off against those of existing clients who share the same execution platform. In our scenario, Client 3 is a new client providing financial services in the US and therefore requires a certifiable degree of privacy and security (e.g., ISO/IEC 27018). Clients can also change their compliance requirements due to changes in the jurisdictions that apply to their services. For example, Client 3 is considering expanding its operations to Europe and therefore it will need to comply with the European Union’s GDPR, which requires explicit user authorisation for any re-purposing of their personal data. This could result in a direct conflict with CISA, which authorises sharing of personal data with federal institutions. Furthermore, variability in the compliance sources and the operating environment can also affect the compliance requirements and their satisfaction. In the case of compliance sources, Client 1, for example, could be required to comply with CISA in the near future. While compliance sources may rarely evolve, changes in the system and its operating environment can occur more frequently. For example, updates to the DBMS may affect how data encryption is supported and hence, the satisfaction of the compliance requirements. This also includes changes in the physical infrastructure of the service. In this sense, the PaaS provider could move some of its data centres to Europe, which would trigger the need to comply with EU regulations for data retention and management. The variability exposed by this scenario can be summarised by the following main concerns: a) Awareness. Runtime variability requires awareness of any changes that take place in the operating environment, the system and the compliance sources which can impact compliance satisfaction. In particular, PaaS clients must be 7 8
Client 3 EU
Data encryp?on Federal sharing (US)
ISO 27018 GDPR
Encrypt data transmission Repurposing authorisa?on
Login protec?on Data provenance
Pla$orm as a Service US
Infrastructure Figure 3: PaaS Scenario.
able to elicit and modify their preferences with respect to the compliance sources they need to satisfy. The provider also needs to be aware of infrastructure changes and assess how these changes impact the compliance requirements. b) Automation: Compliance-as-a-service requires executing appropriate compliance controls using a dynamic approach. This would also involve automating the discovery and interpretation of compliance sources, as well as the identification and remedy of compliance violations and potential conflicts between compliance requirements. c) Assurance: The service provider needs to produce assurances about whether or not the compliance level is that required by its clients. These assurances can be provided by collecting data, showing traceability between compliance controls and requirements or by delivering formal proofs. d) Performance: The on-demand nature of cloud computing means that a cloud provider has to respond to changes in a timely manner so as to avoid service outages.
In this section we present a process to achieve adaptive compliance and a summary of the support provided by the existing literature. This process, shown in Figure 4, extends the compliance management lifecycle of Figure 2 with added support for variability runtime concerns through the MAPE loop. The adaptive compliance process begins with the automated discovery of compliance sources with which the system needs to comply. Factors that influence the discovery of compliance sources include the system’s physical location, its sphere of activity and the potential stakeholders. Next, the compliance sources must be interpreted in order to identify the compliance requirements, which demand close collaboration between legal and domain experts, and software engineers . This activity could benefit from mechanisms to share and reuse compliance requirements, such as a multiorganisation repository. The requirements are subsequently implemented in the system as compliance controls. Since the system is intended to meet differing compliance needs at runtime, the compliance controls should be flexible enough to be enabled, disabled and customised when required.
Compliance sources/ system evoluDon ConﬁguraDon
Compliance controls ReconﬁguraDon plan
• System • Sources • Op. environment
RunDme (MAPE loop)
Figure 4: Adaptive compliance process. At runtime, the system must monitor its own state, the operating environment and the compliance sources. Any changes in these elements may result in either compliance violations or a reduced compliance level. While changes in compliance sources take place slowly, changes in the system or the operating environment often require a response at runtime. When changes are detected, the system must analyse their impact on the compliance level. First, overlaps between the applying compliance requirements should be analysed, since they might lead to conflicts and consequently compliance violations. Second, the compliance level must be checked and if compliance violations are found, these must be diagnosed to determine their causes. In that case, the system needs to plan a reconfiguration of the compliance controls to improve the compliance level when possible. Finally, the computed reconfiguration must be executed in the system, effectively improving the compliance level. This process requires of “live” models, especially at runtime to enact the Knowledge (K) component of the MAPE loop. Such models must describe the compliance sources and its requirements, the system and its compliance controls, and also the operating environment, including user preferences and the system infrastructure. The relevance of these models depends on the particular activities. Some of them are more important at design time (e.g., compliance sources for their discovery and interpretation), while others are necessary at runtime (e.g., operating environment for the monitoring, or compliance controls for the plan). In the following, we explore how the compliance literature supports the adaptive compliance activities and addresses the concerns presented in Section 3. This analysis allows us to identify topics which have been well discussed, along with gaps leading to research challenges. Table 1 relates existing approaches supporting the activities with the concerns that these approaches have addressed. Partially addressed areas are shown in light grey, while areas not addressed are shown in dark grey.
Although discovery is a fundamental activity in the compliance management lifecycle, it has received little attention from the research community. Some studies have high-
lighted its importance [24, 32], but without defining factors that affect applying compliance sources. Some studies have provided repository tools [3, 15]. Kerrigan and Law  describe environmental regulations by means of an XMLbased format and facilitate the discovery through searchable concept hierarchies. Boella et al.  provide the Eunomos web-based system to manage knowledge about laws and legal concepts in the financial sector. However, in general, discovery lacks automated support and a general taxonomy of factors.
The interpretation of compliance sources has been widely covered by the research literature . However, most of the existing work relies on partially or totally manual techniques to extract compliance requirements. These techniques include Semantic Parameterisation , goal based analysis, and CPR (commitment, privilege and right) analysis , which have been validated by means of empirical studies. Some authors have focused on compliance requirements variability, and in particular on the multiple possible interpretations of a regulation [3, 9, 31] and the evolution of the requirements . The analysis and reconciliation of potentially conflicting multi-jurisdictional requirements have also received attention [13, 10]. In terms of automation, some research efforts have focused on the description of compliance requirements by using different approaches, such as Domain Specific Languages (DSLs) , UML  or semi-formal representations . A repository of compliance requirements has also been proposed , although without real tool support. Assurances demonstrating the correctness of compliance requirements with respect to the sources have been suggested, especially in terms of traceability links [4, 9] and formal proofs [36, 3, 31].
Compliance implementation has received attention and partial automated support, in particular from the BPM community. Several works have considered configurable compliance controls for business processes, in the form of compliance descriptors , business process templates  and configurable compliance rules . Implementation automa-
Table 1: Overview of the literature, structured by the concerns and activities of adaptive compliance. tion has been addressed from different perspectives. While some approaches have proposed an automated derivation of compliance controls from the requirement descriptions , others have presented repositories of reusable process fragments  or compliance rules . Some of these also provide support for implementation assurances by explicitly linking compliance controls and requirements , and concepts of the compliance source to the application domain . However, the impact of compliance controls on the system performance has been surprisingly neglected.
The literature on monitoring is mainly focused on system changes, neglecting the compliance sources and the operating environment. While compliance sources rarely change at runtime, the operating environment does, requiring a timely detection and response. Several works have shown awareness of different monitoring factors, such as the system execution , the Quality of Service in Service Level Agrements (SLAs) , or time, resources and data in business processes . However, the operating environment has only been considered for particular aspects of specific cases in the context of business processes . Most of those works present approaches to automate the monitoring in business processes [2, 37] and SOA .
Compliance analysis is the activity that most has attracted most attention from the research community, especially for checking compliance levels. However, additional awareness on the potential conflicts of multi-jurisdictional requirements [10, 13] or the impact of the operating environment [16, 37] is necessary. Compliance checking can take place at design time and at runtime. Design time checking approaches are common for business processes, and rely on a plethora of analytical techniques, such as those based on Petri Nets [1, 26] and temporal logic [1, 7]. Similar approaches have been proposed for general regulatory compliance, by means of inference engines  and first order predicate calculus , and for business to business interactions . Runtime compliance checking has gained momentum recently, especially in business processes [2, 12, 37] and SOA [2, 23]. Some of these compliance checking approaches also provide diagnosis support (i.e. assurances) for the causes of compliance violations [12, 23, 26]. In general, checking automation and diagnosis are well covered at design and runtime. However, automated multi-jurisdictional analysis and the consideration of the operating environment for the checking remain as open challenges. Moreover, the performance of all these
approaches have been generally overlooked, although compliance checking has been proven to be np-complete for business processes .
To the best of our knowledge, the compliance literature presents very few works supporting the remedy of compliance violations. Although some authors have discussed the concept of compliance improvement [11, 5, 18], there is a lack of automated support. Cabanillas et al.  state the need to provide recovery capabilities when compliance violations are detected at runtime. Ly et al.  discuss the notion of healable compliance violations, i.e. violations that can be fixed by restructuring the process or inserting additional branches, while Ghose and Koliadis  present a partially automated technique, based on structural and semantic patterns, to modify non-compliant processes in order to restore compliance. Our vision to enact compliance improvement is through the reconfiguration of the compliance controls. In this sense, several authors have proposed configuration capabilities for implementing compliance, as shown in Section 4.3. However, none of these present specific techniques to remedy violations when detected.
The literature has not paid attention to this activity beyond works on configuration capabilities for compliance. In our view, the key concerns of this activity should be the automated execution, in a timely manner, of reconfigurations that improve the compliance level. Assurances about how the reconfiguration execution has improved the compliance level should also be provided.
Most of the research on compliance modelling has focused on compliance sources and requirements. Multiple approaches have been proposed to represent regulations, using XML notations , UML  or particular DSLs . Other works describe additional compliance sources, such SLAs extending the WS-Agreement notation , or privacy policies using OWL-DL . There are also numerous proposals to represent compliance requirements, especially by means of formal or semi-formal languages [4, 10, 13] and DSLs [2, 35]. Nonetheless, the description of compliance controls and the operating environment appear to have been overlooked: while only few works on business processes address the former [17, 30] by means of compliance descriptors and process fragments, the latter is even more neglected , as we have presented in the previous sections.
Adaptive compliance poses a number of research challenges, some carried over from “traditional” compliance work, as well as some significant new ones. Open research challenges relevant to adaptive compliance but carried over from previous compliance research include: 1) Compliance sources interpretation. Multiple authors have proposed specific techniques to interpret regulations and extract compliance requirements, especially in requirements engineering. However, existing work is still limited, since this activity usually relies on the specific domain knowledge of the requirements engineers and is performed manually. 2) Multi-jurisdictional requirements. The analysis of overlaps between different regulations has also attracted attention, although existing approaches are only partially automated. In order to detect conflicts among different compliance sources at runtime, adaptive compliance requires more fully automated analysis than provided by current techniques. 3) Remedy for compliance violations. Our work also highlighted the ongoing challenge of automated remedies for compliance violations. Although there are multiple proposals for automated compliance checking and diagnosis, existing mitigation techniques for violations usually require human intervention. Since the adaptive compliance process has to handle violations at runtime, we need to provide the process with automated, dynamic mitigation approaches. Our work also suggests that adaptive compliance raises new research challenges. We identify five main gaps in the literature that must be addressed: 4) Compliance readiness. We define compliance readiness as the capability of a system to foresee and comply with different compliance requirements. This capability requires awareness of different compliance sources and requirements that may apply to the system or its clients, and a pool of compliance controls, ready to be customised and invoked. Although some authors have envisaged variability in business process rules to respond to variable compliance requirements, those approaches need to be extended for more complex controls and scenarios. 5) Compliance automation. Currently, only compliance checking has been somewhat automated, and even so, often overlooking the impact of the operating environment. Compliance sources discovery and interpretation remain to be automated, although there are some promising partial successes [15, 3, 34]. A repository of compliance sources and their different context dependent interpretations, could support this tedious and error-prone activity. Moreover, automating the reconfiguration of compliance controls in order to correct compliance violations is needed. 6) Runtime assurances. Demonstrating compliance is often just as important as actually being compliant. There are several approaches to demonstrate compliance by tracing compliance requirements to regulations and compliance controls. However, existing support at runtime is more patchy, and focuses on compliance violations diagnosis, primarily considering systems but not their compliance sources nor their operating environment. Therefore, we need to extend the diagnosis to these elements, and provide evidence about if and how reconfigurations really increase compliance levels. 7) Models for compliance controls and operating environment. Our work shows multiple proposals to de-
scribe compliance rules and requirements, but very few to describe compliance controls and the operating environment. While the operating environment is highly dependent on the specific application domain, we think that a standard way to describe the compliance controls, their variability, and their impact on the system is necessary. 8) Impact on performance. Surprisingly, existing research has overlooked the effects of compliance on system performance. Since the adaptive compliance process is intended to handle compliance issues at runtime, performance is increasingly important. Therefore, more efficient ways are needed to check compliance, which has already been shown to be an NP-complete problem. Furthermore, empirical studies are needed to assess the impact on the system performance of executing compliance controls and monitoring the operating environment.
CONCLUSIONS AND FUTURE WORK
In this paper, we have attempted to broaden the definition of compliance-as-a-service to include our idea for adaptive compliance. We have proposed a process to achieve adaptive compliance and discussed how existing work can support the various activities of our adaptive compliance process. A short review of the literature has identified that while existing approaches focus on design-time compliance, very little work has examined the increasing run-time variability found in compliance sources, systems and their operational environment. Furthermore, our review was used to identify several future research challenges which need to be addressed in order to fulfil our vision for adaptive compliance. Although one of our main ambitions is to automate as much of the compliance process as is feasible, there are limits to this. Currently, we are better equipped to automate checking and enforcement of compliance rules. However, neither all our proposed activities nor compliance rules can be fully automated. For example, a rule that specifies the behaviour of a security incident response team may need to be crafted manually, and its enforcement depends on enforcing human behaviour. This requires a discussion on the “human-in-the-loop” aspects of adaptive compliance. Our future work will include conducting a more in-depth analysis of the literature to further investigate the compliance process gaps identified in this paper. The objective of this in-depth literature review would be to expand our understanding of related areas such as reconfiguration planning and execution in adaptive systems. As one of our main ambitions is to automate as much of the compliance process as possible, future work will need to examine which parts of the process can be automated and to what extent. This work will also look to address issues with automation through runtime re-configuration. Finally, future work will examine how our idea of adaptive compliance can be extended into other domains, such as the Internet of Things, where a myriad of heterogeneous and potentially untrusted devices interact. That could provide an additional and important cyber-physical perspective to adaptive compliance.
Acknowledgements We acknowledge SFI grant 10/CE/I1855 and ERC Advanced Grant no. 291652 (ASAP). We also thank Mark Mcgloin for later discussions on software compliance.
References  A. Awad, G. Decker, and M. Weske. Efficient compliance checking using bpmn-q and temporal logic. In 6th Int. Conf. on Business Process Management, pages 326–341, 2008.  A. Birukou, V. D’Andrea, F. Leymann, J. Serafinski, P. Silveira, S. Strauch, and M. Tluczek. An Integrated Solution for Runtime Compliance Governance in SOA. In ICSOC’10, pages 122–136, 2010.  G. Boella, M. Janssen, J. Hulstijn, L. Humphreys, and L. van der Torre. Managing legal interpretation in regulatory compliance. In 14th Int. Conf. on Artificial Intelligence and Law, pages 23–32, 2013.  T. D. Breaux, A. Ant´ on, et al. Analyzing regulatory rules for privacy and security requirements. IEEE Trans. on Software Engineering, 34(1):5–20, 2008.  C. Cabanillas, M. Resinas, and A. Ruiz-Cort´es. Exploring Features of a Full-coverage Integrated Solution for Business Process Compliance. In Advanced Information Systems Engineering Workshops, pages 218–227, 2011.  F. Daniel, F. Casati, V. D’Andrea, E. Mulo, U. Zdun, S. Dustdar, S. Strauch, D. Schumm, F. Leymann, S. Sebahi, et al. Business Compliance Governance in Serviceoriented Architectures. In Int. Conf. on Advanced Information Networking and Apps., pages 113–120, 2009.  A. Elgammal, O. Turetken, W.-J. van den Heuvel, and M. Papazoglou. Formalizing and Appling Compliance Patterns for Business Process Compliance. Software & Systems Modeling, pages 1–28, 2014.  M. Fellman and A. Zasada. State-of-the-Art of Business Process Compliance Approaches: A Survey. In 22nd European Conf. on Information Systems, 2014.  S. Ghanavati and J. Hulstijn. Impact of Legal Interpretation on Business Process Compliance. In TELERISE, pages 26–31, 2015.  S. Ghanavati, A. Rifaut, E. Dubois, and D. Amyot. Goal-oriented Compliance with Multiple Regulations. In 22nd Int. Conf. Requirements Engineering, 2014.  A. Ghose and G. Koliadis. Auditing business process compliance. ICSOC’07, pages 169–180, 2007.  M. T. G´ omez-L´ opez, R. M. Gasca, and J. M. P´erezAlvarez. Compliance Validation and Diagnosis of Business Data Constraints in Business Processes at Runtime. Information Systems, 48:26–43, 2015.  D. G. Gordon and T. D. Breaux. Reconciling multijurisdictional legal requirements: a case study in requirements water marking. In 20th Int. Conf. on Requirements Engineering, pages 91–100, 2012.  M. Kahmer, M. Gilliot, and G. Muller. Automating privacy compliance with expdt. In ECE/CEC, pages 87–94. IEEE, 2008.  S. Kerrigan and K. H. Law. Logic-based Regulation Compliance-assistance. In 9th Int. Conf. on Artificial Intelligence and Law, pages 126–135, 2003.  D. Knuplesch, W. Fdhila, M. Reichert, and S. RinderleMa. Detecting the Effects of Changes on the Compliance of Cross-organizational Business Processes. In 34th Int. Conf. on Conceptual Modeling, 2015.  F. Koetter, M. Kochanowski, A. Weisbecker, C. Fehling, and F. Leymann. Integrating Compliance Requirements across Business and IT. In EDOC, pages 218–225, 2014.  L. T. Ly, S. Rinderle-Ma, K. G¨ oser, and P. Dadam. On Enabling Integrated Process Compliance with Semantic Constraints in Process Management Systems. Information Systems Frontiers, 14(2):195–219, 2012.  L. T. Ly, F. M. Maggi, M. Montali, S. Rinderle-Ma, and W. M. van der Aalst. Compliance Monitoring in Business Processes: Functionalities, Application, and Tool-support. Information Systems, 2015.
 B. Martens and F. Teuteberg. Risk and Compliance Management for Cloud Computing Services: Designing a Reference Model. In AMCIS’11, 2011.  J. C. Maxwell, A. Anton, P. Swire, et al. Managing Changing Compliance Requirements by Predicting Regulatory Evolution. In 20th Int. Conf. Requirements Engineering, pages 101–110, 2012.  C. Molina-Jimenez, S. Shrivastava, and M. Strano. A Model for Checking Contractual Compliance of Business Interactions. IEEE Transactions on Services Computing, 5(2):276–289, 2012.  C. Muller, M. Oriol, X. Franch, J. Marco, M. Resinas, A. Ruiz-Cort´es, and M. Rodriguez. Comprehensive Explanation of SLA Violations at Runtime. IEEE Transactions on Services Computing, 7(2):168–183, 2014.  P. N. Otto, A. Ant´ on, et al. Addressing Legal Requirements in Requirements Engineering. In 15th Int. Conf. on Requirements Engineering, pages 5–14, 2007.  R. K. Panesar-Walawege, M. Sabetzadeh, and L. Briand. Supporting the verification of compliance to safety standards via model-driven engineering: Approach, tool-support and empirical validation. Information and Software Technology, 55(5):836–864, 2013.  E. Ramezani, D. Fahland, and W. M. van der Aalst. Where Did I Misbehave? Diagnostic Information in Compliance Checking. In 10th Int. Conf. on Business Process Management, pages 262–278, 2012.  E. Ramezani, D. Fahland, and W. M. van der Aalst. Supporting Domain Experts to Select and Configure Precise Compliance Rules. In Business Process Management Workshops, pages 498–512, 2014.  D. Schleicher, T. Anstett, F. Leymann, and R. Mietzner. Maintaining Compliance in Customizable Process Models. In On the Move to Meaningful Internet Systems, pages 60–75. Springer, 2009.  J. Y. Schmidt, A. Ant´ on, J. B. Earp, et al. Assessing Identification of Compliance Requirements from Privacy Policies. In 5th Int. Work. on Requirements Engineering and Law, pages 52–61, 2012.  D. Schumm, F. Leymann, Z. Ma, T. Scheibler, and S. Strauch. Integrating Compliance into Business Processes: Process Fragments as Reusable Compliance Controls. In Multikonf. Wirtschaftsinformatik, 2010.  A. Siena, S. Ingolfo, A. Perini, A. Susi, and J. Mylopoulos. Automated Reasoning for Regulatory Compliance. In 32nd Int. Conf. on Conceptual Modeling, 2013.  Tilburg University. State-of-the-art in the Field of Compliance Languages, 2008.  S. Tosatto, G. Governatori, and P. Kelsen. Business process regulatory compliance is hard. IEEE Transactions on Services Computing, 8(6):958–970, 2015.  A. Toval, A. Olmos, and M. Piattini. Legal requirements reuse: a critical success factor for requirements quality and personal data protection. In Int. Conf. on Requirements Engineering, pages 95–103, 2002.  H. Tran, U. Zdun, E. Oberortner, E. Mulo, S. Dustdar, et al. Compliance in Service-oriented Architectures: a Model-driven and View-based Approach. Information and Software Technology, 54(6):531–552, 2012.  O. Turetken, A. Elgammal, W.-J. Van den Heuvel, and M. P. Papazoglou. Capturing Compliance Requirements: A Pattern-based Approach. Software, IEEE, 29(3):28–36, 2012.  J. M. E. van der Werf, H. Verbeek, and W. M. van der Aalst. Context-aware Compliance Checking. In 10th Int. Conf. on Business Process Management, 2012.  U. Zdun, A. Bener, and E. L. Olalia-Carin. Guest Editors’ Introduction: Software Engineering for Compliance. Software, IEEE, 29(3):24–27, 2012.