The issue for an organisation is how to conform to these rules? This is the key objective of a compliance function. This blog provides an overview of one of the elements that need to be considered when building an optimal compliance function.
Before we can consider conforming to a rule, we need to comprehend what the rules are and what they mean. For external compliance, this necessitates having an understanding of relevant laws and regulations and how they apply to our organisation. This is typically achieved through an Obligations Register that contains information such as:
However, these Obligation Registers are often driven from the legislation and regulations with limited linkage to internal policies and procedures or day to day activities. Damage is done to the Compliance team by them, asking a raft of ‘compliance attestation’ questions to the business that merely ask “Are you compliant with this legislation”, with no value add as to what it means to the organisation in practice.
An alternative approach is to consider starting with what are the key obligations the organisation faces and then link that to both Legislation and Internal Policy and Procedures: For example, if Protection of Customer Data is the obligation, what does this practically mean for our staff in terms of their day to day activities.
We then link this interpretation to the various sources of our rules – Privacy legislation, PCI DSS, ISO 27000, Internal Policies and Procedures and so on. If we are unable to link all key components of the legislation to our plain English interpretations – then we have missed an obligation.
Any update to linked legislation, or policy and procedures can then trigger a review of the plain English obligation. Our approach to the Obligations register, therefore, is to add two new fields to the above list: Obligation Title, Our Interpretation.The other fields are modified to store multiple acts and sections along with an additional field to link to relevant policies and procedures.
Updates to the Obligations register may be maintained internally which will require dedicated compliance or legal staff to remain aware of all relevant obligations and process them into the obligations content.
Alternatively, obligation updates may be automatically processed through a subscription service with a content provider. Protecht is currently working with LexisNexis to deliver industry specific content in Protecht.ERM.
A business intelligence engine can then be used to aggregate and visually display obligations by rating, outstanding reviews etc.
Protecht.ERM Obligations dashboard sample.
Once the rules are understood, processes must be put in place to ensure the rules are met and that assurance is provided to senior management and the board. In a future article, we will explain how this can be achieved.
David Bergmark consults on a variety of market and enterprise risk management issues and is actively involved in the development and implementation of Protecht's risk management software (ERM and ALM). David started out in the audit division of Price Waterhouse in 1990, handling clients such as Macquarie Bank and Bankers Trust. By 1994 he was Risk Controller for Carrington Securities - a financial markets trading company. In 1996 David left Carrington to head up the Risk Management Department at IBJ Australia Bank (IBJA) where he was responsible for the development of all risk disciplines at the bank – market, credit, liquidity and operational.