Equipping your CRM: what a platform brings, and its limitations

What a platform really brings

• Centralisation. Missions, audits, findings, recommendations, documents and actions are no longer scattered across files, messaging systems and shared servers. Information becomes locatable.
• Traceability. Every action, approval, comment and decision leaves a time-stamped trail. What is known as an audit trail (audit trail) turn the statement into a demonstration.
• Standardisation. The missions and control plans follow common models, which makes the work comparable from one function and entity to another — a prerequisite for credible consolidation.
• Operational monitoring. Assigned responsibilities, deadlines, statuses and alerts: open items stop getting lost between meetings.
• Reporting. Producing a consolidated view for management and the board becomes a matter of minutes rather than a manual exercise lasting several days.

Perhaps the most significant gain lies elsewhere: the time thus freed up is time given back to analysis. A team that devotes most of its energy to collecting and formatting has hardly any left to interpret.

What no platform will replace

We need to be just as clear about the limitations, because disappointment almost always stems from poorly calibrated expectations.

• Setting objectives. No tool will tell the organisation what it is trying to achieve, nor what level of risk it is prepared to accept. That is a decision for the board and management.
• Professional judgement. Identifying what genuinely constitutes a major risk, assessing the significance of a finding, formulating a useful recommendation: these acts fall under the scope of expertise, not configuration.
• The decisions. Deciding where to allocate limited resources involves prioritisation that the tool can inform, but never perform.
• The quality of the entered data. A poorly constructed map remains poorly constructed once computerised — it is simply better presented, which can make the problem worse by giving a false sense of security.
• Team buy-in. A tool that we suffer through becomes yet another constraint; a tool that lightens our daily lives becomes a support. This difference plays out in project management, not in the features.

The most frequent sequence error

It involves acquiring a tool to solve an organisational problem. The reasoning seems logical: the devices are scattered, a platform will bring them together. In practice, computerising a mess produces a computerised mess — with the added bonus of a cost and a project to manage.

The working order is the reverse. Clarify first what you want to manage: objectives, major risks, obligations, key controls, responsibilities. Then define the common language — taxonomy, rating scales, reporting formats. Only then choose the tool that supports this architecture, and not the other way around.

This sequencing does not require a perfect device prior to any deployment. It requires knowing what one aims to achieve. A module deployed over a restricted yet clearly defined scope is better than a broad deployment on vague foundations.

Mind the scope actually covered

A note of caution is needed regarding the market: few solutions presented as «GRC» cover the entire scope that this acronym encompasses. Most handle risk management and control monitoring well. Many fewer support the governance dimension—definition and monitoring of objectives, preparation of governing bodies, policy management—or the full range of applicable compliance obligations.

This does not disqualify these solutions: meeting a specific need accurately is better than claiming to cover everything. But one must be aware of this, to avoid two illusions: believing that acquiring a tool equates to setting up a GRC framework, and assuming that a scope not covered by the tool is being handled elsewhere.

Selection criteria for a regulated entity

Beyond the features, a few criteria carry particular weight for a player in the Luxembourg financial sector:

• Modularity. Being able to start with a priority need and then expand, rather than embarking on a global project.
• Audit trail. Complete logging of actions, approvals and decisions — this is what will be examined in the event of an audit.
• Hosting and data privacy. Localisation, access control and processing conditions are compliance issues, not just technical ones.
• Multi-entity tracking. Essential as soon as the group includes several regulated structures.
• Configurability. The tool must fit the organisation's method, not impose its own.
• Reversibility. Being able to extract one's data in a usable format, and having an exit strategy — a now familiar requirement in IT outsourcing.
• Business support. Relevant configuration requires an understanding of the regulatory context; pure technical support is not enough.

Common pitfalls

• Launching the tool project before having stabilised the method and the common language.
• Deploy all modules simultaneously, at the risk of superficial adoption across the board.
• Replicating legacy processes identically, without seizing the opportunity to simplify them.
• Confusing thoroughness of configuration with relevance: an overloaded system discourages usage.
• Neglecting training and support is the primary factor in deployment failure.

The ARCAD approach

ARCAD clearly separates the two stages. First the methodology: objectives, risks, obligations, key controls, responsibilities and expected reporting. Then the tooling, calibrated to this architecture and deployed in stages. This field experience has shaped the design of VIGIL, a GRC platform developed in Luxembourg — a tool conceived by control practitioners to support professional judgement rather than pretend to replace it.