The more sets of rules an organisation is covered by, the more of the security work goes into proving that the work is being done. At some point the proving becomes larger than what it is meant to prove, and the security function spends more time describing the protection than building it. This chapter is about where that point sits and what to do about it.
It opens with a review of what can actually be automated and, just as importantly, what cannot. Collecting evidence, checking configurations and following up deviations lend themselves well. Judgements, trade offs and decisions stay with people. Then follow three phases on the road to automation, giving a realistic order of work rather than a technology leap, and starting from the fact that the process has to exist before it can be automated. Continuous control monitoring comes next, the shift from periodic sampling to running collection of evidence, which changes what an audit can build on at all. Compliance as code gets its own section for those with development environments to build the requirements into. One section shows how the overlap between several sets of rules can be exploited rather than carried, since one and the same piece of evidence often answers requirements in several of them at once. Then follow advice on choosing a platform, the common pitfalls, measurement and a realistic maturity scale. The processes to be automated are described in chapter 13 on building a management system.
The relevance comes from the regulatory load. An organisation handling the Cybersecurity Act, GDPR, customer requirements and possibly DORA or the AI Act at the same time quickly reaches a level where manual follow up takes resources from the work that actually protects the operation. At that point automation is not an efficiency measure but a precondition. At the same time it is worth keeping efficiency and capability apart, since an organisation can become very efficient at reporting a protection that does not hold.
This page shows what the chapter covers and where the limit of automation runs. The phases, the platform choice and the maturity scale are in chapter 21 of the book.
Compliance is not the opposite of resilience. But if you have to choose what to chase, it is resilience that survives an attack.
Key insights
- Automation requires the process to exist first. Automating an unclear way of working gives you an unclear way of working at speed.
- Continuous control monitoring replaces sampling with running evidence, which changes what an audit can build on.
- The overlap between sets of rules is the biggest gain from automation, since one piece of evidence can answer several requirements.
- Compliance and resilience are not the same thing. Automation gives efficiency, not the ability to withstand.
- Measurement is the precondition. What cannot be measured cannot be monitored continuously.
Tools that belong to this chapter
The templates and interactive tools are in the Toolbox, free of charge.
Control mapping
The basis for letting one piece of evidence answer several sets of rules at once.
System tools
Platforms for management systems, GRC and continuous compliance.
Read on
Next step
Where does your organisation stand?
The self-assessment gives you a maturity profile against the ten requirement areas of the Cybersecurity Act in a few minutes, right on screen.