(Want to get articles like this one by email? Here is the sign-up!)
Effective compliance program info for value chain partners and regulators:
Certain third parties also have need for reliable information that supports a fact-based conclusion by that third party that a functioning program exists and is operating.
Those in a present or prospective value chain relationship want to know that they are dealing with a reputable partner that takes its compliance obligations seriously. What they really don’t want is to have their good name get dragged into a well-publicized regulatory enforcement action because of their relationship with another party, purely because of that relationship and for no real substantive reason.
To protect against that possibility, organizations increasingly take two steps with respect to their counter-party: (1) conduct due diligence (both adverse event and reputational); and (2) request compliance program existence confirmation (through certifications, program description summaries, sample reports and/or on-site program reviews.)
The standards applied by value chain partners in the confirmation process will vary, and ISO 37001 may well serve this role in the anti-bribery space once officially adopted. The perceived risk profile of the ‘target’ organization (including the geographies where the parties may be involved together) and the size and complexity of the deal will all be factors in whether the requesting company is satisfied with representations or feels that a deeper dive is warranted.
In a regulatory inquiry or investigations context, different factors are at play. Here, the focus is on an “effective compliance program” – and the definition, components and associated regulatory expectations may vary, according to the agency or department and the standard being enforced.
In virtually all regulatory situations, however, key factors (pro or con) will be the completeness and reliability of the information, and the speed with which it can be produced. A company response to the initial regulatory contact that consists of “I am prepared to take you through our program and the associated audit trail at your earliest convenience”, backed up with a session where program data is current, accurate and complete sets a relatively positive tone at the outset. By contrast, a response along the lines of “we’ll have everything for you in 3 weeks”, followed by excuses as to why certain core programmatic elements are missing or not in writing instantly creates a negative impression that is hard to overcome.
In these contexts, as with the day to day program management needs of the Chief Compliance Officer (CCO), having a SaaS-based compliance management system can make a huge constructive difference. These systems operate as a repository for program data and are organized, through workflows, into critical compliance activity sections. Since any thoughtful CCO realizes that the day will come when value chain partners ask for, and may come when regulators require, certain program information to be produced, s/he can set up report subdivisions in advance within the system. These areas would contain the data that might be needed when the actual request occurs, consisting of stored relatively static documents, such as a company Code of Conduct or approved compliance program description, along with links to current program operational data.
The better systems also have audit trails that detail, for example, who entered (or had access to) what data, and when – and what data was distributed to which parties at what times and dates. Restricted access and security are important and necessary system features.
It is more difficult to have the same degree of advance preparedness for anticipated program information requests from value chain partners or regulators without a compliance management system – but still possible. With respect to the types of information, in what form, that s/he should have readily available, the CCO should consider, for both the regulatory and value chain requestor(s):
- What is my company’s goal with respect to this requestor?
- Conversely, what is the point of view, or bias, of this requestor?
- If the requestor were to go beyond an initial “reasonable” request for information, what would that next level consist of?
- How do I know that the data being used is current, accurate and complete – and how can I prove to the regulatory requestor, in particular, that this is the case?
- How do I keep this data secure?
- Who can I bounce my effective plan report plan off of – for a sanity check?