Security is the best policy – documenting digital security compliance in an increasingly regulated landscape

Until recently UK and EU businesses were primarily concerned with the reporting and governance obligations arising under the GDPR, with the documentation of broader information security protocols being largely at the discretion of the organisation. A number of key operators of essential services, and digital service providers also had obligations under the NIS Directive, the EU's first attempt to harmonise information security approaches. However, in many Member States, NIS was patchily or poorly enforced. In recent and coming months, a significant number of organisations will become subject to new governance and accountability obligations arising under a range of EU laws, including the successor to the NIS Directive, NIS2.

NIS2 significantly expands the number of sectors deemed 'critical' to the existence of civil society in the Member States of the EU and therefore expands the number or organisations subject to information security compliance obligations. NIS2 is not the only new enactment creating governance obligations across the European Union.  The Critical Entities Resilience Act (the CER) requires Member State authorities to engage with critical entities operating within their borders, to ensure the protection of European markets and society against natural and human-caused harms. As part of the transposition of the CER (which is a Directive), many organisations will be required to engage with national governments to provide regular reporting and support response planning.

Sector and product specific information security governance requirements are also a feature of incoming European law. The Digital and Operational Resilience Act (DORA) creates obligations for organisations operating in the financial sector, including a range of technical requirements which should be reflected in policy documentation along with clear reporting mechanisms and other duties. The Cyber Resilience Act (CRA) creates a regulatory regime for the governance of 'products with digital elements', with new certification and reporting obligations for manufacturers and a range of other entities in the EU supply chain for such products. Businesses operating in the UK which are subject to the CRA are also likely to be caught by the requirements of the adjacent (though not expressly aligned) UK regime, the Product Security and Telecommunications Infrastructure Act (PSTIA) and its accompanying Regulations which govern the security of 'consumer connectable devices'.

Although organisations subject to the specific requirements of DORA will not be additionally subject to the equivalent requirements of NIS2, many organisations will face governance duties under multiple regimes; a handful of very large, multi-sector businesses may find that they are subject to them all. With several new compliance regimes coming into force in the coming months and some already operational (either partially or completely) it is a significant challenge for organisations to clearly identify their obligations, let alone meet them. All organisations operating in the UK and EU with any form of IT infrastructure should have some form of information security policy or protocol in place and many will require multiple documents. Some organisations will seek to address different compliance obligations separately, with different policies for handling personal data breaches, reportable incidents under NIS2 or DORA, or product safety protocols under the CRA and PSTIA. Other organisations will seek to combine all of their reporting and response processes into a single document. Compliance approaches can vary for very legitimate reasons based on the level of available resource, the location and specialism of the team members responsible for compliance and the preexisting governance structure and style of the organisation. However, there are some consistent markers of good practice which can be adopted in any policy drafting approach.

Types of digital security governance documentation

A policy is not necessarily the same thing as an incident response plan. While the two things can be combined, it is important to understand the purpose of the document you are drafting, reviewing or revising which will be one or more of the following.

The NIS2/DORA/GDPR policy

A legislation specific policy, often for the benefit of an organisation's management team, setting out the requirements to which the organisation is subject, who is responsible for specific aspects of compliance, and any broad policy approaches taken. Will cover requirements specific to the legislation such as penetration testing or 24 hour report submission under DORA.  Such documents may not contain the detail of how to respond to an incident and may not contain the technical detail of minimum acceptable security measures.

The information security policy

A document outlining the technical security measures that the organisation has in place and any external standards to which it adheres (e.g. information security standards such as ISO27001). This document may not expressly refer to the legislative regimes to which the organisation is subject, so the link between specific measures and compliance duties may not be clear.

The incident response procedure

A structured plan setting out the organisation's plan to be deployed in the event of an information security incident, such as a cyber attack, a data breach, or an adverse event affecting one of its connected products. This is usually a practical step by step guide explaining who should adopt which role, actions to be taken, and the relevant timelines. If the incident response procedure addresses multiple types of incident, it may refer to specific reporting obligations under specific regulatory regimes but it will not generally address compliance obligations arising outside incident response.

The 'one-size fits all'

It is possible to create a hybrid approach where an organisation's overall policy commitments are laid out with additional sections demonstrating compliance efforts related to specific regimes, alongside a clear incident response plan. Such combined documents can be valuable for organisations but are difficult to prepare and maintain particularly for large, multinational, or highly regulated organisations where the division of labour and separate allocation of resources and responsibilities may make it easier (though less consistent) to maintain multiple governance documents and approaches. There is also a strong argument in favour of maintaining specific compliance documentation to address particular regulatory duties to avoid the need to provide more information in response to a regulatory query than is expressly required.

Policy best practice

When preparing any type of policy or governance document, the first essential thing is to identify the precise purpose of your document. Are you seeking to demonstrate compliance with specific legislation? Is it written to inform your senior leadership and others of the policy and ethical approaches that the organisation has adopted? Or is it prepared to provide assistance to those tasked with handling the practical challenges arising from an information security incident?

Once you understand the purpose of the document, consider your audience. Tailoring your approach to meet the needs of your reader is essential but clear simple language is always best, regardless of who will be using your document. For breach response plans in particular, your reader will be under time pressure and a great deal of situational stress so try not to add to that with complex sentence structures or confusing layouts. If your policy requires translation make sure someone has carefully considered both versions to ensure that they are consistent, this is not an area for ambiguity.

Your governance documents should be tailored to meet the specific needs of your organisation and address your specific regulatory requirements. Generic, off-the-shelf templates may provide a useful starting point but the detailed preparation of governance documentation is a great way to stress test whether policies and procedures are actually workable. Whatever approach is taken there are often overlooked practical issues of policy management that deserve attention.

Managing governance documents in a regulatory thicket – overlooked practicalities