Expert Insight: Cliff Martin on Streamlining DORA Compliance

Expert tips on addressing multiple security requirements simultaneously

Cliff Martin is the head of cyber incident response within GRCI Law. He joined the Group in April 2021, bringing experience from the defence industry, where he dealt with both operational technology and IT complexities. Before that, he taught computer systems and network technologies in further and higher education.

Now, Cliff supports clients with their cyber security requirements, helping them prevent and manage cyber incidents.

Thank you for your time again! I’d like to start by quoting something you said in our previous interview:

I think incident management starts right at risk management. As you’re conducting your risk assessments, you want to be thinking about how you’ll be able to detect an incident when one occurs despite your best efforts, and what you need to put in place to be able to get the evidence you need to establish root causes, the extent of the damage, etc.

What you said was in context of the DORA Regulation [Digital Operational Resilience Act], but could you apply the same principles to other security laws and standards too?

Yes, I don’t think DORA’s core requirements are unique at all. We see similar requirements across a range of standards – the PCI DSS [Payment Card Industry Data Security Standard], for example.

Admittedly, with the PCI DSS, not everyone within scope of that standard needs to meet all its many requirements, but one sub-requirement that even merchants that fully outsource must meet is sub-requirement 12.10: Suspected and confirmed security incidents that could impact the CDE [cardholder data environment] are responded to immediately.

While DORA isn’t about the CDE specifically, both the Regulation and the PCI DSS are similar in that you have to report certain types of incidents within a certain time frame. Also, both require you to test your incident response plan on a regular basis – annually, in the case of the PCI DSS. For DORA, we don’t know the frequency yet, as we’re still waiting for the technical requirements [set by the three European Supervisory Authorities] to be confirmed.

But it doesn’t stop at incident response. Many of DORA’s other core requirements, including risk management, security testing and securing the supply chain, overlap with those of the PCI DSS. And indeed other security-related laws in the EU, including the upcoming NIS 2 [Network and Information Security Systems Directive].

Considering these overlaps, can organisations streamline their compliance and implementation projects?

Yes, I think so. Though I should add that streamlining does need to work within the context of the organisation – so for the processes it follows, the documentation it uses, and so on.

But for the sake of complying with the risk management and incident reporting requirements of DORA, NIS 2, or future legislation like these, often, if you’re following good practices already, you have very little work to do. You just need to make sure that you add the right criteria for breach reporting to your processes, which do tend to differ per law, as well as the reporting deadline.

Besides DORA, NIS 2 and the PCI DSS, what other reporting requirements might organisations be able to streamline?

The EU GDPR [General Data Protection Regulation] is one that immediately springs to mind.

You’ve got Article 32, which is about implementing appropriate technical and organisational measures – so making sure you protect the personal data you collect and process. That means putting the right controls in place, which requires conducting risk assessments and generally preparing for the possibility of breaches.

So while the GDPR isn’t that concerned about service availability [DORA’s focus] but concentrates on protecting EU residents’ personal data, it still stipulates reporting requirements. So, reporting certain types of breaches to the supervisory authority and, in some cases, affected data subjects within a certain time frame.

Actually, one challenge we deal with quite a lot at GRCI Law, particularly the DPO [data protection officer] division, is determining whether a personal data breach is reportable. So whether, by the requirements of Article 33, the supervisory authority must be notified of the breach.

DORA and NIS 2 are kind of similar in that you need to conduct a risk assessment, then figure out your incident management requirements, including when and how to report incidents or breaches.

So these laws are different in what they’re trying to protect, but similar in terms of their structure and how they generally work.

Do you have any final words of advice?

Although we’ve still got a fair bit of time before DORA and NIS 2 will be enforced, for me, preparation is key.

So, make sure you’re clear on whether you’re within scope of either or both laws, and if you are, what you’re going to do to meet the core requirements.

If you don’t do anything and then suffer an incident, you will be asked questions about what measures you took to prevent it – what technological measures you’ve implemented, what documentation you have in place, what training you’ve given, and so on.

And organisations can, of course, expect harsher penalties if they failed to do the basics. Suffering an incident is one thing; suffering an easily preventable one is quite another.

We hope you enjoyed this week’s edition of our ‘Expert Insight’ series. Please do leave a comment below to let us know what you think, and if you have any questions you’d like our experts to answer.

We’ll be back in the new year, chatting to another expert within the Group.

In the meantime, if you missed it, check out last week’s blog, where Group CEO Alan Calder gave us his expert insights into DORA’s supply chain security requirements.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.