OperativeOps and the NIS2 Directive
When AI agent deployments touch essential or important entities under NIS2, the entity is in scope of the directive — the software is not. OperativeOps is self-hosted, so it enters your supply chain as a software component rather than as a managed service provider, and the runtime you must secure and monitor is one you already operate.
- Most organisations running OperativeOps are NOT directly in scope of NIS2 — scope depends on sector (Annex I or Annex II) and size threshold (typically ≥50 employees or €10M turnover).
- Organisations in essential or important entity sectors must comply at the entity level; OperativeOps sits in their technology supply chain under Article 21(2)(d).
- OperativeOps is self-hosted only. There is no managed or hosted operation, so it is a software supplier in your supply chain and never a managed service provider — you own the runtime, the monitoring and the incident detection.
- The append-only audit ledger and role-scoped permission boundaries are the controls most directly relevant to Article 21(2)(b) incident handling and 21(2)(i) access control.
- Incident notification remains yours — early warning within 24 hours, substantive notification within 72 hours, and final report within 1 month per Article 23.
- This page is not legal advice. Scope determination and regulatory interpretation require your own counsel.
What NIS2 requires
The Network and Information Security Directive 2 (NIS2, Directive 2022/2555/EU) replaces the original NIS Directive and significantly expands its scope. Member States were required to transpose NIS2 into national law by 17 October 2024.
NIS2 applies to 'essential entities' listed in Annex I — sectors such as energy, transport, banking, financial market infrastructure, health, drinking water, wastewater, digital infrastructure, ICT service management, public administration, and space — and 'important entities' listed in Annex II, including postal and courier services, waste management, manufacture of critical products, food, and digital providers. The size threshold is generally organisations with ≥50 employees or €10M annual turnover, though critical infrastructure may be in scope regardless of size.
Article 21 mandates risk management measures covering at minimum: governance and policy adoption, incident handling, business continuity and crisis management, supply chain security (including supplier and service-provider relationships), vulnerability disclosure, the use of cryptography and encryption, access control and asset management, multi-factor authentication, and secure communications.
Article 23 sets reporting obligations for significant incidents: an early warning to the national CSIRT or competent authority within 24 hours; a substantive incident notification within 72 hours; and a final report no later than 1 month after the early warning. Intermediary reports may be required.
Article 20 places direct responsibility on the management body — boards and executive teams must approve risk management measures, receive regular training on cybersecurity, and can be held personally liable for non-compliance. This is one of NIS2's most significant departures from the original NIS Directive.
How OperativeOps maps to NIS2 requirements
| Requirement | Our control | Where |
|---|---|---|
| Supply chain security (Art. 21(2)(d)) | OperativeOps enters your supply chain as software artefacts and their third-party dependencies, not as an operated service. Because you run it, the supply-chain boundary you have to reason about ends at the release you deploy — there is no external runtime provider to assess behind it. | self-hosted |
| Incident handling (Art. 21(2)(b)) | Append-only audit ledger of every model decision, agent action, tool invocation, and human approval, held in your own database and readable by your existing SIEM tooling. | self-hosted |
| Access control (Art. 21(2)(i)) | Role-scoped agents with explicit permission boundaries: each agent can only read the sources and call the tools it is granted. Per-action human approval gates are configurable per role and tool class. | self-hosted |
| Encryption (Art. 21(2)(h)) | TLS between components in transit; encryption at rest supplied by the storage layer and key management you operate. Your KMS, your key material, your rotation policy — no external key custodian in the path. | self-hosted |
| Business continuity (Art. 21(2)(c)) | Your own disaster recovery and backup strategy, applied to a deployment that has no external runtime dependency. With a local model backend the system continues to function with no outbound connectivity at all. | self-hosted |
| Network segmentation and egress control | All outbound model traffic passes through an egress gate you configure. A deployment with a local model backend can be operated with no outbound path, which is what makes air-gapped installation possible. | self-hosted |
What self-hosting changes for NIS2
For NIS2 supply-chain obligations, what matters is which parties are in the chain and what each of them operates. OperativeOps is self-hosted only — there is no managed or hosted operation — so it is a software supplier and never a managed service provider under Article 21(2)(d). That is a narrower supplier relationship than a SaaS purchase creates: the dependency is on release artefacts and their third-party components, not on somebody else's uptime, patching cadence or incident response.
The corollary is that the runtime is entirely yours. You own the network boundary, the infrastructure and the data plane, so you can conduct your own security audits of the deployment and wire incident detection straight into the security operations you already run. Nothing about the deployment sits outside the perimeter you are already obliged to monitor, and no supplier notification has to reach you before you can see an event — the audit ledger is in your own database.
The same fact sets the workload. There is no infrastructure monitoring you can lean on, so anomaly detection, capacity monitoring, backup verification and patch application are yours to instrument. Article 23 notification was always yours as the entity; self-hosting also makes the detection that precedes it yours. If your organisation is not staffed to run that, a self-hosted deployment is a commitment worth scoping honestly before purchase.
What you are responsible for
- Scope determination — whether your organisation qualifies as an essential or important entity under NIS2 Annex I or II, and whether size thresholds apply to your sector.
- Incident notification process — establishing your internal process for the 24-hour early warning, 72-hour substantive notification, and 1-month final report to your national CSIRT or competent authority under Article 23.
- Board-level governance and training — ensuring your management body approves NIS2 risk management measures and receives cybersecurity training as required by Article 20.
- NIS2-specific risk assessment — documenting the risks your OperativeOps deployment introduces and mitigates within your broader organisational risk management framework.
- Operating and monitoring the deployment — patching, backup verification, capacity and anomaly monitoring, and integration of the audit ledger into your detection tooling. Self-hosting means there is no supplier-operated runtime to fall back on.
- Vulnerability disclosure policy — maintaining a policy for handling and disclosing vulnerabilities discovered in or through your deployment.
- Cyber hygiene programme — implementing and maintaining the broader cyber hygiene requirements, of which OperativeOps is one component.
- Engaging counsel — NIS2 scope determinations and notification obligations require legal interpretation under your national transposition law. We do not provide legal advice.
Frequently asked questions
Is OperativeOps NIS2-compliant?
NIS2 compliance is an obligation on entities (organisations), not on software products. OperativeOps is designed to support the NIS2 obligations of in-scope entities — through an append-only audit ledger, role-scoped permission boundaries, configurable encryption at rest via your own key management, and a deployment that stays inside the perimeter you already defend. Whether your organisation is compliant is a determination for your counsel and competent authority; no software supplier can certify it for you.
When does NIS2 apply to me?
NIS2 applies to your organisation if you operate in a sector listed in Annex I (essential entities) or Annex II (important entities) of the directive and meet the size threshold — generally ≥50 employees or €10M annual turnover. Some sectors (critical infrastructure, certain digital infrastructure providers) are in scope regardless of size. The exact criteria depend on your Member State's transposition law, which may add national-level specifics. Scope determination is a legal question; consult your counsel.
What is OperativeOps' role in NIS2 compliance?
It is a software component in your supply chain. For in-scope entities it is relevant primarily to the supply-chain security obligation under Article 21(2)(d) and the incident handling controls under Article 21(2)(b). Because it is self-hosted, the supplier relationship covers release artefacts and their dependencies only — there is no operated service behind it whose security posture you would also have to assess. No NIS2 attestation is held on your behalf; compliance is a property of your organisation.
How do I report an incident involving an OperativeOps deployment?
The incident notification obligation under Article 23 runs from you (as the entity) to your national CSIRT or competent authority. Because the deployment is yours, so is the detection: (1) detect via the audit ledger and the monitoring you have wired into it; (2) assess significance against your national transposition criteria; (3) submit the 24-hour early warning to your authority; (4) engage your incident response team; (5) submit the 72-hour substantive notification; (6) submit the 1-month final report. Where the incident appears to involve the software itself rather than its configuration, report it so it can be fixed.
Do you provide a software bill of materials (SBOM)?
Ask before you buy. A machine-readable SBOM is a reasonable expectation for a self-hosted component entering a NIS2 supply chain, and we would rather agree what is provided in writing than have this page assert a format and cadence that your auditor then holds us to. In the meantime, the dependency set of a self-hosted deployment is inspectable in the artefacts you run.
Are you a managed security service provider (MSSP) under NIS2?
No, and self-hosting is what settles the question: nothing is operated on your behalf, so OperativeOps cannot be a managed service provider of any kind under NIS2 Annex I (section 8). It is software you run. If you are yourself an MSSP using OperativeOps, your own NIS2 obligations as an essential entity apply to your operations, and the software sits in your supply chain like any other component you deploy.
How does NIS2 interact with GDPR for our OperativeOps deployment?
NIS2 and GDPR are complementary but separate frameworks. NIS2 governs cybersecurity risk management and incident reporting for essential and important entities; GDPR governs personal data processing for any organisation. A significant NIS2 incident may also be a GDPR personal data breach requiring separate notification under GDPR Article 33. See our GDPR compliance page for how OperativeOps supports GDPR obligations. Both sets of obligations run in parallel for in-scope operators.
How does self-hosting affect our NIS2 supply-chain exposure?
It narrows the supplier relationship to software artefacts and their dependencies, because there is no operated runtime behind the release. That simplifies the supply-chain documentation you have to gather: you assess a component you deploy rather than a provider's infrastructure, staffing and incident process. The cost is that you own every operational control — incident detection, business continuity, patching and key management — which is real internal resource. Self-hosting does not eliminate NIS2 obligations; it concentrates them inside your own boundary.