Compliance Tips for the Guilty
Using Culpability Scores to Reduce Risk
Lora Bently, who is responsible for the Sarbox Survival Guide
blog, uncovered a real gem this month. In her entry, "What
Do Sentencing Guidelines Have to Do with Compliance?"
she discusses a conversation that she had with the CEO Brett
Curran of Axentis,
a GRC ( Governance, Risk, and Compliance ) software manufacturer.
In a recent product announcement for Axentis, the company
referenced guidelines for compliance from the U.S.
Sentencing Commission. This is the agency responsible
for establishing Sentencing Guidelines for people found guilty
of certain federal crimes.
Compliance guidelines for the guilty? Doesn't it seem a little
late to be giving these people advice?
According to Mr. Curran, these guidelines are used to assess
a culpability score, and this score will determine
the sentence that's delivered.
This is great to know. Let's use these guidelines as requirements
for a new Compliance Data System.
First let's take a look at what they are:
- Define policies, procedures, and controls.
- Designate high-level people to manage the program day-to-day
- Communicate policies, procedures, standards, and training
to people periodically.
- Audit and monitor the program periodically.
- Periodically promote the program, and enforce it consistently
throughout the organization.
- Take action to prevent future problem occurrences.
- Periodically assess risks and modify controls and policies.
Okay, obviously for an article this size we'll need to make
some assumptions, and leave out some details, but I wanted
to give you the high level of how this is put together.
A Compliance Data System is built using audit intelligence
( a derivative of business intelligence ) techniques, and
I just published an eBook on the proper way to get started
called "A
Racehorse Without a Jockey". So consistent with that
book, we start off by building a charter, stakeholder assessment,
preamble, and elevator speech.
From this exercise, let's clarify exactly what we're trying
to do here. The Project Objective would read something like
this:
Develop a Compliance Data System that clearly demonstrates
that we are following all 7 of the suggested U.S. Sentencing
Guidelines that were promulgated in 1991 by the U.S. Sentencing
Commission. The system should be in place before the end
if this fiscal year.
The key point of clarification here, is that we are not
trying to fill gaps here. The assumption is that we are already
doing all of these things, and the goal of the new Compliance
Data System is to prove that we are doing
these things.
So, with that done let's revisit the requirements, because
I don't like some of the vague language. Here's some clarifications
we will make to move these requirements closer to "operational
definitions".
- For Number 2, let's call "high-level" anybody
in the organization that is a "Vice President",
or has one that reports to them.
- In general, the term "periodically" means every
month.
The next thing to understand, is that the Compliance Data
System looks and feels more like a data warehouse than a transactional
system. Therefore, we will have sources, transformations,
and the target will be our new Compliance Data System. We
will call it SBCS ( Sentencing Based Compliance
System ).
Next, let's take a look at our sources.
- For rule #1, let's assume that there are 7 business units,
and each one has their own web-based repository where policies,
procedures, and controls are stored.
- For rule # 2, the management assignment is done, but not
automated. It goes something like this, "Okay, Mary?
You're managing this now."
- For rule # 3, the communication effort is somewhat organized,
but also not automated.
- For rule #4, internal audit has a transactional system
called IASOR ( Internal Audit System of Record ) where it
records the results of its audits.
- For rule #5, this is managed through their learning system
TEACH, along with the rest of the corporate training classes.
- For rule #6, a system called REACT has been installed
to track risk events, and their resolution.
- For rule # 7, an organized review is done monthly, but
not automated.
To complete the architectural bridge from our existing source
systems, to our target system, we will need to add the following
components:
- A consolidation point for the 7 BU web repositories. We
will use an SOA architecture to pull information out of
each of the existing web repositories, and deposit data
( via web service ) into our collection point.
- A lightweight transactional system that ties into our
existing HR database, to tie up the loose ends from the
stuff that is not yet automated. It will formalize and record
who is managing the program. It will also manage the communication
plan, including who needs to be communicated to, what needs
to be communicated, how it gets communicated, and when the
communication happens. Finally, it will formalize the risk
assessment and control improvements. This system will be
called AuditLink.
The only step left is our transformation logic. Here are
the highlights:
- Since we have the consolidation point for the 7 business
units' policy repository already, the only thing we need
to do is push this over to the target. You can either store
the whole policy in SBCS ( the new data system ), or a link
to where it can be found.
- Since we are building AuditLink from scratch, we have
the advantage of knowing that it will be downstreamed by
SBCS. The transformations will consolidate who is managing
what, with appropriate titles.
- Communication events are transferred to SBCS as they happen
through AuditLink. SBCS consolidates the what, when, and
who.
- Data from IASOR is transferred directly to SBCS as audit
results are recorded there.
- The TEACH system is polled for select audit related classes,
and pushed down to the SBCS. Changes are monitored and recorded
as they happen.
- The entire REACT database is polled and incidents are
transferred to SBCS as they happen.
- Risk assessment and control enhancement is sent to SBCS
once the monthly audit is recorded in AuditLink.
- The SBCS is updated with this information on a daily basis,
and all the change history is stored. "Tiny steps"
are made so that there is a clear audit trail, and all evidence
is captured to support the transformation logic.
Once the Compliance Data System transformations are complete,
a set of batch reports are built to run against the new system.
These batch reports resolve the objective of clearly demonstrating
our compliance.
I hope this gives you a sense for the role of the Compliance
Data System, and how you go about making it happen. Using
our sentencing guidelines and this architecture greatly reduces
your chances that any sentencing happens at all.
|