← Industries/Cybersecurity SMBs
Promethean for Cybersecurity SMBs
NIS2 Art. 21 makes operators directly liable for risk-management evidence — including evidence about the security tools they buy. AI-driven SOC tooling triggers the same scrutiny as the systems it protects. Promethean is the per-decision evidence layer that lets you sell into NIS2-regulated customers (essential + important entities) by giving them auditable proof of how your AI made detection + response decisions.
Who this is for
Compliance + product teams in cybersecurity SMBs (SOC platforms · threat-detection AI · SIEM-AI · GRC tooling · MSSPs). Typically:
- Seed–Series C cybersecurity SMBs with 10–100 engineers; AI used in 1–4 production features.
- Customer base: NIS2 essential + important entities (energy, transport, banking, health, public administration, digital infrastructure).
- Decision volume: 10k–10M AI-classified events per month per customer.
- Multi-tenant by customer organisation; per-customer audit bundles required during their NIS2 audits.
- Procurement increasingly demands ISO 27001 + SOC 2 + an AI-decision audit trail for tools touching incident detection.
The regulatory pressure
NIS2 Directive (EU) 2022/2555 Art. 21 — cybersecurity risk-management measures
Essential + important entities must implement appropriate technical, operational, and organisational measures to manage cybersecurity risks. Supply-chain security (Art. 21(2)(d)) requires assessing tools and providers used.
NIS2 Art. 23 — incident reporting (24h early warning, 72h notification)
Significant incidents must be reported in tight timeframes. Per-decision evidence from AI detection tooling underpins the timeline reconstruction.
EU AI Act Art. 25 + Art. 53 — value-chain + GPAI obligations
Foundation-model providers carry Art. 53 GPAI obligations (technical documentation, training-data summary, copyright policy). Downstream operators integrating those models carry Art. 25 (responsibilities along the AI value chain) + Art. 26/Art. 16 obligations depending on whether they are deployers or providers — including transparency and per-decision documentation where high-risk classifications attach.
Deep-dive →DORA + financial-sector overlap
Cybersecurity tools sold into financial entities are third-party ICT providers under DORA Art. 28. Per-decision evidence supports the financial entity's third-party risk management obligations.
Where LLMs typically run in Cybersecurity SMBs
AI threat-detection classifier
Classifier scoring events as benign / suspicious / critical. Closed-enum output; chain shows precision + recall over time; reviewer-gate on low-confidence enables SOC analyst feedback loop.
SOC alert triage + summarisation
Drafter producing alert summaries + recommended actions for SOC analysts. Schema-bound rationale field; spec hash binds the prompt template per decision.
Incident response playbook drafting
Drafter producing initial response steps from alert context. Always-human reviewer gate (analyst signs before execution); reviewer-verdict captured per step.
Phishing / social-engineering classification
Per-message classifier with closed-enum output (phish / benign / suspicious). Schema-bound output; chain provides evidence of false-positive + false-negative rates.
How the substrate maps to your audit
| Your LLM feature | What the regulator asks | Promethean evidence |
|---|---|---|
| Threat-detection accuracy | NIS2 Art. 21: does the detection layer perform as documented? | L12 chain provides per-decision verdict + outcome data; precision/recall computable against chain. |
| Incident-timeline reconstruction | NIS2 Art. 23: when did detection happen; what did the AI do? | recordedAtIso + specHash + verdict per L12 entry; tamper-evident chain anchors the timeline. |
| SOC analyst review evidence | Was a human meaningfully reviewing AI recommendations? | Reviewer-gate firings + reviewer identifier per entry; override rate computable from chain. |
| Supply-chain assurance to customers | NIS2 Art. 21(2)(d): customers ask us to demonstrate our AI behaves correctly. | Per-customer audit bundle filtered by tenantId; verifier validates with verify.mjs. |
| Model-drift evidence | Has the threat-detection model degraded over time? | modelIdentity + specHash per entry; statistical drift analysis against chain export. |
Which Promethean tier fits
Recommended for typical SMBs in Cybersecurity SMBs
Production€499 / month flat
Up to 25 specs · 1M entries / month · hourly OTS anchoring · multi-tenant · federation read-only.
Cybersecurity SMBs are multi-tenant (one platform, many regulated customers), so Production tier's R4 tenantId + multi-tenant primitives are the natural fit. 1M entries/month covers typical SOC volume for mid-size SMBs. Upgrade to Scale (€1,199/mo) when crossing 25 specs (typically when adding per-customer detection rules or jurisdiction-specific playbooks) or when enterprise customers demand HSM key custody. Enterprise tier matters once selling into government CSIRTs or regulated utilities needing on-prem deployment.
Larger Cybersecurity SMBs operators with multi-tenant or framework-template needs upgrade to Scale (€1,199 / month flat).
What this looks like in practice
Hypothetical: an SMB SOC platform during a customer NIS2 audit
A SOC SaaS SMB serves 40 mid-market customers, several of which are NIS2 essential entities (regional energy distributor, hospital group). One customer's NIS2 supervisor asks the customer: 'Demonstrate that your detection + response tooling produces evidence sufficient to reconstruct incidents and validate your risk-management measures.' The customer asks the SOC SMB: 'Give us proof your AI detection works and we can reconstruct what happened.' Without Promethean: SIEM-log dumps + vendor-written assurance letters. With Promethean: a per-customer audit bundle filtered to their tenantId — every threat-classification decision, every reviewer verdict, every model version, anchored to OpenTimestamps. The customer's supervisor accepts the verifier output (verify.mjs against the bundle); the SOC SMB becomes the preferred vendor in NIS2-regulated procurement.
Frequently asked
We're a cybersecurity vendor, not a regulated entity. Why does NIS2 affect us?
Because your customers are regulated. NIS2 Art. 21(2)(d) requires essential + important entities to assess supply-chain risk including their security vendors. Increasingly your customers' supervisors are asking them to demonstrate the tools they buy produce auditable evidence. Promethean is the layer that lets you answer those questions positively without restructuring your platform. You're not directly regulated by NIS2; you're competing on evidence-readiness with peers who don't have it.
Our AI threat-detection runs at millions of events per minute. Does Promethean keep up?
Not at that granularity — and you wouldn't want it to. Enterprise tier carries a 10M entries/month fair-use allowance (a billing envelope, not measured peak throughput); per-event recording at SIEM volume would exceed that by orders of magnitude regardless. The pattern is to record consequential decisions (alert promotions, incident triggers, automated-response actions, reviewer interactions) at the audit layer — your SIEM keeps the raw event stream. Promethean answers 'what did the AI decide to escalate, and was a human in the loop' rather than 'every packet that crossed the wire'.
Foundation models in cybersecurity (e.g. LLMs analysing logs) — what's our AI Act exposure?
If you're deploying foundation models, your obligations come via AI Act Art. 25 (responsibilities along the AI value chain) plus your role-specific duties — Art. 16 if you're a provider of a downstream high-risk system, or Art. 26 if you're a deployer. The GPAI provider (OpenAI / Anthropic / Google / Mistral) carries the upstream Art. 53 documentation + transparency duties to you. The L12 chain captures the modelIdentity per decision — so when AI Act enforcement asks 'which model + version was making this classification', you have it per call, not as a static config snapshot.
We sell into financial-sector customers — DORA applies. How does that intersect with NIS2?
DORA Art. 28 makes you a third-party ICT provider for financial-sector customers; NIS2 Art. 21(2)(d) makes you a supply-chain risk for cross-sector regulated customers. Both require demonstrating per-decision AI behaviour with audit evidence. The L12 chain serves both — a single audit-trail layer answers both regulatory pathways. For financial-sector customers specifically, the chain feeds their DORA register-of-information entries (provider, criticality, controls).
We've already got SOC 2 + ISO 27001. Why add another evidence layer?
Because SOC 2 + ISO 27001 cover organisational + system controls — they don't certify per-decision AI behaviour. When a NIS2 supervisor or a financial-sector customer asks 'show me what the AI classified during the incident window', SOC 2 doesn't answer it. The L12 chain does. They're complementary: SOC 2 says your organisation has controls; Promethean says individual AI decisions happened the way you claim they did.
Definitions used on this page
The substrate primitives referenced above (L12 receipt chain, spec hash, reviewer gate, fallback behaviour, OpenTimestamps anchor, tenant ID) all have canonical definitions in the glossary: