JASMA

If you’ve ever wished cybersecurity regulations came with a simple on/off switch, the EU’s NIS 2 Directive is here to lovingly take that dream, put it in a risk register, and assign it an owner. NIS 2 (Directive (EU) 2022/2555) raises the cybersecurity baseline across the European Union by expanding who’s covered, tightening incident reporting timelines, and making executive leadership explicitly accountable for cyber risk management.

And yesthis matters to U.S. organizations. Even if your headquarters is in “somewhere with great barbecue,” your customers, subsidiaries, suppliers, cloud footprint, or managed services relationships may connect you to EU scope. NIS 2 isn’t just another compliance checkbox; it’s a framework that pushes organizations toward measurable resilience: prevent what you can, detect what you can’t prevent, and prove you can recover quickly when reality does what it does.

What NIS 2 Is (and Why It’s a Bigger Deal Than NIS 1)

NIS 2 in plain English

NIS 2 is the EU’s updated cybersecurity directive that replaced the original NIS Directive. It broadens sector coverage, standardizes expectations across Member States, and strengthens supervision and enforcement. Practically, it means more organizations must implement “appropriate and proportionate” cybersecurity risk-management measures, report significant incidents quickly, and demonstrate governanceespecially at the management/board level.

Why U.S. companies keep showing up in NIS 2 conversations

Three common reasons:

• You operate in the EU: You have an EU subsidiary, branch, or establishment delivering services in covered sectors.
• You serve EU customers digitally: Certain digital and infrastructure services can pull in non-EU organizations when services are offered within the EU (and may require an EU representative).
• You’re in the supply chain: Even if you’re not directly regulated, your EU-regulated customers will push requirements down through contracts, security questionnaires, audits, and “friendly” emails that start with: “Per NIS 2…”

Who Must Comply: Essential vs. Important Entities

The “size-cap” rule (aka: medium/large companies, welcome to the party)

NIS 2 generally applies to medium-sized and large entities operating in listed sectors. A common rule of thumb is that organizations over the “medium” threshold (often described as more than 50 employees and more than €10 million in turnover and/or balance sheet total) should assume they need a careful scope reviewespecially if they operate in critical industries.

Sector coverage is broader than most people expect

NIS 2 splits covered sectors into two big buckets:

• Annex I (high criticality): think energy, transport, banking/financial market infrastructure, health, drinking water/wastewater, digital infrastructure, ICT service management (including certain managed services), public administration, and more.
• Annex II (other critical sectors): think postal/courier, waste management, chemicals, food, manufacturing of certain critical products, and additional digital services.

Entities in scope are categorized as Essential Entities or Important Entities. Both must meet core requirements, but supervision and enforcement intensity can differ (more on that in a minute).

Quick examples (because “Annex I” isn’t a vibe)

• Essential Entity example: A mid-to-large regional hospital network in the EU, or a cloud provider supporting critical public services.
• Important Entity example: A large food producer, a courier company, or a manufacturer in a listed “other critical” sector.
• Supply chain reality: A U.S. SaaS vendor selling into the EU may not love the phrase “security-related aspects concerning relationships with direct suppliers,” but their EU customers definitely do.

The Core Obligations Under NIS 2

1) Cybersecurity risk-management measures (the “do the work” part)

NIS 2 requires organizations to implement appropriate and proportionate technical and organizational measures to manage cyber risks and minimize incident impact. The directive describes an “all-hazards” approach, meaning your controls should help across a range of threatsfrom ransomware to insider risk to supply chain compromise.

While the exact implementation can vary by Member State, the expected control themes usually include:

• Risk analysis and security policies: documented risk assessment, governance, and security baseline standards.
• Incident handling: detection, triage, containment, forensics, communications, and post-incident review.
• Business continuity and crisis management: backups, disaster recovery, resilience testing, and “keep-the-lights-on” planning.
• Supply chain security: vendor risk management, procurement controls, and security requirements for direct suppliers/service providers.
• Secure development and maintenance: secure SDLC, change control, vulnerability handling, and patch management.
• Effectiveness testing: audits, security testing, and metrics that prove controls work in real life.
• Cyber hygiene and training: workforce training, role-based security expectations, and safe operational practices.
• Access control and asset management: identity governance, least privilege, inventory, and lifecycle control.
• Cryptography/encryption and secure communications: protect data and ensure secure internal communications, especially for emergencies.
• Multi-factor authentication (MFA): explicitly called out frequently in guidance and industry interpretations.

Practical translation: if you can’t answer “What do we run?”, “Who can access it?”, “How do we patch it?”, “How do we detect compromise?”, and “How do we recover?” without opening six spreadsheets and sighing heavily, you have work to do.

2) Governance and management accountability (the “boardroom gets a seatbelt” part)

NIS 2 doesn’t treat cybersecurity as a hobby for the IT department. Management bodies are expected to approve cybersecurity risk management measures, oversee implementation, and receive training so they can make informed decisions. Depending on national implementation and enforcement, leadership may face consequences when oversight is inadequate.

If your leadership team hasn’t had a tabletop exercise since “the cloud” meant weather, NIS 2 is your sign to schedule one.

3) Incident reporting: the famous “24–72–30” timeline

NIS 2 tightens incident notification timelines for significant incidents. While specifics can vary by national law and sector, the directive is widely understood through a staged reporting clock:

• Within 24 hours: an early warning after becoming aware of a significant incident (think “heads up, this is real”).
• Within 72 hours: a more complete incident notification (initial assessment, likely impact, indicators if available).
• Within one month: a final report (root cause, remediation, lessons learned), with progress updates if the incident is ongoing.

The spirit here is speed plus transparency. Regulators don’t expect perfect information at hour 23. They do expect that you’ve started response actions, preserved evidence, assessed potential cross-border/operational impact, and can communicate coherentlywithout your incident response channel devolving into a “who is even on this thread?” situation.

A concrete example: ransomware in a logistics operation

Imagine a Europe-based logistics subsidiary gets hit with ransomware on a Friday night (because cybercriminals also enjoy weekends). Systems that route shipments go down, and you suspect data exposure.

• First 24 hours: declare a significant incident internally, activate incident response, contain spread, start forensic capture, and prepare an early warning with what you know: affected services, initial impact, and immediate measures.
• By 72 hours: refine impact estimates (service disruption scope, operational delays), document suspected entry point (phishing, vulnerable edge device, supplier access), and share meaningful technical/organizational details with the relevant authority/CSIRT.
• Within a month: deliver the final narrative: root cause findings, remediation steps, security improvements, and how you’ll prevent recurrence (yes, that includes the uncomfortable parts, like “we had MFA gaps”).

4) Supply chain and third-party risk (because your vendors are part of your security story)

NIS 2 explicitly addresses security-related aspects of relationships with direct suppliers and service providers. That means procurement and vendor governance can’t be “check the SOC 2 box and hope for the best.” You’ll likely need:

• Vendor risk tiering (who can hurt you the most, fastest).
• Minimum contractual security controls (notification clauses, access controls, vulnerability management, subprocessor transparency).
• Evidence requests that don’t rely on vibes (security testing results, certifications, resilience posture).
• A plan for supplier incidents (how you’ll respond when your provider has a bad day).

For U.S. companies, this is where NIS 2 “arrives” even if you’re not directly regulated: EU customers will ask you to meet these expectations so they can meet theirs.

5) Documentation and proof (compliance is a verb)

NIS 2 compliance isn’t just implementing controlsit’s being able to demonstrate them. Expect to maintain evidence like:

• Risk assessments and policy approvals.
• Security architecture and asset inventory artifacts.
• Training records (including management training).
• Incident response runbooks, exercise reports, and post-incident lessons learned.
• Supplier due diligence, security requirements, and monitoring.
• Metrics that show effectiveness (patch SLAs, MFA coverage, recovery testing results).

Supervision, Enforcement, and Penalties

Essential vs. Important: different supervision style, same need to be ready

A commonly discussed distinction is that Essential Entities may face more proactive supervision (audits and inspections), while Important Entities may see more reactive enforcement (often triggered by evidence of noncompliance or incidents). Either way, a “we’ll deal with it later” strategy tends to fail right around the moment you’re busy dealing with an incident.

Fines and corrective measures

NIS 2 provides for significant administrative fines. The widely cited ceilings are:

• Essential Entities: up to €10 million or 2% of worldwide annual turnover (whichever is higher).
• Important Entities: up to €7 million or 1.4% of worldwide annual turnover (whichever is higher).

Money isn’t the only lever. Authorities can also use remediation orders, audits, increased oversight, anddepending on national implementationmeasures affecting management roles. Translation: the “find out” phase may include more than a fine.

A Practical Compliance Roadmap (Designed for Humans)

Step 1: Confirm scope and ownership

Start by mapping:

• Which legal entities operate in the EU.
• Which services you provide into the EU (especially digital infrastructure and managed services).
• Which business lines align with Annex I / Annex II sectors.
• Who owns NIS 2 compliance across legal, security, IT, procurement, and business leadership.

Step 2: Perform a gap assessment against NIS 2 control themes

Use a structured framework (many organizations map to ISO 27001/27002, NIST CSF, or similar) and then ensure NIS 2-specific requirements are explicitly coveredespecially board accountability, supply chain controls, and reporting timelines.

Step 3: Build a 24–72–30 incident reporting playbook

Don’t wait for an incident to figure out reporting. Pre-build:

• Criteria for what counts as a “significant incident” in your context.
• Draft templates for early warning, 72-hour notification, and final report.
• An escalation tree that includes legal and executive sign-offfast.
• Tabletop exercises that stress the timeline (yes, set a timer; it’s terrifying and useful).

Step 4: Upgrade third-party risk management

Focus on direct suppliers and service providers that are most critical to your operations. Build minimum requirements into procurement and contracting, and ensure security teams have real influence before deals close. (“We’ll add it in the renewal” is not a control.)

Step 5: Formalize management training and governance cadence

Make cybersecurity governance routine:

• Quarterly reporting on risk posture and control effectiveness.
• Annual executive training tied to real threats and business impact.
• Clear documentation showing management approval and oversight.

Step 6: Prepare your evidence package

When regulatorsor customersask “show me,” you don’t want to reply with “give me a week.” Maintain an audit-ready set of policies, procedures, logs, and metrics that demonstrate security-by-design and operational resilience.

Common Mistakes That Make NIS 2 Harder Than It Needs to Be

• Treating NIS 2 like an IT project: it’s a business risk management requirement with executive accountability.
• Waiting for perfect scope certainty: start with a defensible assessment and refine as national laws clarify details.
• Ignoring vendors: supply chain security is not optional, and your contracts will be judged in practice.
• No rehearsal for reporting: the 24-hour clock is not the time to learn where the incident template lives.
• Measuring activity, not effectiveness: “we trained people” matters less than “phishing success dropped and MFA coverage increased.”

NIS 2 in the Broader Compliance Ecosystem

Many organizations will align NIS 2 efforts with overlapping requirements from other regimes (for example, GDPR breach notifications, sector-specific rules like DORA for financial services, and resilience expectations in critical infrastructure). The smartest approach is usually to build one mature security and incident response program that can satisfy multiple reporting and governance obligations, instead of creating separate “compliance islands” that don’t talk to each other.

Final Thoughts

NIS 2 is ultimately about trust: trust that essential services will keep running, trust that organizations can prevent avoidable incidents, and trust that when something goes wrong, the response is fast, documented, and effective. Compliance isn’t magic armor, but a well-run NIS 2 program will make you better at security in ways that customers, regulators, and your future self will appreciate.

500-Word Field Notes: What NIS 2 Prep Looks Like in Real Life

Here’s the part nobody puts in the glossy compliance brochures: NIS 2 readiness is less like “install a tool” and more like “teach an organization to behave calmly during a fire drill.” The most successful teams treat it as a change-management program with security outcomes, not just a policy refresh.

First, scoping is always messier than the kickoff slide suggests. Business units rarely describe themselves as “Annex I digital infrastructure.” They describe themselves as “the team that keeps the platform alive” or “the folks who run the warehouse systems.” That’s normal. What helps is translating legal categories into service maps: what services do we provide, where are they delivered, who depends on them, and what happens if they go down? Once you do that, you can stop arguing about labels and start discussing impactwhich is where cybersecurity decisions actually live.

Second, incident reporting is a muscle, not a memo. Many organizations think they’re “ready” because they have an incident response plan in a shared drive. NIS 2 tests whether that plan works under pressure. The best rehearsal is a timed tabletop: set a 24-hour countdown, drip in incomplete information, and force the team to draft a credible early warning. You’ll quickly discover whether legal review is available on weekends, whether executives know what “significant incident” means, and whether anyone can find the approved contact process without summoning three people and a Ouija board.

Third, vendor conversations get real. NIS 2 pushes organizations to consider supplier vulnerabilities and security practices, which means procurement and security must actually collaborate (shocking, I know). In practice, the “win” is establishing a handful of minimum controls that scale: timely incident notification commitments, MFA requirements for privileged access, vulnerability management expectations, and clarity on sub-vendors. Don’t aim for a 40-page security addendum that nobody reads; aim for enforceable requirements and a monitoring plan you can execute.

Fourth, leadership engagement changes the tone of the program. When executives receive training tied to business risk (service uptime, customer trust, and regulatory exposure) and then formally approve risk-management measures, the rest of the organization takes the work seriously. Suddenly, patching isn’t “IT being picky,” it’s “we’re reducing outage risk and regulatory exposure.” That shift is pricelessand cheaper than learning the lesson during a real incident.

Finally, the teams that thrive build “evidence by default.” Instead of scrambling to prove compliance, they design processes that naturally generate proof: ticketing that documents remediation, dashboards that track MFA coverage, vendor reviews that produce records, and post-incident reviews that show continuous improvement. It’s not glamorous, but it turns compliance from a seasonal panic into a steady operating rhythm. And if your coffee intake becomes a KPI, at least make it a leading indicatornot the whole strategy.