IT Compliance Management Guide: Published: October 2008 For The Latest Information, Please See

IT Compliance Management Guide
Version 1.0
Published: October 2008

For the latest information, please see
microsoft.com/technet/SolutionAccelerators
IT Compliance Management Guide
Copyright © 2008 Microsoft Corporation. All rights reserved. Complying with the applicable copyright laws is
your responsibility. By using or providing feedback on this documentation, you agree to the license agreement
below.
If you are using this documentation solely for non-commercial purposes internally within YOUR company or
organization, then this documentation is licensed to you under the Creative Commons Attribution-
NonCommercial License. To view a copy of this license, visit http://creativecommons.org/licenses/by-nc/2.5/ or
send a letter to Creative Commons, 543 Howard Street, 5th Floor, San Francisco, California, 94105, USA.
This documentation is provided to you for informational purposes only, and is provided to you entirely "AS IS".
Your use of the documentation cannot be understood as substituting for customized service and information
that might be developed by Microsoft Corporation for a particular user based upon that user’s particular
environment. To the extent permitted by law, MICROSOFT MAKES NO WARRANTY OF ANY KIND, DISCLAIMS
ALL EXPRESS, IMPLIED AND STATUTORY WARRANTIES, AND ASSUMES NO LIABILITY TO YOU FOR ANY
DAMAGES OF ANY TYPE IN CONNECTION WITH THESE MATERIALS OR ANY INTELLECTUAL PROPERTY IN THEM.
Microsoft may have patents, patent applications, trademarks, or other intellectual property rights covering
subject matter within this documentation. Except as provided in a separate agreement from Microsoft, your
use of this document does not give you any license to these patents, trademarks or other intellectual property.
Information in this document, including URL and other Internet Web site references, is subject to change
without notice. Unless otherwise noted, the example companies, organizations, products, domain names, e-
mail addresses, logos, people, places and events depicted herein are fictitious.
Microsoft, Active Directory, Excel, SharePoint, SQL Server, Visual Studio, Windows, and Windows Server are
either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other
countries.
The names of actual companies and products mentioned herein may be the trademarks of their respective
owners.
You have no obligation to give Microsoft any suggestions, comments or other feedback ("Feedback") relating to
the documentation. However, if you do provide any Feedback to Microsoft then you provide to Microsoft,
without charge, the right to use, share and commercialize your Feedback in any way and for any purpose. You
also give to third parties, without charge, any patent rights needed for their products, technologies and
services to use or interface with any specific parts of a Microsoft software or service that includes the Feedback.
You will not give Feedback that is subject to a license that requires Microsoft to license its software or
documentation to third parties because we include your Feedback in them.
IT Compliance Management Guide iii
Contents
Overview ..................................................................................................... 1
Grant Thornton LLP Statement ..................................................................... 3
Guide Purpose........................................................................................... 4
Guide Scope ............................................................................................. 4
How to Use This Guide................................................................................ 5
Business Drivers ........................................................................................ 6
Support and Feedback ................................................................................ 9
Acknowledgments .................................................................................... 10
Chapter 1: GRC Authority Documents .......................................................... 13
Chapter 2: Using Controls for Compliance Management ............................... 17
Chapter 3: Using an IT Framework for Compliance Management.................. 23
Life Cycle Fundamentals ........................................................................... 23
How Frameworks Benefit Organizations ....................................................... 25
Chapter 4: MOF and Compliance Management ............................................. 27
A Framework for Your Organization ............................................................ 27
Mapping Authority Documents to MOF ......................................................... 28
IT Audit Process ...................................................................................... 29
Chapter 5: Microsoft Technology Solutions for Compliance
Management .............................................................................................. 39
Technology Solutions for IT Control ............................................................ 41
Overview
The IT Compliance Management Guide is designed to help IT managers, business
managers, Microsoft customers, and the ecosystem of Microsoft partners plan for and
address specific IT compliance requirements that relate to applicable governance, risk,
and compliance (GRC) regulations, publications from standards bodies and industry
organizations, organizational policies, and agreements, all of which are collectively
referred to in this guidance as authority documents. The goal is to shift the effort of GRC
requirements enforcement and management to Microsoft products through the
configuration of existing features and functions.
The guide was created with extensive input from GRC auditors, GRC subject matter
experts, consultants, and those members of the technical community who work with
complex GRC requirements in their own organizations. The auditing firm Grant Thornton,
LLP reviewed this guide and associated workbook and provided a statement in the
"Grant Thornton LLP Statement" section.
The guide introduces an approach based on Microsoft® Operations Framework (MOF)
4.0. MOF provides an IT service life cycle process model that helps you address these
compliance requirements as well as organization-wide governance initiatives. Many
frameworks exist that specialize in IT governance, such as Control Objectives for
Information and related Technology (COBIT, for IT services) and ISO 27002 Code of
Practice for Information Security Management. The goal of MOF is to support these
industry-recognized frameworks with concise and meaningful guidance that integrates IT
processes with team accountabilities and defined outcomes. Because MOF uses
question-based guidance and document structure, it is easy to adapt MOF to your
organization or even integrate its identified best practices with your chosen framework.
The Microsoft Excel® workbook IT Compliance Management Resources that
accompanies this guide identifies Microsoft products and technology solutions that can
help you address compliance requirements when your organization is ready to deliver IT
GRC controls and compliant technical solutions.
Although the IT Compliance Management Resources workbook includes specific
technical and configuration guidance for the referenced products and solutions, it is not a
comprehensive GRC solution. Auditor opinions might differ on the sufficiency of a specific
control within your organization. Microsoft recommends that you consult your GRC
subject matter expert, legal counsel, or auditor for answers to specific compliance
questions in your organization, such as gap analysis between the provided configuration
guidance and your organization's GRC requirements. Only they are familiar with your
organization’s requirements to the degree that is required to make such a decision.
This Overview includes the following sections:
 Grant Thornton LLP Statement. This section is a statement by Grant Thornton LLP,
who was engaged by Microsoft to ensure that this guide aligns with general auditor
expectations, terminology, concepts, and objectives that might be applicable to an
organization managing GRC requirements.
 Guide Purpose. This section provides a concise statement of the guide's purpose
and includes an important "Caveats and Disclaimers" subsection.
 Guide Scope. This section describes the guide's structure and provides information
about the content of the guide's chapters.
2 IT Compliance Management Guide
 How to Use This Guide. This section describes how the information in this guide
can be used to craft and implement an effective compliance strategy based on MOF
and specific Microsoft products and technology solutions.
 Business Drivers. This section discusses business drivers for compliance, including
opportunities to establish and improve processes, gain competitive advantage, and
increase return on investment (ROI) for your organization through time and cost
savings. It also includes information about the challenges of regulatory complexity,
achieving and maintaining compliance, and the consequences of noncompliance.
 Acknowledgments. This section provides a list of contributors to this guidance.
Overview 3
Grant Thornton LLP Statement

Microsoft, Inc. has engaged Grant Thornton LLP to provide guidance in order to align the
IT Compliance Management Guide with general auditor expectations, terminology,
concepts, and objectives that may be applicable to an organization managing
governance, risk, and compliance (GRC) requirements. Grant Thornton has participated
as an advisor and reviewer of content within this guide and associated workbook.
This guide contains the information that will enable IT professionals to have an informed
discussion with their GRC subject matter experts, including legal and audit personnel.
The overview of the audit process and descriptions of general GRC terminology and
control concepts will allow IT professionals to be an active participant in these
discussions. The associated workbook provides a comprehensive list of Microsoft
resources that address GRC planning and product configuration topics relevant to IT
professionals.
The Microsoft Solution Accelerator Team (SAT) approach to creating this guidance has
included an extensive and collaborative development process including pilot users. This
process has included recommendations by auditors, GRC subject matter experts,
Microsoft product experts, consultants, and members of the technical community faced
with complex GRC requirements within their organizations. Feedback was gathered from
multiple collaborative meetings, reviews, and public solicitations for feedback.
Recognizing the need to maintain this GRC guidance, Microsoft has established a forum
to review ongoing customer and partner feedback. The SAT group has also elected to
internally sponsor qualified change requests for Microsoft products where such changes
assist the customer in meeting GRC requirements.
The chosen list of GRC authority documents represents a wide range of controls
addressing financial, data privacy, security, and best practices applicable to a wide range
of industries and international organizations. Although the list of GRC authority
documents may not be applicable to every organization, the controls represented by this
list will likely share GRC control objectives with other applicable international and
domestic GRC authority documents.
The Microsoft Operations Framework (MOF) referenced in the guide is both a reasonable
and extensible framework by which an organization may manage GRC requirements and
solutions. Organizations can benefit from the flexibility of the framework to manage
change in their IT infrastructure to meet applicable GRC requirements. For organizations
that use frameworks other than MOF, such as COSO or ISO 27002, MOF Service
Management Functions (SMFs) address many of the broad requirements of these
frameworks and can also be used as part of an organization’s overall toolkit. The
achievement of specific compliance objectives depend upon many factors and readers of
this document should make their own independent evaluation of relevant regulations and
applicability of this guide for their purposes.
As with any tool, the use of the information in this guide should be discussed with
organizational GRC subject matter experts to determine how it fits within the
organization’s overall efforts.
www.GrantThornton.com/IT-Compliance
Guide Purpose
The purpose of this guide is to help your organization identify and plan to implement
available software, tools, and technology solutions to address GRC requirements using
an IT framework.
The guide provides several benefits for your organization. It shows how you can apply a
control framework to both present and future authority documents, which helps to make
the process of interpreting authority document requirements easier and more efficient.
The guide also refers to solutions and software product configuration guidance that can
help you address GRC requirements through the completion of GRC control objectives
encountered for each SMF within MOF.
Caveats and Disclaimers

The intention of this guidance is to help you understand typical compliance obligations
that organizations might be required to address. However, regulations change and laws
can vary greatly by location and industry. This guidance does not constitute legal advice,
and is not a substitute for individualized legal and other advice from a GRC subject
matter expert. Microsoft recommends that you consult your team of legal advisors before
you decide whether to implement the processes in this guidance to help address the
compliance obligations of your organization.
Guide Scope
The IT Compliance Management Guide provides an overview of potentially applicable
authority documents for your organization that represent a wide range of GRC
requirements. Hundreds of other authority documents might also apply to your
organization. However, the authority documents referenced in this guide show specific
control types that will likely meet the requirements of other authority documents. Consult
your GRC subject matter expert when determining what existing IT GRC controls might
meet additional authority documents.
This guide also provides information about how to address compliance requirements
through control objectives in each function of an IT framework (MOF). In addition, it
provides guidance for applying the Manage layer of MOF and aligning the MOF life cycle
phases to address requirements that pertain to privacy and security controls of applicable
authority documents. The MOF guidance focuses on the tasks prescribed by the GRC
SMF to identify compliance needs and implement effective controls.
The guide consists of the following chapters:
 Overview. This chapter introduces the guide, defines its audience, and provides
business driver information. It also includes a "How to Use This Guide" section and a
listing of contributors.
 Chapter 1: GRC Authority Documents. This chapter provides a brief overview of
the representative authority documents discussed in the guide.
 Chapter 2: Using Controls for Compliance Management. This chapter provides
information about different types of compliance management controls.
 Chapter 3: Using an IT Framework for Compliance Management. This chapter
discusses how IT frameworks address compliance objectives and the benefits that
they provide.
 Chapter 4: Using MOF for Compliance Management. This chapter provides
information about using the MOF GRC SMF and other SMFs for compliance
management as well as an overview of the IT audit process.
 Chapter 5: Microsoft Technology Solutions for Compliance Management. This
chapter includes content to explain how to review each MOF SMF to process GRC
Overview 5
authoritative documents, understand requirements, develop controls, implement

configuration to enable controls, and manage their operation.
How to Use This Guide

This section provides a summary of how to use this guide to better understand the
processes involved in addressing compliance obligations. The discussion in the guide
can act as an abstraction layer to define the different authority documents, and to
determine and prioritize which technology solutions will help address the organization’s
compliance obligations. In addition, the guide helps the reader understand the benefits of
addressing compliance issues throughout the phases of the MOF 4.0 life cycle phases
based on the GRC SMF of the Manage layer: Establish, Assess, and Comply.
Organizations of all types are required to address various GRC obligations. For example,
an organization that handles credit card transaction data would likely need to comply with
Payment Card Industry Data Security Standard (PCI DSS) requirements. If that
organization operates internationally, they might also be required to handle data covered
by European Union Data Protection Directive (EUDPD) regulations. In addition, many
states within the United States have mandates that are similar to the EUDPD to protect
personally identifiable information (PII) data. Many of the privacy requirements within
these authority documents are also represented by the AICPA Generally Accepted
Privacy Principles (GAPP), but they require additional interpretation and analysis by GRC
subject matter experts if GAPP is to be used as a method by which a United States
organization addresses EUDPD requirements. Even the data of an organization’s
employees might require compliance with regulations. If a United States organization
maintains a health plan for its employees, corresponding data is subject to Health
Insurance Portability and Accountability Act (HIPAA) regulations.
To achieve compliance objectives, executives and IT management should ensure that
the compliance controls are coordinated with business goals and that the IT department
passes required compliance audits.
This guide approaches compliance with four important goals in mind:
 Shift the effort of complying with applicable GRC authority document requirements to
existing Microsoft products whenever possible.
 Use Microsoft partner solutions whenever possible to enable Microsoft products and
technologies to be made compliant through a single plan.
 Minimize the financial and business impact of required changes and audits within the
organization's IT department and general organization.
 Consolidate redundant controls and achieve efficiencies by analyzing, implementing,
and maintaining controls through a centralized, MOF-controlled process.
To achieve these goals, perform the following tasks:
1. Meet with the organization’s GRC subject matter experts to discuss goals and
determine how to proceed. If your organization has no GRC subject matter expert,
consider hiring a qualified Microsoft partner or audit firm for this task.
2. Research the IT Compliance Management Guide to determine what guidance can
best help achieve the organization’s compliance objectives. The MOF life cycle Plan
phase provides the structure needed to ensure that the IT processes and compliance
controls implemented meet the goals outlined.
3. Determine that the MOF Plan, Deliver, and Operate life cycle phases can be
effectively applied to ensure proper planning and delivery of technical controls as well
as effective ongoing maintenance of the controls as shown in Table 4.1.
4. Consult Table 5.1, ―Control Categories Mapped to Technology Solutions‖, in this
guide to determine any new technologies to focus on. Referring to this table, it is
apparent that Identity Management is a technology solution category that can help
with the Security Management and Administration control category.
5. Research specific technologies in "Chapter 5: Microsoft Technology Solutions for

Compliance Management" to understand which technologies can help address the
remaining control objectives. Consult the IT Compliance Management Resources
workbook and review the GRC Functions Inventory tab to learn how specific
Microsoft product features and functions can help address professional
responsibilities.
6. Discuss ideas with GRC subject matter experts to help tailor the proposed plan to
meet unique compliance needs and obligations.
7. Finalize a plan to incorporate the technology solutions, prioritize the remaining control
categories, and develop a strategy to implement them. After the plan is reviewed and
approved by your organization’s GRC subject matter experts and IT, budget can be
allocated accordingly to implement appropriate controls.
8. Execute the finalized plan with IT according to the MOF Delivery phase and the GRC
Job Aids tab of the IT Compliance Management Resources workbook. These job aids
will provide specific implementation and configuration guidance to your IT staff.
9. Begin the process of monitoring, incident management, and continual GRC
requirements alignment through the Operate and Manage SMFs within MOF.
Business Drivers
Many organizations view GRC activities as daunting tasks from which they receive little in
return. Although GRC efforts present significant challenges, they also offer corresponding
benefits. This section discusses business challenges and opportunities related to GRC
efforts.
Business Challenges
Compliance presents a number of challenges, which include managing a complex set of
GRC authority documents, addressing the difficulty of achieving, demonstrating and
maintaining compliance, and understanding the consequences of noncompliance.
GRC Authority Document Environment Complexity

The regulatory environment has become increasingly complex as the number and
breadth of regulations has increased. Most authority documents do not mention the
existence of other GRC authority requirements that share the same control intent, which
causes duplicate controls to exist within the same environment. This added complexity
places greater responsibility on organizations and executives to manage GRC authority
document requirements and to provide meaningful, ongoing evidence of compliance that
can put a significant burden on the organization. Specific requirements for each GRC
authority document also vary, along with the scope of activities that apply to each
regulation. A thorough analysis of each requirement is needed to determine the course of
action for each organization. Organizations must be diligent in their efforts to understand
how these GRC requirements apply to their business over time, and practical about
implementing controls and business practices to demonstrate compliance.
Achieving and Maintaining Compliance

Many organizations have found it difficult to achieve and maintain compliance with the
various GRC authority documents that apply to them. Specifically, many organizations
find that their GRC efforts are more complex, time-consuming, and costly than originally
anticipated, even if the organization made a sincere effort to control processes in the
past. These costs are associated with the need to prove compliance through
configuration states and receipts for actions over time. Difficulties also stem from
attempting to attain compliance with multiple regulations at a specific time—even as the
regulations often apply to separate departments of the organization.
Overview 7
After your organization completes its initial GRC efforts, the next challenge is to maintain
compliance in a cost-effective manner. The responsibility to maintain this ongoing effort
often remains dispersed and even unassigned. Unclear lines of responsibility can limit
your organization's ability to view compliance holistically and can increase the risk of
duplicating efforts. For example, if your organization experiences difficulty budgeting for
GRC requirements, consider a review of GRC assignments and authority.
Noncompliance Consequences
Many businesses are compelled to address GRC requirements to avoid the legal
consequences and risks of noncompliance. Consequences of noncompliance often
include references to financial, civil, and criminal penalties, but consider first the effect on
the organization’s reputation to its customers and shareholders and its ability to access
the resources it needs to succeed. In many ways, the financial and legal consequences
are not as compelling and are more remote than the real cost of diminished brand
reputation.
The consequences of noncompliance vary from one regulation to another, but they can
include:
 Loss of reputation, customer and business partner trust
 Loss of market share if competitors comply and your organization does not
 Loss of focus from business goals and objectives
 Significant fines (both personal and organizational)
 Personal legal liability and even incarceration for extreme offenses
 Litigation from shareholders and other parties
 Limited access to capital markets and loss of listings in the stock markets
 Diminished credit ratings
 Limited ability to do business in specific jurisdictions
 Increased regulatory oversight
The threat of these potential consequences provides significant motivation to
organizations and their executives to manage compliance effectively and proactively.
Business Opportunities
Compliance not only presents challenges to overcome, it also offers opportunities for
improvement within your organization. Such business opportunities include the chance to
improve processes, create competitive advantage, and further integrate IT into your
business to improve ROI.
Process Visibility, Measurement, and Improvement

Most regulations require organizations to have documented, measurable, and repeatable
business processes, and that those processes have appropriate controls in place to
prevent mistakes or fraud. Automated processes generally have more effective controls
than manual processes, and auditors can generally rely on automated controls more than
manual ones because they are less subject to human error or intentional misdeeds. For
these reasons, compliance requirements might be better met through automating
inefficient and potentially unreliable manual processes. Although the primary justification
for automating processes is to improve technical controls and the ability to repeat them,
an added benefit is that this process improves efficiency, visibility, and therefore
management potential of these processes. Some potential examples of automated
controls include the following:
 Automated password and complexity requirements such as those enforced by Active
Directory® Domain Services (AD DS).
 Workflow automation for user access granting, modification, and termination that can
be developed using Windows® SharePoint® Services.
 Automated change control solutions such as Microsoft Visual Studio®.
Automated identity management provides a good example of how an automated process
improves efficiency. Many auditors have drawn attention to the lack of technical controls
around the user life cycle management process that involves user account and profile
creation, modification, and deletion. To address this deficiency, organizations have
implemented automated identity management tools such as AD DS. Although the
purpose of such tools is primarily to automate the technical controls around critical
business processes, implementing them also improves the efficiency of the user
management process.
Competitive Advantage
In many industries, strong or early adherence to industry-recognized GRC authority
documents and related GRC practices can create a competitive advantage for an
organization. Organizations that provide services to other businesses can benefit from
early and proven compliance with regulations, because other organizations are more
likely to do business with compliant organizations that are in a position to help them
address their own compliance requirements in a visible and proven manner. When the
competition might agree to contractual GRC requirements without a comprehensive
solution, your organization can tout a GRC solution that is a clear competitive edge.
IT outsourcing firms, service bureaus, information processing industries, and health
insurance administration firms are examples of organizations that stand to benefit from
this competitive advantage. Implementation of standards can also lead to better IT agility,
and allow an organization to deliver more quickly and completely on business needs, in a
compliant manner.
There are available examples or public statements such as press releases and Web site
endorsements that should be considered. Microsoft recommends that you consult with
your auditor and legal counsel when developing a public statement regarding compliance
because there are certain limitations.
Privacy is another significant concern for businesses and individuals today. Strong
compliance with privacy regulations also provides a competitive advantage for
organizations. Organizations can market their compliance with privacy regulations to
build trust and market share with consumers, and allay the prevalent concern over
privacy and identity theft among the public. In addition, because compliance with the
EUDPD is a prerequisite to doing business in some European countries/regions,
compliance with this regulation can open up new markets for an organization's products
and services.
IT Integration and Return on Investment

Compliance requirements can help IT managers integrate technical solutions more
deeply into their organizations. Although many regulations do not specifically require IT-
based controls, it is often IT management that ends up implementing the technical
controls that the regulations strongly suggest. This approach increases the need for IT
and business management to work closely together to solve the difficult challenges of
compliance.
The opportunity to take advantage of information technology to administer and maintain
compliance controls can create a benefit for the IT infrastructure being used. By
calculating the time and resources that can be saved by integrating compliance controls
with information technology versus the one-time and ongoing costs, the total ROI for the
investment can be determined. For example, the full implementation of AD DS represents
a one-time and ongoing cost but also a recurring savings of system adminstration
oversight.
Overview 9
As IT managers become partners with management, they can benefit from increased
management visibility and communications to develop IT initiatives that can achieve
efficency gains and cost savings for the organization. For example, initiatives focused on
process automation and sound security principles such as authentication and data
retention can address compliance requirements while also delivering additional benefits
for the organization.
Support and Feedback

To ask questions or provide feedback, subscribe to the Compliance Management Forum.
This forum also provides the ability to join discussions and collaborate on GRC-related
compliance management issues with your peers.
Acknowledgments
The Solution Accelerators – Security and Compliance (SA-SC) team would like to
acknowledge and thank the team that produced the IT Compliance Management Guide.
The following people were either directly responsible or made a substantial contribution
to the writing, development, and testing of this guidance.
Users designated with an asterisk * worked on the original version of the Regulatory Compliance
Planning Guide. Users designated with a cross † worked on the original version and on this
updated and enhanced version.
Authors
Ross Carter *
John Cobb Wadeware LLC †
Lana Earhart *
Anthony Noblett Socair Solutions †
Content Contributors
Accenture LLP, Technology Consulting – Security
Derick Campbell
John Cobb Wadeware LLC
Graham Hill KPMG
Karen Massie Genesa Tech
Don McGowan *
Colin Mitchell
David Mowers *
Sai Sireesh Pachava
Frank Simorjay
Product Manager
Frank Simorjay
Program Managers
Bill Canning *
Jeff Coon Volt Information Sciences *
Luis Martinez
Jeffrey Miller
Editors
John Cobb Wadeware LLC †
Jennifer Kerns Wadeware LLC *
Steve Wacker Wadeware LLC
Testers
Gaurav Singh Bora *
Overview 11
Archita Dash Infosys Technologies Ltd *

Raxit Gajjar Infosys Technologies Ltd
Praneta Mehta Infosys Technologies Ltd
Sumit Parikh
Release Managers
Karina Larson
Karl Seng Siemens Agency Services *
Shealagh Whittle Sakson & Taylor
Contributors and Reviewers

Karri Alexion-Tiernan *
Rajiv Arunkundram
Michael Atalla
Kai Axford
Norman Barber *
Jeremiah Beckett Secure Vantage Technologies Inc.
Tony Bradley Evangelyze LLC
JC Cannon †
Chris Caren
Mike Chan
Matt Clapham *
Tom Cloward
Fatih Comlekoglu Blue Ridge Networks
Kelli Cook
Paul Cooke
Tom Daemen *
Mike Danseglio *
Christine Duell Valente Solutions *
John Duronio Duronio Consulting
Chris Farrow Configuresoft *
Tom Gemmell
Joe Gimigliano Purdue Pharma *
Sheila Gulati
Steven Hamburg Eclipsecurity, LLC *
Patrick Hanrion *
Clare Henry
Bill Hilf
John Howie
Guy-Marie Joseph ConnecTalk Consulting Services *
Adam Jung
David Krogh
Jason Lee *
Il-Sung Lee
Douglas Leland
Don Lemmex
Uri Lichtenfeld
Brendon Lynch *
Tod Manning
John Marshall
Alan Meeus
Noelle Mendez-Villamil
Giovanni Mezgec
Colin Mitchell
James Mizell
Betsy Norton-Middaugh
John Novak
Olav Opedal
Sai Sireesh Pachava
Barney Regen Gaylord Entertainment *
Thomas Rizzo
Miles Romello Wachovia *
Kim Sanchez
Peter Shablik Grant Thornton LLP
Mark Simon Eclipsecurity, LLC *
Ben Smith *
Nathan Snyder Electronic Evidence Discovery, Inc.
Diana Spickerman
Kaushal Toprani
John Traynor
Gary Verster
Ann Vu
Aaron Weller Protiviti
Jono Wells
Jeff Williams *
John Wylder *
Raymong Yamka, Jr. Grant Thornton LLP
Chapter 1: GRC Authority Documents
Increased government oversight in recent years has resulted in new regulations that
affect organizations in a wide range of international industries. In addition, GRC efforts
need to address authority documents that include publications from standards bodies and
industry organizations as well as organizational policies and agreements with clients,
vendors, and partners.
This chapter provides brief descriptions of the eight representative GRC authority
documents that this guide uses as authority documents that might apply to your
organization. If additional authority documents apply to your organization, it's likely that
they share requirements with these GRC authority documents. Consult your subject
matter expert(s) for further advice.
 Sarbanes-Oxley Act (SOX)
 Gramm-Leach-Bliley Act (GLBA)
 Health Insurance Portability and Accountability Act (HIPAA)
 European Union Data Protection Directive (EUDPD)
 Payment Card Industry Data Security Standard (PCI DSS)
 ISO 27002 Code of Practice for Information Security Management (ISO 27002)
 Control Objectives for Information and related Technology (COBIT) 4.1
 American Institute of Certified Public Accountants (AICPA) Generally Accepted
Privacy Principles (GAPP)
The following subsections describe these authority documents. Although this guide does
not specifically address other authority documents, the analysis in the guide might also
be used to help you address other compliance scenarios that apply to your organization,
such as newly devised data breach legislation or localized regulations. Consult your GRC
subject matter expert for gap and overlap analysis of any new GRC authority document.
The Sarbanes-Oxley Act of 2002 (SOX)

SOX was enacted in the United States in response to a lack of corporate financial
governance controls that resulted in questionable accounting practices. From an IT and
internal control perspective, the most prominent part of SOX is Section 404 as enforced
by the Public Company Accounting Oversight Board (PCAOB). This section of the act
requires publicly traded companies to establish internal controls for financial reporting
that result in a less than remote probability of a material financial misstatement. Section
404 also requires publicly traded companies to engage independent auditors who must
attest to the effectiveness of internal controls. The U.S. Securities and Exchange
Commission (SEC) enforce public issuer compliance with SOX and the PCAOB enforces
related audit standards.
Gramm-Leach-Bliley Act (GLBA)

The Gramm-Leach-Bliley Act (GLBA) was enacted by the United States government in
1999. GLBA, also known as the Financial Services Modernization Act of 1999, protects
the privacy and security of private financial information that financial institutions collect,
hold, and process. The privacy component of this act requires financial institutions to
provide customers with an annual notice of their privacy practices, and to provide them
the option to direct financial institutions not to share such information. The safeguards
component of the regulation requires financial institutions to establish a comprehensive

security program to protect the confidentiality, integrity and availability of the private
financial information in their records. Availability might refer to who can access the
information, or the availability of a service or function. Consult your GRC subject matter
expert for clarification. A number of U.S. federal agencies, including the Office of Thrift
Supervision (OTS) and the Office of the Comptroller of the Currency (OCC), enforce
GLBA.
Health Insurance Portability and

Accountability Act (HIPAA)
HIPAA includes among its components privacy and security rules for the handling of
personal and medical information within the health care industry. These rules focus on
Protected Health Information (PHI) and electronic PHI (ePHI) that result from efforts to
streamline the health care system in the United States and mandate the standardization
of electronic transactions, code sets, and identifiers. The privacy and security rules for
this act are detailed and prescriptive. Although the regulation focuses on organizations in
the U.S. health care industry, it can extend to other organizations if they engage in
certain activities, such as managing employee group health plans, or providing services
to organizations that this regulation directly affects. If your organization is in the United
States and maintains a health plan for its employees, HIPAA most likely applies to the
collected and stored information. The U.S. Health and Human Services department
(HHS) Office for Civil Rights (OCR) enforces HIPAA regulations.
European Union Data Protection Directive

(EUDPD)
EUDPD provides baseline requirements that all European Union (EU) member states
must achieve through national regulations to standardize the protection of data privacy
for citizens throughout the EU. It is important to understand that EUDPD drives additional
regulation at the country/region (member state) level. Interpretation and language
differences have resulted in differing control requirements in member states. The
directive has a strong influence on international regulations because of the limitations it
places on sharing personal information about EU citizens outside of the EU in areas
deemed to have less than adequate data security standards. Examples of specific laws in
countries/regions that represent EU member states include:
 Act on Processing of Personal Data (Act No. 429 of 31 May 2000) (Denmark)
 Federal Act Concerning the Protection of Personal Data (Datenschutzgesetz 2000 -
DSG 2000) (Austria)
EUDPD and its pursuant regulations affect organizations that do business in the EU or
handle the data of EU citizens. If the organization handling EU data is located within the
United States, that organization may either voluntarily conduct an internal audit and
submit an attestation of security practices to the United States Government in the form of
a Safe Harbor membership application, or include data privacy and protection language
to any business contract involving EU data. This language is boilerplate, and is approved
by the EUDPD. Various regulatory agencies of EU member states enforce the various
national privacy regulations based on EUDPD. See also the following section (AICPA
GAPP).
AICPA Generally Accepted Privacy Principles

(GAPP)
Developed by the Canadian Institute of Chartered Accountants (CICA), the American
Institute of Certified Public Accountants (AICPA), and the IT Governance Institute, the
Chapter 1: GRC Authority Documents 15
Generally Accepted Privacy Principles (GAPP) encapsulate requirements of sound

privacy practices and policies based in part on the EUDPD standards. The GAPP
standard was developed in an effort to consolidate requirements within privacy laws and
regulations that apply to organizations. Application of GAPP can enable entities in non-
EU member nations to satisfy EUDPD requirements. Although GAPP implementation will
aid organizations in matters of information privacy and protection, it is not a guarantee of
compliance with any specific regulation, rule, or requirement of an applicable governing
body. Consult your GRC subject matter expert for advice on how GAPP can help create
information privacy and security policy that is equivalent with EUDPD standards within
your organization.
Payment Card Industry Data Security

Standard (PCI DSS)
The Payment Card Industry Data Security Standards (PCI DSS) are the result of a
collaborative effort between credit card merchants Visa, MasterCard, American Express,
Discover, and the JCB International Credit Card Co., Ltd. The individual credit card
companies each addressed customer data privacy and security requirements with
separate programs that were merged so that the industry could address the need with a
unified standard. PCI DSS sets requirements that apply to the business and technical
operations of credit card processing vendors and data handlers. The standard dictates
GRC requirements that apply to the network, credit card data, vulnerability management,
access control measures, audit mechanisms, and documented security policy. PCI DSS
is applicable to any entity that accepts, processes, transmits, or stores credit card
transaction data and certain metadata. Vendors who do not abide by this standard might
have their vendor status suspended or revoked, can be fined for noncompliance, and
could lose their ability to process credit card transactions.
ISO 27002 Code of Practice for Information

Security Management
ISO 27002 is a comprehensive information security management standard published by
the International Organization for Standardization (ISO) and the International
Electrotechnical Commission (IEC). These organizations derived this new standard from
BS 7799 in the United Kingdom to provide an information security management
framework. ISO 27002, formerly ISO 17799, takes a very broad approach to information
security for electronic files, paper documents, recordings, and all types of
communications. Although ISO 27002 is a standard and not a regulation, some
regulations recommend it as the appropriate way to manage security within an
organization. Many organizations also include its terminology and processes in security
agreements for its vendors.
COBIT
The Information Systems Audit and Control Association (ISACA) and IT Governance
Institute (ITGI) publish and maintain a single volume of IT practices labeled Control
Objectives for Information and related Technology (COBIT 4.1). COBIT provides a
structure to plan, organize, acquire, implement, deliver, support, monitor, and evaluate IT
infrastructure. COBIT provides generic management principles that can be applied
across a range of IT frameworks and compliance requirements. Therefore, it
complements other authority documents in this document. COBIT and MOF share IT
focus, and can leverage each other when managing and implementing GRC solutions
within an organization.
Chapter 2: Using Controls for
Compliance Management
In this guide, controls are specific activities performed by people or systems designed to
minimize the risk of business and compliance objectives not being addressed.
Organizations use controls to regulate their business processes, which include
production, distribution, finance, and so on. Controls help organizations to ensure desired
behavior, and to reduce and prevent the spread of problems and errors.
Many regulations have the sole purpose of ensuring that organizations have proper
controls in place. For instance, HIPAA requires that proper controls over information
security and privacy are in place to protect patient records. The Securities and Exchange
Commission (SEC) and Public Company Accounting Oversight Board (PCAOB)
regulations associated with SOX require that publicly traded companies in the United
States implement controls to minimize the probability of a material misstatement in
financial statements.
Organizations implement controls for many reasons, including the following:
 Reduce the risk of fraud
 Protect organization and customer assets
 Prevent disclosure of organization and customer secrets
 Comply with regulations
 Improve business awareness
 Improve efficiency
 Improve accuracy
The following figure illustrates how different types of controls relate to each other.
Figure 2.1. Control relationships

Administrative Controls
Although all controls are put in place to address risks to the business, administrative
controls and technical controls differ in how they are implemented. Administrative
controls regulate and guide the business processes of the organization. For example, the
requirement for management approval of purchase orders is a business control that is
designed to require specific authorization, prevent unnecessary expense, and other
business-related requirements. Administrative controls might exist for almost every
process in an organization, from hiring, to purchasing, to sales, to financial reporting.
Technical Controls
Technical controls regulate and guide the operation of IT in the organization, including all
of the processes, and systems within it. These controls focus on processes that concern
IT managers, including availability, change management, user provisioning, security, and
other processes. There are two broad IT control categories: general controls and
application controls.
General Controls
General controls apply to the entire IT infrastructure of the organization. Organizations
must have reasonable general controls in place before they can rely on their application
controls. Reasonableness is usually determined by the organization’s auditors and GRC
subject matter experts.
General controls focus on many areas of responsibility for IT managers and staff,
including:
 IT organization
 Policy creation and communication
 System security
 Operations
 Change management
 Incident handling
 Monitoring
 Service, system, and application performance
Application Controls
Application controls are unique to each application that your organization uses to run its
business. In this respect, application controls are the IT components that support
administrative controls. Application controls help to minimize mistakes and prevent or
detect unauthorized or improper actions, such as potential fraud. Because application
controls are so closely tied to the business processes their applications support, these
controls are often considered administrative controls implemented by information
technology.
Application controls focus on:
 Data preparation procedures. These procedures help to minimize errors and
omissions. For example, during data origination, error-handling procedures help to
detect, report, and legitimately correct errors that are specific to the data while
logging any findings and actions.
 Accuracy, completeness, and authorization checks. These checks help to ensure
change control and validation for input data as close to its point of origin as possible.
Transaction data processing is subject to a variety of procedural controls to enforce
these checks.
 Data processing integrity. Such integrity helps to ensure separation of duties,
which strengthens data integrity. A greater degree of data validity is achievable by
Chapter 2: Using Controls for Compliance Management 19
including automated and logged checks and balances that separate duties and
require the actions of one individual to be verified by another.
 Output distribution. This distribution is enabled to ensure quality and consistency in
data that is output from IT systems. For example, affected controls include those that
define or communicate management policies and describe the proper procedures
and format for distribution of data.
 Sensitive information transmission protection. These procedures help ensure
that adequate protective measures are in place to prevent unauthorized access to
and tampering with sensitive information during electronic transmission and transport.
Additional Classification of Technical

Controls
There are two additional ways to classify technical controls. First, controls can be
classified as either manual or automated. Manual controls require a person to enforce the
control, whereas the IT system enforces automated controls. Assuming that effective
change control and security is in place, automated controls typically require testing of a
single or small sample because these controls can be relied upon to operate consistently.
Technical controls can also be classified as either preventive or detective. As the names
indicate, preventive technical controls prevent unwanted events from occurring. Detective
technical controls cannot prevent unwanted events, but they can detect events and then
notify a person or system to respond to them. Based on these factors, four types of
technical controls are possible as shown in the following figure:
Figure 2.2. Favorability of technical controls

A password complexity policy requirement is a good example of the various types of
technical controls and how they work. Suppose an organization has a requirement—
either from a regulation or as part of their security policy—that passwords must be no
fewer than eight characters long. There are a number of ways to address this
requirement, depending on the type of controls that the organization implements. The
following IT control examples provide different ways to address this requirement:
 Manual detective. This type of control requires a person to determine manually
whether an unwanted event, in this case a short password, has taken place. For this
example, the organization could institute a manual detective control that would
require an administrator to run a report once a week to calculate password length,
and thereby find any passwords fewer than eight characters long. When the results of
the report detect a password of insufficient length, the administrator can take some
action, such as to disable the account or send a note to the offending user’s
manager. Manual detective controls are generally inefficient because they take time
to detect an unwanted condition, might be repeated, and require human effort both to
detect the problem and resolve it. For this reason, you should consider using manual
detective controls only as a last resort and when other types of controls are not
available. Auditors require extensive evidence to support the assertion that a manual
control is effective and therefore sufficient. These controls considerably complicate
audits.
 Manual preventive. Sometimes a manual preventive control is sufficient to achieve
the objective. A manual preventive control in this situation could require the
organization to publish a password policy that requires all employees to use complex
passwords at least eight characters long before they can access the organization's
network. A manual preventive control might be a system administrator review for

sufficient length prior to establishing user accounts. The intent of the control is to
prevent short passwords, but it requires human compliance to be effective.
 Automated detective. This type of control allows a system to detect automatically
unwanted events and notify the appropriate personnel to remediate them. For this
example, an automated detective control could take the form of an automated
process that scans for insufficient passwords and then notifies an administrator when
it detects one. As in the manual detective example, the administrator would take
action when a password problem is found, but the incidents and undesirable
conditions would still occur and be subject to an auditor’s scrutiny of why such
conditions are allowed within the organization.
 Automated preventive. When possible, an automated control is preferable because
it eliminates the human factor of possible noncompliance. For this example, the
organization could use an operating system capability that will not allow users to
establish short passwords. This control complies with the password policy
requirements and is much more difficult for personnel to ignore or circumvent. These
controls are the easiest to audit and demonstrate their effectiveness. They are also
the most trusted by auditors.
Note that because automated controls reduce human involvement, they are generally
considered more effective than manual controls. In addition, it is generally preferable to
prevent problems than to detect and respond to them. Therefore, automated preventive
controls are generally preferred over the other three control types.
Because understanding the different types of control categories is important, an
organization cannot use automated preventive controls without guidance on how to apply
the controls. This guide goes beyond IT control frameworks by providing guidance on the
implementation of the controls rather than just describing them.
In addition, there might be situations in which automated preventive controls are not
practical for the organization. An example is the use of the system lockout feature after
an incorrect number of password attempts. Although an automated preventive control
could be the lockout of an account after five unsuccessful attempts, this configuration
might not be acceptable in a high transaction volume business such as a retail catalog
organization. Instead, a temporary lockout (for example, 15 minutes) with the incident
captured for later management review as an automated detective control might be more
feasible. Similarly, after hours shipments might be necessary for certain customers and
systems might need to capture but not prevent shipments by individuals not explicitly
authorized.
Cumulative Controls
Sometimes a single control is not sufficient to address an organization’s needs. In this
case, more than one control might be necessary to reach the level of control that is
required. When several controls combine to achieve a specific control objective, they
become cumulative controls, sometimes referred to as redundant controls.
Organizations often use cumulative controls when they must rely on manual controls, or
when the risk that the organization faces is large in scope. For example, if a policy or
manual preventive control is the only way to enforce a password length requirement, it
also would be advisable to implement a manual or automated detective control to monitor
the level of compliance.
Cumulative controls could also be helpful when your organization must address a
significant risk. For example, running critical business functions on an obsolete operating
system is generally considered a large security risk. However, if your organization has no
other choice, you can implement other controls to compensate for this risk. In this case,
you might not allow the vulnerable system to connect to the network. In addition, the use
of removable media on computers could be prohibited to reduce the risk of malicious
Chapter 2: Using Controls for Compliance Management 21
software infection. Any one of these controls might not be enough to address this
problem. However, they can be effective when you combine them.
Compensating Controls
Sometimes a control or a set of controls achieves the same desired outcome of a GRC
requirement, but does not do so with the same level of precision as the primary control.
When individual controls or sets of controls combine to achieve the same outcome as a
GRC requirement, they become compensating controls.
For example, a legacy system might not be able to comply with current data encryption
guidelines. However, additional tools can be used to compensate and provide the
appropriate encryption. Another example might be organizations that rely on periodic
evaluations of authorized users to compensate for potential deficiencies with the user
account maintenance controls.
Why Technical Controls Are Important

Technical controls are important because they provide an efficient means for your
organization to combine and automate its business-focused requirements and
compliance objectives. IT managers can implement technical controls to establish reliable
processes to measure and improve the organization's IT control environment. Effective
technical controls also position your organization to better adjust to changing compliance
requirements. They also help IT demonstrate compliance to auditors. IT auditors greatly
prefer to assess automated technical controls because they can evaluate them more
quickly and reliably to determine the quality of the compliance efforts that the
organization has in place. This can reduce the time, expense, and disruption of your IT
audits.
Chapter 3: Using an IT Framework for
Compliance Management
This chapter of the IT Compliance Management Guide introduces a holistic life cycle
approach to addressing GRC requirements using Microsoft® Operations Framework
(MOF) 4.0. IT control frameworks provide structures that define what to do. MOF
approaches things from the next level: integrating the IT control framework with business
processes and applying the controls efficiently and effectively. It includes some
information about life cycle fundamentals and describes the benefits that MOF provides
organizations to help them achieve their IT GRC control objectives.
The chapter then shows the process that was used to map relatively nonprescriptive
authority documents to IT GRC control objectives, and how these objectives are
addressed through Microsoft technologies using MOF. This mapping can help you
simultaneously address many GRC requirements. The framework also allows you to
avoid overlapping efforts to address common IT control objectives for your organization.
This chapter includes the following sections:
 Life Cycle Fundamentals. This section explains the fundamentals of a life cycle–
based framework approach to compliance.
 How Frameworks Benefit Organizations. This section explains the benefits that
you can take advantage of through a MOF–based approach to compliance.
Life Cycle Fundamentals

Instead of viewing each GRC authority document and associated requirements
separately, this guide provides you with a means to consider all of the authority
documents that it includes at the same time to achieve your organization's IT GRC
control objectives.
Many common GRC authority documents significantly overlap in the technical controls
that they require. To make this process more efficient, often you can implement a single
technical control to help address the GRC requirements for a number of GRC authority
documents.
For example, regulations such as the Health Insurance Portability and Accountability Act
(HIPAA), the Gramm-Leach-Bliley Act (GLBA), Sarbanes-Oxley (SOX), the Payment
Card Industry Data Security Standard (PCI DSS) and laws based on the European Union
Data Protection Directive (EUDPD) or United States legislature covering the protection
and reporting requirements of personally identifiable information (PII), require
management to establish procedures (controls) to ensure that actions to request,
establish, issue, suspend, and close user accounts occur in a controlled manner.
Establishing one set of technical controls to help address these user account life cycle
requirements for all the regulations improves the efficiency and effectiveness of the
organization’s compliance efforts while reducing GRC compliance costs and auditing
efforts.
MOF helps organizations address this issue with the Service Management Functions
(SMFs) of the Plan phase. The Business / IT Alignment SMF helps ensure that the IT
services and policies align with business processes. This effort also enables
organizations to view Governance, Risk, and Compliance (GRC) requirements with a
holistic approach that examines how they relate to each other and develop common
controls that meet current and future GRC demands.
The following figure illustrates how you can use technical controls simultaneously to help
address many primary authority documents.
Figure 3.1. Technical controls can address many authority documents

simultaneously
Developing Common Technical Controls

As compliance authority documents continue to increase, many organizations face the
challenge of how to focus their compliance efforts to address the requirements of multiple
authority documents. For example, a publicly traded U.S.–based financial services firm
might need to comply with requirements from several regulations, including those from
GLBA, SOX, and various U.S. Securities and Exchange Commission (SEC) regulations.
Currently, an organization that must address the requirements of multiple regulations
might do so as follows:
1. Review each regulation.
2. Determine control requirements specific to each applicable regulation and standard.
3. Implement the appropriate controls.
4. Conduct an audit to determine compliance sufficiency.
Unfortunately, these steps are inefficient because the organization has to repeat all of
them to address each GRC authority document, and possibly each GRC requirement
within them. The following figure illustrates the inefficiency of dealing with standards and
regulations one at a time. The result is redundant efforts that potentially lead to
overlapping or conflicting controls and policies, which increases GRC costs to the
organization.
Chapter 3: Using an IT Framework for Compliance Management 25
Figure 3.2. Addressing regulations inefficiently outside of a coordinated MOF GRC

SMF
The following section describes how a well thought-out compliance framework provides
many benefits for your organization in addition to those mentioned in this section.
How Frameworks Benefit Organizations

MOF provides many significant benefits for organizations seeking to achieve their
compliance objectives. The framework–based approach to compliance allows
organizations to:
 Efficiently plan, deliver, operate, and continually manage GRC requirements and
associated solutions of the organization. The MOF life cycle approach provides
guidance to help IT organizations implement and support IT services while delivering
the necessary business performance with an acceptable level of risk.
 Scale delivered solutions by combining technical controls to address multiple
regulatory standards, such as those from SOX and HIPAA, by consolidating audit
activities. The Business / IT Alignment SMF of the MOF Plan phase enables
organizations to examine the relationship of the various requirements and establish
common controls that meet the compliance standards.
 Address and plan for new regulations rapidly as they are introduced. The Manage
layer of MOF deals with the need to sustain and grow the business while managing
risks and adapting to changing regulatory requirements.
 Prioritize spending on only those technical controls that will deliver the greatest
impacts. The Business / IT alignment SMF provides guidance to synchronize IT
services with business processes and prioritize the implementation of those services
that most affect the organization.
 Prevent duplication of work within departments with effectively planned compliance
solutions that communicate across the organization. The Business / IT Alignment
SMF of the Plan phase also allows organizations to examine the big picture and
ensure that the processes they implement and the controls they put in place address
the need as a whole and prevent redundancy or conflicts between different
compliance solutions.
 Update current GRC requirements more efficiently through controlled delivery of

incremental changes to your organization's existing technical controls. The Change
and Configuration SMF is designed to control necessary changes within IT services.
 The Business / IT Alignment SMF of the Plan phase works in concert with the GRC
SMF to establish and maintain a common ground between the IT department, the
business and its auditors.
The following figure illustrates how MOF can help simplify compliance for your
organization.
Figure 3.3. A conceptual view of a control framework
The next chapter describes how you can use MOF to achieve all of these compliance
benefits for your organization.
Chapter 4: MOF and Compliance
Management
This chapter of the IT Compliance Management Guide focuses on mapping regulations to
technology solutions and their prescribed configurations. It introduces and defines the
process that was developed to translate relatively nonprescriptive regulations to specific
technologies that can help address compliance and privacy assurance objectives.
This chapter uses tables to depict GRC authority document relationships within MOF
Service Management Functions (SMFs). Each intersection in the tables indicates
coverage of GRC authority document concepts and requirements within the indicated
rows.
This chapter includes the following sections:
 A Framework for Your Organization. This section explains why Microsoft
recommends using Microsoft® Operations Framework (MOF) 4.0 as the foundation
for managing compliance efforts in an organization.
 Mapping Authority Documents to MOF. This section presents an overview of how
the example authority documents map to specific MOF SMFs.
 IT Audit Process. This section provides step-by-step guidance for how to properly
prepare for a compliance audit, and how to remediate compliance issues identified
during an audit.
A Framework for Your Organization

Microsoft recommends that you use MOF to help address your organization’s compliance
objectives effectively. MOF is a freely available framework that provides a comprehensive
approach for addressing compliance and support from partners, and training and
certification are available. Using MOF enables your organization to map applicable
authority documents to planned and delivered scaled solutions within your organization.
Your organization can then more efficiently focus its IT control efforts on addressing the
requirements defined in the framework rather than individual regulations.
In addition, as new authority documents affect the organization, you can process them
through the framework and then concentrate your efforts on those parts of the framework
in which the requirements have changed. You can also map a wide variety of IT control–
related requirements to the framework, including industry-specific requirements, such as
the Payment Card Industry (PCI) security requirements, internal policies, and so on.
Microsoft recommends that organizations use MOF and a set of technical controls to
organize their compliance efforts. Several frameworks exist that could be used as a basis
for this framework. These frameworks include the following:
 Microsoft Operations Framework (MOF) 4.0
 IT Governance Institute (ITGI) Control Objectives for Information and related
Technology 4th Edition (COBIT 4.1)
 ISO 27002 Code of Practice for Information Security Management
 The British Office of Government Commerce IT Infrastructure Library (ITIL)
 American Institute of Certified Public Accountants/Canadian Institute of Chartered
Accountants (AICPA/CICA) Trust Services Framework
 American Institute of Certified Public Accountants/Canadian Institute of Chartered

Accountants (AICPA/CICA) Generally Accepted Privacy Principles Framework
 The Unified Compliance Framework (UCF)
Mapping Authority Documents to MOF

This section presents an overview of how the authority documents in this guide map to
specific technology solution life cycle phases of MOF.
Eight authority documents were mapped—SOX, GLBA, HIPAA, EUDPD, PCI DSS, ISO
27002, COBIT and AICPA GAPP—to the framework. Whenever possible, mapping was
conducted with the assistance of pre-existing guidance from accredited agencies and
government organizations. The documents that contain this guidance, which this guide
refers to as bridging documents, are generally accepted by the audit and regulatory
community as a reasonable representation of the control requirements for these authority
documents. The following bridging documents were used to help map the MOF SMFs:
 Sarbanes Oxley Act. IT Control Objectives for Sarbanes-Oxley (PDF) from the IT
Governance Institute.
 Gramm-Leach-Bliley Act. Standards for Safeguarding Customer Information (PDF)
from the Department of the Treasury; Office of the Comptroller of the Currency,
Office of Thrift Supervision; Federal Reserve System, and Federal Deposit Insurance
Corporation.
 Health Insurance Portability and Accountability Act. HIPAA Administrative
Simplification Regulation Text (PDF) from the Department of Health and Human
Services, Office for Civil Rights.
 European Union Data Protection Directive. Directive 95/46/EC of the European
Parliament and the Council of 24 October 1995 on the protection of individuals with
regard to the processing of personal data and on the free movement of such data
Official Journal L 281, 23/11/1995 P. 0031 – 0050. This resource also overlaps with
AICPA/GAPP and US state PII objectives.
 ISO / IEC 27002:2005(E) Code of Practice for Information Security Management.
Available from the International Electrotechnical Committee Web store. Because
COBIT and ISO / IEC 27002:2005(E) both deal with information security and process
governance, this resource also overlaps with COBIT IT control objectives.
As described in the ―Caveats and Disclaimers‖ section in the Overview, this guide does
not constitute legal advice and is not a substitute for individualized legal and other advice
that you should receive from your GRC subject matter expert. These mappings should
therefore only be used as a general guide. To determine the specific requirements for
your organization, consult your GRC subject matter expert.
Chapter 4: MOF and Compliance Management 29
Table 4.1. Major Authority Documents Map to MOF Service Management Functions
X's represent where control categories intersect with the GRC authority documents.
Microsoft Operations Authority Document Coverage

Framework
ISO 27002
MOF
PCI DSS
Service
EUDPD
COBIT
HIPAA
GLBA
GAPP
MOF Management
SOX
Phase Function
Manage GRC X X X X X X
Manage Change &
Configuration X X
Management
Manage Team X X X X X X X X
Plan Business / IT
X X X
Alignment
Plan Reliability X X X X X X X
Plan Policy X X X X X X X X
Plan Financial
X X X X X X X X
Management
Deliver Envision X X X X X X X X
Deliver Project Planning X
Deliver Build X X
Deliver Stabilize X X X X X X X X
Deliver Deploy X X X X X X X X
Operate Operations X X X X X X X
Operate Service
X X X X X X X X
Monitoring
Operate Customer
X X X X X X X
Service
Operate Problem X X X X
Management
IT Audit Process
Audits are a critical component of the compliance process. In general, it is the auditors
who will determine whether your organization sufficiently complies with the authority
documents that it must address. For example, with regard to SOX, external auditors will
often determine the sufficiency of internal controls within your organization as part of the
audit in relation to quarterly financial reporting. Understanding how the audit process
works and how auditors operate is important because it informs IT managers how to
establish an environment that is compliant and easy to audit. This section focuses on
how auditors generally conduct an IT audit. Consult your GRC subject matter expert for
specific details of audits that apply to your organization.
It is important to understand what auditors look for during a GRC-related audit. During the
audit, the auditors seek to verify the following conditions:
 The organization has designed reasonable and effective controls as part of a control
program to address applicable GRC requirements and there are no design
deficiencies.
 The control documentation or related assertions provided by the organization fairly
represent the control environment.
 The controls were placed into operation at a specific date and time.
 The organization consistently applies the controls they have designed and there are
no operational deficiencies.
 Exceptions that the organization experiences are addressed in an authoritative,
timely and productive manner while being clearly documented.
If the auditors determine that an effective control environment does not exist or that the
organization does not adhere to the control environment, they note these deficiencies in
their final audit report and might issue a corrective action, which is an auditor demand
that a control or incident be managed within a certain timeframe. This audit report is
generally provided to the organization’s audit committee so that identified issues are
appropriately exposed to management. Obviously, it is preferable that no deficiencies are
noted in this report and no corrective actions issued.
The following process describes the general activities that auditors conduct during an
audit. Your auditor might conduct the audit using a slightly different approach, and the
audit frequency could be affected by how often internal audits are conducted. If internal
audits are conducted quarterly, an external audit may likely occur semi-annually or
annually as prescribed by applicable GRC authority documents:
 Step 1: Plan the audit (auditor)
 Step 2: Hold audit kickoff meeting (auditor/organization)
 Step 3: Gather data and test technical controls (auditor/organization)
 Step 4*: Remediate identified deficiencies (organization)
 Step 5*: Test remediated risks and risk assessment (auditor/organization)
 Step 6: Analyze and report findings (auditor)
 Step 7: Respond to findings (organization)
 Step 8: Issue final report (auditor) and repeat these steps from Step 1
* These steps might or might not apply to specific types of audits
The following diagram shows the IT audit process.

Figure 4.1. Flow diagram of the overall IT audit process

Understanding the steps in the IT audit process positions IT managers to know what to
expect from the audit. In this way, you can better achieve your organization's GRC
control objectives, and optimize the audit process to complete it more efficiently.
Step 1: Plan the Audit

This step aligns with the Business / IT Alignment SMF of the MOF Plan Phase with some
integration of the Establish IT Governance activities of the GRC SMF. To plan for the
audit, the auditor requires the organization to provide a list of all technical controls that it
currently uses, in addition to documentation that defines how each control works. The
auditor will also likely ask for other non-IT controls. The documentation provided by IT
staff should describe how the controls minimize risk for the organization and address
their compliance requirements. The auditor uses these documents to determine the
design adequacy of the technical controls in your organization, and to discover probe
points where sufficiency can be measured. These points might include log points,
authorization points, and incident management records for the period since the last audit.
The audit team typically determines the scope of technical controls that the auditor
focuses on in the organization. This scope might also be determined by a client or partner
with contractual expectations of the organization, or an agreed-upon segment of controls
being reviewed over time that adds up to a comprehensive audit. The scope also
depends on the type of audit being performed. In a SOX audit, for example, the scope of
the audit will be the primary financial accounts and the mission-critical applications that
support them. And the PCI DSS standard has been updated to include language that
additionally specifies applicable scope, another example of how specific language
updates can affect scope. The auditors also use the planning phase to define any areas
that might require special focus. They might base this need for special focus on areas of
weakness noted in a previous audit, previously issued corrective actions, guidance from
regulatory agencies, or a risk assessment of the current environment. It is very useful to
be aware of the scope of the audit to be as prepared as possible for it.
Figure 4.2. The IT audit planning process
Step 2: Hold Audit Kickoff Meeting

The next step is related to the Project Plan SMF of the MOF Deliver Phase. The auditor
and organization meet to kick off the IT audit process and confirm the audit plan for the
organization. In addition, the auditor will use this opportunity to identify which of the
organization’s resources will be required to support the audit process.
Figure 4.3. The IT audit kickoff process
Step 3: Gather Data and Test Technical

Controls
Steps 3 through 7 of the IT Audit Process relate to the Stabilize SMF of the Deliver Phase
coupled with the Assess, Monitor, and Control Risk task of the GRC SMF within the
Manage layer of MOF. The auditors conduct tests to ensure that the documented controls
are in place and working appropriately. The number and type of tests that the auditors
conduct depend on the type of controls that they test, in addition to the criticality of the
system that the technical controls address.
For example, an IT administrator might demonstrate to the auditor how users complete
and submit a form to create access for themselves to the system. The auditor verifies that
the information requested of the user addresses both regulatory and operational
requirements. For manual controls related to this process, the auditor examines the
validity and thoroughness of policy documentation for the organization and observes the
operation of corresponding controls in the same manner. The auditor will also verify that
appropriate approvals are obtained.
Figure 4.4. Gathering data and testing technical controls for the IT audit process
Step 4: Remediate Identified Deficiencies

Based on the test results, the auditors inform the organization of any deficiencies they
have identified. In some cases, it will be possible for the organization to address these
issues relatively quickly. When such deficiencies are identified, the auditors might allow
some time for the organization to correct them through the issuance and tracking of
corrective actions and corrective actions reports, commonly referred to as CARs.
Remediation efforts should be prioritized so that the more critical risk/impact assessment
issues within the respective control areas are addressed first.
Figure 4.5. Remediating deficiencies identified in the IT audit process

Step 5: Retest Controls for Remediated Risks

The auditors retest controls for remediated risks. The auditors can either accept or reject
that the deficiencies were adequately addressed. If the auditors determine that the
organization has adequately addressed the deficiencies, they might not include these
deficiencies in the final audit report.
Figure 4.6. Retesting controls that remediate risks identified in the IT audit process
Step 6: Analyze and Report Findings

When all testing is complete, the auditors compile their findings in a report. This report
details any deficiencies discovered during the audit. Typically, deficiencies belong to one
of the following categories:
 Design deficiencies. These deficiencies are situations in which the auditor finds a
complete or partial lack of controls for a given risk, or finds that the controls are not
sufficient to adequately accomplish their goal. An example of a design deficiency is if
the organization handles confidential customer information, such as a name,
address, and driver's license number, but has no process defined for how it protects
this personally identifiable information (PII).
 Operational deficiencies. These deficiencies are situations in which the auditor
finds that the organization does not apply the controls as designed. These situations
could occur if the control was documented but never put into production, or if the
control is in production but the organization does not adhere to it. For example, a
control might state that a vice president or higher level executive must approve a
user access request for a particular sensitive resource before the user is granted
access. This control would constitute an operational deficiency if the auditors
determine that access is routinely granted without such approval. A common failure
within organizations is the documenting of policy without sufficient controls around its
enforcement. The issuance of GRC policy within an organization without proper
policy management is an invitation for control failure.
The auditor produces a summary of control deficiencies report for the organization that
includes the extent and number of exceptions that the organization needs to address.
Figure 4.7. Analyzing and reporting findings of the IT audit process
Step 7: Respond to Findings

The organization is generally allowed to respond to the auditors’ findings, either with their
view of any circumstances that could mitigate the findings or with plans to address the
auditors’ findings in the future. Most organizations try to address the identified IT control
deficiencies before their next audit. If findings are publicly known, there will be
considerable pressure to fix the deficiencies. Careful adherence to MOF SMF guidance
will help IT staff correctly resolve any issues. A rushed fix might lead to additional control
failures, such as change control.
Figure 4.8. Responding to findings of the IT audit process
Step 8: Issue Final Report

This step aligns with the Comply with Directives task of the GRC SMF, as well as the
Deploy SMF of the Deliver Phase in MOF. As the last step in this process, the auditor
issues a final report for the audit. Ideally, this report will identify areas that show systemic
gaps and their associated risks. The report should provide the organization with specific,
actionable findings that the organization can address and resolve. This report is shared
with IT management, in addition to affected teams (such as Finance for SOX and Human
Resources for HIPAA) for inclusion in the overall audit report. The audit report might also
be shared with the board of directors or appropriate third parties such as regulatory
agencies, clients, and partners. The entire process then repeats.
Figure 4.9. Issuing the final IT audit report
How to Optimize the Audit Process

There are many ways to make the audit process more efficient and less difficult, including
the following:
 Perform a risk impact analysis and identify assets that represent greater risk for the
organization. Focus on the appropriate creation of IT GRC controls to govern these
important assets, starting with the MOF GRC SMF.
 Work with the auditor early in the process to understand the key areas on which they
plan to focus during the audit.
 You can reprioritize projects to ensure that you address what the auditors identify
as key risks in the environment, thus avoiding deficiencies in the audit.
 Although an auditor must remain independent, an initial discussion regarding
expectations and firm specific standards might be extremely beneficial.
 There might be an opportunity to use organizational knowledge to assist the
auditor in refining the scope of the audit.
 Many regulations include an initial risk assessment phase in which IT
professional participation might help the auditor focus on relevant risks to the
identified audit purpose.
 Perform a pre-audit readiness assessment to determine compliance with the stated
regulations prior to a first-time-through audit.
 Fulfill requests for information in a timely, complete, and organized manner.
 Assign an individual coordinator to funnel requests, schedule meetings, and handle
other requirements to minimize organizational disruption and auditor on-site time.
 Shift GRC efforts to technologies and implement automated technical controls
whenever possible. These controls are superior to manual ones because auditors
can more easily test and validate them. In addition, prioritize the implementation of
preventive controls over detective controls. Compensating controls should be used
only in situations in which preventive and detective controls are not an option.
The primary ways to optimize the efficiency and lower the cost of the IT audit process for
your organization include the following:
 Maintain clean and concise documentation of overarching processes and technical
controls. Outdated documentation equals a control failure on many levels, including
training, documentation, procedure, and any actions that were uncontrolled as a
result of the outdated documentation.
 Organize your technical controls to work with the framework language and
terminology that your auditors use. This approach will help ensure that you and your
auditors communicate clearly about the regulatory objectives.
 Take advantage of a technical controls framework as described in "Chapter 3: Using
an IT Framework for Compliance Management" in this guide. The framework
approach will help you to more effectively address a variety of regulations with a
single set of controls.
MOF can provide you with planning options to realize IT control efficiencies for your
organization. A framework links business requirements to IT activities through a
consistent model. You can use this model to identify the IT resources you need to define
and achieve your organization's IT control objectives.
Figure 4.10. MOF life cycle phases (Plan, Deliver, and Operate) and the Manage
layer
Chapter 5: Microsoft Technology
Solutions for Compliance Management
This section presents the technology solution categories that are relevant to GRC. So far,
this guide has focused on how requirements from authority documents can drive specific
IT control requirements. Now the focus shifts to the technology solutions that can help
address those requirements.
A list of technology solutions was created and validated, along with the categories for
them that are relevant to compliance, against ISO 27002, National Institute of Standards
and Technology (NIST SP800) recommendations, and other frameworks. Based on this
process, the following 19 technology solution categories were derived:
 Document Management. Document management solutions combine software and
processes to help you manage unstructured information in your organization. This
information might exist in many digital forms, including documents, engineering
drawings, XML files, images, and audio and video files.
 Business Process Management. Business process management (BPM)
applications help provide end-to-end visibility and control over all segments of
complex, multistep information requests or transactions that involve multiple
applications and people in one or more organizations.
 Project Management. Project management solutions apply knowledge, skills, tools,
and techniques to a broad range of activities to help meet the requirements of a
particular project. Project management knowledge and practices are best described
in terms of component processes. These processes divide into five process groups:
envision, plan, develop, stabilize, and deploy.
 Risk Assessment. This category can have several meanings. The information
security community defines it as a systematic method to identify the assets of an
information-processing system, the threats to those assets, and the vulnerability of
the system to those threats. In the context of regulatory compliance, risk assessment
is the process of assessing the level of compliance and compliance inadequacies
within an organization.
 Change Management. Change management systems are process structures that
cause IT managers to review proposed changes for technical and business readiness
in a consistent manner. The IT managers can then relax or strengthen the changes to
adjust to business needs and experiences.
For example, an organization could involve a database to help personnel make better
decisions about future changes based on historical data that indicates the success or
failure of similar changes it has tried in the past. Change management is also a
structured process that communicates the status and existence of changes to all
affected parties. The process can yield an inventory system that indicates what
actions were taken and when, which affects the status of key resources to help
determine problems and resource management.
 Network Security. Network security solutions constitute a broad solution category
designed to address the security of all aspects of the network for the organization,
including firewalls, servers, clients, routers, switches, and access points.
 Host Control. Host control solutions control the operating systems in servers and
workstations. Their functions also include implementing security best practices at all
levels of the operating system in each host, maintaining the most current updates
and hotfixes, and using secure methods for daily operations.
 Malicious Software Prevention. Malicious software prevention solutions include

antivirus, antispyware, and antispam solutions as well as rootkit detectors.
 Application Security. Application security combines good development practices
with specific software security.
 Messaging and Collaboration. Messaging and collaboration applications have
become essential tools. Collaboration applications can range from integrated
document programs, such as Microsoft® Office to portals, instant messaging, online
presentation software, and peer-to-peer programs.
 Data Classification and Protection. Data classification and protection deals with
how to apply security classification levels to the data either on a computer or in
transmission. This solution category also deals with data protection in terms of
providing confidentiality and integrity to data that is either at rest or in transmission.
Cryptographic solutions are the most common method that organizations use to
provide data protection.
 Identity Management. In an information network, organizations use identity
management software and processes to help manage users' digital identities and
their digital entitlements.
 Authentication, Authorization, and Access Control. Authentication usually
involves a user name and a password, but it can include additional methods to
demonstrate identity, such as a smart card, retina scan, voice recognition, or
fingerprints. Authorization focuses on determining whether someone (after they are
identified) is permitted to access requested resources. Access is granted or denied
depending on a wide variety of criteria, such as the network address of the client, the
time of day, or the browser that the person uses.
 Training. It is vital to the overall success of organizations to familiarize employees by
providing training on requirements and processes specific to security and
compliance. Training provides the critical link between people, processes, and
technologies that make security programs work.
 Physical Security. Physical security solutions secure physical access and control of
the information systems and workstations in organizations.
 Vulnerability Identification. Vulnerability identification solutions provide tools that
can help test for vulnerabilities in organizations' information systems. IT personnel
must be aware of vulnerabilities in their IT environments before they can effectively
address them.
 Monitoring and Reporting. Monitoring and reporting solutions collect and audit logs
that result from authentication and access to systems. These solutions are either
designed to collect specific information based on compliance to certain regulations,
or use existing logs built into operating systems or software packages.
A subcategory of monitoring and reporting is the collection, analysis, and correlation
of all logged data across an organization. This task is sometimes accomplished
through a dashboard-type solution, which can better analyze the various types of
information gathered throughout an organization. This type of solution allows IT
management to better determine whether events are correlated to each other.
 Disaster Recovery and Failover. If a natural or man-made disaster occurs,
information systems must return to operational states as quickly as possible. Disaster
recovery and failover are terms that relate to this category. Failover refers to
redundant systems that operate in parallel to the operational systems at all times. It is
preferable to disperse these systems geographically.
One way to provide redundancy is to implement systems that are inherently protected
from certain kinds of failure. Such systems include the multimaster Active Directory®
Domain Services (AD DS), clustered SQL Server®, and Windows Server® Network
Load Balancing and Cluster Service (MSCS) technology.
 Incident Management and Trouble-Tracking. Incident management and trouble-
tracking solutions are customized systems that manage specific business processes
Chapter 5: Microsoft Technology Solutions for Compliance Management 41
from beginning to end. The actual system functionality closely matches the Customer
Relationship Management (CRM) business application category.
The next section illustrates how each of the Microsoft Operations Framework (MOF) 4.0
life cycle phases map to specific technology solutions. You can use these mappings to
help determine the types of controls that you want to implement for your organization.
Technology Solutions for IT Control

The following table shows a consolidated view of technology solutions and their
relationship to MOF service management functions. To use this table, first find the rows
for the MOF Service Management Functions that your organization needs to address.
The check marks in the columns indicate which technology solutions can help you
address GRC objectives within each Service Management Function.
Table 5.1. Control Categories Mapped to Technology Solutions

IT Compliance Management Guide: Published: October 2008 For The Latest Information, Please See

Transféré par

Informations du document

Description originale:

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

IT Compliance Management Guide: Published: October 2008 For The Latest Information, Please See

Transféré par

Droits d'auteur :

Formats disponibles

IT Compliance Management Guide

Published: October 2008

Grant Thornton LLP Statement

Caveats and Disclaimers

authoritative documents, understand requirements, develop controls, implement

How to Use This Guide

5. Research specific technologies in "Chapter 5: Microsoft Technology Solutions for

GRC Authority Document Environment Complexity

Achieving and Maintaining Compliance

Process Visibility, Measurement, and Improvement

IT Integration and Return on Investment

Support and Feedback

Archita Dash Infosys Technologies Ltd *

Contributors and Reviewers

The Sarbanes-Oxley Act of 2002 (SOX)

Gramm-Leach-Bliley Act (GLBA)

component of the regulation requires financial institutions to establish a comprehensive

Health Insurance Portability and

European Union Data Protection Directive

AICPA Generally Accepted Privacy Principles

Generally Accepted Privacy Principles (GAPP) encapsulate requirements of sound

Payment Card Industry Data Security

ISO 27002 Code of Practice for Information

Figure 2.1. Control relationships

Additional Classification of Technical

Figure 2.2. Favorability of technical controls

network. A manual preventive control might be a system administrator review for

Why Technical Controls Are Important

Life Cycle Fundamentals

Figure 3.1. Technical controls can address many authority documents

Developing Common Technical Controls

Figure 3.2. Addressing regulations inefficiently outside of a coordinated MOF GRC

How Frameworks Benefit Organizations

 Update current GRC requirements more efficiently through controlled delivery of

Figure 3.3. A conceptual view of a control framework

A Framework for Your Organization

 American Institute of Certified Public Accountants/Canadian Institute of Chartered

Mapping Authority Documents to MOF

Microsoft Operations Authority Document Coverage

* These steps might or might not apply to specific types of audits

The following diagram shows the IT audit process.

Figure 4.1. Flow diagram of the overall IT audit process

Step 1: Plan the Audit

Figure 4.2. The IT audit planning process

Step 2: Hold Audit Kickoff Meeting

Figure 4.3. The IT audit kickoff process

Step 3: Gather Data and Test Technical

Step 4: Remediate Identified Deficiencies

Figure 4.5. Remediating deficiencies identified in the IT audit process

Step 5: Retest Controls for Remediated Risks

Step 6: Analyze and Report Findings

Figure 4.7. Analyzing and reporting findings of the IT audit process

Step 7: Respond to Findings

Figure 4.8. Responding to findings of the IT audit process

Step 8: Issue Final Report

Figure 4.9. Issuing the final IT audit report

How to Optimize the Audit Process

 Malicious Software Prevention. Malicious software prevention solutions include

Technology Solutions for IT Control

Vous aimerez peut-être aussi