A Framework for Effective Policy Development

Eric Bonnell, SVP, Risk Management, Atlantic Union Bank

Eric Bonnell, SVP, Risk Management, Atlantic Union Bank

When I think of a framework, the vision of a building’s construction comes to mind. There are no walls or floors yet, only girders and studs to form the shape and provide strength. As a framework is a repeatable concept, down the street might be yet another new construction with the same look and feel. In effect, frameworks provide structure, promote safety, and require discipline.

The word “framework,” as it applies to policy documentation, is often misused. A framework as defined by the Miriam-Webster Dictionary is: 

1. a basic conceptional structure (as of ideas)

2. a skeletal, openwork, or structural frame

The policy document itself is not the framework; the framework is the blueprint that is described within the document. Builders use the blueprint to understand how things go together and to guide the success of their new construction project. The same goes for policy, standards, and procedures. Each describes a framework that sets expectations for operational excellence. They also provide a guide to measuring success and quality through control assessments that drive the assessment of risk. 

Let me now provide a general framework for building a policy structure; think of it as a “meta-framework” for how to document frameworks. First, let’s break down each level and discuss the purpose of each level of policy documentation.

Policy

Policy documents describe the program being implemented at the highest level. The framework described in a policy is akin to the property layout map for the new building construction, along with a description of any permits needed and regulatory tasks to address (e.g., where the foundation will go, how large it will be, what building codes must be followed, and contacts to obtain building permits, inspection approvals, etc.).

“The purpose of a policy is to establish the scope, guiding principles, and highest-level requirements for your program. A policy can call out what standards the company must follow, internally and externally. It will also describe governance expectations”

The purpose of a policy is to establish the scope, guiding principles, and highest-level requirements for your program. A policy can call out what standards the company must follow, internally and externally. It will also describe governance expectations. In short, the policy describes “what will be measured.” If a sentence feels like “what or how something is done,” don’t put it in policy and keep reading.

Standard

Standards describe the functional and tactical requirements of the program. The statements in the standard should address the “what needs to be done and what does that look like” of the program. Often, the framework that a standard will describe will be broken up into operational elements or domains. For example, the framework for a regulatory standard may be broken down into requirements that address these parts of the program:

1. Scope – what is clearly included as part of the program and what is not, providing definitions where applicable.

2. Governance – what the governing body will look like, who will reside on it, how it will report organizationally, who makes decisions, what reporting and monitoring are required, and how issues escalated.

3. Actions – there may be several sections here, one for each tactical requirement. Each will describe the inputs, what will be done with those inputs, what outputs will be expected (e.g., results, exception reporting, key metrics, etc.), how the task is communicated, and how long will the process action documentation needs to be retained. The actions described in the standard must align with the principles and requirements stated within the policy.

4. Exception Handling – what is and is not tolerable as an exception and for how long based upon risk. Explain the exception process (or provide a linkage to an exception process documented elsewhere).

5. Communication – who and what needs to be communicated and for what purpose. Align this standard with any other standard or procedure that must be addressed.

The structure of each standard may vary depending on the situation or application, but basically, the document should describe what requirements need to be accounted for within the procedures you will document below. Structure your document to go through each action point clearly, logically, and sequentially.

Procedure

Procedures are the “how” of completing a scoped task. Define roles and responsibilities here and then describe the procedure step by step, being clear as to:

• what inputs are gathered

• how each input is processed

• what roles are involved in each step (using “RACI”: note who is responsible, accountable, consulted, and informed)

• what the output looks like, and where does it go next

Keep procedures simple and make sure each maps back to the critical controls in the standard documents governing it. Try to use references for items already documented so that there is a single source for each point; otherwise, you risk inconsistencies down the road as you grow and change.

Adapting Existing Frameworks

There are generic frameworks for key programs you will need to implement that are available from international standard organizations, industry-specific organizations, and regulators. These frameworks are generally technology and process agnostic and can be used as a starting place to adapt to your business. Use these to create working frameworks for your institution based on how it is organized.

How to Get Started

With this “meta-framework,” you can become an effective policy architect. You can provide clarity of purpose, expectations, and execution for each function to bring the framework to life. Here are some final tips for policy writing and style that can help you be successful:

1. Keep the documents technology and jargon agnostic to allow for changes to people, processes, and technology over time (i.e., say “the core system” instead of calling out your system/vendor).

2. Be careful of your usage of “shall” (implies no exceptions allowed), “must” (minimal exceptions might be allowed), “should” (comply whenever feasible), etc.

3. Be consistent throughout your suite of documentation so that each point has a single document source, and refer to it in the others as required.

4. Maintain a current hierarchical map of policy documentation so that you understand how it all fits together.

5. Leverage your business partners in legal, compliance, and marketing to help you produce a clear, consistent, and easy-to-read draft to present for committee approvals. 

Construction

Legal