Skip to content
My account

Certificates that say what they do not cover

A certificate logo alone says little. We therefore list the auditor, scope and term for each certificate — and explicitly what it does not cover. An ISO 27001 certificate is not a penetration test, and “GDPR certified” does not exist for our service.

Request certificatesRead data processing agreement

We release the C5 report under a non-disclosure agreement; certificate documents with scope without further conditions.

Available evidence
4
another openly named
C5 audit period
12 months
Type 2, ISAE 3000
Notification to you
24 h
from confirmed knowledge
Penetration tests
2 × annually
changing providers

Four certificates with scope — and what we don't have

Each entry states the type of evidence: a certificate confirms compliance with a standard, an attestation the judgement of an auditor over a limited period. The scope is just as important — it says whether a certificate refers to our management system or the building in which the platform runs. The last entry is neither a certificate nor an attestation, but an obligation for which there is no certificate at all for our service.

  1. ISO 27001
    Certificate
    Auditor
    Accredited certification body, annual surveillance audit
    Validity period
    Valid until 30 November 2027 · recertification every three years

    ISO/IEC 27001:2022 — Information security management system

    Scope: Operations of the systems, network and cloud platform including the associated management processes at locations fra1, fra2, ber1, muc1 and hel1

    Covers

    • Existence and effectiveness of an information security management system
    • Systematic risk assessment and derivation of measures from Annex A
    • Roles, responsibilities, training and document control
    • Processes for changes, access rights, suppliers and incidents

    Explicitly does not cover

    • No statement on the technical security of a single product or API
    • Not a substitute for a penetration test — the standard audits processes, not attack surfaces
    • No statement on GDPR compliance; that is a different legal framework
    • The scope is freely selectable — without looking at the certificate, “ISO 27001” says little
  2. BSI C5:2020
    Attestation
    Auditor
    Auditing firm according to ISAE 3000 (revised)
    Validity period
    Audit period 1 July 2025 to 30 June 2026 · follow-up audit in progress

    BSI Cloud Computing Compliance Criteria Catalogue, Type 2

    Scope: Bare Metal, Public Cloud, Object and Block Storage, Kubernetes, control plane and customer panel at locations fra1, fra2, ber1, muc1 and hel1

    Covers

    • Effectiveness of controls over a continuous period of twelve months (Type 2)
    • Basic and additional criteria including encryption, logging and incident management
    • The transparency criteria: jurisdiction, data location, handling of official investigation requests, certifications of subcontractors
    • Findings of the auditor are stated in the report, even if they are unpleasant

    Explicitly does not cover

    • Not a certificate, but an audit opinion for a defined period — it says nothing about periods after that
    • No statement on systems that were put into operation after the audit period
    • The full report is only issued under a non-disclosure agreement
    • Only covers the locations and services mentioned in the scope; there is no C5 attestation for anything beyond that
  3. EN 50600
    Certificate
    Auditor
    Notified body, assessment per location
    Validity period
    Per location, reassessment in case of structural changes

    EN 50600 — Availability class of the data centre infrastructure

    Scope: Assessment of the data centre infrastructure at the locations where the platform runs — VK4 in Frankfurt am Main (fra1, fra2), Munich (muc1) and Helsinki (hel1); VK3 in Berlin (ber1)

    Covers

    • Structural and technical design of power, cooling, cabling and security systems
    • Level of redundancy and the question of whether paths are not only duplicated but also routed separately
    • Classification of protective measures against access, fire and water

    Explicitly does not cover

    • A building is assessed, not a management system — the class is a selection criterion for us, not evidence of our operations
    • No statement on IT operations, software or the availability of individual services
    • A VK4 facility can still fail if operations make mistakes
    • The class applies per location, not per customer or per rack
  4. ISO 50001
    Certificate
    Auditor
    Accredited certification body
    Validity period
    Valid until 14 May 2028 · annual surveillance audit

    ISO 50001:2018 — Energy management system

    Scope: Our operations at locations fra1, fra2, muc1 and hel1 — the certificate is on the respective location map

    Covers

    • Systematic recording and improvement of energy performance
    • Measurement concept, key figures and objectives per location
    • Consideration of energy efficiency in procurement and planning

    Explicitly does not cover

    • No statement on absolute emissions or the actual electricity mix
    • No certificate for renewable energy — that is a matter of supply contracts
    • Not every location is included — the certificate is not available for our at location ber1 operations
  5. GDPR
    No proof possible
    Auditor
    —
    Validity period
    Permanent obligation, no expiry date

    Regulation (EU) 2016/679 — General Data Protection Regulation

    Scope: The entire operations of the platform

    Covers

    • Data processing agreement (DPA) under Art. 28 as part of every contract
    • Documented technical and organisational measures under Art. 32
    • Record of processing activities, deletion concept, reporting process under Art. 33
    • Complete list of sub-processors with country of establishment and purpose of processing

    Explicitly does not cover

    • There is no recognised certification under Art. 42 GDPR for our service — nobody is “GDPR-certified”
    • The responsibility under Art. 24 remains with you as the controller
    • We cannot assess whether your processing is lawful; we only provide the infrastructure

Who can legally access your data

The decisive question is not just where a server is located, but which law governs the company operating it — and whether there is an entity that can be forced to hand over data.

One company, one law

The platform is operated by ENTRONYX Deutschland GmbH, a company based in Germany. There is no parent company, no holding company in a third country and no intermediary company through which a foreign authority could intervene.

What the CLOUD Act actually regulates

The US CLOUD Act of 2018 obliges providers subject to US law to hand over data upon court order — regardless of the country in which it is stored. The connecting factor is not the server location, but the legal control over the operator. For us, this connecting factor is clear: the operating company is subject to German and European law.

Processing in Germany and Finland

Your data is processed in data centres in Germany and Finland and thus within the European Union. You choose the location when ordering; there is no automatic replication to another location. Identity management, key hierarchy and on-call duty remain with the same company — there is no administrative access from a third country.

Requests from authorities

We examine requests from security authorities individually for legal basis, jurisdiction and proportionality; we reject insufficiently justified requests. As far as legally permissible, we inform affected customers before handing over data. We publish the number and type of requests semi-annually in a transparency report.

Legal framework

No third-country access
Operating company
ENTRONYX Deutschland GmbH
Registered office
Cologne, Germany
Place of processing
Data centres in Germany and Finland, location selectable when ordering
Applicable law
GDPR, BDSG, German law
Corporate affiliation
No parent company, no holding company in a third country
Data processing agreement (DPA)
Art. 28 GDPR, integral part of the main contract

Sub-processors

The directory in section 14 of the Privacy Policy lists every contractor with their country of establishment, service, scope and legal basis. We announce changes at least 30 days in advance; you can object within this period.

All documents for tenders and procurement

NIS2 and requirements for suppliers

If your company falls under Directive (EU) 2022/2555 and its implementation in German law, Art. 21 para. 2 lit. d requires you to also manage the security of the supply chain — this includes the provider on whose infrastructure you operate. You can use the following existing documents for this assessment.

ISO/IEC 27001
Certificate on the information security management system, with scope Valid until 30 November 2027 · recertification every three years
BSI C5, type 2
Attestation on the effectiveness of the controls; the report under non-disclosure agreement Audit period 1 July 2025 to 30 June 2026 · follow-up audit in progress
SLA measurement procedure
Availability measured externally, calculation method in the contract, measured values public on the status page Service Level Agreement, clause 2
Reporting channels with deadline
Notification of a security incident to you with type, affected data categories and measures taken 24 hours from awareness

You assess whether and how your own obligations apply, including the reporting obligations under Art. 23. This overview states what we contribute to this; it makes no statement about a classification of ENTRONYX under NIS2.

Who gets to the metal

Security falls into two halves that have nothing to do with each other. The physical half answers who can access our systems, who opens a rack, and what happens to a storage medium when it is removed. The logical half — encryption, permissions, logging — is in the section below. A good answer to one question is not an answer to the other.

A second boundary runs through the physical half, which we explicitly draw here. Securing the building — grounds, reception, mantrap, fire zone, backup power — is not a service we provide, but a prerequisite: a location is only considered if it is fully designed and individually verifiable. What lies behind the last door, however, is our business — our racks, our systems, our storage media, and the decision about who gets access to them.

Single server rack from the front, the perforated metal door closed and secured with a flush swing handle and lock cylinder. Through the uniform perforation, the identical device fronts can be seen as a regular stack, each with its own green status light.
Entrance to a technical building made of light precast concrete: a recessed opening with a wide door made of brushed steel and glass, behind it a bright, empty vestibule with an unadorned counter. The concrete wall next to it is smooth and unlettered.

Physical access up to the system

Between the street and the server lie five separate controls: premises, reception, mantrap, server room, rack. The first four secure the building; we verify that they are present and individually logged before selecting a location. The mantrap requires a cabin that measures weight and contour, letting exactly one person through per clearance — tailgating is therefore not just prohibited, but impossible. The fifth control belongs to us: only those who are registered, identified and continuously accompanied can access our systems — we grant the clearance.

Steps to the rack
5, each individually logged
Prior registration
24 hours, with name and ID details
Biometrics
Palm vein recognition, reference only local
Escort
Continuous, along the entire route
Video recording
Access routes and rack rows, 90 days storage

Cabinet and cage

The last metre is the one that an access concept most frequently leaves open — and the only one on this path that we control ourselves. Every cabinet is individually locked; electronic locks record every opening with a timestamp and identity. The log is available in the customer panel and not just to us.

Lock
Mechanical or electronic, per cabinet
Opening log
Timestamp and identity, available in the panel
Colocation cage
Access list per cage, maintained by the customer
Sensors per rack
Temperature, humidity, power, door contact
External companies
Four-eyes principle in the server room

What the location must provide

Fire, water and power outages are physical events with an immediate impact on data — whether they cause damage is decided at the building level. We do not build there, we select. A location is therefore only considered by us once the following values are proven; we require evidence of them before the first rack moves in, and have them confirmed again in the event of structural changes. Nitrogen instead of water is required: the oxygen concentration drops to 15 vol.%, the fire is smothered, the hardware remains intact.

Fire compartments
F90 separated, 90 minutes fire-resistant
Extinguishing agent
Nitrogen instead of water, target value 15 vol.% oxygen
Power supply
Two separate paths A and B into the rack
Emergency power supply
N+1 (one generator more than necessary), 72 hours fuel supply
Control room
Staffed around the clock, at every location

End-of-life storage media

A data carrier only leaves a location erased and checked — and if it is not reused, additionally physically destroyed. Every process is logged with serial number, procedure and test result; without a log, a carrier is considered not erased.

Basis
BSI TL-03423 with measure CON.6 of the IT-Grundschutz
SSD and NVMe
Sanitize command according to ATA or NVMe, with verification
Hard drives
Multiple overwriting
Reallocation in inventory
Secure Erase and firmware reinstallation
Before disposal
Physical destruction, even after successful erasure

Structural design, cooling, backup power, and the five access levels in detail can be found in the overview of the locations where the ENTRONYX CLOUD platform runs — with the availability class per location and the places where we do not publish a specification.

Access control per location

Six layers between you and your data

The second half: encryption, key management, tenant isolation, hardening, vulnerability management. These layers work independently of the building — they still protect even if someone is standing in front of the rack. Each block names its boundary, because a layer without a named boundary is a promise without scope. The details are part of the documentation of technical and organisational measures according to Art. 32 GDPR and can be requested as an annex to the data processing agreement (DPA).

Encryption of data at rest

Block Storage and Object Storage are encrypted at the storage layer level without you having to configure anything. Each volume and bucket receives its own data key, which is never stored in plaintext on a disk.

Block Storage
AES-256-XTS, key per volume
Object Storage
AES-256-GCM, active by default (SSE-S3)
Own keys
SSE-C and SSE-KMS available with BYOK
Backups
Encrypted before leaving the source system
Databases
Encrypted volumes plus TLS to the client
Erasure
Destruction of the key, then overwriting

Restriction: We do not encrypt bare metal servers for you — there you have full access to the disks and therefore the responsibility. We provide TPM 2.0 and recommend LUKS2 with a key that is not located on the same system.

Encryption of data in transit

Public endpoints exclusively speak TLS. Between locations, traffic is additionally encrypted at layer 2 because it runs over routes that we do not physically control. MACsec encrypts every single Ethernet frame on the line there: a capture on the fibre does not yield any usable plaintext.

Public API
TLS 1.3, TLS 1.2 only with AEAD suites
Deactivation of TLS 1.2
Planned for 31 December 2026, announced in advance
HSTS
max-age 63072000, includeSubDomains, preload
Internal services
Mutual TLS authentication (mTLS)
Location interconnection
MACsec on all routes between locations
Certificates
ECDSA P-256, 90-day term, automatically renewed

Key management

The root of the key hierarchy lies in hardware security modules (HSM) at two locations. Data keys are derived from there and rotated regularly; a key never leaves the module in plaintext.

Hardware
HSM cluster according to FIPS 140-2 Level 3
Locations
fra1 and muc1, mutually redundant
Hierarchy
Root → region key → data key
Rotation
Data key every 90 days, automatically
Own keys
Import via KMS API, revocation at any time
Four-eyes principle
For every operation on the root key

Restriction: If you bring your own keys and revoke them, the data encrypted with them is irretrievably lost. This is intentional and cannot be reversed by us either.

Tenant separation

There are multiple independent separation layers between two customers on the same hardware. None of them is considered the sole safeguard.

Virtualisation
KVM with SELinux isolation per instance
Memory access
IOMMU mapping, no shared device paths
Network
Dedicated VXLAN segment per project, no shared L2
Storage layer
Separate namespaces and keys per account
Bare Metal
Physical separation, no multi-tenant on the metal
Reuse
Secure Erase and firmware reinstallation before reallocation

Restriction: With shared vCPU families, side-channel observation cannot be completely ruled out — i.e. inferences from the timing and cache behaviour of the shared CPU. If you need to rule this out, you need dedicated cores or Bare Metal — we prefer to state this clearly rather than hiding it in a footnote.

Hardening and integrity

All systems we operate boot via a verified chain and are checked against a documented baseline configuration. Deviations automatically generate a ticket.

Baseline configuration
CIS Benchmark Level 2 for hypervisor hosts
Boot chain
Secure Boot and Measured Boot via TPM 2.0
Login
Keys only, no password SSH
Administrative access
Only via jump hosts with session recording
Reconciliation
Automated daily, deviation = ticket
Firmware
Signature verification, canary ring (early access group) across 4% of systems

Vulnerability management and testing

Vulnerabilities are evaluated based on exploitability in our specific environment, not solely on CVSS score (the general severity rating of a vulnerability). Deadlines run from the time we become aware, not from publication.

Critical
Remediation or mitigation within 24 hours
High
Within 7 calendar days
Medium
Within 30 calendar days
Low
Within 90 calendar days
Penetration tests
Twice a year externally, changing providers
Red team exercise (simulated attack)
Once a year, without prior notice to operations
Bug bounty (reward for reported vulnerabilities)
€500 to €15,000, with an explicit commitment not to take legal action against reported findings

Restriction: We provide customers with a summary of the most recent penetration test upon request. We do not release the full report — it contains attack paths that would still be useful even if the individual findings have been resolved.

Network cabinet from the front, filled with identical switch chassis in a continuous stack. Each has the same dense row of identical ports at the same distance; a light patch cable of the same length leads from each port and is bundled upwards at the side.

A test run reads stored blocks again in the background and compares them with their checksum. This way, a silent read error is noticed before someone requests the file. Integrity is the part of security that no one notices as long as it holds — ENTRONYX CLOUD therefore runs it as a separate layer alongside encryption and access.

What happens when something happens

The reporting obligation under Art. 33 (1) GDPR with its 72-hour deadline applies to you as the controller — i.e. the company that decides on the purpose and means of processing. Our obligation as a processor under Art. 33 (2) is “without undue delay” and is therefore undefined. That is why we contractually commit to 24 hours from confirmed knowledge.

Initial assessment
15min
Notification to you
24h
Your deadline for the supervisory authority
72h
Post-incident review
10Working days

  1. Detection

    continuous

    Automated analysis of telemetry from the network, hypervisors and control plane, supplemented by information from the bug bounty programme and CERTs. An on-call team is staffed around the clock.

  2. Initial assessment

    15 minutes

    Classification of whether a security-relevant event has occurred, which systems might be affected and whether personal data is involved. In case of uncertainty, the decision is made in favour of the higher level.

  3. Mitigation

    Immediately after assessment

    Isolation of affected systems, blocking of access, securing of forensic evidence before any recovery. Securing evidence takes precedence over recovery, unless there is a risk of data loss.

  4. Notification to you

    24 hours from awareness

    As a processor, we are obliged to report without undue delay under Art. 33(2) GDPR. We set a strict upper limit of 24 hours from confirmed awareness for this — even if the cause is still unclear. The notification includes the nature of the incident, affected data categories, likely consequences and measures taken.

  5. Your notification to the supervisory authority

    72 hours

    The reporting obligation under Art. 33(1) GDPR applies to you as the controller, not us. Within our notification, we provide all the details you need for your own notification, and designate a dedicated contact person for enquiries from the supervisory authority.

  6. Post-incident review

    10 working days

    For every incident of the two highest levels, a written review is produced with a timeline, cause and measures. We publish operational disruptions without security relevance in full on the status page; affected customers receive security-relevant incidents directly.

Art. 28 GDPR is part of the contract, not an additional form

If you process personal data via our infrastructure, we are the data processor and you are the data controller. The corresponding agreement is concluded with the main contract; you do not need to request it separately and we do not charge for it.

You can find the complete list of sub-processors with country of establishment, purpose and location of processing, the technical and organisational measures as well as the objection procedure for changes in the Privacy Policy.

DPA and sub-processors
As a file
Right to issue instructions
Only documented instructions, text form is sufficient
Right to audit
On-site audit upon registration with 30 days' notice
Alternative evidence
C5 attestation and ISO 27001 certificate with scope
Subprocessors
General authorisation, change announced 30 days in advance
Objection
Within 30 days, with special right of termination
Confidentiality
Obligation of all employees, even after leaving
Assistance obligations
Data subject rights, data protection impact assessment, notifications
Deletion at the end of the contract
Return or deletion after a 30-day grace period

Audit us before you trust us

Certificates with scope, the summary of the last penetration test, the list of sub-processors and the data processing agreement are ready. A non-disclosure agreement is sufficient for the C5 report.

Request documentsAvailability commitments
Critical vulnerability
24 h until resolution
Bug bounty
500–€15,000
Key rotation
every 90 days
On-site audit right
30 days notice