The primary objective of the Process Pack for IT GRC is to help you implement IT GRC control and risk management in your organization. Compliance is the final step in the governance, risk management, and compliance (GRC) process. GRC helps organizations to identify risks, mitigate those risks, and verify that the risks continue being mitigated over time. Centralization of auditing systems helps to manage GRC efforts. Centralization of auditing systems also improves the efficiency of compliance auditing. These techniques will help lower auditing costs and minimize disruption to daily operations.
Governance in the GRC Process
Governance consists of the actions taken to address the risks identified during the risk assessment. Governance occurs when both automated and manual policies, methods, tasks, practices, systems, and training are put into place to mitigate identified risks. To enact governance, organizations design controls that include control objectives and activities.
The following activities are examples of how to apply governance to protect sensitive data:
- Create policies that describe proper handling
of sensitive data.
- Train employees on data handling
policies.
- Apply policies to systems that store
sensitive data.
- Monitor and log handling of sensitive data to
ensure that policies are followed.
Risk Management in the GRC Process
Risk management is a program to mitigate or remove risks. It starts with an assessment of each area of an organization to determine where risks may exist. Each department, such as security, operations, sales, and development, can perform its own risk assessments. To begin with, organizations should work with a compliance auditor to perform a risk assessment of their organization. After risks are identified, they should be prioritized, and an action plan should be put into place that is based on those priorities.
A risk action plan should consider techniques to manage risk that fall into one or more of the following categories:
Technique |
Description |
Avoidance |
This technique eliminates the risk by withdrawing from or not becoming involved with the action that would incur the risk. |
Reduction |
This technique mitigates or optimizes the risk through preemptive actions. |
Sharing |
This technique shares the risk with other entities by transferring the risk, outsourcing the risk, or insuring against the risk. |
Retention |
This technique accepts the risk and provides appropriated budget for resolving the risk. |
The risk management plan should prioritize each risk and then determine how each risk will be addressed: Should the risk be ignored, mitigated, or avoided?
Organizations are often concerned with risks that may be addressed through aspects of information technology management, including data input, data output and data access management. The following types of risks often concern business organizations:
- Compliance risks. Risks that the
organization may incur by not adhering to appropriate statues and
regulations.
- Operational or transaction risks.
Risks that the organization may incur that are associated with the
delivery of products and services.
- Litigation risks. Risks associated
with real or threatened litigation.
- Reputation risks. Risks associated
with financial loss as a result of damage to an organization’s
reputation.
The following are examples of how to address the risk involved with storing credit card information for each of the risk plan techniques:
- Avoidance. Don’t collect credit card
information.
- Reduction. Mitigate the risk by
improving protection of credit card information.
- Sharing. Outsource part of the risk by
obtaining a qualified vendor to handle the credit card
information.
- Retention. Ignore the risk and do not
improve protection of credit card data. Instead, choose to accept
losses if the credit card information is compromised.
Compliance in the GRC Process
Compliance is the validation that identified risks are being mitigated (lowered or lessened) through operational tasks that are also called controls. The following are examples of how risk mitigation can be validated:
- For each identified risk, is there a policy
in place for avoiding or mitigating the risk?
- Have the appropriate people been informed of
the policies?
- Have the policies been deployed via
processes, software, or IT controls?
- Are policies being monitored to ensure
compliance, and when breaches in policy occur are they quickly
remediated?
For true compliance, each step must be verifiable by an auditor. Such verification is often achieved through audit reports, event logs, video tapes, and version history.
The following are examples of how to verify compliance:
- Show that policies have been developed to
address identified risks.
- Show that policies have been deployed where
appropriate.
- Prove that policies have been in place and
followed during the enforcement period.
Process Pack for IT GRC Terms and Concepts
For this evaluation guide you will implement an IT GRC management program (or compliance program) for a fictitious company, Contoso. To obtain the full benefit of the evaluation guide, familiarize yourself with the following terminology and taxonomy:
- Compliance program. Within GRC, a
logical grouping of managed entities, IT controls, risks, and
policies created to manage compliance efforts for a particular
authority document. IT GRC programs:
- Define a collection of risks, control
objectives, control activities, and compliance results. These
collections allow the IT GRC program manager to manage the risks
and controls specifically for a program.
- Define user roles and rights by establishing
user permissions in the program. This approach allows delegation of
tasks based on user roles within the program, and prohibits
unauthorized review of control status within the program.
- Are used to manage compliance efforts for a
particular scope. Program scope is the managed resources defined
within a program (for example, servers, clients, services, and
administrators.)
- Define a collection of risks, control
objectives, control activities, and compliance results. These
collections allow the IT GRC program manager to manage the risks
and controls specifically for a program.
- Internal control. An accounting or
system procedure designed to promote efficiency, or assure the
implementation of a policy, or safeguard assets or avoid fraud and
error.
- Authority document. The primary source
of requirements, including regulations, standards, and policies;
these documents are referenced within GRC. Authority documents are
often produced by government regulating bodies, industry groups
that create guidelines that meet regulating body expectations, and
industry groups that create guidelines and standards in an effort
to self-regulate companies that operate within the industry.
GRC authority documents contain expectations as written by an authority, such as a government entity, a standards body, or an organization’s written policy. A GRC authority document may contain risk mitigation requirements that stipulate specific or generalized configuration, operation, or other service parameters that apply to an organization, its personnel, its business processes, and its technologies.
Many types of authority documents exist, including the following examples:
- Sarbanes Oxley Act of 2002 (SOX). SOX
is a law that requires enhanced corporate responsibility and
disclosures; it is enforced by the Security and Exchange Commission
(SEC) and related bodies. The SEC enforces laws that regulate
investor information with regard to securities information for
publicly traded companies. Laws such as the Securities Act of 1933
require publicly traded companies to produce and distribute
financial statements. Financial statements are produced in
accordance with industry standards, including Generally Accepted
Accounting Principles (GAAP).
- Payment Card Industry (PCI). Created
by the Payment Card Industry Security Standards Council to enhance
and regulate payment card data security. Payment cards are issued
by companies such as Visa and MasterCard. PCI is an industry
self-regulating standard by which organizations that process credit
card transactions must adhere to internal control frameworks and
specifications to ensure safe handling of cardholder
information.
- Health Insurance Portability and
Accountability Act (HIPAA). A law enacted by Congress in 1996
that protects workers health insurance coverage. This law also
establishes national standards for electronic transactions
processed by healthcare providers (including doctors and
hospitals), insurance plans, and employers. The standards address
the security and privacy of health data.
- Sarbanes Oxley Act of 2002 (SOX). SOX
is a law that requires enhanced corporate responsibility and
disclosures; it is enforced by the Security and Exchange Commission
(SEC) and related bodies. The SEC enforces laws that regulate
investor information with regard to securities information for
publicly traded companies. Laws such as the Securities Act of 1933
require publicly traded companies to produce and distribute
financial statements. Financial statements are produced in
accordance with industry standards, including Generally Accepted
Accounting Principles (GAAP).
- Framework. Within a program, a
framework is a way of classifying, grouping, and displaying
controls.
- Risk. A specific, unrealized, but
potential harm that could adversely affect an organization’s
business objectives. As a result of risk, an organization might
incur costs or might fail to attain a potential benefit. Risk is
measured in terms of impact and probability. Risks may be
associated with control objectives, control activities, or other
risks.
- Control objective. A description of
the specific results that should be achieved to manage risks
identified through the risk assessment. An objective is a
description of the desired state. The control objective can be
identified as a harmonized statement of authority document
requirements that must be achieved.
- Control activity. A task performed
with the clear intention of satisfying a desired control objective.
It often takes the form of prescriptive guidance that details the
required implementation needed to satisfy an objective on a
specific platform.
- Automated control activity. Automated
control activities use Microsoft System Center Configuration
Manager to validate configuration settings against predefined
baselines. The results from Configuration Manager (and any
threshold defined in the program or in the control activity form)
are used to determine the control activity’s compliance.
- Manual control activity. Manual
control activities require users to manually assert the result of
the activity. An individual will use forms and screens to manually
enter the activity information into the program.
- Control categories. Control objectives
and control activities that affect similar information technology
operations and are grouped together to clearly manage the control
environment.
- Control sub-categories. A lower level
of category (grouping of individual control objectives) that helps
organize the information in a meaningful way.
The following are examples of control categories and objectives:
- Control category. Identity and access
management
- Control sub-category. Access management
- Control objective. Security requires a
complex password
- Control activity. Password complexity is
configured to require all users to include alpha and numeric
characters.
- Control category. Identity and access
management
- Control test automation. The Process
Pack for IT GRC uses the Desired Configuration Management feature
in Configuration Manager along with supplied product-specific
baselines to enable control test automation. The Configuration
Manager connector in Service Manager 2012 populates the Service
Manager data warehouse database with control test results, which
are processed for validation against compliance objectives.
- Threshold. The minimum percentage of
applicable managed entities in the program scope that must be
compliant for a control activity to be considered compliant.
Roles within an IT GRC Program
Within any organization there are individuals who manage GRC-specific programs, information, and distribution of information. In creating an IT GRC program, you should be aware of the human resources (roles) that support the IT GRC program.
GRC-specific information is used to support business operations as well as internal and external audits. Most of the information captured is confidential and may be used for internal and external reporting. With the Process Pack for IT GRC, role–based access is configured to include the basic roles for individuals within an organization who define and work with an IT GRC program.
Program Readiness Review
After you create an IT GRC management program, configure the control objectives for the program, and configure the control activities for the program you can create a compliance program readiness review. A program readiness review helps the compliance program manager to ensure that all of the control objectives and control activities in the program are ready for an audit or management review. You can perform the readiness review on one or more control objectives in a program or for the entire program using the Start Readiness Review wizard.
The program readiness review is created using the following table and instructions.
Information needed |
Value |
Program |
Credit Card Processing Compliance Program |
<review_program_work_item_title> |
Credit Card Processing Compliance Program Readiness Work Item |
<review_start_date> |
Today |
<review_end_date> |
Two months from today |
<categories_control_objectives> |
PC5 / Policy Needs Assessment |
To perform a program readiness review of an existing program using the Start Readiness Review wizard
-
Click Start, click All Programs, click Microsoft System Center, click Service Manager 2010, and then click Service Manager Console.
The System Center Service Manager Console starts.
-
In the Service Manager Console, in the Navigation pane, click Compliance and Risk Items.
-
In the Compliance and Risk Items pane, go to the All Compliance and Risk Items/Program Management/All Programs location.
-
In the Results pane, click <program> (where program is the name of the program that you want to modify).
-
In the Tasks pane, click Start Readiness Review.
The Start Readiness Review wizard starts.
-
Complete the following pages in the Start Readiness Review wizard using the provided information, and accepting the defaults unless otherwise specified.
-
On the Before you Begin page, click Next.
On the Program Selection page
-
In Program Title, select <program> (where program is the name of the program for which you want to check readiness).
-
Click Next.
On the Review Activity Details page
-
In Review Program Work Item Title, type <review_program_work_item_title> (where review_program_work_item_title is the title you wish to assign to the work item title for the readiness review).
-
In Review Program Start Date, select <review_start_date> (where review_start_date is the starting date for the readiness review work item).
-
In Review Program End Date, select <review_end_date> (where review_end_date is the ending date for the readiness review work item).
-
Click Next.
On the Control Objective Selection page
-
In Select Categories and Control Objectives, select <categories_control_objectives> (where categories_control_objectives are the categories and control objectives to be selected for the readiness review).
-
Click Next.
On the Summary page
-
Review the list of configuration settings for creating the work item.
-
Click Create.
On the Completion page
-
Review the status of the Control Objectives Summary.
-
Click Close.
-
The work item created by the wizard is visible in the Work Items/Activity Management/Manual Activities/All Activities location. For more information about the work items in System Center Service Manager, see the topic "Managing Activities and Changes" in the System Center Service Manager Help, which is included with System Center Service Manager.