NIS2 Compliance on AWS for Growing EU Businesses

NIS2 compliance on AWS is not a box-checking exercise. For organizations that operate essential or important services in the EU, the real test is whether leadership can show that cyber risk is understood, controls are operating, incidents can be managed, and critical services can recover under pressure.

AWS provides a strong foundation for that work, but a cloud provider does not make an organization compliant by default. The shared responsibility model still places responsibility for identities, configurations, workloads, data, monitoring, and operating procedures with the customer. That distinction is where many compliance programs stall.

For growing businesses, the practical objective is clear: build an AWS environment where security controls are designed into daily operations and where evidence is available before a regulator, customer, insurer, or board asks for it.

What NIS2 requires from AWS-based organizations

NIS2 is an EU cybersecurity directive that raises expectations for risk management, incident reporting, supply-chain security, business continuity, and management accountability. Its precise application depends on the national law implementing the directive and whether your organization falls within a covered sector and size threshold. Legal counsel should confirm scope and reporting obligations in every relevant jurisdiction.

From an infrastructure perspective, NIS2 expects more than a set of security products. It expects an operating model. Your organization should be able to demonstrate how it identifies material risks, protects systems and data, detects suspicious activity, responds to incidents, restores services, and improves after failures.

For AWS environments, that usually means connecting cloud architecture to governance. A multi-account landing zone, identity controls, centralized logging, encryption, backup testing, vulnerability management, and documented incident playbooks need to work together. A control that exists only in a policy document will not stand up well to scrutiny.

Management also has a direct role. Executive teams should receive meaningful risk reporting, approve security priorities, and understand the consequences of weak controls. Delegating day-to-day administration to an internal IT team or managed services provider is sensible. Delegating accountability is not.

The AWS shared responsibility model under NIS2

AWS is responsible for securing the underlying cloud infrastructure, including facilities, hardware, core networking, and managed service infrastructure. Customers remain responsible for how they use AWS services. That includes IAM permissions, network architecture, operating system patching for applicable compute services, application security, data classification, encryption choices, and security monitoring.

This boundary changes by service. With Amazon EC2, your team generally has more responsibility for guest operating systems and installed software. With managed services such as Amazon RDS or AWS Lambda, AWS handles more of the underlying platform, while you still manage access, configuration, data protection, and application behavior.

A mature NIS2 program documents these responsibility boundaries instead of assuming them. For each critical service, identify the service owner, data owner, technical owner, recovery objective, logging source, supplier dependencies, and response procedures. This creates accountability that survives staff changes and audit cycles.

A practical NIS2 compliance on AWS control baseline

The best starting point is not an enormous framework spreadsheet. Start by identifying the systems that deliver critical services, the data they process, and the dependencies that could interrupt them. Then build and test a control baseline around the risks that matter most.

A useful AWS baseline typically includes the following components:

• Centralized identity and least privilege. Use AWS IAM Identity Center or an equivalent federated approach, enforce multi-factor authentication, eliminate shared administrator accounts, and review privileged access regularly. Permission boundaries and role-based access reduce the risk of excessive standing privileges.
• Multi-account separation and governance. Separate production, development, security, logging, and shared services accounts. Use AWS Organizations, service control policies, and controlled account provisioning to establish consistent guardrails without slowing engineering teams down.
• Centralized, protected logging. Send CloudTrail, Amazon CloudWatch, VPC Flow Logs, and key workload logs to a dedicated log archive. Restrict deletion rights, define retention periods, synchronize time sources, and ensure security teams can search events during an investigation.
• Continuous security monitoring. Use services such as Amazon GuardDuty, AWS Security Hub, AWS Config, Amazon Inspector, and Amazon Macie where they fit the environment and data classification. The value is not the alert volume. The value is a documented triage process, clear ownership, and timely remediation.
• Resilience and recoverability. Define recovery time objectives and recovery point objectives for each critical workload. Backups should be encrypted, isolated where appropriate, monitored for completion, and restored on a scheduled basis. A backup that has never been restored is only an assumption.
• Secure delivery and vulnerability management. Build security checks into CI/CD pipelines, use infrastructure as code through Terraform or AWS CloudFormation, scan images and dependencies, and maintain a risk-based patching process. Emergency changes need records and post-change review, even when speed is required.

Not every organization needs every AWS service on day one. A smaller company with a focused application stack may begin with strong identity, logging, backups, and alert handling. A larger regulated operator may need deeper segmentation, a SIEM integration, formal change control, and 24/7 monitoring. The right design follows service criticality and risk, not a generic cloud checklist.

Evidence matters as much as configuration

NIS2 readiness often breaks down when a team can demonstrate that a control was enabled but cannot show that it is operating consistently. Audit-ready evidence should be built into normal cloud operations rather than collected in a rush before an assessment.

For example, a policy requiring quarterly access reviews should produce review records, reviewer approvals, exceptions, and remediation evidence. A backup policy should produce backup reports, restore-test results, recovery decisions, and lessons learned. An incident plan should produce exercise records and after-action improvements.

AWS configuration evidence can support this work through CloudTrail records, AWS Config history, Security Hub findings, IAM reports, ticketing records, pipeline logs, and AWS Artifact documentation. However, raw technical data alone is not enough. An assessor or executive needs context: what the control is intended to achieve, who owns it, how often it runs, what happens when it fails, and where exceptions are approved.

A well-maintained control register is useful here. Keep it concise and map each control to the relevant NIS2 risk area, AWS service or operational process, owner, evidence source, and review frequency. This becomes a working management tool rather than another document that goes stale.

Incident reporting requires operational preparation

NIS2 incident reporting timelines can move much faster than many internal escalation processes. The directive establishes staged notification expectations for significant incidents, while the final details must be interpreted through applicable national rules. Teams should not wait for an event to decide who has authority to classify an incident or contact regulators, customers, insurers, and legal counsel.

Your AWS incident response plan should define how alerts become cases, who has access to emergency accounts, how logs are preserved, and how affected workloads can be isolated without destroying evidence. It should also establish decision points for invoking executive leadership and external specialists.

Run tabletop exercises against realistic scenarios: compromised cloud credentials, ransomware affecting a connected environment, a third-party SaaS outage, accidental deletion, exposed data, or a regional service disruption. Test the technical response and the communication path. An engineering team may contain an issue quickly while the organization still fails because reporting, documentation, and customer communications were delayed.

Supplier risk includes your cloud operating model

AWS is a major supplier, but it is not the only supplier that matters. NIS2 supply-chain expectations extend to managed service providers, software vendors, CI/CD platforms, identity providers, monitoring tools, contractors, and any organization with privileged access or operational dependency.

Assess suppliers based on the service they provide and the access they hold. A vendor with read-only marketing analytics access does not carry the same risk as a managed security provider with administrator privileges. Contracts, data processing terms, access controls, security commitments, incident notification obligations, and exit plans should reflect that difference.

This is also where fragmented IT management creates unnecessary risk. When several vendors each own a narrow slice of the environment, no one may be accountable for cross-platform incident response, configuration drift, or recovery testing. A single technical partner can reduce that coordination burden, provided responsibilities remain explicit and transparent.

NIS2 Compliance on AWS: Common Questions

Does AWS certify that our organization is NIS2 compliant?

No. AWS can provide security and compliance documentation for its services, but NIS2 compliance is assessed at the organization level. Your governance, workloads, identities, data handling, suppliers, processes, and incident response all matter.

Is a Well-Architected Review enough for NIS2?

A Well-Architected Review is a strong technical input, especially across security, reliability, and operational excellence. It is not a complete NIS2 program because it does not replace legal scope analysis, management governance, supplier management, policy ownership, or incident reporting procedures.

Do we need a SIEM to meet NIS2 expectations?

Not always. The requirement is to detect, investigate, and respond effectively. A centralized SIEM may be justified for complex, high-volume, or highly regulated environments. Smaller teams may initially use AWS-native monitoring and a managed security workflow, provided log coverage, alert triage, retention, and escalation are demonstrably effective.

How often should we test backups and incident response?

The answer depends on the criticality of the workload and the impact of outage or data loss. Critical systems generally need more frequent restore tests and exercises than low-impact internal tools. Set a defined cadence, document results, and increase testing after material changes or incidents.

Can a managed services provider handle NIS2 operations?

Yes, a managed provider can operate monitoring, patching, backups, access reviews, infrastructure automation, and incident support. The organization should retain governance, approve risk decisions, review reporting, and ensure that service responsibilities are documented. Advanced Vision IT helps businesses turn these responsibilities into measurable AWS operating practices rather than disconnected compliance tasks.

The most effective path is to treat NIS2 as a reliability program with regulatory consequences. Start with the critical services your business cannot afford to lose, establish ownership and evidence around the controls that protect them, and test the response before an incident forces the issue.

Author: Yavor Y. Zlatev CEO of AdvisionIT
Date: 18.08.2026