⚠  DRAFT

NIS2 Alignment Note

Directive (EU) 2022/2555  ·  Product: Exceptao  ·  Last updated: 2026-09-19  ·  Version: 1.0

This note says what Exceptao does, and does not do, for an organisation working through its obligations under the NIS2 Directive. It is written for the person who has to answer for those obligations — a CISO, a head of security, a compliance lead — not for a procurement checklist.

It is not legal advice and it does not establish whether you are in scope. NIS2 is a directive, so your obligations are the ones your own Member State enacted, and those differ. Compliance remains yours; Exceptao is a tool you use to carry it out and to prove that you did.
What this note is careful about. Every capability described below was read off the running code on 2026-09-19, and the sections that matter most are the negative ones. §7 says plainly that there is no designation record. §8 lists the NIS2 features that exist in the Polish public-sector build and are not part of Exceptao. §3 says which evidence export exists for the NIS2 catalogue and which does not. A note that only lists what a product has is not useful to someone who has to rely on it.

§1. Scope — and why a directive is harder than a regulation

NIS2 is a directive. It does not apply to you; your Member State’s transposition of it does. In practice that means the following vary by country, and Exceptao does not model the variation:

If you are established outside the EU and offer in-scope services within it, Art. 26(1)(b) and Art. 26(3) may place you under the jurisdiction of the Member State where your designated representative is established. Groups operating across several Member States should look at the “main establishment” rule in Art. 26(2) before assuming they answer to one regulator.

Exceptao does not determine your scope, and deliberately does not offer a wizard that pretends to. A self-identification questionnaire exists in the platform’s Polish public-sector module, encoding Polish statutory criteria in Polish; it is not part of the Exceptao build and it would be wrong to point an Irish or Australian entity at it. See §8.

§2. What Exceptao is, in this picture

Exceptao is a control-and-evidence registry entered through exception management. It records the controls you say you operate, the evidence you hold for them, the exceptions where you knowingly do not comply, the risks you have accepted, and — where the module is enabled — the incidents you are working. Everything it records goes into a per-tenant, append-only, hash-chained audit log that you can verify yourself without trusting us.

What it is not is an automated control tester. It does not connect to your endpoints, your cloud accounts or your identity provider to observe whether a control is actually operating, and it does not claim to. The distinction shows in the grading vocabulary, which is worth reading literally:

StateWhat it actually means
not_coveredNo control in your register is mapped to this catalogue item.
partially_coveredA mapped control exists, and there is at least one open exception against it.
stale_evidenceA mapped control exists with no open exception, but its most recent evidence is older than the freshness window — or there is none.
coveredA mapped control exists, no exception is open against it, and its evidence is within the freshness window. This is a declaration with dated evidence attached. It is not a test result.
verifiedReserved for a catalogue item attested by a recent passing machine check run by the platform itself — the check result is the evidence, system-authored and timestamped.

No NIS2 catalogue item can currently reach verified. The map from machine checks to catalogue codes is a reviewed artefact, deliberately conservative, and today it attests codes in NIST CSF 2.0, ISO/IEC 27001:2022, SOC 2 and PCI DSS v4 only. Nothing in it points at the NIS2 catalogue. For NIS2, the honest ceiling is covered: declared, evidenced, dated, and recorded in a log that cannot be quietly rewritten afterwards.

That is the whole proposition, and it is a narrower one than the automated-compliance vendors make. What you get is not “we tested it for you”; it is “here is exactly what you claimed, when you claimed it, what you attached, who approved it, and proof that none of it was edited after the fact.”

Which modules an Exceptao tenant actually has

The platform hosts several modules; they are enabled per subscription rather than by brand. A tenant created on the Exceptao brand is provisioned with the Exceptions module by default. Risk Register and Incidents are entitlements added to a subscription, not defaults. The NIS2 sections below note which module each capability needs, because a capability you are not entitled to is not a capability.

§3. The NIS2 catalogue that ships

The directive is seeded into the platform’s framework catalogue as eu-nis2 (“EU NIS2 Directive”, version 2022/2555), with thirteen catalogue controls:

The descriptions are paraphrased summaries, not verbatim quotation; the canonical text is reachable from the framework’s EUR-Lex link. The catalogue is platform-shared and brand-neutral — it is not a Polish artefact with English labels on it.

How a tenant uses it

  1. Activate the eu-nis2 framework for your tenant.
  2. Create a control assignment against each catalogue item you intend to answer, optionally scoped to one organisational unit.
  3. Attach evidence to the assignment. Evidence objects go to Cloudflare R2 and are served through pre-signed URLs valid for 15 minutes. Upload, download and removal are each written to the audit chain.
  4. Raise an exception wherever you knowingly do not meet a measure, with a justification, a compensating control and an expiry date. This is the part of the product the rest of it is built around: NIS2 does not require perfection, it requires that the gaps are known, owned, time-boxed and reviewed.

What you can export today — and what you cannot

ArtefactStatus for an Exceptao tenant
Framework control catalogue and your activationsAvailable. Read through the catalogue and tenant-activation endpoints.
Control-coverage reportAvailable as a cross-framework coverage view over your control register.
Custom report builder, CSV exportAvailable. Each export is audit-logged.
Audit-log CSV export and the verification endpointAvailable to the auditor role and Tenant Admin. See §6.
Board-ready framework coverage PDFNot available for NIS2. The one-click PDF exists for ISO/IEC 27001:2022, SOC 2, NIST CSF 2.0 and PCI DSS v4. A request for the NIS2 slug returns 404. Stated because it is exactly the artefact a reader of this section would assume exists.
Signed evidence “audit pack” ZIPNot available. The pack builder exists in the platform, but its only HTTP entry point sits inside the Polish public-sector module and is gated on that module’s entitlement. See §8.

§4. Art. 21(2) — measure by measure

Three columns, and the third is the one to read. “What remains yours” is not boilerplate: for most of these measures the substantive work is done in your estate and Exceptao is the register that records it.

Art. 21(2)What Exceptao providesWhat remains yours
(a) Risk analysis and information system security policies Exceptions: policy-exception tracking with justification, compensating controls, approval routing and a mandatory expiry date, so a deviation cannot quietly become permanent. Risk Register (entitlement): a risk catalogue with treatment actions, a risk-appetite policy, and a next-review date per risk. Writing the policies. The platform tracks deviation from and acceptance of a policy; it does not author one.
(b) Incident handling Incidents (entitlement): the full Art. 23 lifecycle — see §5. Detection, containment, eradication and recovery. Submitting the report to your national authority.
(c) Business continuity, backup management, crisis management A catalogue item to assign and evidence against. Separately, the Operator’s own continuity posture for the Service — dual-provider encrypted backups, point-in-time recovery, and two restore drills — is documented at /legal/security and is relevant to your assessment of us as a supplier, not to your own (c). Everything substantive. There is no purpose-built business-continuity workflow in the product; you track (c) as a control assignment with your BCP attached as evidence.
(d) Supply chain security A vendor register with assessments, and the ability to turn a vendor finding into a risk register entry. Thirty-one frameworks are seeded in the catalogue for mapping, including NIST CSF 2.0, NIST SP 800-53, MITRE ATT&CK, SLSA, CISA CPGs, DORA and the EU Cyber Resilience Act. Licensing caveat: ISO/IEC 27001 and 27002, SOC 2, IEC 62443, CIS Controls and PCI DSS are seeded as control shells — code and neutral label only, no licensed text — because their text is not ours to redistribute; you supply your own copy. The contracts, the diligence questionnaires you actually send, and the decision. §9 covers assessing the Operator as one of your suppliers.
(e) Security in acquisition, development and maintenance A catalogue item to assign and evidence against. The Operator’s own development and supply-chain posture is at /legal/security. All of it. This measure is about your systems; Exceptao is not your development environment.
(f) Assessing the effectiveness of risk-management measures Review cycles on exceptions with a recorded attestation and a due date; a next-review date per risk with treatment actions tracked to completion; evidence freshness enforced in the coverage grading, so an unreviewed control decays to stale_evidence rather than sitting green for ever. The assessment itself. There is no effectiveness score and no effectiveness KPI in the product; what it gives you is a review cadence that you can prove you kept.
(g) Cyber hygiene and cybersecurity training A catalogue item to assign and evidence against, and control assignments for hygiene measures such as patch management or credential policy. The training, and the completion records. Training-completion tracking is not part of the Exceptao build — the importer that exists is scoped to the Polish public-sector module and is scheduled only on that brand’s host. See §8.
(h) Cryptography and encryption policy A catalogue item to assign your own policy against. Separately, what the Service enforces for your data: TLS at the edge, a LUKS-encrypted data volume unlocked from network-bound Tang servers, Fernet-encrypted credential columns, and provider-side encryption for evidence objects — with the honest caveat that per-tenant data encryption keys and client-side evidence encryption are designed and not built, so Cloudflare holds the key to evidence objects at rest today. Detail at /legal/security. Your own cryptographic policy, key management and inventory.
(i) Human-resources security, access control, asset management Role-based access control with least-privilege built-in roles and tenant-defined custom roles; SSO through your own identity provider; organisational-unit scoping so a unit-bound role sees only its own records; an asset register with vulnerability records; and audit-logged de-provisioning — member removal and role changes are written to the chain under the acting operator’s identity. Your HR security procedures. Note the precise wording above: the platform logs de-provisioning events and, since 2026-09-21, does run periodic access-review campaigns — a point-in-time list of every member, role grant and scope, signed by a tenant admin, with a hash of the signed list written to the audit chain. It is a self-attestation: we prove the signature and the population, not that the reviewer read the list, and it is never presented as verified evidence.
(j) Multi-factor authentication and secure communications The strongest claim in this table, and it is enforced rather than offered. MFA is mandatory for every account holding a local password, on every pricing tier: middleware refuses every authenticated API call from an account with no second factor until it enrols one. Second factors are TOTP or a WebAuthn passkey (FIDO2, platform or roaming authenticator), with signature-counter validation and automatic revocation on a counter regression. Accounts that sign in through your identity provider hold no local password and are governed by your IdP’s policy. SSO is available over OIDC (authorisation code with PKCE only) and SAML 2.0. All traffic is TLS, terminated at the Cloudflare edge; the negotiated minimum is an edge configuration rather than an application setting — /legal/security §6.1 states it. Enforcing MFA in your own IdP for SSO accounts — that is the one path Exceptao cannot police, because it never sees a password for those users.

§5. Art. 23 — the 24-hour / 72-hour / one-month cadence

Requires the Incidents module entitlement.

StageDeadlineWhat the platform does
Early warning24 hours from detectionOn creation you record the detection timestamp, and the deadline for each stage is computed from it directly — detection + 24 hours, + 72 hours, + 30 days. Submitting a stage writes a structured report and an audit-chain entry. Only incidents assessed as significant carry deadlines at all; an incident that has completed its lifecycle has no next deadline and drops out of the reminders.
Incident notification72 hours from detection
Final report30 days from detection

Reminders. A pre-deadline warning is sent four hours before a stage deadline, to the holders of the built-in itso role and, where no such role is assigned, to the tenant administrators. The job runs hourly and asks “is a deadline due within four hours”, so an incident gets several chances to be seen; the audit row makes every run after the first a no-op for that stage, and advancing a stage earns a fresh reminder rather than being swallowed by a cooldown. A separate daily digest reports stages that are already overdue.

What the platform does not do: it does not submit anything to any authority. Exceptao structures the content and holds you to the clock; a named person at your organisation files the report through your Member State’s own channel. Cross-border impact under Art. 23(6) and any parallel GDPR Art. 33 notification are likewise yours to make.

§6. The evidence an auditor can actually check

This is where Exceptao differs from a spreadsheet, and it is worth understanding mechanically rather than taking on trust.

Two limits, stated because an auditor will find them anyway. The chain evidences integrity, not truthfulness: it proves a row was not altered or removed after it was written; it does not prove the row was accurate when written. And an actor with superuser access to the database could drop the trigger — which is an auditable schema change rather than a silent edit, which is the property the design is actually buying.

§7. Accountability roles — and the designation record we do not have

The platform ships built-in roles: tenant_admin, submitter, approver, auditor, and itso (a unit-scoped reader, and the role the incident deadline reminders address). Roles can be assigned at tenant level or bound to a single organisational unit, and tenants may define custom roles over the same permission vocabulary. Every role assignment and removal is written to the audit chain.

There is no designation record. Several NIS2 transpositions require an entity to designate a named individual accountable for cybersecurity, to document the designation, and to be able to produce that documentation on inspection. Exceptao does not model that. There is no designation object, no validity period, no legal-basis reference and no generated designation letter — what exists is an RBAC role called itso and the audit-chain record of who was granted it and when.

That is a real capability and it is not the same artefact. It is stated here explicitly because the sibling Polish document published a field-by-field designation-record schema that does not exist in any build, which is precisely the kind of claim this note is written to avoid. The designation record is on the roadmap; when it ships, this section changes.

§8. NIS2 features that are not part of Exceptao

The platform contains a Polish public-sector module built for the Polish Act on the National Cybersecurity System. It is a subscription entitlement rather than a brand restriction, so nothing in the authorisation layer would stop it being granted to an Exceptao tenant — but its content columns exist only in Polish, its statutory logic is Polish, and it is sold under a different brand. It should not be read as part of what you are buying here:

A prospective international customer who needs one of these should say so rather than assume it: the capability exists, the localisation does not.

§9. Assessing the Operator under Art. 21(2)(d)

If you are in scope of NIS2, adopting Exceptao makes the Operator part of your supply chain, and Art. 21(2)(d) puts the diligence on you. The documents to ask for are already published:

Incident notification to you. The DPA commits the Operator to notifying you of a personal data breach affecting your data without undue delay and within 72 hours of becoming aware, which is set to let you meet your own Art. 23 and GDPR Art. 33 clocks rather than to suit ours.

The gaps, so you do not have to find them. The Operator holds no SOC 2 or ISO/IEC 27001 certification. No independent penetration test has been commissioned. Per-tenant data encryption keys and client-side encryption of evidence objects are designed and not built, so evidence files are protected at rest by the storage provider’s own encryption, to which that provider holds the key. Of the two backup restore drills, one is automated and quarterly and the other is operator-run and cannot be scheduled as designed. These are stated here rather than left for your questionnaire because a supplier that makes you find its gaps has told you something already.

Is the Operator itself a NIS2 covered entity? [TO BE COMPLETED: the Operator’s own NIS2 scope determination — whether METAMORFOZIS GLETSCHMANN sp. j. falls within Annex I point 8 (digital infrastructure / managed service providers) as transposed in Poland, given its size. A legal determination, not a lookup; recorded in the legal-review queue and not guessed at here.]

§10. GDPR interface

In operating the Service the Operator processes personal data as your processor under GDPR Art. 28; that relationship is governed by /legal/dpa. Processing in which the Operator is itself the controller is recorded at /legal/ropa.

An incident record may contain personal data of individuals affected, and a NIS2 notification and a GDPR Art. 33 notification are separate obligations with separate recipients that frequently arise from the same event. Note one architectural consequence in particular: the audit chain retains the actor identity, IP address and user-agent of everyone who acted on an incident for the lifetime of the tenant account, and those fields cannot be erased without invalidating the chain. The erasure mechanism is pseudonymisation of the identity the row resolves to, not deletion of the row. This is set out fully in /legal/ropa under PA-002.

§11. What the platform does not do

§12. Contact

General and commercialhello@exceptao.com
Security disclosuressecurity@exceptao.com
Data protectionprivacy@exceptao.com
Legallegal@exceptao.com