November 27, 2018 / 12:48 AM / 3 months ago

Putting policies in place: Policy systems – preparing the place for your policies (4/5)

NEW YORK(Thomson Reuters Regulatory Intelligence) - About 2,400 years ago Archimedes, the Greek scientist and mathematician, posited, “Give me a lever long enough and a place to stand, and I can move the earth.”

A boy looks at the "Craftweak" exhibit by Taiwan artist Yeh Ting-hao during the "Funky Light" 4th Digital Art Festival in Taipei November 8, 2009. REUTERS/Nicky Loh (TAIWAN SOCIETY)

Archimedes was talking about physical levers, but the same is true of communications. To move people, you need a lever – motivation – and a place to stand – an effective platform from which to communicate. In the context of policies, the lever is the consequence of ignoring policy directives; the place to stand is the system that houses and distributes them.

To extend the metaphor for just a moment, your policies system is the solid ground from which you launch policies into your corporate space, and it provides the foundation on which policy management stands and from which the enterprise, as a whole, is governed.

With that said, we will look at the requirements for a solid policies system. The focus is on a basic system, not on broader governance, risk, and compliance (GRC) and related capabilities. What is listed here are the have-to-haves learned through (sometimes painful) experience.

I will offer more extensive comments about many of the elements mentioned here in a forthcoming article on managing the policy function.

One more note: Because I am lazy, and am trying to cut down on length, I refer to “policies” and “documents,” but for this read “policies, procedures, and related documents”. (You probably do not want to read all of that time after time anyway.)


The data elements (fields) attached to policy documents are key to both displaying and managing your firm’s policies. The following data elements are necessary for a competent policy system.

-Labelling/naming/numbering/unique identifiers

Unique identifier: Every document in the repository must have a unique identifier, a number or combination of letters and numbers that will identify/point to that document throughout its lifecycle. The unique identifier must stay the same when a policy is replaced by a new version.

Naming convention: To the extent possible establish a naming convention, a standard for the way documents are displayed in the system that will make some sense to your policy writers, readers and owners. Consider including:

-The type of document: policy, procedure, form, et al.

-The applicability: firm-wide; geographic region and/or business or function.

-Description of the actual content.

Divorce the unique identifier from the naming convention. The name can change but the unique identifier must remain constant.

The URLs, the link to the current published document, must not break when a new version is published.


To whom the policy applies, e.g., businesses, jurisdictions, roles.


Policy owner: The name of the one person who is responsible for the document, for gathering the input, moving the document through its process, and ensuring the document is reviewed on schedule.

Owner’s manager: The name of the person you can go to if things are falling behind or who can replace the owner if necessary.

Approvers: The person(s) or committee(s) who have approved the published document. You will be asked!

Publisher: The business or functional group with primary interest in and responsibility for the document

Note: In large, complex organisations, you may need a policy manager layer aligned with each publisher to be the primary liaison between the global policy manager and the individual policy owners.


The individuals who have contributed to the policy along the way. This will help when it is time for revisions, especially if the owner is no longer available.


Review cycle: The maximum time allowed between publication and review. The system should be able to set defaults, but “by-hand” setting or override must be convenient.

Due date: The date of the next review date. This may be based on a formula – the last publication date + the review cycle – or set based on a project for the policy.


Policies frequently establish dependency relationships, e.g., an enterprise-wide policy may spawn a small library of implementing procedures or versions with additional jurisdictional requirements. The system must:

-Identify parent/child relationships.

-Identify owners of child policies, so they can be alerted when parents are changed.

-Allow the managers of the policy system to view these relationships in both directions (look up the parent of a child or all the children of a parent).


Not all documents tie back neatly to a specific regulation. That said, it is useful to have this field available if you have the information.


-The time that retired policies must be kept. The retention period starts when a document is archived (replaced or retired).

-Policies must be dated with their archiving date.

-All data applicable to the policy when it is archived must be archived with the policy.

-The system must purge documents at the end of their retention period. The purging function must have an override for cases where policies must be held for litigation or other legal or regulatory issues.


The history of all published versions. All published versions must be tracked and maintained. You do not need (or want) all the drafts created, reviewed and edited leading up to publication.


The single most important role of the system is to make policies available to employees. It is critical, therefore, to design and build an intuitive interface that makes it easy for users to find the policies they need.


The display of policies: The page or pages on the system user interface where each document appears, the grouping of the documents and the menuing are all driven by the system. The system must have the flexibility to accommodate the organisation you and your users want. Work closely with your stakeholders when you build this organization, and keep in mind that:

-The system must be able to organise and display the policies according to the applicability and/or ownership of the policies.

-The organisation/menuing system will be used both by people working on the documents and by readers who like to browse through/click their way to the documents they want.

-Assume that the organisation will change over time. Make sure that the system allows you to change the organisation without undue pain. (See “Bulk update”, below.)


While some people like to browse, others prefer to use a search function. A few features will be helpful:

-Filters: Searches limited to specific menu categories established for the interface or using filters based on key administrative data, e.g., publication date, author or owning business or function.

-Weighting: Factors that will elevate a search return toward the top of the list, e.g., search words that appear in titles, special search words or phrases that the authors can predict will be particularly important.

-Thesaurus: Words related to the search terms: e.g., user inputs “personal trading”, system returns a document on “employee trading”; also related word forms, e.g., user enters “authorise”, system returns documents containing “authorisation, authorising, authorised”.

-Key word display in context: Show the search word or phrase as it appears in each document that the search returns.


The following are key administrative and application management capabilities:


Permission (who can do what in the system) must be assigned, tracked and carefully managed. Permissions include:


-upload and/or edit drafts;

-publish to the general population;

-approve new or revised policies;

-revise or retire;

-change attached data;

-make simultaneous changes to multiple policies.


-change system display and/or categorisation;

-restrict read access;

-assign permissions;

-read and/or modify reports.

While you do not want to over-complicate, consider the number of levels of permission required for the way you are managing and protecting your documents.


The system must be able to store multiple common document formats, e.g., Word, PDF, PowerPoint, email, spreadsheets, Visio and similar workflow and org-chart formats.


Big … and bigger. Keep in mind that the system must have the capability to store not only today’s policies, but also every published version (along with attached data) for as long as your firm, regulators and lawyers require.

Include capacity for the system audit trail in the space calculation.


Most policies are meant to be available to all employees, but the system must be capable of restricting access to those few documents (e.g., HR disciplinary policies and audit procedures) that must have restricted access.


Corporate structures change. People come and go or switch responsibilities. Products evolve. Any of these changes may have to be reflected in the data surrounding multiple policies. The system must have a way (well-guarded and narrowly permissioned) to make the same change to multiple documents at once.


Every action in the system, including the date and the person who took that action, must be recorded in an audit trail. As noted above, space for the audit trail must be accounted for in the technical requirements.


Policy systems are not usually considered critical from an operational, business-continuity point of view. That is, if there is a major failure, it is OK if it takes several days for the policy system to recover, but the system and its content must be recoverable. It is essential, therefore, to have operational back-up for both the system and the data.


Workflow: The capability of the system to track and facilitate the progress of a process — edits, approvals, et al — is a topic all by itself. For the purposes of this article, we can say that workflow is a nice-to-have, not a hard requirement.


Assuming you are starting from scratch, one of the most important decisions is whether to have the system built internally or to buy a vendor’s solution. Some thoughts:


-Does your company have the in-house capability to build and maintain the system?

-If the system will be built as an add-on to, or extension of, an existing system, what are the limitations of that existing system?

-What are the cash costs involved with an internal build, e.g., additional software licences, hardware requirements and upgrades, temporary programming staff during the build?

-Can you get long-term support? You may get an internal project approved for building your system, but what about version 2.0? And what about ongoing technical support? You do not want to have to battle for support at the outset of each budget season.

-What will be the cost of user support?


Besides the capabilities of the vendors’ systems, consider:

-Costs: Licences per seat; tailoring of the software; configuration and migration of your data; expansion of internal systems necessary to interface with the vendor’s product, et al.

-Responsiveness of the vendor: Vendors compete for your business and, therefore, keep improving their products, but will the improvements for the marketplace in general be helpful to you? Will you be able to get your issues and enhancements attended to without undue expense?

-How is the financial health of the vendor? Will the vendor be around for the long haul?

-Where will your data be stored? I have always maintained that while the system may be outsourced, the data must be maintained in-house. Externally stored data brings up a number of additional issues, e.g., How secure will the data be? How portable if you decide to change vendors? What if the vendor goes under or is bought by a competitor?

-What is the cost of making the vendor selection? It is easy to ignore how much time and effort is needed to make a selection and to vet the winner.


No matter the system, it is essential that the data be portable. The need to access the policies themselves and all the data around them (applicability, ownership, approvals, review history, et al) will likely to outlast the life of the system in which the data resides. That data must be accessible in the next system.


Whatever system you settle on, keep two things in mind:


Include not only the technical system testing (does it work the way it is supposed to?), but also user testing (does it function the way users want and expect?).

Leave time and budget for correcting issues that come up during testing.


Plan time for moving all current documents into the system, including as much data connected with the current and past versions as you and the document owners can collect.

Test the migration process with a pilot set of documents.

During migration, set a freeze on any changes to the documents you are migrating on a group-by-group basis.

Do not assume that migration will go without any glitches. Your project plans should include time for corrections during migration.


To manage the policies you have to know their current status, the next actions required, when that action is scheduled to take place and who is responsible. The system must therefore be able to provide reports on the following:

-The universe: A report that dumps out everything in the database in a format or tool that you can manipulate: filter, search, sort, graph, et al.

-Individual policy profiles: All the data attached to any given policy.

-Review date: What is coming up, what is overdue and how long.

-Ownership: The individual and his/her manager; the business unit or function.



-Dependencies: Child/parent relationships in both directions.

-Retired policies.

-Histories: The dates of all published versions.

-Policies by data element: The ability to list all policies that have common data elements.

-Regulator/regulation (if available).

-Permissions: Who can do what in the system.

-Aggregation at different levels: The flexibility to show data at the 30,000 feet (10,000 metres) level down to the weeds: aggregate reporting across the entire database, down to individual categories or sub-categories.

-Flexibility: The ability to generate the data and view that you forgot you were going to need, or that audit or senior management suddenly wanted to see.

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 Sept. 19. 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

0 : 0
  • narrow-browser-and-phone
  • medium-browser-and-portrait-tablet
  • landscape-tablet
  • medium-wide-browser
  • wide-browser-and-larger
  • medium-browser-and-landscape-tablet
  • medium-wide-browser-and-larger
  • above-phone
  • portrait-tablet-and-above
  • above-portrait-tablet
  • landscape-tablet-and-above
  • landscape-tablet-and-medium-wide-browser
  • portrait-tablet-and-below
  • landscape-tablet-and-below