NEW YORK (Thomson Reuters Regulatory Intelligence) - You may have got the sense from the previous two articles in this series on policy practices, management and governance that I tend not to make hard and fast rules, preferring to work with principles. For many years, I had a quotation from the poetry of William Blake posted in my office, “One law for the lion and the ox is oppression.” In other words, “Thou shalt not kill” would starve the lion. That said, the principle that all beings must be provided with the opportunity to eat can apply to all. So, we will continue to set principles here without being overly prescriptive.
With that in mind, this article on structure will not provide a singular policy template; it will offer a set of elements that are needed universally and in a section on headlines, will lay down some things that (dare I say it) simply have to be done right.
There are two primary goals: 1) Help subject-matter-experts who are not writers by trade get down a draft that can be published with little editorial pain. 2) Provide some criteria for policy managers and editors by which they can ensure consistent, competent documents.
BASIC ELEMENTS - 10 MUST-HAVES
The following are elements that all policies must have:
These are not necessarily meant to be the exact names of your sections but refer to the section “Headlines: promises and limitations” near the end of this article, if you are considering different names.
1) A descriptive title: The title of the policy is the first filter by which potential readers determine whether the document is relevant to what they need to know.
2) Key administrative information: This is not a narrative section, but a brief listing, including:
a. Date: All policies must be dated as to when they were written, updated, or substantively reviewed. This establishes the version history and lets readers know whether the document is reasonably up to date.
b. Unique identifying number: A number by which the document can be selected in a policies database and referenced by other policies. Thought needs to be given to establishing a numbering convention that can tie the document to its source.
3) Version history: This is a list of the published versions that tells readers and reviewers how it has evolved and whether changes are keeping up with changes in regulation, business practices, etc. Note, I prefer this section placed at the end of the document, not up front, so it doesn’t get in the way of the meat of the content, but “One law …”
4) Introduction: This is the first “written” section. It is a brief (emphasis on brief) statement of why the policy has been created. It is designed to set the context and motivate the reader. Remember, the mission of a policy is to inform readers of what they are supposed to do or are prohibited from doing. An extended introduction gets in the way of that mission.
A few examples: “The XYZ regulator has posted rules on ABC topic. This policy details how those regulations affect our firm and how we will implement them.” “This policy sets forth how the firm implements laws and regulations covering ABC in many jurisdictions. Violation of the laws and regulations on which this policy is based can have serious implications for the firm, and may result in civil or criminal penalties on the individuals involved.” “This policy provides detailed requirements supporting the principles of the firm’s Code of Conduct regarding XYZ.”
Note: Using the name or title of a regulation is often helpful, but regulation numbers and sections get in the way of the instructions your policy is designed to deliver. Say, “SEC regulations require that…” not “SEC 1933 ACT, Part 230; 230.140, section 2(11).” If you are compelled to include rule citations, put them in footnotes.
One last, ironic thought. This section on introductions is much longer than any introduction ought to be.
5) Relevance: This section lets readers know whether this document is meant for them. It states the activities and people to whom the policy is relevant. In short, it defines the scope of the document: Examples: “This policy relates to the handling and safe-keeping of client funds. Although it is based on a UK law, it is applicable globally”; “This policy relates to all personnel of the IT department when reviewing or revising application code of any live, client-facing application.”
6) Policy statements, primary takeaways, key points, highlights: Whatever you decide to call it, this is an essential element, and frequently the most difficult to get right. The section is designed to give the reader a quick sense of the policy’s key points. The challenge is to cover the basics without giving readers the impression that they don’t have to read the whole policy.
One way to handle this is to make a general statement and reference the details in the body of the policy: e.g., “Employees in certain job functions must have personal trading pre-approved by XYZ (see section E.2. on page 4).” That communicates the requirement for trade pre-approval but pushes readers into the policy to learn the details.
Try to keep to a handful of key points. Think of this section as a set of bullets you might prepare for senior management.
7) Exceptions: There are very few policies for which there are no exceptions. That said, in most cases there are (or should be) limitations and rules around those exceptions. The Exceptions section:
a. Describes the conditions for which exception may be granted;
b. Sets down any limitations (e.g., if the exception extends a policy deadline, there may be a limit as to how long that deadline may be extended);
c: States who has the authority to grant the exception;
d: Sets requirements for documentation of the exception.
8) Ownership: While many policies are cooperative efforts, requiring substantive input from multiple parties, there still has to be one group who owns the document, who pulls together the stakeholders, manages approvals, et al. This group must be identified to ensure proper maintenance, review and revision.
9) Questions: As clear as a given policy may be, questions can always arise. The document itself must provide a point person or contact for those questions. The contact may be an individual, a function, or a mailbox or voicemail.
If an individual is named, the name and contact must checked on a regular basis. If it is a function (e.g., “contact your compliance department”), you must be reasonably sure that the readers will know how to contact the function. If it is a mailbox or voicemail, make sure it is checked at least daily.
10) Related documents: Policies rarely stand alone. Different aspects of the topic of a policy are likely to be covered in another document; implementation may depend on a related procedure; the policy may be a local or business-specific version of an overarching policy; et al.,
The related documents section lists (and if appropriate links to) these documents. The list should not include every document that touches on a similar theme, but it should include those with substantive interdependencies – documents that are required for readers to understand and carry out the requirements of the document at hand.
After you have the up-front material – title, date, intro, relevance, key points – you dive into the body of the policy, the explanation of exactly what is expected of your readers. Here’s where headlining becomes vitally important (see the section “Headlines: promises and limitations” at the end of this article).
As you develop the body of the policy, there are a few major sections you may want to consider. Two notes on these: First, if you use these sections, place them where they most logically fit in the policy as a whole. Secondly, if you don’t need them, leave them out entirely. Don’t put in the section only to mark it “NA.”
Who are your readers? If the policy is applicable only to an expert audience, you may not need definitions. If the readership is general and special terms are needed to understand the document, definitions are appropriate.
How many terms do you need to define? If there are only two or three, consider defining them in the text when they are used, rather than providing a separate Definitions section.
Where should a Definitions section be placed? If your expected readers need these definitions to understand what you are saying in the policy, the definitions should be placed early in the document before you get into the meat of your topic. If you are not sure, or if the definitions might be needed only for an occasional reader (e.g., an audit team), put the Definitions section in the back as a reference.
How many roles are specified? As is the case with definitions, if there are just a few roles to be called out, they are best placed in text where you describe the actions: e.g., “All employees must pre-clear political contributions with compliance, who are responsible for determining whether the contribution will be allowed, and for regulatory reporting as necessary.” No need, to pull a roles and responsibilities section for just the two roles, all employees and compliance.
On the other hand, if there are multiple roles, separating a Roles and Responsibilities section can be very helpful. In some cases, the Roles and Responsibilities section will carry most of what you have to say.
The classic description of “policy” versus “procedure” is that policies say what to do; procedures say how to do it. That’s fine, but as you write policies, consider whether you have provided enough information so that readers will know, at least, how to get started doing what you want them to do. For instance, let’s go back to pre-approval of trades. Don’t just require readers to pre-approve under XYZ circumstances and stop there. Let readers know how to do it: “Write an email to your compliance officer and manager, who will be responsible to reply within 24 hours”; or “Submit your request through the ABC Request System, at URL…”
At the same time, don’t get deep into the weeds. Do not, for instance, provide line-by-line instructions on how to use the request system. That is better moved to a user manual or HELP system. Similarly, while the policy may give a high-level sense of what the approval is based on — possible conflicts, the appearance of prior knowledge about the company, et al — the details of the criteria used to determine approval are best moved to a procedure addressed to the approvers.
You may be surprised at this, but most people do not read policies for entertainment, and few will sit down with a policy and read it from beginning to end. What employees typically do is scan for the specific information or instructions they need. This makes helpful document titles and section heads particularly significant. Think of titles and headlines as search filters. If the title excludes what I am looking for, I won’t open the document. Once I open the document, the same is true for section heads. I scan the headlines for the stuff I need to know.
Another way to look at it is that headlines provide both promises (you will find this stuff here) and limitations (you won’t find what you are looking for here).
An example: Let us assume you are writing a policy on driving rules with a section on traffic lights. The title of the policy might be “Driving rules.” Now consider possible headlines for your traffic lights section:
Signals and signs: Too broad. Readers might reasonably expect information about traffic lights, but also about signs, road-side warnings, and the like. A section about traffic lights would not fulfil the promise made by the headline “Signals and signs.”
Red lights: Too narrow. You might be using this as a short-hand for all traffic lights, as in “It’s a small town with just one red light.” While that might give you certain literary satisfaction, it will undermine the effectiveness of the policy. Remember, readers will be scanning for information. If they are looking for information on all traffic lights, or for green or yellow lights, they will likely skip over this section, even though it may contain the information they seek.
Traffic lights: The correct choice, but if your headline is “Traffic lights,” make sure that you include all traffic lights. If your traffic light section covers only red or red and green, you will be frustrating you readers.
So make sure there is a proper match between your headlines and section content.
Finally, a note that maybe more about style than structure. Use bullets. If you have three related points to get across, they may fit into a single, well-constructed paragraph. But digging three points out of a paragraph is harder than spotting three bullets under a well-designed headline.
Tony (Anthony) Stein LinkedIn profile(here).
(Mr. Stein has been a leader in policy development, management and governance for more than two decades, establishing and leading the policies efforts first at Goldman Sachs, where he introduced the notion of enterprise-wide policies and helped establish and manage the regulatory change effort, and then BNY Mellon, where he built the function literally from the ground up. He is currently an independent consultant in the program management and policies space. The views expressed are his own.)
This article was produced by Thomson Reuters Regulatory Intelligence and initially posted on Aug. 29. Regulatory Intelligence provides a single source for regulatory news, analysis, rules and developments, with global coverage of more than 400 regulators and exchanges. Follow Regulatory Intelligence compliance news on Twitter: @thomsonreuters