Compliance by Design

NIS2 and DORA are active law, and neither of them lets you outsource the liability. This is how our architecture maps to the articles a regulator will actually cite.

Most vendors answer a compliance question with a certification badge. A certification tells you the vendor was audited. It does not tell you who can read your data, what leaving costs, or whether your evidence trail survives contact with an adversary. Those are architectural questions, and they have architectural answers.

Book an Architecture Review See the Article Mapping

Liability Cannot Be Outsourced

Two instruments changed the calculus for regulated entities operating in and into the EU. Both moved accountability upward, into the management body, and outward, across the supply chain.

NIS2 Directive (EU) 2022/2555

Personal executive liability. Management bodies are personally accountable for negligence in cybersecurity risk management. The duty follows the officer, not the contract.

Strict notification windows. A mandatory 24-hour early warning, followed by a formal incident notification within 72 hours. Detection latency becomes a compliance variable.

Supply chain duty of care. Organisations are legally responsible for verifying the security of their own sub-processor dependencies, including the ones their vendors introduce without notice.

DORA Regulation (EU) 2022/2554

ICT concentration risk. Direct regulatory scrutiny on over-reliance on a small number of concentrated third-party cloud providers.

Compulsory exit strategies. Financial entities must demonstrate viable, tested exit plans that can be executed without operational disruption.

Isolated continuity. Mandates isolated, immutable operational backups that remain usable during a vendor outage rather than because of one.

Where Multi-Tenant SaaS Conflicts With the Regulation

These are not vendor failures. They are structural properties of the multi-tenant delivery model, and they sit directly across the obligations above.

The Shared Tenancy Trap

Their breach becomes your breach. Cross-tenant metadata leakage and unvetted sub-processor changes create an attack surface you are accountable for but cannot inspect.

The Sovereignty Conflict

Data residency is not data sovereignty. Telemetry held in the EU region of a US-owned vendor remains subject to the US CLOUD Act, because the obligation attaches to the corporate entity rather than the disk.

The DORA Exit Problem

Proprietary formats, narrow export windows, and egress charges make clean regulatory offboarding impractical. An exit plan you have never tested is not an exit plan.

Forced Upgrade Windows

SaaS updates run on the vendor's schedule. Sudden schema shifts and API deprecations break detection content and SOAR workflows at times you did not choose.

The Architectural Boundary

The question that decides sovereignty is simple: in normal operation, does anything about your estate cross your own perimeter?

The SaaS Model — Data Export

Internal endpoints generate sensitive logs
Logs are forwarded outbound through your firewall
Data is processed in a multi-tenant cloud
Vendor analytics and AI engines ingest the metadata

Result: loss of data sovereignty and CLOUD Act exposure.

The SinonTech Model — Data Isolation

Internal endpoints generate logs
Logs route directly to your self-hosted cluster
All detection, correlation, and storage occurs internally
Threat intelligence flows in; zero telemetry flows out

Result: deterministic compliance and absolute sovereignty.

Mapping Architecture to Regulatory Articles

Each obligation below is met by a specific platform behaviour rather than a policy document. Your auditor can test every row.

Mapping of NIS2 and DORA articles to the compliance requirement and the SinonTech platform that implements it.
Regulatory Mandate	Compliance Requirement	SinonTech Implementation
NIS2 Article 21	24-hour and 72-hour incident logging and real-time response	Umbra SIEM — real-time local ingest and correlation with no SaaS round-trip latency
NIS2 Article 21.2(e)	Supply chain vulnerability handling and patch security	SinonKeystone — cryptographic patch verification against signed digests, with staged deployment rings
NIS2 Article 21.2(i)	Access control, multi-factor authentication, and secure communications	SinonAuth and SinonVPN — on-premises IAM plus an identity-aware bastion with session recording
DORA Article 16	Isolated backup and disaster recovery against defined RTO and RPO	SinonStore — S3-compatible immutable vault with ransomware shielding and point-in-time air-gapped recovery
DORA Article 28	Mandatory ICT exit strategy and reversibility	Native PostgreSQL and Elasticsearch schemas — export at any time, at zero egress cost, in a format you already know

This mapping describes how the architecture supports each obligation. It is not legal advice, and compliance remains an assessment of your organisation as a whole. We are happy to walk your auditor through any row.

The Four Pillars of Sovereign Architecture

Everything above rests on four engineering decisions that we do not compromise on.

1. Zero Telemetry

No phone-home channels in any deployment mode. Your internal topology, alert volumes, and configuration never cross your perimeter, because there is no code path that sends them.

2. Open Data Standards

Built natively on standard PostgreSQL and Elasticsearch. No proprietary storage format stands between you and your own records, so export is immediate and free.

3. Cryptographic Auditing

Hash-chained, tamper-evident audit logs. Alteration of a historic record breaks the chain and is provable, which is what non-repudiation means in practice.

4. Air-Gap Native

Deploys on bare metal, Kubernetes, or a sovereign cloud without WAN access. An air gap is a supported configuration, not a degraded one.

If You Would Rather Not Run It Yourself

Sovereignty and operational convenience are usually presented as a trade-off. The Sinon-Hosted model exists because they do not have to be.

SaaS Experience

Zero IT overhead.

No servers to rack
No Kubernetes to manage
Automated scaling and uptime
Fully managed by SinonTech SREs

Sovereign Guarantee

Single-tenant isolation.

Dedicated bare-metal instances
Located in Tier-3 EU data centres
Zero cross-tenant metadata sharing
You hold the encryption keys

DORA Position

Legal data ownership.

Standard PostgreSQL schema access
Immediate, zero-cost data export
No US CLOUD Act exposure
Verifiable single-tenant isolation

Compliance Questions

Does using an EU data centre make a US vendor compliant?

Data residency and data sovereignty are not the same thing. Telemetry stored in an EU region of a US-owned vendor remains reachable under the US CLOUD Act, because the obligation attaches to the corporate entity rather than the physical location of the disk. Sovereignty requires that no third party holds a compellable data path — an architectural property, not a contractual one.

Can we outsource NIS2 liability to our security vendor?

No. Under NIS2, management bodies are personally accountable for negligence in cybersecurity risk management. A vendor contract may allocate cost, but it does not transfer the regulatory duty. Article 21.2(d) additionally makes the organisation responsible for verifying the security of its own supply chain and sub-processor dependencies.

How does self-hosting help with the DORA exit strategy requirement?

DORA Article 28 requires financial entities to hold viable, tested exit plans that can be executed without disruption. Because our platforms store data in standard PostgreSQL and Elasticsearch schemas with no proprietary format and no egress charge, an exit is a database dump you can perform at any time. There is no narrow export window, no data conversion project, and no egress tax to budget for.

What is ICT concentration risk and why does it matter?

DORA places direct regulatory scrutiny on over-reliance on a small number of concentrated third-party cloud providers. If your SIEM, your identity provider, your object storage, and your productivity suite all resolve to the same hyperscaler, a single vendor incident becomes an operational resilience event across your whole estate. Distributing those functions onto infrastructure you control removes that correlation.

Can the platform meet the 24-hour and 72-hour notification windows?

NIS2 Article 23 requires an early warning within 24 hours and a formal incident notification within 72 hours. Umbra SIEM ingests and correlates locally with no SaaS round-trip, so detection latency is a function of your own hardware rather than a vendor queue. Hash-chained audit logs provide the tamper-evident evidence trail a regulator will expect alongside the notification.

Do the platforms send any telemetry back to SinonTech?

No. There are no phone-home channels in any deployment mode, including Sinon-Hosted. Threat intelligence such as CVEs and IOCs flows inbound to your instance via VeritasFeed; nothing about your internal topology, alert volume, or configuration flows outbound. The platforms are designed to run air-gapped without WAN access.

Does moving off a SaaS platform put us out of compliance during the migration?

No, because the migration runs in parallel. The first phase mirrors your syslog and event streams into Umbra alongside your existing platform, so both are ingesting simultaneously and detection parity is verified against historic telemetry before anything is deprecated. See the migration path for the phase breakdown.

Is this legal advice?

No. This page explains how our architecture supports specific obligations under NIS2 and DORA. Whether your organisation is compliant is an assessment of your organisation as a whole, and depends on governance, process, and controls well beyond any one platform. We work alongside your legal and audit teams rather than in place of them.

Map Your Own Regulatory Gaps

A 60-minute architecture review maps your current third-party SaaS dependencies against your NIS2 and DORA obligations, and tells you plainly where the gaps are.

Phone: 0141 536 0433

Email: info@sinontech.co.uk

Book an Architecture Review View Pricing