NIS2 & UK NIS Regulations
Status: not directly in scope · supplier to in-scope entities · last updated 27 May 2026
The EU NIS2 Directive (Directive (EU) 2022/2555) and the UK Network and Information Systems Regulations 2018 (as amended) impose security and incident-reporting obligations on operators of essential or important services. Glassbreak is not currently directly in scope as an essential or important entity in either jurisdiction, but a non-trivial fraction of our customers are. This page describes our posture, the Article 21 risk-management measures we align to, and what we contractually offer customers who must answer NIS2 supplier-management questions about us.
Scope analysis
| Ref | Requirement | Status | How we meet it / gap |
|---|---|---|---|
| NIS2 Annex I (essential) | Sectors of high criticality | N/A | We are not energy, transport, banking, financial market infrastructure, health, drinking water, waste water, digital infrastructure as a DNS service provider / TLD registry / cloud / data centre / CDN / trust service provider / e-comms provider, ICT service management, public administration, or space. Not in scope as essential. |
| NIS2 Annex II (important) | Other critical sectors | N/A | We are not postal, waste management, manufacture/production/distribution of chemicals, food, manufacture of medical devices / computers / electrical equipment / machinery / motor vehicles, research, or any of the digital providers listed (online marketplaces, search engines, social networking platforms). Not in scope as important. |
| NIS2 Article 2(3) | Size threshold (medium-sized: ≥50 staff OR ≥€10M turnover) | N/A | Below threshold at current headcount and turnover. The size threshold is the primary scope filter for "important" entities; we are under it on both counts. |
| NIS2 supply-chain spillover | Supplier to in-scope entities — Article 21(2)(d) | Met | When an in-scope customer onboards Glassbreak, they MUST conduct an Article 21(2)(d) supply-chain risk assessment of us. This page provides the inputs they need; the standard contract terms below mirror typical NIS2 supplier clauses (notification SLAs, audit rights, sub-processor disclosure). |
| UK NIS Regulations 2018 | UK RDSP / OES status | N/A | We are not a Relevant Digital Service Provider (RDSP) — not an online marketplace, online search engine, or cloud computing service as defined by Schedule 1. Not an OES under any of the listed sectors. Same outcome as NIS2 EU side. |
Article 21 risk-management measures — our coverage
NIS2 Article 21(2) lists ten categories of risk-management measures that essential and important entities must implement. Customers who are themselves in scope must show their regulator that critical suppliers (including Glassbreak) apply equivalent measures. Our coverage:
| Ref | Requirement | Status | How we meet it / gap |
|---|---|---|---|
| 21(2)(a) | Policies on risk analysis and information system security | Met | Risk Assessment + Treatment Plan at /policies/risk-treatment-plan. Information Security Policy at /policies/information-security. Reviewed annually. |
| 21(2)(b) | Incident handling | Met | Incident-response procedure at /policies/incident-response with SEV-1/2/3/4 classification, response phases, customer-notification SLAs (SEV-1 ≤1h), and post-mortem template. |
| 21(2)(c) | Business continuity (backup management, disaster recovery, crisis management) | Met | Multi-cloud topology, 22 scripted DR scenarios, nightly backup integrity check. Full posture at /trust/iso-22301 with RTO/RPO per surface. |
| 21(2)(d) | Supply chain security | Met | Supply Chain Risk Management Plan at /policies/supply-chain-risk. Sub-processor intake + annual reassessment at /policies/procedures/supplier-assessment. Published sub-processor list at /legal/sub-processors with 14-day notification of changes. |
| 21(2)(e) | Security in network and information systems acquisition, development, and maintenance | Met | Controlled SDLC procedure at /policies/sdlc; security review mandatory in PR workflow; OpenTofu state under version control; no manual cloud-console changes. |
| 21(2)(f) | Policies and procedures to assess effectiveness of measures | Partial | Daily security-snapshot at /trust covers most operational controls; quarterly management-review cadence at /policies/cadences/management-review; full effectiveness-measurement programme tied to specific KRIs is in progress. |
| 21(2)(g) | Basic cyber-hygiene practices and security training | Met | Onboarding security training (/policies/onboarding §§4.3, 5, 8); annual refresher; phishing-resistant MFA enforced; role-specific training before production access. |
| 21(2)(h) | Policies and procedures regarding the use of cryptography and, where appropriate, encryption | Met | Cryptography policy at /technology/encryption: AES-256-GCM at rest, TLS 1.2+ in transit, Argon2id password hashing, hybrid PQ key wrapping (RSA-OAEP-8192 + ML-KEM-1024), Wycheproof vectors in CI. |
| 21(2)(i) | Human resources security, access control policies, asset management | Partial | Background checks for workforce members with production access (/policies/onboarding §3); RBAC implemented; centralised endpoint inventory not yet formal at current headcount. |
| 21(2)(j) | Use of multi-factor or continuous authentication, secured voice/video/text comms, secured emergency-comms systems | Met | MFA enforced for all administrative and customer-facing accounts; TOTP + WebAuthn supported; emergency-comms surfaces (ack tokens, message broadcast) are themselves the product — end-to-end encrypted with PQ-hybrid key wrapping. |
Incident reporting — our offer to in-scope customers
NIS2 Article 23 sets a three-stage incident reporting cascade to the competent authority / CSIRT for in-scope entities:
- Early warning — within 24 hours of becoming aware of a significant incident.
- Incident notification — within 72 hours, updating the early warning with an initial impact assessment.
- Final report — within one month, including a detailed description, severity, impact, and mitigating measures.
If an incident on Glassbreak infrastructure could trigger an in-scope customer's reporting obligation, we contractually commit to:
| Ref | Requirement | Status | How we meet it / gap |
|---|---|---|---|
| T+1 hour | Initial notification to affected customers (SEV-1) | Met | Confirmed within 1 hour of incident declaration. Sufficient for the customer to start their 24-hour early-warning clock with the competent authority. |
| T+24 hours | Initial impact assessment | Met | Affected scope, surfaces, customer-data implications. Aligned with the customer's 24-hour early warning to authorities. |
| T+72 hours | Updated impact assessment + indicators | Met | Indicators of compromise, attack vector, current mitigations. Aligned with the customer's 72-hour notification to authorities. |
| T+30 days | Final post-mortem | Met | Published as customer-facing post-mortem and (if applicable) in our public security-timeline. Aligned with the customer's one-month final report. |
Standard NIS2-aligned contract terms
For customers who are themselves in scope, our standard DPA addendum already covers:
- Notification clause — incident notification timing aligned with Article 23 cascade (above).
- Audit rights — Article 21(2)(d)-aligned audit rights including the right to review our most recent SOC 2 (when issued), ISO 27001 (when issued), and the annually-updated trust-page evidence.
- Sub-processor disclosure — 14-day prior notice of new sub-processors via /legal/sub-processors.
- Cooperation with competent authority — we commit to reasonable cooperation if the customer is requested to provide incident information to a competent authority or CSIRT.
What changes if we become directly in scope
We would become directly in scope under NIS2 if we either grew past the 50-staff / €10M turnover threshold AND started providing a service in an Annex I or II sector, or if the European Commission's implementing acts revise the sectoral definitions to include emergency-communications providers as digital infrastructure (currently being discussed in the context of the Cyber Resilience Act interplay).
If that becomes the case, we will:
- Register with the relevant member-state competent authority within the prescribed window.
- Submit to the registration-management portal at ENISA-coordinated points of contact.
- Formalise the Article 21(2) measures into a controlled document set (most already exist; the gap is the documented audit cadence).
- Pursue the ISO 27001 + ISO 22301 certification path documented at /trust/iso-27001 and /trust/iso-22301 in parallel — both are widely accepted by competent authorities as evidence of Article 21 conformity.
If you are an essential or important entity under NIS2 or an OES / RDSP under UK NIS and need a Glassbreak supplier attestation for your competent-authority filing, write to compliance@glassbreak.io.