Information architecture is an important step while implementing a policy management software or a compliance software.However, this step is often ignored and people realise the lack of information architecture when they face difficulty to locate information.The objective of this discussion is to introduce the usage of information architecture planning for projects on policy management and compliance monitoring. This is applicable while implementing quality management systems also.

Introduction

While discussing about policies and procedures, a senior Compliance Officer of a major corporation told me that if it is not documented, it does not exist. Policy management is the cornerstone of an organisation with good governance and risk management.

In addition, policy management is an important part of an organisation’s compliance monitoring programme. The main objective of implementing a policy management software is to increase management visibility. During the development of Compliance Track compliance software we therefore built policy management software as a basic component.

Businesses operate in an environment with regulatory and self-imposed constraints and the goal is to deliver shareholder returns by working within these constraints. These constraints or controls are documented and communicated using policies and procedures. Policy management provides an organisation with a control framework for its operations.

The need for Information Architecture

Organising policy management or compliance monitoring functionality and the related content into a structure that people are able to navigate easily needs good planning. Good information architecture can avoid the problem of ‘finding.'

The challenge is multiplied compared to other situations as the data is predominantly available in an unstructured manner. For example, consider the situation of an insurance claim. A claims specialist should identify the claim against the policy or a specific clause of the policy, and then move the claim according to the next step in the workflow according to a defined procedure or a clause in the specific claims procedure. At a later stage, the audit or the compliance team should be able to trace each of these and should be able to report based on specific industry rules, company policies and resulting actions. If there are weaknesses in the system, the identified control weaknesses should be trigger points to review and update policies and procedures.

The most common problem with information architecture of a system for policy management or a compliance monitoring is that they blindly follow a company’s organisational structure. However, different users have different needs while analysing data. For example, a compliance manager or the regulator wants to organise and see the system from the point of view of mitigating compliance risk. Therefore, he may tend to categorise the policies according to the regulations while implementing a policy management software. A process owner need to look from a process point of view and the board may be happy with a document hierarchy planning similar to the organisational structure. Therefore, to cater to all types of users, one needs to consider information architecture seriously and answer questions related to often-confused terms like taxonomy, metadata, category etc.

Policy management – Types of Documents

The term ‘policy’ in policy management refers to various document types. One type of classification is the hierarchical arrangement of these documents (hierarchical taxonomy).We could consider these documents in various tiers. Tier 1 is the high-level document depicting the ‘intention’ of the organisation (compliance or policy manual). Tier 2 is more detailed and shows ‘how the intention’ is implemented in practise (procedure manual). Depending on the type of industry, there could be Tier 3, Tier 4 etc type of documents (sub-procedures, work instruction etc). Now, let us consider the types of documents in policy management in the context of implementing a policy management software or developing a compliance monitoring programme.

Compliance Manual a.k.a Policy Manual

The term compliance manual refers to a collection of policy documents relating to the regulatory constraints within which the company operates. The compliance manual is the organisation’s starting point in the Compliance Lifecycle. Compliance Lifecycle denotes the end-to-end compliance between the regulator and the firm.

The compliance manual is a statement by the company, telling the regulator, its own staff and other stakeholders that it undertakes to comply with the rules of the regulator. The policy documents in the compliance manual are of high-level nature and these documents are Tier 1 in classification.

For example, for an FSA regulated company in the UK, the compliance manual may contain policies under COBS (Conduct of Business), TCF (Treating Customers Fairly) etc and their applicability in each business area. Briefly, the compliance manual will show “Which” of the regulator rules are considered by the organisation to comply and “Where” (business area/process).

The compliance manual should state who is the firm’s Compliance Officer, MLRO(Money Laundering Reporting Officer), other officers and approved persons are, along with contact details for selected individuals. Ideally, the Compliance manual should reference the related procedures manual for more detailed information on how it is implemented in a process.

Procedure Manual a.k.a SOP

Business Process Mapping is not a term usually talked alongside a discussion of compliance monitoring programme or policy management software implementation. Documenting a process often opens up opportunities for improvement in efficiency. Visual business process maps are good tools to train employees. The process map is a good starting point for creating a procedure manual.

A procedure manual is a guide that defines detailed procedures in a specific business process. It will identify who will carry out the procedure, what actions will be taken on breaches or failure and how to rectify errors. The procedure manual should tell ‘How’ the firm would comply with the regulator rules as outlined in the Compliance Manual and are Tier 2 in the classification.

Sub-procedures, Work Instructions etc

These are the other types of documents in the context of a policy management. These types of documents are common for a compliance manager from the manufacturing industry. These documents are Tier 3, Tier 4 etc in classification.

Forms, training material, Compliance Tests, Reports etc

These documents have a contextual hierarchy. For example, the training material for a policy document is associated with the specific policy document. Similarly, a form is associated with the context of another document. When we define a compliance or audit test, it is associated with the context in which the parameters are specified.

Visual Mapping as an approach for policy management

If we consider the user’s context of making sense of unstructured data, he uses a visual approach by looking at similar documents and comparing related content. What if, this approach is available during the creation and deployment of such data. Alternatively, what if the existing unstructured data can be visually mapped to other related structures of data.

Let us consider an example of a typical policy management software implementation. Consider the rules applicable to the firm are available in a visual map. One can then map the policy documents and its specific clauses to the right set of rules. This can immediately give value by showing the gap areas related to compliance risk. Now, one can easily map the specific clauses to the right set of defined controls and the risks it mitigates and the right set of compliance tests audit tests. Policy compliance test results are then easily available to report according to the compliance life cycle.

Conclusion

Today, the challenge is not about not having enough policy management software vendors or compliance management software vendors. The challenge is to get an immediate grasp of risks facing the organisation and its transparency to the right stakeholders. Creating value from investment in a compliance function depends on this real time visibility factor for the right actions by the right people in the right time. For attaining such a goal, projects on policy management software implementation should consider information architecture seriously

Read on Policy Management functionality of Compliance Track Policy Management Software

About the Author and the background for this blog

John Cyriac is the CEO of the Compliance Software as a Service company Compliance Track.

The views expressed in this article are based on his interviews with various compliance managers across the industry and across the globe.

Please visit Policy Management Software to see how the concept of information architecture is implemented.