The Policy Lifecycle August 18, 2009 By Sumner Blount Director, GRC Programs CA, Inc.

Governance, Risk, Compliance (GRC) is a hot topic these days.

But, ignoring all the buzz about this topic, how is it really manifested on a day-to-day basis for a typical large company? The governance of risk and compliance should be an ongoing, continuous process comprised of the following general responsibilities:

• Identify the business requirements
• Determine corporate policies that will help the company meet these requirements
• Establish controls in order to ensure compliance with these policies
• Monitor compliance and remediate when necessary

Each of these steps is iterative, and the whole process involves feedback mechanisms to continually improve the overall effectiveness and efficiency of the corporation. But, the underpinning of all these areas is a strong and comprehensive framework for the management and enforcement of corporate policies. Let's consider each of these areas in order to see how they interact, and contribute to this policy framework.

Determining Business Requirements
First, any company has a set of business objectives that they have established to ensure the viability and growth of the enterprise. These are determined by the Board and executive management, and are communicated downwards into the organization. These objectives reflect the overall mission statement of the corporation, and are used to guide or direct employee behavior and decisions towards meeting these objectives.

Second, corporations must meet the regulatory requirements mandated by the government or by their industry. In some cases, these requirements have the force of law (SOX), and in some cases they only have market forces that will serve to encourage compliance (PCI). But, in many cases, these distinctions are arbitrary and not relevant to the compliance decisions made by upper management.

The third area of requirements can come from enterprise risk. These include risks across all areas, the major ones being financial risks, operational risks, IT risks, market risks, and external risks. As risks are identified and assessed, policies can be created to attempt to control the negative aspects of those risks, or to prudently manage any risks related to new business opportunities.

Policy Management
In order to meet these needs, companies create and enforce policies. A policy is a statement that embodies the goals and behavior norms that the company wants to instill in its employees and business partners. Policies are not immutable. They can change as new regulatory requirements arrive, as the business goals of the company change, or as the corporate risk tolerance level changes.

In theory, all policies should be followed and there should be some sort of remediation action prescribed for non-compliance with a given policy. In reality, though, all policies are not created alike. The policy that prohibits employees from bribing governmental officials is likely to get much more importance and enforcement (hopefully!) than a policy that is less critical to the successful operation of the business.

In general, regulatory requirements turn directly into policies based on the requirements of that regulation. If, for example, a company decides that it needs to comply with a given governmental or industry regulation, a set of corporate policies are created (even if the policy is simply "We will comply with this requirement") that will define what level of compliance is required. However, in limited cases, a policy may intentionally exclude certain regulatory requirements if a conscious decision is made to not conform to those requirements. This generally rare case would occur, for example, if the penalty of non-compliance with a given requirement is lower than the cost of compliance.

The following graphic illustrates the policy lifecycle:

Management of corporate policies is a major and important element of governance. It needs to be much more than simply creating a document, sending it out to all employees, and then filing it away in a file cabinet. Policy management includes a series of key steps, with feedback loops, intended to ensure that policies are well-communicated, fully understood by the target audience, and enforced.

When approved, there should be a formal process defined for management of the actual policy document. This requires a central repository, document versioning, edit histories, and similar basic capabilities. Once published, awareness campaigns generally help ensure that all target users are aware of what the policy requires them to do, or not do. Awareness campaigns typically include an automated process of self-attestation so that management can track who has read the policy and agrees to abide by it. Finally, policy testing is often used to ensure that despite their self-attestation, users actually understand the policy, and how it relates to them.

Controls
In order to enforce its policies, an enterprise must translate them into a series of control objectives. These are statements of results that need to be achieved in order to enforce the policies. Control Objectives are often non-specific, in that they describe the ultimate goal, but do not define the actual mechanisms or processes (controls) that are required to achieve the goal.

These control objectives will, in turn, be implemented by a set of controls to ensure that these objectives are met. Controls are simply technology, procedures, or a combination of the two that are intended to ensure the correct operation of internal business processes. Controls can generally be categorized as one of the following:

• Preventative: A preventative control stops a risk from occurring.
• Detective: A detective control identifies a problem when it occurs and communicates it to management. For example, a control might determine that the wrong password was entered three times and either lock the user out for a period of time, or notify the Administrator, or both.
• Corrective: A corrective control attempts to rectify a problem once the problem is detected. For example, a control might search for accounts that were associated with terminated employees, and automatically remove those accounts.

Controls can be manual, automated, or a combination of the two. Anytime a paper form or a signature is involved, then the control is at least partly manual. In general, automation of controls is desirable for three reasons. First, it ensures consistency and reduces the risk of human error. Secondly, automated controls tend to be more auditable than manual controls because there is more likely to be "proof of compliance" available through event logs, audit trails, or the like. And finally, the control becomes much more scalable as the number of controls or users increases over time. For example, if the removal of accounts for a departed employee requires multiple administrators to physically go to multiple systems and manually remove those accounts, it will be time-consuming and error-prone, especially during times of high turnover. If an automated de-provisioning system is deployed, this process can be done with a few keystrokes by the System Admin. Much simpler...less time-consuming...more secure...and less error-prone.

These controls must be created, monitored, and tested, with the test results reported to upper management to ensure effective oversight. Controls are generally tested by a specific testing group, or possibly by the IT Compliance team. In many cases, the testing of a given set of controls is initiated by a compliance audit for a specific regulation. For example, an annual SOX audit may trigger testing of those controls that impact SOX compliance. A subsequent PCI audit may have the same effect, possibly resulting in the redundant testing of those controls that relate both to SOX and PCI. This redundant testing of controls is caused by compliance silos - a lack of a centralized repository where all information about controls and their status is kept. It is a very common and problematic aspect of many compliance efforts.

When a control fails, a remediation process is initiated in order to make the control match the requirements of the corporate policy. This remediation process may be very simple and straightforward, or in some cases could require a substantial IT project to correct them. This might involve assigning engineers to design, test, and document a fix, as well as supporting personnel.

Failed controls also impact the risk profile of the associated policy, and this risk needs to be communicated back to the policy owner, so that it can be effectively mitigated. This is a common problem in many organizations that don't have a centralized repository of risk and compliance controls information. Using an example similar to the one above, let's assume that a given control is used for both PCI and SOX compliance. During the annual SOX audit, the control is tested and the error rate is determined to be higher than allowed by the associated policy. This control failure impacts PCI compliance, possibly to an unacceptable level. But, without a mechanism to communicate this information, or at least a central place where it is stored, the owner of the PCI compliance program now has an emerging risk that he is unaware of.

Putting it all together
Understanding policies and controls is a critical success factor for any company embarking on a GRC program. They represent the foundation for a comprehensive approach to GRC - and facilitate the ability to truly govern risk and compliance programs across the enterprise. Policies and controls can't just be created and never touched again - companies must consider a policy management platform that supports a continuous process of policy lifecycle management.

In this three-part series, the goal was to tackle three pillars of critical importance to deploying GRC programs. The first installment dealt with the common problem of information silos in risk management and compliance - also a critical hurdle to overcome. The next installment will focus on some key risk management concepts, and highlight the importance of a common risk management framework across the organization.