Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
Showing results for 
Search instead for 
Did you mean: 
Active Contributor
0 Kudos

A caveat: I'm definitely not a Governance, Risk and Compliance (GRC) expert - so I am exploring largely uncharted waters- so please bear with me as I stumble around and shine my process-fixated flashlight on some GRC-related issues. I'm starting with a more technical-focused examination as my first foray but expect more theoretical discussions in later blogs.

Anyone who is involved in corporate IT or enterprise software has probably heard about GRC or were required to add GRC-related functionality to an offering  - regardless of whether it was a corporate service, application or process.  To be effective and achieve a degree of acceptability based on completeness, such efforts must - like strands of hungry ivy - touch most aspects of corporate life.

How does such integration work in practice in the daily life of someone involved in IT - in particular, how does GRC impact those involved in process improvement projects?  I'd like to focus on one very particular aspect of GRC-related activities - collecting data for continuous monitoring (CM) and auditing (CA), especially as they relate to compliance - and discuss such work as it impacts process design environments.

Some definitions

What is GRC?

I like the following definition from Norman Marks, because it emphasizes that GRC is much more than software:

GRC is about how you (a) identify the objectives, strategies, and goals of the organization, (b) optimize performance and achievement of those objectives, (c) with consideration and management of risks to achieving objectives, while (d) remaining in compliance with applicable laws and regulations. [SOURCE]

What is compliance?

Compliance is all about 'defining a policy', 'enforce the policy' and 'prove that the policy is implemented' and affects to some degree all publicly owned companies regardless of their industry or country of origin. There are a variety of compliance regulations including:

  • Sarbanes-Oxley Act: Known as SOX, this Act requires company financial executives to be culpable for financial reporting. Independent auditors review financial controls and processes to ensure accurate financial reporting. Controls of records and processes are preserved to prevent fraudulent activities.
  • SEC Rule 240.17a-4(f): The Securities and Exchange Commission rule -- which was passed in the wake of the Enron scandal and others -- requires public companies to store certain data and business records, including some e-mail, on non-erasable and non-rewritable media
  • Japan's Personal Information Protection Act: The Personal Information Protection Act. The Personal Information Protection Act applies to government or private entities that collect, handle, or use personal information of 5,000 or more individuals 
  • Gramm-Leach-Bliley Act: The Gramm-Leach-Bliley Act addresses the protection of nonpublic personal information, requiring that financial records are properly secured, safeguarded, and eventually disposed of in a manner that completely destroys the information.

Compliance auditing tools enable organizations to link compliance objectives to the IT infrastructure and provide monitoring, attestation, and reporting tools. They create a secure audit trail and present a unified view of an individual's activities based on company policies. Furthermore, they ensure that security-related changes are properly approved and that only authorized persons or systems have access to sensitive data.

These requirements require that data from various corporate applications must be stored and analyzed to assure that certain policies (either from internal or external entities) are being met. Thus, processes as such are also affected by such policies / regulations.  

Enter continuous monitoring (CM) and continuous auditing (CA)

To meet these data-collection and data-analysis requirements and to assess that they are working properly, two areas have crystallized in GRC-related circles: continuous monitoring (CM) and continuous auditing (CA).

Continuous monitoring is an automated feedback mechanism for management to ensure that the systems and controls have been operating as designed and transactions are processed appropriately. [SOURCE]


Continuous auditing consists of the automated collection of audit evidence and indicators by an internal or external auditor from an entity's IT systems, processes, transactions, and controls on a frequent or continuous basis. This information enhances auditor capabilities and helps to ensure compliance with policies, procedures, and regulations. [SOURCE]

Process-specific compliance monitoring options

Note: In this blog, we are just focusing on the data collection in processes for compliance monitoring purposes.  Other GRC-related requirements such as Separation of Duties (SoD) must also be reflected in processes.

Assumption: Since such GRC-policies are strategic, a centralized data pool is part of a more general GRC platform that collects information from a variety of sources in order to present a unified view of the compliance-related activities in an enterprise. I'll call the centralized data store for processes the "Process Monitoring Data Store".

Processes are the core of the enterprise IT landscape and, because of their ubiquitous character in enterprise life, produce an unbelievable amount of data that is relevant for compliance monitoring.  In order for these tools to work correctly, there must be information collected from all stages of the process-related lifecycle. The question is how best to achieve this data collection requirement for processes. I see the following options.

Option 1:  Add monitoring directly to the process design

In this option, the process designer is responsible to add compliance auditing manually to the process design. This effort might be easy as calling a web-service before and after each process step that sends the data to an monitoring repository.



  • This is a non-standard solution and is probably easier to configure to deal with personalized data or additional process-specific data
  • Can capture non-standard events (for example, certain types of exceptions).
  • If compliance policies / auditing requirements just apply to certain types of types of tasks, the process designer can selectively add auditing to the design. This ability is based on the assumption that the process designer knows what sorts of tasks require compliance monitoring.


  • Leads to more complicated process design models. The problems is similar to that seen in a Slipstream 2.0: Business Activity Management for SAP NetWeaver BPM, Part 2 where events must be manually added to the BPM process
  • Leads to great deal of effort in terms of governance between compliance checkers and process designers
  • Requires a great deal of effort to add monitoring to legacy processes. It would be necessary to change every process which would require an amazing amount of regression testing.

Option 2:  Add monitoring directly to the BPM engine

In this option, the BPM engine is directly connected to the monitoring environment or creates logs that are available to the CM platform.   


  • No impact on process design.
  • Legacy processes won't have to changed to add monitoring functionality.


  • Doesn't take into account the distinct compliance-requirements for specific types (finance, etc) of processes. "One size fits all" standardization is never very efficient.
  • Possible performance problems, because auditing is in every process

Option 3:  Add monitoring to the underlying business objects

In this option, the monitoring is added to the underlying business objects and transactions. Since many processes result in CHUD actions in business objects, these changes could then be tracked.


  • This option could be used to add monitoring to user interactions that don't take place via process environments - for example, direct access via the SAPGUI (for example, working in a transaction).
  • Probably the most compatible with SAP's existing GRC products (for example, SAP BusinessObjects Process Control).


  • Huge amount of data would be created
  • Difficult to deal with processes and process tasks that don't use business objects (approval, collaboration, etc)


GRC-related concerns are just one influence of which process designers must be aware.  Although the functional requirements of Business must play the most important in creating a process, other factors must not be forgotten.  Of the three options described above, I prefer Option 1, because it provides the process designer more flexibility to decide what role compliance must play in a process.  Ideally, tools could help the process designer deal with such issues at an early stage.  If we expand the definition of process governance to include such GRC-related topics then process governance tools might also assist process designers to meet these requirements.

Perhaps, the intelligent use of process design element attributes in combination with a BPM-engine that understands such attributes would eliminate many of the disadvantages of Options 1 and 2 and allow for an efficient monitoring of such processes.

Labels in this area