Capturing Compliance Requirements: A Pattern-Based Approach

This article first appeared in IEEE Software magazine and is brought to you by InfoQ & IEEE Computer Society.

A new pattern-based framework captures and manages business process compliance requirements by acting as a springboard to fully automate and continuously audit business processes.

In today’s IT-centric business environment, managing compliance withregulations, laws, and other imperatives has become critical for success. Directives govern almost every aspect of running a business, requiring organizations to provide assurances to regulators, stakeholders, customers, and business partners. Assuring compliance across an enterprise necessitates a holistic, tractable, and disciplined approach for defining an integrated, consistent set of process- and system-level
internal controls. Internal controls in particular should help an organization achieve its objectives regarding effective and efficient operations; reliable internal and external reporting; and compliance with applicable laws, regulations, and internal policies.1 A series of large corporate scandals in the early 2000s led to various laws and regulations, such as the Sarbanes–Oxley Act (SOX) and Basel I–III. To address these regulatory measures, many companies have taken steps to integrate controls in their business processes (BPs) and enterprise systems. However, most of these attempts have led to highly tailored, isolated solutions involving hardcoded controls implementing requirements across multiple systems. This scattered structure impedes adaptation to the constantly changing business environment and growing body of laws, regulations, and standards.2 As a first step toward comprehensive management of BP compliance, we’ve developed a pattern-based approach that captures and manages BP compliance requirements. This approach acts as a springboard to fully automate and continuously audit BPs. The Challenges of BP Compliance Mainstream approaches to managing internal controls in BPs are fragmented and focus mainly on retrospective reporting. 3 However, this can lead to reactive risk prevention, which often incurs costly penalties. Existing tools, such as Oracle GRC (Governance, Risk, and Compliance) Accelerators and SAP BusinessObjects GRC solutions, offer solutions only for monolithic applications (such as enterprise resource planning systems). This severely restricts these solutions’ usability for modern BPs and supporting enterprise systems, which are highly distributed and interconnected.

BP compliance and specifications should be decoupled and managed as separate entities because they adhere to different life cycles and because different stakeholders typically formulate them.3 By logically decoupling compliance requirements from process specifications, we can better manage their independent evolution and adaptation. To achieve this, we should establish round-trip traceability between compliance requirements and BP specifications. Analyzing changes’ impacts requires compliance requirements to be traceable back to their original sources and forward to the processes and enterprise systems that implement and enforce them. In this way, we can also avoid duplicate implementations and methods of handling compliance information in different applications.

We can considerably reduce the errors and omissions generated in expensive manual process inspections by partially or fully automating assurance tasks, thereby lowering compliance assurance’s overall cost. The degree of this automation is contingent on the ability to capture and formalize compliance requirements. Unfortunately, using formal languages to capture compliance requirements is diffi cult for business users who are unskilled or inexperienced with such languages.

Our Framework and Model

The problems related to BP compliance, including adaptability and evolution, reactive risk management, and automation (including formalization), demand a repeatable, predictable, holistic approach spanning the BP life cycle. To address these problems, we first developed a BP compliance management (BPCM) framework that integrates compliance management practices with the BP life cycle. Then, we developed a conceptual model (aligned with the framework) for a centralized compliance repository to capture and manage compliance requirements and relevant concepts. (An earlier paper introduces the underpinnings of the framework and conceptual model.4) figure 1. The business process compliance management (BPCM) framework. (a) Its operational components. (b) The conceptual model for the compliance repository’s key elements. The framework integrates compliance management practices with the BP life cycle. The model captures and manages compliance requirements and relevant concepts.

(Click on the image to enlage it)

figure 1. The business process compliance management (BPCM) framework. (a) Its operational components. (b) The conceptual model for the compliance repository’s key elements. The framework integrates compliance management practices with the BP life cycle. The model captures and manages compliance requirements and relevant concepts.

Figure 1a depicts an operational view of our framework; for a description of the key operational components, see the “Business Process Compliance Management Framework” sidebar. The figure illustrates how the main phases in the BP life cycle are interconnected to compliance management practices to achieve  compliance to requirements. These practices are grounded in the COSO (Committee of Sponsoring Organizations of the Treadway Commission) framework,1 the de facto standard for establishing internal controls. Figure 1b shows the key concepts and relationships that emerge from the compliance management practices, which comprise the building blocks of the compliance repository. The framework incorporates patterns to facilitate a business-user-friendly way to define internal controls for recurring compliance requirements in a semiformal (graphical) notation. This facilitates automated generation of the corresponding formal  specifications, while helping to shield business and compliance experts from formal languages’ complexity. We extended and enhanced our pattern-based approach in diverse directions to address a wider range of control rules. To investigate the approach’s applicability, we implemented an integrated suite of software applications and experimented with three of the suite’s key components in two case studies.

Controls and Process

Control Patterns

Controls can be preventive or detective. Preventive controls help prevent violations; examples include authorizations, segregation of duties, and supervisory approval. Detective controls often produce information regarding an occurred violation to help people understand its causes; examples include management reviews and reconciliations. We can also categorize controls by where they’re applied.5 Process controls apply policies and practices concerning the design and execution of BPs; such controls include authorizations, approvals, inspections, and segregation of duties. Technical controls involve using devices or systems mainly for authentication, encryption, or security purposes; such controls include firewalls and intrusion prevention or detection systems. Physical controls exist largely to guard critical assets; such controls include locks, fences, and alarms.

Controls and Business Processes

BPs are subject to both preventive and detective process controls. Automating these controls is of the utmost importance because, in the long run, periodically designing and testing manual controls is expensive. Automated assurance of processes implemented in enterprise systems assumes formally define rules for process controls. We should formalize only those controls that we can cost-effectively check and monitor through automated techniques. A control rule is typically a declarative statement consisting of a set of conditions followed by one or more conclusions. BP elements and their attributes are the building blocks of rule statements. For example, using linear temporal logic (LTL), we can formally specify a control that checks “Customer loan requests above $1 million to be approved by supervisors”:

G(CreateLoan.LoanAmount > $1M ?
F(ApproveLoan.Role(Supervisor))

Facilitating Formalization

Formally specifying rules for automated compliance assurance offers great value to compliance management. However, formal languages’ complexity and inherent usability problems pose significant difficulties for users. We developed process control patterns to help compliance and business experts specify structured and semiformal representations of process controls and to automatically generate formal rules for subsequent compliance assurance activities. Control patterns are high-level, domain-specific templates that represent desired properties that apply to process specifications. For instance, Receive_Invoice LeadsTo Make_Payment uses the LeadsTo pattern to express a control that checks whether Make_Payment logically follows Receive_Invoice. Expressions use patterns and process elements, their attributes, or conditions based on them. To address the specification of complex controls, we can combine expressions and nest them via Boolean operators (such as and, or, and xor).

We should formalize only those controls that we can cost-effectively check and monitor through automated techniques.

Identifying Patterns

To discover patterns for recurring types of controls, we analyzed a range of regulations, standards, and frameworks—for example, COSO, COBIT (Control Objectives for Information and related Technology), OCEG (Open Compliance & Ethics Group) GRC, ISO/IEC 27000, and SOX—and investigated compliance requirements in several studies. We also studied research on pattern-based approaches for specifying diverse requirements for processes (see the “Related Work in Automating Compliance” sidebar). In identifying the patterns, we focused on preventive process controls that we could apply to automated design-time verification and runtime monitoring. We distinguish between four pattern classes:

• Order patterns concern the behavioral aspect of process specifications, such as activity sequencing.
• Occurrence patterns address rules concerning the existence of certain structures or conditions in process specifications.
• Resource patterns address authorizations, assignments, and segregation-of-duties requirements. For example, Verify_Banking_Privilage SegregatedFrom Check_Credit_Worthiness specifies a segregation-of-duties rule indicating that these activities must be assigned different roles and that different users must perform them.
• Time patterns are used with order and occurrence patterns to address temporal rules over processes. For example, Receive_Invoice LeadsTo Make_Payment_Within 5(days) specifies a time constraint on the flow of activities.

Table 1 lists the patterns we identified.

(Click on the image to enlage it)

It groups them into basic and advanced categories to distinguish between commonly used patterns and those that are less frequent and typically address more complex controls.

Mapping

Following a pattern-based approach, we can abstractly express a control using patterns and then map them into a set of formal statements using a mapping scheme between the patterns and appropriate formal languages. We used LTL and metric temporal logic (MTL) as formal languages, mainly because of their expressive power and widespread use in research and practice. MTL lets us formalize expressions that use time patterns; LTL doesn’t support such properties.
For each pattern, we developed a mapping to LTL or MTL to automatically generate corresponding formal statements. For example, Verify_Banking_Privilege SegregatedFrom Check_Credit_Worthiness generates these LTL statements:

• F(Verify_Banking_Privilege) ^ F(Check_Credit_Worthiness) checks whether these two activities exist in the specification.
• G(Verify_Banking_Privilege.Role(Role1) ?(Check_Credit_Worthiness.Role(Role1))) checks whether the two activities are assigned to different roles.
• G(Verify_Banking_Privilege.User(User1) ?(Check_Credit_Worthiness.User(User1))) checks whether different users perform these two activities.

We can use these statements as input to compliance verifi cation and monitoring.

Implementation

Figure 2 shows our software suite’s three key components. (Working demonstrations are at http://eriss.uvt.nl/compas.) The compliance requirements manager helps compliance and business experts defi ne and manage compliance information and associate it with BPs. This information’s key elements are the requirements, directives, risks, controls, and formally specifi ed rules. We implemented this component as a Web application, and it acts as an interface to the compliance repository. The compliance rule modeler (see Figure 3) is a stand-alone tool for designing graphical representations of pattern-based expressions and automatically generating corresponding formal statements. It retrieves the process elements that help build the expressions from the BP repository and stores the expressions and generated formal statements in the compliance repository. Both repositories share the same database environment. The design-time compliance verification manager is a Web application that supports the static verification of process specifi cations against formal rules. First, it retrieves the process models (specifi ed in Business Process Execution Language) to be verified from the BP repository. Then, using the integrated Web Service Analysis Tool (WSAT; www.cs.ucsb.edu/~su/WSAT), it transforms them into formal representations so that the Spin model checker (http://spinroot.com) can check them against formal control rules. Both WSAT and Spin are widely used tools. Next, this component retrieves the results from the model checker and reports them to the dashboard.

(Click on the image to enlage it)

figure 2. The three key components of the BPCM suite, including the business process and compliance repositories.

Case studies

The two case studies involved banking and e-business; we chose these domains because they apply strict, highly diverse regulations. The fi rst case study involved loan processing. The second involved an Internet reseller company and covered processes such as order processing, invoicing, payments, and delivery. We observed how the participants applied our approach and the three tool suite components, and we tested the patterns’ expressiveness in capturing controls originating from real-life requirements. In total, 59 high-level compliance requirements constrained the processes we covered in the case studies; these requirements covered concerns such as segregation of duties, management reviews, and authorizations. These requirements originated mainly from ISO/IEC 27000, SOX, and internal policies. For both studies, the research team comprised three compliance and two business experts; they cooperated closely to work through our framework’s stages. The case organizations had already identifi ed the directives with which they aimed to comply. Taking into account the requirements originating from these  directives and the existing processes’ definitions, the team identified and assessed the risks to fulfill the  requirements. Then, they defi ned the necessary controls to mitigate risks, generated formal rules, and verifi ed process specifications against these controls.

Table 2 shows the types and number of controls resulting from the risk assessment.

(Click on the image to enlage it)

Most were preventive process controls, involving rules that concerned mainly segregation of duties, condition-based sequencing of activities, and authorizations. The detective process controls mostly involved management reviews and reconciliations. On the other hand, the technical controls were preventive and involved using specific techniques for data encryption, data retention, and authentication mechanisms.
Preventive process controls were of particular interest to us because they’re the main target for pattern-based representations and formalization. Participants were able to express 72 controls (out of 82) using the rule modeler but couldn’t express 10 preventive process  controls using available patterns. Those 10 controls mainly involved rules regarding the structure and integrity of the data manipulated during the processes. They typically demanded sequential numbering of certain business objects such as orders or invoices. Patterns weren’t effective for this type of control. Likewise, the patterns didn’t support the  epresentation and formalization of technical controls, physical controls, and detective process controls because their verifi cation often requires manual checks to guarantee assurance. Despite these limitations, patterns effectively expressed and formalized controls for automated assurance. In particular, they accurately captured and verifi ed concerns relevant to control-fl ow, resource, and temporal aspects of processes. The PLeadsTo order pattern was most common, followed by the SegregatedFrom resource pattern and Exists occurrence pattern. Among time patterns, Within k was the most common. These four patterns appeared in the expressions of 60 (out of 72) process controls.

(Click on the image to enlage it)

figure 3. A screenshot of the compliance rule modeler showing examples of graphical, pattern-based expressions. It retrieves the process elements that help build the expressions from the BP repository and stores the expressions and generated formal statements in the compliance repository.

Our research is ongoing in several directions to enhance and fully support the compliance management framework. We’re developing and experimenting with the compliance-monitoring and resolution mechanisms for runtime compliance management. In addition, we’re defining vertical compliance management solutions to cater to industry-specific compliance requirements in domains such as healthcare, environment, energy, and manufacturing. Finally, we’re moving our compliance management solutions into the cloud and offering them in an open compliance-as-aservice platform.

Acknowledgments

We thank PricewaterhouseCoopers (Netherlands), Thales Services (France), and our COMPAS (Compliance-Driven Models, Languages and Architectures for Services) project partners for assisting with the case studies and scenarios and for their valuable feedback.

References

1. Internal Control—Integrated Framework, Committee of Sponsoring Organizations of the Treadway Commission (COSO), 1994.
2. T. Meservy et al., “The Business Rules Approach and Its Impact on Software Testing: A Case Study,” IEEE Software, preprint, 29 Sept. 2011; doi:10.1109/MS.2011.120.
3. G. Governatori and S. Sadiq, “The Journey to Business Process Compliance,” Handbook of Research on Business Process Modeling, J. Cardoso and W. van der Aalst, eds., IGI Global, 2009, pp. 426–454.
4. O. Turetken et al., “Enforcing Compliance on Business Processes through the Use of Patterns,” Proc. 19th European Conf. Information Systems (ECIS 11), Assoc. Information Systems, 2011, paper 5.
5. Red Book 2.1 (GRC Capability Model), Open Compliance and Ethics Group, 2012.

The Business Process Compliance Management Framework

The business process compliance management framework has the following key operational components. (To see how they fit together, see Figure 1 in the main article.)

Objective Setting and Boundary Identification

The first step to an improved understanding and establishment of compliance is setting objectives and identifying boundaries. Boundaries include both  mandatory directives, such as laws and regulations (for example, SOX—the Sarbanes-Oxley Act), and voluntary sources, such as best practices, standards, policies, and business contracts. From the compliance perspective, key concepts in this phase are directives (compliance sources) and compliance requirements. Requirements can take the form of abstract constraints or control objectives, such as those specified by the COBIT (Control Objectives for Information and related Technology) framework.

Risk Assessment and Response

A risk-based approach is fundamental to better understand and manage the inherent uncertainty involved in pursuing organizational objectives. Taking into consideration the compliance objectives and the current design of processes, it’s essential to identify, assess, and prioritize the key events that might compromise process compliance.

Control Definition and Implementation

Controls are key to decreasing the likelihood of a compliance risk. They mitigate risks and provide reasonable assurance of compliance requirements’ fulfillment. At this stage, compliance experts (internal auditors) typically work with legal experts and business process (BP) experts. This is because analyzing risks over processes and defining necessary controls requires not only compliance but also BP domain knowledge.

Design-Time Compliance Verification

Design-time compliance verification is a preventive key to ensuring that processes progressing to execution are compliant by design. This typically involves using model checking to statically verify process specifications against formal control rules that can be checked during the BP life cycle’s design phase. Once the process specifications are verified, tested, and reach a steady state, they’re deployed and executed.

Runtime Compliance Monitoring

At design time, verification of processes against all applicable requirements isn’t always possible because some rules require runtime information or variable instantiations that aren’t available then. At runtime, we observe the executing instances of processes against those rules that depend on runtime conditions. Like design-time verification, runtime compliance monitoring is preventive—it aims to detect possible violations before they occur. For example, a segregation-of-duties requirement might prevent a particular user from approving the order that he or she created.

Offline Compliance Analysis and Monitoring

This detective step complements prior preventive assurance activities to provide a lifetime guarantee for BP compliance. This stage mainly involves analyzing process execution data to detect possible violations and trends. Dashboards present findings in the form of compliance indicators. If monitoring indicates deviations from or violations of requirements, process definitions might need corrective adjustments.

Related Work in Automating Compliance

Research on automating compliance assurance of business processes (BPs) and enterprise systems typically exploits formal techniques^1–3 and concentrates on specific BP concerns or a certain BP life-cycle phase. To facilitate the rule specifications at the user level, some researchers have adapted pattern-based approaches or graphical languages. For example, Kioumars Namiri and Nenad Stojanovic focused on the BP execution phase and proposed a set of patterns for monitoring compliance at runtime². Linh Thao Ly and her colleagues followed a similar approach for monitoring BP executions against requirements specified using compliance rule graphs, a language for modeling rules regarding events’ occurrence and ordering⁴.
Wil van der Aalst and his colleagues applied process-mining techniques on process event logs or real-time data to monitor the processes’ behaviors⁵.
For static BP verification during design time, Jian Yu and his colleagues⁶ extended the patterns that Matthew Dwyer and his colleagues proposed. Volker Gruhn and Ralf Laue also studied extensions to those patterns for rendering real-time related properties⁸. Ahmad Awad and his colleagues introduced a visual language, BPMN-Q (Business Process Modeling Notation-Query), that implements a basic set of patterns (occurrence, leads-to, and precedes) to express compliance requirements regarding BP control flow and data flow⁹. BPMN-Q uses computational tree logic (CTL) as its formal underpinning. Andreas Speck and his colleagues proposed G-CTL, a graphical language for CTL, for specifying process requirements to be verified at design time. However, their specification doesn’t employ patterns¹⁰. Modeling resource allocations and authorizations in BPs is also an important research area, particularly in information systems security. Christian Wolter and Andreas Schaad proposed a set of patterns for modeling such constraints in BPMN models¹¹. The patterns commonly applied in the research discussed here form the basis for most of the patterns in Table 1 in the main article. We consolidated these patterns and extended them in diverse directions to cover a wider spectrum of rules, taking into account various compliance directives. We then investigated their use and capability in real-life cases.

References

¹G. Governatori and S. Sadiq, “The Journey to Business Process Compliance,” Handbook of Research on Business Process Modeling, J. Cardoso and W. van der Aalst, eds., IGI Global, 2009, pp. 426–454.
²K. Namiri and N. Stojanovic, “Pattern-Based Design and Validation of Business Process Compliance,” Proc. Confederated Int’l Conf. On the Move to Meaningful Internet Systems (OTM 07), LNCS 4803, Springer, 2007, pp. 59–76.
³Y. Liu, S. Muller, and K. Xu, “A Static Compliance-Checking Framework for Business Process Models,” IBM Systems J., vol. 46, no. 2, 2007, 335–361.
⁴L.T. Ly et al., “Monitoring Business Process Compliance Using Compliance Rule Graphs,” Proc. Confederated Int’l Conf. On the Move to Meaningful Internet Systems (OTM 11), LNCS 7044, Springer, 2011, pp. 82–99.
⁵W.M.P. van der Aalst, H. Beer, and B.F. van Dongen, “Process Mining and Verification of Properties: An Approach Based on Temporal Logic,” Proc. Confederated Int’l Conf. On the Move to Meaningful Internet Systems: CoopIS, DOA,and ODBASE, Part 1, LNCS 3760, Springer, 2005, pp. 130–147.
⁶J. Yu et al., “Pattern Based Property Specification and Verification for Service Composition,” Proc. 7th Int’l Conf. Web Information Systems Eng. (WISE 06), LNCS 4255, Springer, 2006, pp. 156–168.
⁷M. Dwyer, G. Avrunin, and J. Corbett, “Patterns in Property Specifications for Finite State Verification,” Proc. 21st Int’l Conf. Software Eng. (ICSE 99), ACM, 1999, pp. 411–420.
⁸V. Gruhn and R. Laue, “Specification Patterns for Time-Related Properties,” Proc. 12th Int’l Symp. Temporal Representation and Reasoning (TIME 05), IEEE CS, 2005, pp. 189–191.
⁹A. Awad, M. Weidlich, and M. Weske, “Visually Specifying Compliance Rules and Explaining their Violations for Business Processes,” J. Visual Languages and Computing, vol. 22, no. 1, 2011, pp. 30–55.
¹⁰A. Speck et al., “Formalizing Business Process Specifications,” Computer Science and Information Systems, vol. 8, no. 2, 2011, pp. 427–446.
¹¹C. Wolter and A. Schaad, “Modeling of Task-Based Authorization Constraints in BPMN,” Proc. 5th Int’l Conf. Business Process Management (BPM 07), LNCS 4714, Springer, 2007, pp. 64–79.

About the Authors

Oktay Turetken is a research fellow at the European Research Institute in Service Science at Tilburg University. His research interests include business process management, governance, risk and compliance, software process improvement, and project management. Turetken has a PhD in information systems from Middle East Technical University. Contact him at o.turetken@uvt.nl.

Amal Elgammal is a PhD student in information management at the European Research Institute in Service Science at Tilburg University. Her research interests include business process verifi cation, business process compliance management, healthcare compliance, business process monitoring and auditing, and service engineering. Elgammal has an MSc in information systems from Cairo University. Contact her at a.f.s.a.elgammal@uvt.nl.

WIllem-Jan Van Den Deuvel is a full professor of computer science in Tilburg University’s Department of Information Systems and the managing director of the European Research Institute in Service Science. His research interests include cloud service engineering, service governance, performance analytics of software-enabled service networks, and business transaction management. Van den Heuvel has a PhD in computer science from Tilburg University. Contact him at w.j.a.m.vdnheuvel@uvt.nl.

Michael P. Pazazoglou is the chair of Tilburg University’s computer science department and the scientifi c director of the European Research Institute in Service Science and the EC’s Network of Excellence, S-Cube. His research interests include service-oriented computing, Web services, large-scale data sharing, business process management, and federated information systems and distributed computing. Papazoglou has a PhD in microcomputer systems engineering from the
University of Dundee. He’s a Golden Core member and a Distinguished Visitor of the IEEE Computer Society. Contact him at m.p.papazoglou@uvt.nl.

This article first appeared in IEEE Software magazine. IEEE Software's mission is to build the community of leading and future software practitioners. The magazine delivers reliable, useful, leading-edge software development information to keep engineers and managers abreast of rapid technology change.