Not legal advice. This post covers the technical side. Whether your company is in scope, and as which type of entity, is a legal question; check the official guidance from the National Cybersecurity Authority and talk to your lawyer.
Greece transposed the EU NIS2 Directive (2022/2555) into national law with Law 5160/2024. It widens the set of companies with cybersecurity obligations well beyond the old NIS rules: energy, transport, banking, health, digital infrastructure, ICT service management, public administration, manufacturing of critical products and more. It also makes management personally accountable for approving and overseeing cybersecurity measures.
Most of the published guidance is written for lawyers and boards. This post is for the engineers who have to make it real.
Are you in scope?
Broadly, NIS2 applies to medium and large companies (around 50+ employees or €10 million+ turnover) in the sectors listed in the directive's annexes, with some providers in scope regardless of size, for example certain digital infrastructure providers. Entities are classed as essential or important; both have the same security duties, with different supervision and fines. In Greece, entities register through the National Cybersecurity Authority's NIS2 registry.
Even if you are not in scope yourself, you may feel NIS2 through your customers. In-scope companies must manage supply-chain risk, so expect security questionnaires and contract clauses if you sell software or services to them.
What the law asks for, in engineering terms
Article 21 of the directive lists the minimum risk-management measures. Here is what each one means on an AWS estate.
1. Risk analysis and information security policies
- A written inventory of systems and data, with owners. Tags for environment, service and owner on every resource make this maintainable.
- A short security policy the team actually follows, reviewed yearly and approved by management.
2. Incident handling
- Centralised, tamper-resistant logs: an organisation-wide CloudTrail trail delivered to a separate log-archive account, with S3 Object Lock or restricted delete permissions.
- Threat detection with GuardDuty enabled in every account and region you use, findings routed to the people on call.
- A documented on-call rotation and incident runbook (see the reporting section below).
3. Business continuity, backups and crisis management
- AWS Backup plans for databases and volumes, with copies in a separate account and, where it matters, a vault lock so backups can't be deleted by a compromised admin.
- Multi-AZ for production databases and load-balanced services.
- A restore test on a schedule, with the time it took written down. An untested backup is a hope, not a control.
4. Supply-chain security
- A list of your critical suppliers (cloud, SaaS, payment, CI) and what data each one holds.
- Least-privilege access for third-party integrations, with roles instead of shared keys.
- Pinned and scanned dependencies and container images, so a compromised upstream package doesn't flow straight to production.
5. Secure development and vulnerability handling
- Code review and CI on every change, with infrastructure changes going through Terraform pull requests.
- Vulnerability scanning with Amazon Inspector for EC2, Lambda and ECR images, plus dependency scanning in CI.
- A patching cadence with deadlines by severity, and a way to see what is overdue.
6. Assessing whether the measures work
- AWS Config and Security Hub with a recognised baseline (such as the AWS Foundational Security Best Practices standard) to track drift.
- A periodic internal review. Our five-dimension cloud audit is one way to do it and gives management a one-page view.
7. Cyber hygiene and training
- Security training for staff, and specific training for management, which the law requires.
- Basic hygiene enforced by guardrails rather than reminders: S3 Block Public Access at account level, IMDSv2 required, default EBS encryption.
8. Cryptography and encryption
- Encryption at rest everywhere with KMS keys, and TLS for all traffic in transit.
- Key policies that separate who can use a key from who can manage it.
9. Access control, HR security and asset management
- One identity per person through IAM Identity Center connected to your identity provider, with no long-lived personal access keys.
- Joiner, mover and leaver steps that remove access on the day someone leaves.
- Separate accounts for production with organisation-level guardrails (SCPs).
10. Multi-factor authentication and secure communications
- MFA enforced for every human, including through the identity provider, and a locked-away root account with hardware MFA.
- A secure, out-of-band channel for incident communication in case your main tools are affected.
Incident reporting: 24 hours, 72 hours, one month
For a significant incident, NIS2 sets a reporting timeline to the national CSIRT or competent authority: an early warning within 24 hours of becoming aware, an incident notification within 72 hours with an initial assessment, and a final report within one month. Your on-call process has to be able to produce that information under pressure:
- When did we detect it, and how? (Alert timestamps and GuardDuty findings.)
- What is affected: which services, which data, which customers?
- Is it likely malicious, and could it affect other organisations?
- What have we done so far, and what is the current impact?
Write a reporting template into your incident runbook now, with a named person who decides whether an incident is significant. Logs that are centralised, retained and searchable are what make the 72-hour report possible; keeping them in the EU keeps GDPR happy at the same time.
The evidence pack
When a supervisor or a customer asks how you comply, you want to hand over evidence, not promises. Keep these up to date:
- Asset and supplier inventory with owners.
- Security policy and management approval records, including training.
- Security Hub or Config compliance reports over time.
- Backup restore test records.
- Incident log, postmortems and any reports sent to authorities.
- Access reviews and leaver records.
If you already have ISO 27001 or SOC 2
Much of the work overlaps. ISO 27001 controls cover most of Article 21, and SOC 2 evidence such as access reviews, change management and incident response is reusable. The gaps are usually the NIS2-specific ones: the 24/72-hour reporting flow, management training and accountability, and registration with the national authority.
Where to start
- Confirm with your legal adviser whether you are in scope, and register if you are.
- Run a baseline review of your cloud estate against the ten areas above.
- Fix the high-impact gaps first: MFA and SSO, centralised logging, tested backups, and the incident reporting runbook.
- Turn on continuous checks so you know when something drifts.
Penalties under NIS2 can reach €10 million or 2% of worldwide turnover for essential entities and €7 million or 1.4% for important ones, but in practice the bigger risk for most companies is losing a customer who can't accept your answers to their security questionnaire.
Frequently asked questions
What are the NIS2 incident reporting deadlines?
For significant incidents: an early warning within 24 hours of becoming aware, an incident notification within 72 hours, and a final report within one month.
Does using AWS make us NIS2 compliant?
No. AWS secures the underlying cloud, but you are responsible for how you configure and operate your accounts: identity, logging, backups, patching and incident response.
Which Greek law implements NIS2?
Law 5160/2024 transposes the NIS2 Directive (EU) 2022/2555 into Greek law. The National Cybersecurity Authority publishes guidance and runs the registry for in-scope entities.