Policies are a thorn in the side for many people, like an obstacle course strewn with potholes, blind corners, barriers, and complex or confusing signs, or a maze that’s difficult to decipher and navigate.
I’ve found that this applies equally to people who write and approve them, as well as to people who are required to understand and comply with them in the course of doing their jobs.
In this article, I’ll be sharing tips on how to impress Regulators and Auditors – not just how to survive their reviews. These tips are based on our more than 25 years in the regulatory trenches — writing, simplifying, refocusing, and correcting policies; overhauling policy frameworks, and supporting our clients with responding to audit and regulatory points that resulted from poorly written policies.
What Makes a Policy “Poorly Written?”
There are many ways in which policies are poorly written, key of which include the following.
They:
- Contain procedural steps which is the biggest and most frequent mistake when it comes to writing good policy. It’s the villain that is virtually always the cause of a poor regulatory/audit outcome.
- Are too verbose and contain extraneous narrative, trying to be more than they need to be.
- Don’t tie in with the related regulation(s). We’ve seen many policies that either generally refer to a regulation in a broad context or that are written using a shot-gun approach that encompasses multiple regulations, often without clear explanation and direction.
- Miss the key points of the regulation. Unlike extraneous narrative, this issue is a failure to hone in on the most salient drivers and purposes of a regulation. The result of this is often a summary of the reg that does not stress its focus and areas requiring compliance.
- Aren’t organized and presented intuitively, resulting in people in the Business Units (BU) not knowing specifically which policies they should be complying with. For example, one of our Mortgage Servicing industry clients had written and organized all their polices under the related regulation, e.g., RESPA policies, TILA policies, etc., the result of which was that no one knew where to look for the policies that related to their specific role or function.
- Are written using legalese, which few people without a law degree understand. (We are big fans of the plain English movement.)
- Are not connected with related policies at other levels. For example, a BU level policy is not tied in with a related Enterprise level policy, thereby causing a gap in understanding and full compliance.
- Are redundant or overlap with other policies causing maintenance issues that may lead to some policies being updated and others not – which, in turn, potentially exposes the firm to significant risks, as well as challenges with compliance.
Tips for Making a Great Impression
So, how to impress the regulators and auditors? Do the opposite of the above! Below, I tie in the missteps in policy writing with suggestions for improvement.
Policies Should ONLY Contain Governing Statements
When writing a policy, clearly and concisely (and using plain English) state what the responsible department or party will do to comply with the relevant provisions of the related regulation.
We recommend using the word “will” (not the antiquated “shall”) instead of “should” or any other language that implies instruction or wiggle room. A good test to determine if you were successful in leaving out procedural steps is to see if there are any sentences or sections in the policy that answer the question “How?” If there are, take them out or rewrite them from a “governing statement” point of view.
Why this is so important: When your firm is audited, the person performing the regulatory review or audit will test to ensure compliance with everything that is stated in your policy. Often, procedures are best practices that typically have some leeway. Policy clauses never do.
Limit the Narrative / Focus the Policy
There should be nothing extraneous in the policy. From our experience, a strong policy contains the following:
- Header: It is good policy for your firm to require that all policies contain their Effective Date, Approval Date, Last Review Date, Next Review Date, and Applicable Law(s)/Regulation(s). This type of information is almost uniformly required by regulators and auditors. We recommend implementing a best practice to review your policies annually (and update the dates accordingly whether or not changes are made).
- Background/Rationale for the Policy: This should be a brief explanation of the purpose of the policy so that your management and staff have a clear understanding of why it’s important to comply with the policy (other than that it’s required by a reg).
- Policy Requirements: This is where your governing statements come in. Often within a policy, there are various discrete requirements. They should be broken out as concisely and as targeted as possible. For example, if a policy is written for a specific function, there will be multiple areas of responsibilities within that function. The policy should, therefore, be granular enough so that people performing the different roles clearly understand what’s expected of them. Some policy clauses may also contain a related control.
- Responsible Party(ies): Indicate the position(s)/role(s) responsible for performing the tasks or oversight related to compliance with the policy.
- Related Polices: If there are related policies either within other functional areas or at the enterprise level, for example, link to them so that all related information is interconnected.
- Related Procedures: Connecting a policy with its related procedures (and vice versa) is an excellent way for your management and staff to understand the connection between what they are doing and what is important and required from a compliance point of view.
- Revision History: Maintain a high-level list of edits made between annual Effective Dates, along with the date and author of each. This provides an important audit trail.
Make Sure Your Polices are Easily Accessible
Accessibility doesn’t necessarily just mean ensuring your policies are stored on your intranet site in a folder called “Policies.” Management and staff in each BU need to know which policies are applicable to their functions and roles, as well as where and how they are stored.
For example, building upon the problem mentioned earlier regarding organizing policies by regulation: If this is the way in which your firm wrote the company’s policies, that’s fine. However, be sure that employees know which regulations and which policy clauses within those regulations specifically apply to them. We addressed this on behalf of our client by creating a table that granularly cross-referenced and linked functional roles to policy clauses.
The Bottom Line
While there is not necessarily a “best” way to structure your policies (for example, by regulation, organizational structure, or functional departments and roles), we are confident that the tips above will help ease the pain of a regulatory review – and may even leave the regulators and auditors smiling.
If you’d like more information or a free high-level evaluation of your policies or framework, get in touch by completing the form below or giving us a call.
