How do you implement NIS2 and organise security requirements in the cloud?

How do you implement NIS2 and organise security requirements in the cloud?

NIS2 is the EU cybersecurity directive, transposed into national law across member states (in Poland through the amended National Cybersecurity System Act). For most technology companies the question is not “does NIS2 apply to us” but “what exactly must we do and where do we start”. This article organises the requirements and sets out a practical implementation order, without the legal jargon and with everything mapped to the cloud.

Step 1: work out whether NIS2 even applies to you

NIS2 splits covered companies into two categories, which determine how intensely you are supervised:

• Essential entities - larger companies in critical sectors (energy, transport, banking, digital infrastructure, healthcare and others). They face ex-ante supervision (checks can happen proactively).
• Important entities - companies in important sectors (including digital service providers, manufacturing, postal services, waste management). They face ex-post supervision (a response after an incident or a signal).

Coverage depends on the sector and company size (usually the medium-enterprise threshold, so at least 50 employees or the corresponding turnover). If you provide digital services, hosting, cloud or software to covered entities, you often fall into scope as part of their supply chain, even if you are smaller yourself. The first implementation step is therefore an honest classification, because it sets the scope of your obligations.

Step 2: the four groups of obligations you must cover

Regardless of category, NIS2 comes down to four areas. They form the implementation checklist:

Incident-reporting deadlines are the most commonly overlooked element, and they tend to be enforced most strictly: an early warning within 24 hours of detection and a fuller notification within 72 hours. Without working monitoring and ready runbooks, meeting those windows is not realistic in practice.

Step 3: do not build from scratch, map onto ISO 27001

The most common mistake is treating NIS2 as a separate, new project. In reality the NIS2 risk-management requirements overlap heavily with ISO 27001 controls (Annex A): access control, cryptography, incident management, business continuity, supplier security. If you have or are building an ISMS for ISO 27001, you are already doing most of the NIS2 work.

So the practical order is one control mapping onto both frameworks at once, rather than two separate matrices. We set out the starting point in our article on preparing the cloud for ISO 27001, and the shared-compliance-layer logic for multiple clouds in our guide to multi-cloud compliance. What NIS2 mainly adds on top is hard incident-reporting deadlines and formal management accountability, which ISO 27001 does not require outright.

Step 4: translate the obligations into cloud mechanisms

This is where implementation gets concrete. Each obligation has a technical counterpart:

• Access control and identity - MFA, least-privilege and regular access reviews in IAM; for distributed environments it is worth basing this on a zero-trust architecture.
• Encryption - data at rest and in transit, managed keys (KMS, Cloud KMS, Key Vault), secret rotation.
• Incident detection and reporting - a central store of logs and alerts, runbooks for common scenarios, clearly assigned responsibility and an on-call rota, so the 24/72-hour windows are achievable.
• Business continuity - tested backups and DR plans with verified RTO/RPO.
• Evidence and audit - continuous evidence collection (who, what, when), so you can demonstrate compliance without a frantic document scramble before an inspection.

The key principle: controls written as code and enforced in the pipeline are easier to prove than policies in documents, because the actual and declared states do not drift apart.

How Devopsity supports NIS2 implementation

Devopsity starts with classification (whether you are an essential or important entity and what follows from that) and a gap analysis against the four NIS2 areas. Then we map the requirements onto ISO 27001 controls and onto concrete cloud mechanisms, implement them as code (policy-as-code, IAM, encryption, monitoring), set up the incident-reporting process with runbooks built for the 24/72-hour windows, and establish continuous evidence collection. We do not leave you with a list of recommendations: we implement and operate these controls day to day. The scope is on our security and compliance page.

Need to organise your NIS2 requirements?

Book a free 30-minute call. We will classify your company under NIS2, run a gap analysis and propose an implementation plan mapped to ISO 27001 with concrete cloud controls.

Book a call Send us a message

Frequently asked questions

How do you implement NIS2 and organise your security requirements?

NIS2 is best implemented in four steps. First work out whether you are an essential or important entity, because that sets the scope of your obligations and how intensely you are supervised. Then cover the directive’s four areas: risk management, incident handling and reporting within set deadlines, supply-chain security, and management accountability. Next, map the requirements onto ISO 27001 controls, which overlap heavily, rather than building everything from scratch. Finally, translate the obligations into concrete cloud mechanisms (IAM, encryption, monitoring, incident runbooks, tested DR), ideally written as code. Devopsity runs this process from classification and gap analysis through to implementing and operating the controls.

Who does NIS2 apply to?

NIS2 covers essential and important entities in defined sectors. Essential entities are larger companies in critical sectors (energy, transport, banking, digital infrastructure, healthcare and others), under ex-ante supervision. Important entities operate in important sectors (including digital service providers, manufacturing, postal services) and face ex-post supervision. Coverage depends on sector and company size, usually from the medium-enterprise threshold. Cloud, hosting and software providers often fall into scope as part of the supply chain of covered entities, even as smaller companies.

How quickly must an incident be reported under NIS2?

NIS2 requires significant incidents to be reported in stages: an early warning usually within 24 hours of detecting the incident, a fuller notification within 72 hours, and a final report later. Meeting those windows requires working detection (central monitoring and logs), ready incident runbooks, and clearly assigned responsibility and an on-call rota. Without this the deadlines are not realistically achievable, which is why the incident-reporting process is one of the first things Devopsity sets up during NIS2 implementation.

Does ISO 27001 help with NIS2 compliance?

Yes, to a large extent. The NIS2 risk-management requirements overlap substantially with ISO 27001 controls (Annex A): access control, cryptography, incident management, business continuity and supplier security. If you have or are building an information security management system for ISO 27001, you are already doing most of the NIS2 work. What NIS2 mainly adds is hard incident-reporting deadlines (24/72 hours) and formal management accountability, which ISO 27001 does not require outright. That is why it is worth mapping both frameworks onto one set of controls rather than running two separate projects.