Governance consists of the actions taken to address the risks identified during the risk assessment. Governance occurs when both automated and manual policies, methods, tasks, practices, systems, and training are put into place to mitigate identified risks. To enact governance, organizations design controls that include control objectives and activities.

The following activities are examples of how to apply governance to protect sensitive data:

• Create policies that describe proper handling of sensitive data.
  
  
• Train employees on data handling policies.
  
  
• Apply policies to systems that store sensitive data.
  
  
• Monitor and log handling of sensitive data to ensure that policies are followed.
  
  

Risk management is a program to mitigate or remove risks. It starts with an assessment of each area of an organization to determine where risks may exist. Each department, such as security, operations, sales, and development, can perform its own risk assessments. To begin with, organizations should work with a compliance auditor to perform a risk assessment of their organization. After risks are identified, they should be prioritized, and an action plan should be put into place that is based on those priorities.

A risk action plan should consider techniques to manage risk that fall into one or more of the following categories:

The risk management plan should prioritize each risk and then determine how each risk will be addressed: Should the risk be ignored, mitigated, or avoided?

Organizations are often concerned with risks that may be addressed through aspects of information technology management, including data input, data output and data access management. The following types of risks often concern business organizations:

• Compliance risks. Risks that the organization may incur by not adhering to appropriate statues and regulations.
  
  
• Operational or transaction risks. Risks that the organization may incur that are associated with the delivery of products and services.
  
  
• Litigation risks. Risks associated with real or threatened litigation.
  
  
• Reputation risks. Risks associated with financial loss as a result of damage to an organization’s reputation.
  
  

The following are examples of how to address the risk involved with storing credit card information for each of the risk plan techniques:

• Avoidance. Don’t collect credit card information.
  
  
• Reduction. Mitigate the risk by improving protection of credit card information.
  
  
• Sharing. Outsource part of the risk by obtaining a qualified vendor to handle the credit card information.
  
  
• Retention. Ignore the risk and do not improve protection of credit card data. Instead, choose to accept losses if the credit card information is compromised.
  
  

Compliance is the validation that identified risks are being mitigated (lowered or lessened) through operational tasks that are also called controls. The following are examples of how risk mitigation can be validated:

• For each identified risk, is there a policy in place for avoiding or mitigating the risk?
  
  
• Have the appropriate people been informed of the policies?
  
  
• Have the policies been deployed via processes, software, or IT controls?
  
  
• Are policies being monitored to ensure compliance, and when breaches in policy occur are they quickly remediated?
  
  

For true compliance, each step must be verifiable by an auditor. Such verification is often achieved through audit reports, event logs, video tapes, and version history.

The following are examples of how to verify compliance:

• Show that policies have been developed to address identified risks.
  
  
• Show that policies have been deployed where appropriate.
  
  
• Prove that policies have been in place and followed during the enforcement period.
  
  

For this evaluation guide you will implement an IT GRC management program (or compliance program) for a fictitious company, Contoso. To obtain the full benefit of the evaluation guide, familiarize yourself with the following terminology and taxonomy:

• Compliance program. Within GRC, a logical grouping of managed entities, IT controls, risks, and policies created to manage compliance efforts for a particular authority document. IT GRC programs:
  
  
  • Define a collection of risks, control objectives, control activities, and compliance results. These collections allow the IT GRC program manager to manage the risks and controls specifically for a program.
    
    
  • Define user roles and rights by establishing user permissions in the program. This approach allows delegation of tasks based on user roles within the program, and prohibits unauthorized review of control status within the program.
    
    
  • Are used to manage compliance efforts for a particular scope. Program scope is the managed resources defined within a program (for example, servers, clients, services, and administrators.)
    
    
• Internal control. An accounting or system procedure designed to promote efficiency, or assure the implementation of a policy, or safeguard assets or avoid fraud and error.
  
  
• Authority document. The primary source of requirements, including regulations, standards, and policies; these documents are referenced within GRC. Authority documents are often produced by government regulating bodies, industry groups that create guidelines that meet regulating body expectations, and industry groups that create guidelines and standards in an effort to self-regulate companies that operate within the industry.
  GRC authority documents contain expectations as written by an authority, such as a government entity, a standards body, or an organization’s written policy. A GRC authority document may contain risk mitigation requirements that stipulate specific or generalized configuration, operation, or other service parameters that apply to an organization, its personnel, its business processes, and its technologies.
  Many types of authority documents exist, including the following examples:
  
  
  • Sarbanes Oxley Act of 2002 (SOX). SOX is a law that requires enhanced corporate responsibility and disclosures; it is enforced by the Security and Exchange Commission (SEC) and related bodies. The SEC enforces laws that regulate investor information with regard to securities information for publicly traded companies. Laws such as the Securities Act of 1933 require publicly traded companies to produce and distribute financial statements. Financial statements are produced in accordance with industry standards, including Generally Accepted Accounting Principles (GAAP).
    
    
  • Payment Card Industry (PCI). Created by the Payment Card Industry Security Standards Council to enhance and regulate payment card data security. Payment cards are issued by companies such as Visa and MasterCard. PCI is an industry self-regulating standard by which organizations that process credit card transactions must adhere to internal control frameworks and specifications to ensure safe handling of cardholder information.
    
    
  • Health Insurance Portability and Accountability Act (HIPAA). A law enacted by Congress in 1996 that protects workers health insurance coverage. This law also establishes national standards for electronic transactions processed by healthcare providers (including doctors and hospitals), insurance plans, and employers. The standards address the security and privacy of health data.
    
    
• Framework. Within a program, a framework is a way of classifying, grouping, and displaying controls.
  
  
• Risk. A specific, unrealized, but potential harm that could adversely affect an organization’s business objectives. As a result of risk, an organization might incur costs or might fail to attain a potential benefit. Risk is measured in terms of impact and probability. Risks may be associated with control objectives, control activities, or other risks.
  
  
• Control objective. A description of the specific results that should be achieved to manage risks identified through the risk assessment. An objective is a description of the desired state. The control objective can be identified as a harmonized statement of authority document requirements that must be achieved.
  
  
• Control activity. A task performed with the clear intention of satisfying a desired control objective. It often takes the form of prescriptive guidance that details the required implementation needed to satisfy an objective on a specific platform.
  
  
• Automated control activity. Automated control activities use Microsoft System Center Configuration Manager to validate configuration settings against predefined baselines. The results from Configuration Manager (and any threshold defined in the program or in the control activity form) are used to determine the control activity’s compliance.
  
  
• Manual control activity. Manual control activities require users to manually assert the result of the activity. An individual will use forms and screens to manually enter the activity information into the program.
  
  
• Control categories. Control objectives and control activities that affect similar information technology operations and are grouped together to clearly manage the control environment.
  
  
• Control sub-categories. A lower level of category (grouping of individual control objectives) that helps organize the information in a meaningful way.
  The following are examples of control categories and objectives:
  
  
  • Control category. Identity and access management
    
    
  • Control sub-category. Access management
    
    
  • Control objective. Security requires a complex password
    
    
  • Control activity. Password complexity is configured to require all users to include alpha and numeric characters.
    
    
• Control test automation. The Process Pack for IT GRC uses the Desired Configuration Management feature in Configuration Manager along with supplied product-specific baselines to enable control test automation. The Configuration Manager connector in Service Manager 2012 populates the Service Manager data warehouse database with control test results, which are processed for validation against compliance objectives.
  
  
• Threshold. The minimum percentage of applicable managed entities in the program scope that must be compliant for a control activity to be considered compliant.
  
  

Within any organization there are individuals who manage GRC-specific programs, information, and distribution of information. In creating an IT GRC program, you should be aware of the human resources (roles) that support the IT GRC program.

GRC-specific information is used to support business operations as well as internal and external audits. Most of the information captured is confidential and may be used for internal and external reporting. With the Process Pack for IT GRC, role–based access is configured to include the basic roles for individuals within an organization who define and work with an IT GRC program.

After you create an IT GRC management program, configure the control objectives for the program, and configure the control activities for the program you can create a compliance program readiness review. A program readiness review helps the compliance program manager to ensure that all of the control objectives and control activities in the program are ready for an audit or management review. You can perform the readiness review on one or more control objectives in a program or for the entire program using the Start Readiness Review wizard.

The program readiness review is created using the following table and instructions.

To perform a program readiness review of an existing program using the Start Readiness Review wizard

The work item created by the wizard is visible in the Work Items/Activity Management/Manual Activities/All Activities location. For more information about the work items in System Center Service Manager, see the topic "Managing Activities and Changes" in the System Center Service Manager Help, which is included with System Center Service Manager.