NIS2 readiness for EU SaaS · the 90-day playbook

NIS2 has been in force since 17 October 2024 and the Hungarian transposition (2025 government decree) makes the obligations concrete for any "important" or "essential" entity. If your SaaS serves EU customers and crosses any one of: 50 staff, €10M revenue, healthcare / fintech / utilities sector, or critical-infrastructure adjacency · you're in scope.

The teams that wait for the first incident to do the paperwork have already lost the audit. Below is the 90-day plan we run on every cybersecurity engagement that lands a SaaS team from "vaguely aware" to "evidence pack on the shelf". Built from what landed in 2025 audits and what didn't.

Who NIS2 actually applies to (and who skips most of it)

NIS2 splits in-scope organisations into "essential" (banks, healthcare, energy, transport, large cloud providers) and "important" (SaaS over 50 staff or €10M revenue, ICT-managed services, food, manufacturing, postal). Essential entities get inspected proactively; important entities get inspected after a triggering event. The obligations are similar; the inspection cadence is the difference.

If you're under 50 staff and under €10M and not in a flagged sector · you're not directly in scope. But your customers might be, and their procurement departments will require NIS2 attestations from you starting Q4 2025. The downstream pressure means most B2B SaaS in 2026 ends up running this playbook either way.

Weeks 1-3 · Incident-response runbook (the first audit ask)

The single thing every NIS2 inspector asks for first: "show me your incident-response procedure." If the answer is "we're written down somewhere in the team Notion", the audit is over. NIS2 wants three concrete artifacts:

1. 24-hour early warning template · who, what, when, severity, currently-known impact, ongoing mitigation actions.
2. 72-hour incident assessment · root cause hypothesis, scope of affected data / systems, list of affected customers, planned recovery steps, contact channel for follow-up.
3. 1-month closing report · final root-cause analysis, full impact statement, lessons learned, structural fixes implemented, evidence of fix.

All three should be pre-filled with the studio's contact data, the national-CSIRT submission portal URL, and the on-call escalation tree. The on-call engineer at 3am should be filling in three blanks, not authoring the document from scratch.

# runbooks/incident-early-warning.yml · template the on-call fills in
incident_id: "INC-2026-04-29-01"
detected_at: "2026-04-29T03:14:00Z"  # ISO 8601 UTC
severity: "Sev1"  # Sev1/Sev2/Sev3 mapped to NIS notification triggers
known_impact: "User authentication degraded · ~12 % of logins failing"
ongoing_actions:
  - "Rolling back deployment of commit 9a3b7e2"
  - "Scaling auth service to 4x capacity"
contact_for_followup: "incident@dfieldsolutions.com · +36 70 ..."
csirt_notification:
  submitted: false  # flip to true once filed via NBH portal
  expected_by: "2026-04-30T03:14:00Z"  # 24h from detected_at

Week 4 · Supply-chain risk register

Most production-grade SaaS depends on 8-15 critical third-party vendors (AWS / GCP / Azure, Stripe, SendGrid, Cloudflare, Datadog, GitHub, Auth0). NIS2 wants a written assessment of each: what does this vendor do, what data flows to them, what's their attestation status, what's the impact if they fail, and what's the fall-back plan?

A practical register fits on one spreadsheet. One row per vendor · columns: vendor, function, data category, DPA on file (Y/N + date), SOC2 / ISO 27001 attestation (link + expiry), business-impact severity (1-5), fallback plan (free text). Sort by impact severity. Anything in row 1-3 without a current attestation goes on a 30-day quarantine list · either get the paperwork or migrate.

Weeks 5-7 · Access management overhaul

Three things every NIS2 inspector verifies in week-five evidence:

• MFA on every production access · no exceptions for ops, admins, or the founder.
• Long-lived secrets rotated within 6 months · API keys, database passwords, signing keys, OAuth client secrets.
• Just-in-time elevated access · nobody holds permanent production-write rights. Elevation is requested, time-boxed (typically 4 hours), logged, and auto-expires.

Tooling-wise: Azure PIM if you're on Microsoft, AWS IAM Identity Center + temporary policies if you're on AWS, 1Password Secrets Automation as a vendor-neutral option. The point is the audit log: "engineer X requested prod-write at 14:32, used it for 22 minutes, expired at 18:32" · with the timestamps in a queryable log.

Weeks 8-9 · Patch SLA + automated dependency updates

Internal SLA we ship on every NIS2 engagement: critical CVE 72 hours, high 7 days, medium 30 days, low next-quarterly-window. Wire automated dependency updates (Renovate or Dependabot) so a new CVE auto-creates a PR + an issue with the right severity tag.

The wiring matters more than the SLA itself. A patch SLA written down but executed manually slips constantly · automated PRs that the on-call engineer just merges (with regression tests in CI) get the SLA met without anyone tracking calendars.

Weeks 10-11 · Tabletop exercise

Pick a realistic incident scenario and run the runbook end-to-end. Examples we've run with clients:

• Stripe API key leaked via a misconfigured CI runner · how do we detect, rotate, notify customers, file the early warning?
• Compromised dependency in the build chain (npm install pulls a malicious update) · how do we contain, rebuild, attest the next deploy?
• Database read-replica exposed publicly for 14 minutes · how do we measure exposure, notify, file the 72-hour assessment?

Time every phase. The first tabletop usually exposes 3-5 bottlenecks (the on-call doesn't know who to call at the national CSIRT, the runbook is in a Notion page nobody can find at 3am, the early-warning template requires data that takes 4 hours to gather). Fix all of them before the real incident exposes them.

Week 12 · Team training + audit-ready evidence pack

Two-hour session walking the whole team through the runbook + access policy + tabletop after-action. NIS2 wants evidence of training; a calendar invite + slides + a sign-in sheet is the evidence. Pin everything in a single folder named `nis2-evidence/` with sub-folders per audit ask:

• `runbooks/` · incident response, escalation, communication templates.
• `vendors/` · supply-chain risk register, DPAs, attestations with renewal dates.
• `access/` · access policy, MFA enrolment evidence, JIT log samples.
• `patches/` · patch SLA policy, sample tickets showing the SLA being met.
• `tabletops/` · after-action reports, fixes applied with timestamps.
• `training/` · session materials, attendance log, signed acknowledgements.

Where this fits in our cybersecurity engagement

We run this 90-day playbook end-to-end inside our Cybersecurity service as a build sprint or a 3-month embedded retainer · the audit tier surfaces the gaps, the build / retainer ships the fixes. Typical engagement € 18-32k for the build sprint variant; € 9-12k/month for the retainer variant.

If you're approaching the deadline (Q4 2025 procurement asks from larger customers, or a planned audit in Q1 2026), the playbook can compress to 60 days with weekend overlap on the runbook + tabletop weeks. Anything tighter than 60 days is theatre · the tabletop has to actually catch the bottlenecks before the inspector does.

The pricing page has the tiers; the contact page takes a sentence and we reply within 24 hours. EN or HU.