Compliance software – a solution or creating another problem?

March 1, 2017

Compliance software can include any technology which is used to aid a compliance officer in the daily running of their compliance programmes. The technology itself can range from simple emails and spreadsheets through to an enterprise-wide governance risk and compliance solution, and anything in between. For the purposes of this discussion, I will be defining compliance software as those systems and tools designed specifically for compliance (such as registers for gifts or declarations of conflicts of interest) or those that are easily adaptable to compliance-related tasks (such as online training via a Learning Management System), rather than generic office tools.

The issue

The key issue with the use of compliance software is when people confuse the software with the compliance programme. Technology, and software in particular, is never going to be a complete answer for compliance, which is, at its core, a business process. Software solutions must be made to fit the processes and programmes which have been defined – not the other way around.

Where there is software in the market that has been designed specifically to support compliance issues, it may be the case that the processes in the software are based on extensive knowledge and best practices. In this event, where this knowledge can be clearly seen, such software can be utilised by a company as a guide, but it remains true to say that each company needs to retain control over its own processes. It makes no sense for a company to outsource their key compliance processes to a third party who has built generic (albeit configurable) software and who knows neither the company culture nor the specific risks the company faces.

Is compliance software necessary?

Does a company need compliance software at all? The answer to this depends on a number of factors, including the size of the company and their culture.

Take, for example, a programme to manage conflicts of interest within a company. There are a number of ways to implement this programme. Assuming that there is buy-in from the board and management and that resources are available, at the cheapest and simplest end there could be a policy stating that all conflicts must be reported to line managers. The policy can be posted on a noticeboard and training can be provided in a classroom environment so that no further technology is required. The scalability of this simple programme could be supported by the use of generic technology, such as emails to announce the policy or a spreadsheet to track training. However, it can be seen that beyond the smallest company with the simplest programmes, more technology will be required, and the use of systems specifically designed for compliance will be of greater use than those designed for general office use.

Whilst this low-technology-based implementation has a number of advantages (not least of which are low cost and speedy deployment), it also has a number of drawbacks. These drawbacks include difficulty to scale the technology to large numbers of employees in several locations, and a lack of documentation (which is necessary to confirm that staff have read the policy, that they have been trained on its contents and that they are actually following it).

The benefits of using software which has been specifically designed for compliance issues go beyond just scale. The software can also provide:

  1. Speed – the rollout of communications, training, policies and processes can be managed far more quickly via tools which know the user population (via a connection to a human resources system or email address book), can segregate the population (so specific instructions can be given to individual groups) and can manage those who don’t respond
  2. Cost reduction – using an electronic platform means that more people can be informed of new policies and trained for less cost than in classrooms (although the quality of the training may not be the same)
  3. Certainty of process – the processes defined in your programme can be built into the system, forcing the users to follow a fixed path (for example, keeping messages within the system (rather than email) or building a workflow to ensure that decision-making is always done at the right level and with the right information)
  4. Monitoring and measuring – the effectiveness of the programme can be tracked more easily when metrics can be taken directly from the systems running the programme (for example, determining the number of people who have completed a training programme or the number of people who have registered a conflict)
  5. Documentation and audit trails – the biggest advantage of software solutions is the document trail, which not only confirms that the programme is being adhered to but means that a compliance officer can easily find previous versions of policies, records of training and information about any registered conflicts and decisions made pursuant to conflicts (which is of great assistance in the event of an audit or an incident).

Buy or build?

So what is the best solution –having someone within the company build the system, or outsourcing to a supplier of generic software?

Building your own system will mean that the software will exactly match your requirements and perfectly fit your processes and other systems. However, as a compliance officer, what do you know about software development? If you are lucky enough to have a business analysis team available who do know about software development, what do they know about compliance? And how much time is going to be needed to bridge the knowledge gaps between the two? If this hurdle is overcome and a design specification is provided, the next issue relates to the actual coding. Again, some companies have developers on staff (though not often for anything other than business development), but most will use outsourced resources. With this comes another level of management to ensure that the specification is understood, carried out and tested appropriately.

If you decide to buy your software from a supplier, a good outsourcing partner should have the capacity and skills to complete your project without any problems. From the outset, you need to ensure you are able to clearly define your requirements and manage the development (which can be quite complex if you are using an off-shore provider). Given the nature of software development, costs can be considerable if you change your requirements mid-way – whether you are using a fixed price model or not.

Other things to consider

  • Who will support the software once it is released? Some companies have existing help desks that are able to provide support for the new software, but many companies will either need to seek support options elsewhere or provide the extra support themselves. Regardless, sufficient documentation (such as user guides and configuration manuals) and training will be required before anyone will be in a position to provide support.
  • How will the compliance team maintain the software? Whether due to minor changes in a process or major changes in the programme (possibly due to legislation or policy), software is rarely built to a level that will not require changes to code in the future. When outsourced resources are used, people often move on or are no longer available for the project. Even when internal resources are used, depending on the level of documentation provided in the original design, it can be a significant challenge to get access to the original programmers, so time (and cost) is needed to make even a very minor change.
  • Where will the application be hosted? Again, some companies will have dedicated hosting facilities available but many will not. Where hosting is provided, the software will need to be tested to ensure that it can provide adequate performance for the potential users, wherever they may be. Where there is no hosting, an external provider will need to be found, and technical resources will need to be in place to build the application in the hosted environment.
  • How will availability be ensured? Whichever solution is found to host the system, it will need to be available whenever the users need it. In some companies this may only be within business hours, but in other, global businesses, multiple time zones and working practices may require 24/7 availability.
  • How will the data be protected and remain private? Regardless of the location of the hosting (inside or outside the company), most compliance-related systems will hold information of a private or sensitive nature. Compliance with privacy legislation can be a significant issue, especially where multiple jurisdictions are involved. Of particular importance when considering privacy is the need for consent and access to the information. Protection of the data using encryption methods is also essential, both when in transit and stored.
  • Who will pay for the system? One final, though vital, point is deciding who will pay for the system. The choice is generally between using a central compliance (or legal) budget or sharing the costs between the business units who will be using the system. The benefits of a central budget are that the control remains with the people who have designed the programme and therefore know why it is necessary. On the other hand, a system which is not paid for by the business units risks being seen as an imposition and not part of the business’s own processes.


Ensuring the effectiveness of the technology

The solution to the above issues is to think about the introduction of IT systems in the same way as any other compliance problem. The first step is to gain commitment. This includes commitment from executive management as well as those who will be involved in the process. To achieve this you must be clear about the risks and obligations which the system is being designed to manage and focus on how the system will support the strategic goals of the organisation.

There also needs to be a definite answer to the question of whether to build or buy. You will need to think about your company culture, budget, size and geographic locations, and whether you have the necessary resources to complete an internal build project. If you are able to build internally, you will need to ensure that there is a plan to meet the challenges outlined above. Where you decide to purchase a system, test the market and select a vendor who understands the goals of compliance and has built a flexible system which allows you to fit their software around your processes.

The next stage is to implement your system. This entails more than the basic parts of designing the processes, purchasing or building the system then implementing and testing the processes. The key element, which is often overlooked, is communication, since a major risk for any system is that people won’t use it. A clear strategy for communications is required, and it must include a detailed training programme (either in the classroom or online) that covers the reasons for the system (e.g. corruption or health and safety) and when the system will be available as well as how to use it.

The final stage of the system implementation is to ensure that the technology is actually being used. This can be achieved in a number of ways, such as monitoring access to the system after the rollout, reviewing the information entered into the system and asking the users for their feedback. Where issues are found, a review will need to be conducted to understand the root cause – whether the processes were not well designed, the communications were ineffective or the technology was not suited to the needs. In each case the causes should be remediated so that the system and programmes do not fail or be seen as failing.

The last review which needs to be carried out is to establish whether the overall system meets the goals set out in the planning phase. This might consider things such as whether the budget was sufficient, whether the technology choice was appropriate and whether the risks and obligations have been managed.


It is clear then that software systems can, and should, be an integral part of solving compliance challenges. The keys to making them work, however, are ensuring that the software is selected and configured to fit the programme rather than the other way around, and not ignoring the soft skills of management buy-in, communications and training.

Previous Article
Our 10 year anniversary and The Red Flag Group in numbers
Our 10 year anniversary and The Red Flag Group in numbers

Founded in 2006, the Firm has evolved and rapidly grown to meet the needs of our clients, developing cuttin...

Next Article
Identify and manage compliance issues using email sweeps
Identify and manage compliance issues using email sweeps

Many companies find that they experience the same type of compliance issues over and over again. Most compa...