the ibm risk and compliance framework: addressing · pdf filethe ibm risk and compliance...

The IBM Risk and Compliance Framework: addressing the challenges of compliance

A framework for successWhite paper

January 2005

IBM Risk and Compliance

The IBM Risk and Compliance Framework: Addressing the challenges of compliance

The IBM Risk and Compliance Framework: Addressing the challenges of compliancePage 3

Executive summary

Organizations face an alphabet soup of regulatory requirements — ranging from Sarbanes-Oxley (SOX), SEC 17a-4, Patriot Act, Basel II, and HIPAA, just to name a few — while being challenged to better manage the increasing volumes of data that need to be cost-effectively captured, stored and analyzed.

The IBM Risk and Compliance Framework is a tool that illustrates the infrastructure capabilities available to address the wide range of compliance requirements facing organizations today. It is designed to help provide flexibility when choosing technologies and the ability to protect and leverage existing investments. Using this framework, organizations can standardize on the use of common technologies to design and deploy a compliance architecture that can help them address their compliance initiatives more effectively.

This paper discusses the challenges that companies face during the planning and implementation of solutions which are used to address the requirements associated with compliance, and how IBM can help companies address those challenges. It is intended for use by business operations strategists, IT strategists and senior executives in risk management and board management who are responsible for planning and implementing the infrastructure used to support regulatory compliance.



Compliance landscape

What is compliance? Simply put, compliance is the process of adhering to a set of guidelines or rules established by government agencies, standards groups or internal corporate policies. Adhering to compliance-related requirements is a challenge because of:

• The frequent introduction of new regulations • Vaguely written regulations which require interpretation• No consensus on best practices used for compliance• Multiple regulations that overlap, potentially from different geographies, that may have different requirements• Constantly changing regulations • Regulatory agencies that generally will not approve, recommend or validate any information technology products or related services

Therefore, compliance becomes a continuous process, not a one-time project, and continues to drive business agendas as organizations are being held accountable for meeting the myriad of mandates specific to their vertical markets. Examples include Basel II for risk management in the banking industry; SEC 17a-4 for brokers/dealers in financial markets; and the Healthcare Insurance Portability and Accounting Act (HIPAA) for the healthcare industry.

In addition, organizations might also be required to address cross-industry legislation, such as Sarbanes-Oxley (SOX), and other internal control processes, such as ISO 9000 or Six Sigma. Simply stated, the breadth and complexity of these challenges has resulted in point solutions for many organizations over the past few years. The opportunity for organizations to approach compliance from a more strategic perspective could help them move beyond simply meeting individual compliance mandates to realizing tangible business benefits from their infrastructure investments as a whole.

The scope of compliance also permeates other aspects of an enterprise. Table 1 illustrates some issues an enterprise should consider as it attempts to establish its scope and approach to compliance.



Table 1: Scope of compliance

Area Consideration

Strategy • As a company develops its strategy, it must

determine which regulations are relevant.

• Compliance sustainability needs to be an integral

part of any compliance strategy.

Organization • The organizational structure must be established

to meet the specific requirements (or intent) of

each regulation (e.g., Sarbanes-Oxley

recommends the Chief Executive Officer and

President be two different people).

Processes • Key processes must be documented

and practiced.

• Audits or reviews must take place to ensure

documented processes are effectively being

used to address compliance/regulation

requirements.

Applications and data • Applications must be designed, implemented

and continuously tested to support the

requirements of each regulation.

• Data must be properly protected and handled

according to each regulation.

Technology • The necessary technology must be used to

address the requirements of each regulation

(e.g., correct type of media required for

SEC 17a-4).

Facilities • Facilities must be designed and available to

meet the needs of each regulation (i.e., some

regulations may require records to be readily

available at an off-site location).

Compliance architectures

In the past, point applications have been a common approach for addressing near-term, tactical responses to legislation. Over time, this approach has proven to be limited, as regulatory requirements become more numerous and increasingly complex. As data volumes continue to grow exponentially, combined with the need to address these broad and deep compliance requirements, organizations may want to consider architectures that can not only deliver specific capabilities today, but be flexible enough to address the requirements they may face tomorrow.



These issues also provide an opportunity for organizations to examine their current infrastructures and business capabilities. They can use this opportunity to build an IT infrastructure that supports both business-driven requirements while capturing the information that may be needed to support regulatory reviews. As a result, they can create an IT infrastructure that not only supports compliance-driven requirements but helps make their business more agile and responsive.

The creation of an architecture by standardizing on the use of compliance-driven capabilities and supporting technologies across an enterprise can provide a company with these potential benefits:

• Reduced total cost of ownership: Investments can be leveraged across multiple regulations. For example, many regulations specify document retention requirements, which can be met by a single investment in a content and records management system.• Flexibility: One of the difficulties with compliance is that new regulations are introduced and existing regulations are changed on a frequent basis. By centrally managing compliance initiatives via an enterprise-wide compliance architecture, companies can quickly adapt to these changes.• Competitive advantage: A compliance architecture can allow a company to better understand and control their business processes, which allows them to respond more quickly and accurately to external or internal pressures. Furthermore, certain regulations, such as the Basel II Accord, contain tangible business benefits through reduced minimum capital requirements, which could be enabled by an enterprise-wide compliance architecture.

IBM offers products, solutions and services designed to help companies adopt best-practices, transform their business operations and gain deeper insight and predictability from their business information as they address regulatory-driven requirements. Key business drivers for investment include the ability to better manage information assets, demonstrate compliance with regulatory and legal obligations, reduce the risk of litigation, reduce cost of storage and discovery and demonstrate corporate accountability.



IBM’s breadth of offerings offers a broad approach to the management of risk and compliance challenges.

The IBM Risk and Compliance Framework (see Figure 1) is a tool and set of organizing principles, which can be used to help companies affected by multiple regulations manage their business and technology investments. It describes a unifying framework that encompasses risk and compliance technologies and services and can be used to help support the creation of a compliance architecture.

Figure 1: The IBM Risk and Compliance Framework



This framework is designed to help:

• Provide a holistic view of the elements essential for compliance• Describe the major components or candidate building blocks of an end-to-end solution• Consider multiple regulations across industries and geographies• Provide a common language (or set of semantics) to facilitate collaboration • Provide the basis for:

• Identifying the scope of a project• Defining a roadmap for building a total solution• Identifying elements, which, if not considered, may increase project risk• Assessing current infrastructure, tools and technologies to identify gaps

• Provide clients with acceleration of time to value

The framework was created by analyzing several regulations and standards to determine which components could be used to help address common requirements. The rationale for adding a component to the framework was if it provided capabilities to help meet functional requirements, either explicitly mentioned in or implied by a regulation, or was supportive of best practices.

The framework does not prescribe technology choices or business processes. It also does not include all of the elements required for an end-to-end I/T system since some components (contained within infrastructure and LoB systems) are dependent on the mechanism (technology versus manual process) chosen by a company (e.g., database, application server, and data warehouse).

This framework does not suggest where the functionality described by each component should reside within an IT architecture. Combinations of these components may be provided by a single product or solution. For example, the capture, indexing, retention and records management components might all be provided by a single content management application.

In general, the framework provides a set of focus areas that should be considered when creating solutions to help address compliance. The components are grouped into three areas:

• Business components (see Table 2)• Information management components (see Table 3)• Cross-regulation components (see Table 4)



Table 2: Business components

Component

Business

performance

management

Business process

management

Risk

management

Compliance

monitoring

Reporting

Analytics

Description

Provides a mechanism to help

optimize business perfor-

mance via key performance

indicators that help monitor

efficiency against operational

targets

Enables the management,

documentation and enforce-

ment of business processes

Provides a mechanism to

define, assess and develop

strategies to manage risk

A mechanism used to define,

manage and visualize (e.g.,

dashboard) events or condi-

tions related to a regulation

The generation of reports that

can be created on either an

ad-hoc or scheduled basis,

and can be statistical, or

informational in nature

Functions that provide the

sorting and manipulation of

information, such as:

• Statistical analysis

• Online analytical processing

• Text analysis (e.g., Natural

Language Processing

engines)

Example

• Using business intelligence

combined with business

performance management

solutions to gain increased

ROI related to SOX compliance

• Establishing and evaluating

an internal control structure

(SOX)

• Management of operational

risk (Basel II)

• Required process area at

Level 3 of the Capability Matu-

rity Model Integrated (CMMI)

• Amount of time elapsed for

a re-credit to a consumer

(Check 21)

• Ensuring the latest security

patches are on machines

(HIPAA)

• Volumes of messages super-

vised versus total volume of

messages (NASD 3010)

• Financial reporting and dis-

closure of material events

(SOX, Basel II)

• Early warning reporting

(TREAD)

• Algorithms used to calculate

the minimum capital require-

ments of banks (Basel II)

• Algorithms used to select

messages for supervision

(NASD 3010)

• Data mining to detect

statistical patterns, predict

behavior (e.g., probability of

default for Basel II), and

identify anomalies in the

data (Anti-money laundering

portion of the USA Patriot Act)



Collaboration &

workflow

Training

A collaborative environment

for the creation and manage-

ment of information. This

environment should also have

a mechanism to define the pro-

cess, roles and execution of a

set of ordered activities associ-

ated with a particular task.

Provides the delivery of educa-

tional material to users and the

tracking of their progress

• Document management

environment for the creation

of investment research

reports (NASD 2711)

• The creation of SEC filing

documents (SOX)

• Corporate responsibility for

financial reports (SOX 302)

• Qualification exam

(NASD 2711)

• Security awareness and

training (HIPAA)

Table 3: Information management components

Component

Capture

Indexing

Retention

management

Description

Provides the mechanism to

capture specific types of con-

tent into a repository, such as:

• E-mail messages

• Instant messages

• Faxes

• Documents

• Voice

• Images (e.g., checks and

forms)

Provides the ability to evaluate

entities, and create and

manage indexing terms that

aid in finding and accessing

the entity

A mechanism to manage and

enforce simple retention poli-

cies associated with data

Example

• Automated message capture

of all e-mail and instant

messages (NASD 3010)

• Requirement to organize and

index information

(SEC 17a-4)

• Correspondence must be

retained for three years

(SEC 17a-4)



Data

authentication

Archival

Information

integrity

Information

integration

Records

management

Data privacy

Content

management

Provides the ability to ensure

that the given information

was in fact produced by the

entity whose name it carries

and/or that it was not forged

or modified. This is used for

accountability and non-repudi-

ation. Examples include digital

signatures.

Provides a mechanism to man-

age archival of data due to cost

or for disaster recovery. This

may also include the creation

of duplicate copies of the data

A mechanism used to assess

and verify the quality of the data

The ability to provide a con-

solidated view of multiple

disparate data sources

The creation and implementa-

tion of systematic controls

for information from the point

where it is created or received

through the end of its life cycle

A mechanism used to define

and manage the proper use

of sensitive data (i.e., manage-

ment of personal and financial

information)

A mechanism to help manage

(including version control)

and distribute content from

diverse sources (i.e., a content

repository)

• Corporate responsibility for

financial reports (SOX 302)

• Ability to discern invalid or

altered records (21 CFR 11)

• Duplicate copies of records

and indexes must be created

and stored separate from the

originals (SEC 17a-4)

• Assessment of the quality of

scanned images (Check 21)

• Verification of the data record-

ing process (SEC 17a-4)

• Consolidation of several

years of data for risk

calculations (Basel II)

• Securities broker/dealers

must maintain all records

under 17a-3 (a)(13) until

three years after termination

of employment (SEC 17a-4)

• Records related to a new

drug application must be

retained for five years past

the date of submission (FDA

Good Laboratory Practices)

• Obligations with respect to

disclosure of personal

information (GLBA)

• System used to manage

and maintain check images

(Check 21)

• Repository for investment

research reports (NASD 2711)



Search &

retrieve

Cleaning &

processing

Provides access to data

through a search and retrieve

capability. Also includes

specific requirements for spe-

cialized applications such as

litigation support.

A mechanism to clean and

process data. Also includes

the notion of ETL (i.e., extract,

transform and load).

• Every broker/dealer is

required to immediately

produce records pursuant to

17a-3 (SEC 17a-4)

• De-duplication of e-mail

messages sent to multiple

recipients within the same

enterprise (NASD 3010)

• The cleaning and processing

of financial data prior to load-

ing it into a data warehouse

for risk calculations (Basel II)

Table 4: Cross-regulation components

Component

Line of business

systems

Security

Identity

management

Access control

Description

The general term used to

describe a set of business

applications including ERP,

CRM, Supply Chain, etc. These

applications are required to

get a complete picture of an

enterprise.

Security applies to all elements

of this framework. It not only

covers access to applications

and data, but also business-

rule and role-based views

of data. It is composed of

technology, process, and orga-

nizational components.

A set of components that deal

with identifying and managing

individuals in a system and

enabling administrative tasks

(e.g., password management)

A mechanism to define and

enforce the restrictions or

rights of each individual or

application. This includes roles

based access control.

• ERP systems which help

manage complex manufac-

turing environments to

maintain FDA compliance

• LDAP directory server used

to manage the identify of

employees

• Ensuring patient records are

accessible only to authorized

health care providers (HIPAA)



Common components

Since there are so many regulations and standards in use today, the IBM framework uses a taxonomy, or classification system, to group similar regulations together (see Table 5). For example, while records retention requirements vary across regulations, the issues they fundamentally address can be grouped together into a classification of information lifecycle management.

Authentication

Encryption

Audit control

Infrastructure

Resilience

Authentication is the process

by which an entity attempts to

confirm that another entity is

who it claims it is.

The use of an algorithmic

process to transform data

into a form in which there is

a low probability of assign-

ing meaning without use of

a confidential process or key.

In this framework, it includes

encryption of data and or com-

munications.

A mechanism to manage the

audit information contained

within an end to end system

Infrastructure primarily covers

hardware, platform software,

and network connectivity as

well as all systems manage-

ment related components. It is

included in this framework for

completeness.

The capability of an enterprise

to adapt rapidly and respond to

any internal or external adverse,

fast changing or unexpected

condition and to continue

business operations without

significant disruption

• LDAP directory server used

to authenticate employees

• Ability to ensure confidential-

ity (21 CFR 11)

• Exemption for encrypted data

(SB 1386)

• Every broker/dealer must

have in place an audit system

providing accountability for

inputting of records, and it

must have this system

available for examination

(SEC 17a-4).

• Each piece of information

and index must be duplicated

and stored separately from

the original (SEC 17a-4).

• Contingency plans (HIPAA)



Table 5: Regulatory taxonomy

Classification

Corporate governance

Business improvement

Business resilience

Transaction integrity

Information protection

Information lifecycle

management

Concepts contained within

• Financial reporting

• Transparency

• Business controls

• Accountability

• Corporate and

accounting fraud

• Disclosure

• Financial transactions

• Material events

• Safety information

and recalls

• Risk mitigation

• Regulatory capital

requirements

• Engineering models

• Disaster recovery

• Availability

• Anti-money laundering

• Anti-terrorism

• Broker surveillance

• Electronic signatures

• Security

• Privacy

• Information management

standards

• Retention requirements

• Recordkeeping standards

Examples

1. SOX

2. SEC Act of 1933, 1934

3. TREAD

4. IAS

1. Basel II

2. CMMI

3. ISO 9000

1. NFPA 1600

2. Check 21

1. NASD 3010/3110

2. NASD 2711

3. NYSE 472

4. 21 CFR 11

5. Patriot Act

1. HIPAA

2. GLBA

3. SB 1386

4. EU Data Privacy

5. FOIA

6. ISO 17799

7. NERC 1200 UAS

1. OMB A-130

2. SOX

3. SEC 17a-4

4. DOD 5015.2

5. PRO 2

6. MoREQ

7. VERS

8. DOMEA

9. NOARK



Each component identified may also be associated with one or more classifications. Table 6 denotes which components can be used for multiple regulation types and indicates if the component provides functionality that would be of primary or secondary concern within a specific classification.

Table 6: Component mapping to regulatory classifications

Risk and compliance on demand

Today’s competitive business environment mandates that organizations unite employees, partners and suppliers with the systems and information that enable them to do business more effectively. New technology, coupled with broad adoption of open standards, has made a breakthrough possible—one that allows organizations to do business in ways that had not been thought of even a few years ago. This breakthrough is what IBM describes as On Demand Business. Similarly, today’s complex regulatory environment challenges organizations to address risk and compliance effectively and efficiently.



An On Demand Business is an enterprise whose business processes— integrated end to end across the company and with key partners, suppliers and clients—

can respond with speed to any client demand, market opportunity or external threat. From a risk and compliance perspective, an On Demand Business is an enterprise whose risk and compliance initiatives are integrated across the enterprise, allowing them to respond rapidly to requests from regulators as well as to an emerging and changing regulatory environment.

The IT infrastructure needed to support an On Demand Business is known as an On Demand Operating Environment. The Risk and Compliance Framework helps in the creation of this environment ensuring the correct services required to address regulatory challenges are considered. This framework allows for the evaluation of IT needs and existing technology to determine how to deliver the underlying infrastructure to support a resilient, responsive, focused and variable business that can address regulatory challenges, now, and in the future.

Using the IBM Risk and Compliance Framework

The IBM Risk and Compliance Framework is designed to help a company move across the compliance maturity continuum (see Figure 2). In this continuum, a company can start by using manual processes or deploying tactical, point-solutions to comply with a regulation by a certain deadline to avoid penalties. In many cases, companies start at this phase since they must first understand what compliance means in their environment. This approach enables organizations to first understand what needs to be done, then what can be optimized or automated. The improve phase is characterized by the deployment of applications and infrastructure to replace manual processes to better support compliance sustainability. In the transform phase, companies can begin to leverage their investments in compliance to derive a competitive advantage by unlocking the value of the information captured.



This framework can be used in several ways:

• As a tool to help clients organize their thoughts and evaluate what may be desirable enhancements for their compliance environment.• As a tool that allows clients to assess or evaluate their current I/T infrastructure.• As a tool to see which offerings are available from IBM and IBM Business Partners to help address compliance issues.• As input to specific control objectives contained in other frameworks, such as CobiT. For example, in the CobiT Planning and Organization domain, one control objective discusses the need to define the information architecture. If a company has decided to use CobiT as their framework for I/T governance, they can use the IBM Risk and Compliance framework to provide guidance during the definition of their controls.

Figure 2: Compliance maturity continuum



The key objectives in using this framework in a gap assessment would be to

• Evaluate the impact of multiple regulations.• Utilize existing infrastructure.• Identify how to leverage investments for business improvement.• Develop overall roadmap.

Example: Using the framework in a gap analysis

This section shows the steps involved in using this framework in a gap assessment, where the key objectives would be as listed below.

Establish the scope

1. Client, working with their counsel and audit resources, identifies the regulations, practices, and/or codes applicable to the corporation, geography and/or business unit.2. Client identifies regulatory timeline and existing initiatives.3. Clients may choose to include internal policies that go above and beyond requirements from external regulators (e.g., interest groups).

Determine the requirements

1. Client, working with their counsel and audit resources, identifies the requirements related to regulations, practices, and/or codes applicable to the corporation, geography and/or business unit.2. Clients may choose to include additional requirements related to internal policies that go above and beyond requirements from external regulators.



Perform as-is analysis

1. Map existing infrastructure to R&C capabilities: a. Identify all applications and processes to address capabilities. b. Consider core and supplemental applications to develop a complete inventory.2. Map existing requirements to applications: a. Align requirements to applications. b. Highlight areas where multiple applications serve similar requirements or if there are no applications available.

Perform to-be analysis

1. Review and update requirements: a. Consolidate requirements. b. Update based on emerging regulations.2. Conduct envisioning sessions: a. Present best practice templates for business practice. b. Discuss envisioned processes.

Perform the gap analysis

1. Identify issues and opportunities: a. Identify issues related to legacy technologies. b. Identify opportunities to leverage existing infrastructure and/or new products or solutions.2. Identify solutions alternatives: a. Evaluate existing infrastructure. b. Identify potential products and solutions. c. Estimate effort and benefits.



Develop a road map

1. Evaluate alternatives: a. Develop evaluation matrix. b. Perform evaluation and feedback sessions.2. Develop business case: a. Develop business benefits case. b. Develop recommendation.3. Develop/confirm workplans, budget and roadmap: a. Prioritize deployments. b. Develop strategic roadmap. c. Develop near-term workplan and budget worksheet. d. Confirm findings and recommendations with advisory/legal function. e. Develop final report.

For more information

For more information, contact your IBM representative or IBM Business Partner, or visit the IBM Risk and Compliance page at ibm.com/software/info/

openenvironment/rcf

G507-1471-00

© Copyright IBM Corporation 2005

IBM CorporationIBM Risk and Compliance CouncilRoute 100Somers, NY 10589U.S.A.

Printed in the United States of America01-05All Rights Reserved

IBM and the IBM logo are trademarks of the Inter-national Business Machines Corporation in the United States, other countries or both.

Other company, product and service names may be trademarks or service marks of others.

References in this publication to IBM products or services do not imply that IBM intends to make them available in all countries in which IBM operates.

Clients are responsible for ensuring their own compliance with relevant laws and regulations.

It is the client’s sole responsibility to obtain advice of competent legal counsel as to the identification and interpretation of any relevant laws, including but not limited to, the Sarbanes-Oxley Act, that may affect the client’s business and any actions client may need to take to comply with such laws.

IBM does not provide legal, accounting or audit advice or represent or warrant that its services or products will ensure that the client is in compliance with any law. The information contained in this doc-ument is provided "as is" without warranty of any kind, express or implied. IBM shall not be respon-sible for any damages arising out of the use of, or otherwise related to, this document. Nothing con-tained in this document or other documentation is intended to, nor shall have the effect of, creating any warranties or representations from IBM (or its suppliers or licensors), or altering the terms and conditions of applicable agreements governing the use of IBM hardware, software or services. IBM clients are responsible for ensuring their own compliance with legal requirements.

Printed in the United States on recycled paper containing 10% recovered post-consumer fiber.