1 Overview

The following big picture gives an overview of how people, processes and technology interact in an enterprise. It shows a very mature stage of the enterprise; IBM calls it on demand. In this context we call it the transform stage. The red parts in the figure only occur in this transform stage.

There are five layers. We first describe them briefly, and later look at them one by one.

· On top, the jurisdiction layer shows where regulations come from that an enterprise may have to comply with, and what influence enterprises may have to ease their compliance tasks.

· The strategy layer means the business strategy of the enterprise. We look specifically at how regulations should be treated here and how risk comes in.

· The deployment layer is about how the business strategy gets transformed into something actionable. From the IT perspective one would call it the modeling, development, and deployment layer, but it also contains non-IT deployments.

· The operation layer contains the day-to-day business of the enterprise. In IT terms, it contains the runtime systems, but it also contains the employees and how they can be aided in keeping the enterprise in compliance with the relevant regulations.

· The events layer contains real-time event collections and reactions on them. It could logically be considered part of the operation layer, but it contains so many new aspects for an enterprise that we treat it as a separate layer.

2 The Jurisdiction Layer

Let us first look at the jurisdiction layer:

The most important parts are the two light-blue process boxes. The upper box contains laws and regulations, i.e., actual legal documents put into force by legislative bodies. The lower box contains refinements of laws and regulations that may not be binding, but that sometimes play a larger role for enterprise deployment than the laws and regulations themselves because those are not concrete enough for deployment. Such refinements are typically made either by standards organizations for many enterprises together, or by the enterprise’s external auditors or legal council for a specific enterprise.

The notion of laws versus regulations, where governments make laws and regulators make regulations, is of no large importance for us. However, most countries do have such a multi-layer approach to legislation; the exact names correspond to the USA. Laws are typically quite generic, and then lower-level bodies, e.g., in the USA the Federal Trade Commission (FTC) and the Securities and Exchange Commission (SEC) work out more detailed requirements. In particular where IT is concerned, one tries to be technology-neutral in laws. Regulations start to address technology, but details may still be hidden in terms like “appropriate”, “reasonable”, and “state-of-the-art”. Such terms are then refined even further by industry best practices.

Currently there is almost no technology on the jurisdiction layer. However, in the long run (i.e., in our transform stage) it will be beneficial to start the formalization of policies right on this layer, to have the smallest possible semantic gap. In particular, instead of individual enterprises trying to derive actionable policies from regulations or best practices one by one, standards organizations can aid by producing such policies for the industry as a whole, to the benefit of all. The results of such formalizations are taxonomies and regulation models over those taxonomies, i.e., actual rules of what should or shouldn’t be done in the given terms. It the taxonomies of different regulations and standards can be unified at least to some extent, then regulation models can be combined. For instance, one can then join the privacy laws or the retention requirements of several countries into one model for a multi-national enterprise.

It may sound futuristic that regulators themselves would produce formalized taxonomies or even regulation models, but it may not be so far off, e.g., if one considers the advent of the Extensible Business Reporting Language (XBRL) as a reporting language with unified taxonomy and its recognition by the SEC.

3 The Strategy Layer

Next we discuss the strategy layer in detail.

This is the layer where leaders of the enterprise set directions for the enterprise, abbreviated as a business policy, and define internal processes for bringing their strategies into real life. As we concentrate on risk and compliance, we mention in particular a possible Chief Risk Officer (CRO) and a Chief Compliance Officer (CCO). At least for the Sarbanes-Oxley Act, the Chief Executive Officer (CEO) and the Chief Financial Officer (CFO) are also personally responsible, and in general a risk and compliance strategy should have support from these roles in order to be successful. Internal auditors also play a large role.

The picture, for lack of space for more arrows in the 5-layer version, does not show that there will be specific risk and compliance policy parts in the overall business policies, as well as specific internal processes that ensure risk and compliance.

· Compliance policies at this level may just be the identification of the regulations that apply to the given enterprise or to specific lines of business or geographies within it. Or they may be the choice of a standardized best practice to follow. Where there is no such best practice, the enterprise itself must make similar refinements of a regulation as we discussed under best practices above, i.e., it defines its own real practice. This policy may also go somewhat further than a best practice, taking some of the specific processes and roles of this enterprise into account, as far as they are known on the strategy layer. For instance, within a given enterprise it is easier to state what “need to know” means than in general.

· Risk policies may be general thoughts about the risk appetite of the company, in particular for issues where the financial value is not easily derivable from hard data at present, e.g., the loss of brand value in case of non-compliance with certain laws or publicized security incidents.

· Risk and compliance processes are initially about how the enterprise sets about implementing better practices, i.e., typically a project-style process such as “the Sarbanes-Oxley project”. There are some standards in this space, such as the COSO control framework and enterprise risk management framework, or, when starting to consider IT, the COBIT control framework or the ITIL governance processes. In the transform stage shown here parts of such frameworks will already be coded on the lower layers and have become a policy-driven, natural part of the business.

4 The Deployment Layer

On the deployment layer, strategies get put into practice, i.e., it is about transitions and change and documentation of what is being done. For IT (or technology in general), this layer covers enterprise modeling, application and infrastructure development, and application and infrastructure deployment.

The picture shows that the major issue is to model business processes and rules. The light blue boxes show that the processes may exist even without formal models, but in the transform stage we assume that models already exist, and that modeling tools are used to represent them. In IBM, such a tool may be the WebSphere Business Modeler. While most enterprises did not have real business process models until recently, the Sarbanes-Oxley Act forced them to at least model their financial processes (although a simple graphic is a sufficient model), and we believe that many other laws that aim at accountability for actions and their consequences will carry this beyond financial processes.

We stress that rules or policies that are derived from regulations or from strategic business policies (as the incoming red arrows show) should remain separate entities in the models, even where business processes are changed to accommodate them. This is important because the business processes may be changed again for many other reasons, and each new version has to be checked for policy compliance. Hence the policies should be expressed in the modeling tools, but as separate constraints. A long-term goal is automatic compliance checking.

For regulations, the best case is if they were already modeled on the jurisdiction layer. Otherwise the formalization has to take place on the deployment layer. If there are business process models in the enterprise that predate the current compliance issues, a terminology mapping will usually be necessary between the existing business process vocabulary of the enterprise and the vocabulary of the regulations or standards.

The deployment layer is also the first layer where one can make real risk models, in particular for operational risk. This means to associate potential adverse events with elements of the business process, and possibly to assign probability distributions to them and to compute their effect over the business process model. Then the business processes may be optimized for risk as one of several optimization criteria, weighted according to the risk strategy.

The first abstract business process models are typically refined into more concrete, deployable models. This may include programming those parts of the processes that are done automatically, designing user interfaces for the borders between automatic parts and human parts, and providing guidance for the humans who execute the human parts. In automatic parts, the risk and compliance policies should as far as possible be automatically followed, but remain policy-based as far as possible for later changes. For the human parts, one should try to integrate risk and compliance policies right with the task explanations. There may also be specific learning material that humans in certain roles need to go through as separate processes.

5 The Operation Layer

The operation layer is about the actual execution of the business processes.

Given the business process models and rules from the deployment layer, one wants to ensure that the actual execution follows the processes and adheres to the rules. This is shown by the two incoming black arrows from the deployment tool of the higher layer to the business process execution and to policy provisioning. In real life, however, for a long time the arrow to the business process execution will still be the other way round, i.e., the enterprise has existing processes and the model is derived from them, typically informally.

Furthermore, currently humans play a large role in many business processes and some of them necessarily have considerable freedom in their business decisions. One cannot assume that the risk and compliance guidance for them is perfect, nor that they all honestly and carefully adhere to it.

This already motivates why there are monitoring and reporting components on this layer and special roles such as internal auditors and risk analysts, and not only on the deployment layer. More uses for these components become clear with the events layer.

For technical implementations, the policy provisioning part is of particular importance. This is where risk and compliance plays a specific role in deployments. For instance, rules about who is authorized to do what may be translated into access control policies. Privacy rules may also be translated into access control policies, but also into encryption rules or data labeling rules. Retention rules for business data may be translated into concrete storage settings. Accountability rules may be translated into logging, but also into digital signature rules. Some of this will initially need human knowledge and later at least detailed IT models and trust models on the deployment layer.

6 The Events Layer

The events layer contains components for dealing with real-time events.

One type of events originates in the operation layer of the enterprise, as the many downward arrows on the right show. The assumption here is that all applications and middleware get equipped as event emitters for a common event bus because the rules that may work on events may be so global that one cannot provision them all to the individual components.

The second type of events is external. While some of these may come in the same nicely structured way as internal events, only from other enterprises, some may be much more vaguely defined and need specific, sometimes human, monitoring, e.g., political developments or certain market shifts.

Sensors are specific components whose primary goal it is to notice events, in particular physical problems with temperature, humidity, fire, power etc., but also sensors for digital network problems, or for human burglars.

Correlation engines and analytics engines are the components that evaluate events. We speak of correlation for real-time analysis, typically relatively simple and fast operations on an event stream. Analytics denotes more complex operations that are typically somewhat offline. Both may use historical data; analytics almost always will. Furthermore, not drawn here, at least analytics will often use the models from the deployment layer to give more semantics to the raw events. Furthermore, at least correlation will usually need rules, also derived from the deployment layer, to know what to look for – typically deviations from policies that couldn’t be perfectly enforced.

The results of all these components are brought back into the operations layer, at least where something is not as it should be. At the beginning, this will mostly be into a visualization tool, so that humans can react on the events. Later, or where well-known expected events are considered part of this layer and not of the business processes, the events may be fed back directly into a business or IT process.

7 Outlook

Our Risk and Compliance Big Picture complements IBM’s Risk and Compliance Framework. While the framework concentrates on the different capabilities of an enterprise required by different regulations (such as data retention, resiliency, etc.) and what IBM products and services offer these capabilities, we concentrate on how things hang together in a rather capability-neutral way.

More detailed research results on topics covered here can be found at the REALM project page.