The first part of this series introduced the business case for Continuous Controls Monitoring (CCM) as a way to mature your IT governance, risk, and compliance functions. This second part starts to itemise the missteps I encountered on a recent deployment of a SaaS platform to automate my client’s CCM processes.
Mistake 1 – Lack of an existing CCM strategy
If you’re not already doing some type of controls monitoring, embarking on a large/full-scale CCM automation project is not advisable.
Starting a CCM automation project without an existing controls monitoring strategy is akin to receiving the keys to a brand new electric vehicle, getting behind the wheel, and expecting it to drive itself.
Prior to embarking on CCM automation and before selecting vendors and products, key things to clarify include:
- Business drivers i.e., why do we need controls monitoring?
- What is the current state and future state of controls monitoring?
- Stakeholder involvement i.e., is there buy-in from all the participants?
- What monitoring can we leverage in our existing IT and security architecture?
- Where will telemetry data come from and what are our connectivity options?
A simple gap and maturity assessment of existing controls monitoring processes can help management determine the organisation’s readiness for automation. This can also help to develop the business case and crystalise functional and non-functional requirements for the project.
Mistake 2 – Lack of a technology risk management framework
Having a standardised risk and controls framework is a key step when implementing controls monitoring. It is common for larger organsations to develop an internal IT risk and controls framework by adapting industry-recognised frameworks such as COBIT, CSA CCM, NIST, ISO27002 and PCI-DSS.
The need for one may seem pretty obvious. However, it is not uncommon for organisations to embark on costly CCM projects using frameworks that
- do not reflect the risks facing the organisation nor align with its business objectives;
- are not aligned to industry-recognised technology risk management frameworks;
- contain unclear control objectives and multiple control duplications; and
- use inconsistent terminology to outline risk and control statements.
Most CCM technology vendors use leading industry security standards and IT governance frameworks as a basis for designing their monitoring logic. While many may claim to be able to adapt their products to suit ‘any framework’, it is more beneficial to start from a ‘known state’ for your particular business context.
Mistake 3 – Lack of verifiable metrics and key risk indicators
“You cannot manage what you cannot measure,” goes a popular adage.
Fundamental to embarking on a CCM project is defining a set of control metrics (qualitative or quantitative) that can provide a realistic indication of your organisation’s IT risk.
Whether based on manual or automated data collection and analysis, well-defined control metrics with defined thresholds can provide a reasonable view of control effectiveness and evidence of compliance. Key risk indicators (KRI) can, in turn, highlight degraded controls that need immediate attention.
Linked to my previous point, a comprehensive risk management framework can provide an approach for setting an organisation’s risk appetite, identifying core risks, mapping them to IT and security controls, outlining control objectives and mapping those objectives to verifiable metrics and KRIs.
CCM automation works best when projects can leverage well-defined metrics/KRIs or where there is a standardised risk and control framework in place from which these can be easily derived.
You cannot automate from nothing!
Mistake 4 – Ignore IT and Security Operations teams
Attempting to monitor controls and measure technology risk without consulting the IT and security teams that operate the controls can be an expensive misstep.
Linked to the previous point about metrics, high-quality and sustainable metrics should be developed in partnership with IT and security teams (prior to automation).
Using your technology risk management framework, engage with infrastructure teams – servers, networks, databases, storage, cloud – and Security Operations to develop meaningful metrics that reflect real-world business concerns.
The journey to successful CCM automation begins with forming alliances with IT infrastructure teams. Spend some time understanding their technologies and upgrade plans.
Review operational procedures and identify potential opportunities for data collection; for example in an AWS environment, teams might already be using CloudWatch and Guard Duty for monitoring.
Obtain buy-in from team leads regarding the frequency of compliance reporting and agree ownership for data generation. Find compromises that don’t require teams to spend an unreasonable amount of time formatting data for compliance reporting.
IT and Security teams are often stretched to breaking point and so selling the idea that automating controls monitoring can reduce the impact of audits and replace cumbersome reporting can lead to quick wins.
Mistake 5 – Lack of access to data sources
A recent Quod Orbis survey indicated that “42% of organisations surveyed have a dedicated in-house compliance capability with direct access to all necessary data and systems”.
This seems to be an optimistic assessment of the actual situation. In my experience, risk and compliance teams often rely heavily on other departments to generate, format, and share the data needed for controls monitoring.
The same survey noted that “37% of organisations said they needed to access between 70 and 90% of the estate” for compliance reporting.
Prior to embarking on CCM automation and before spending time working out connectivity requirements, it is important to understand how much of the technology estate is needed for controls monitoring. The benefits of having access to an accurate IT asset inventory cannot be understated.
It is also beneficial to try to obtain (at the bare minimum) ‘audit/read-only’ and least-privilege access to as many of those technologies as possible.
The concluding part of this series (Part 3) lists the remaining 5 missteps I encountered during my recent CCM automation project and some lessons learned.
