Security and Compliance.
How we protect our clients' systems and data, and how we demonstrate it.
We develop custom software solutions and operate them. Development and operations are in the same hands, on our own infrastructure in Germany, which is used by no one but us. For you, the result is an application that is available. We bear full responsibility for the technical foundation behind it, and this page sets out how that foundation is built, where your data is processed, who can access it and which procedure we follow in the event of a disruption or a security incident.
Every statement on this page can be substantiated. For an in-depth review of individual points, we will provide you with the corresponding evidence.
Four commitments.
Each of these commitments is a technical property of our infrastructure, not a declaration of intent.
Dedicated hardware in Germany
Your applications run on servers that belong exclusively to us and that we share with no third party. There is no shared hypervisor and no third-party workload on the same machine. The data centers are located in Falkenstein, Saxony, and are certified to ISO 27001.
Zero Trust down to the process level
No service in our environment is trusted merely because of its position in the network. Every single process has its own cryptographic identity and authenticates itself each time it establishes a connection. On the majority of our nodes, this identity is additionally bound to a hardware security chip and therefore cannot be copied.
Encrypted in transit and in backup
Connections between our systems run over encrypted networks and mutually authenticated TLS, including within our own infrastructure. Database backups are encrypted before they leave the originating system. The corresponding keys are kept offline in a separate location. The dedicated backup storage and all work devices of our staff are fully encrypted.
Cryptographically secured access
Servers are accessed exclusively with cryptographic keys. Password login is disabled server-side on all systems, not merely discouraged. All applications use central single sign-on with a mandatory second factor.
Verifiable certification status.
- GDPR Compliant
- ISO 27001 data centers Certified (operator)
- Data processing in Germany Exclusively
- Subprocessors EU only
Our data centers are certified to ISO 27001. For our own operations, we provide the evidence directly: we set out in detail which measures we implement and substantiate every one of them. In several respects these measures go beyond the requirements of common audit catalogs, for example with hardware-bound machine identities, consistent mutual authentication of internal connections and a fully declarative, versioned description of the entire infrastructure.
We answer vendor questionnaires and security audits in full and without evasive wording. Send us your organization's questionnaire and you will receive it back completed.
Five principles on which our infrastructure is built.
The following five principles underlie every decision about our infrastructure. We disclose them so that you can place the measures in the next section in context rather than having to assess each one individually.
Closed by default, opened only case by case
Instead of relying on an upstream firewall, every system starts with all access blocked. Every reachable service requires an explicit, versioned rule that includes the permitted network range. A port left open by mistake is thereby ruled out.
Administrative access is not reachable from the internet, only through a separate access system. There, too, login is possible exclusively with a cryptographic key.
Identity instead of network trust
A service is granted access because it can prove its identity, not because of its position in the network. For this we use SPIFFE, an open, vendor-neutral standard for service identities. Every process has its own short-lived identity, and when a connection is established, both sides authenticate each other. This applies to everything from log data and metrics to the container registry and the database cluster, which rejects unencrypted connections.
On the majority of our nodes, the machine's identity is additionally bound to a hardware security chip. There, a copied disk or a replicated virtual machine cannot take it over. The remaining nodes authenticate through a procedure that is verified to an equivalent standard.
Credentials are bound to identities, not to files
Credentials are not stored in configuration files but managed centrally in a vault that we operate ourselves. We use OpenBao for this, the open-source continuation of HashiCorp Vault. A service proves its identity and receives exactly the credentials assigned to it, for a limited period. Staff authenticate through single sign-on with a second factor and are granted access only to the areas assigned to their role.
For a growing share of services, credentials are generated on demand and expire after a short time. A leaked credential would by then already be invalid. We are continuously extending this procedure.
The entire infrastructure exists as versioned source code
Operating systems, services, network configuration, DNS records and permissions are fully described as code and versioned. Every change is tied to a cryptographically signed commit, and deployment is automated. There are no manually configured servers in our environment.
Every change to your environment can therefore be traced by time and author, and a rebuild is reproducible rather than improvised. If the actual configuration deviates from the recorded state, an automated comparison reports it.
Up-to-date network architecture
Our infrastructure is built consistently on IPv6. Every service has its own address instead of sharing one through address translation. This enables precise permissions and unambiguous logs. Peers that support only IPv4 reach us through dedicated gateways.
Communication between servers runs entirely over encrypted networks, even within the same data center. Database replication, cluster communication and administrative access therefore remain protected even if the underlying network is intercepted.
The design would work independently of location. We deliberately remain on dedicated hardware that is used by no one but us.
What we implement in practice.
Four areas with six measures each, listed in full.
Infrastructure & network
- Dedicated servers for our exclusive use, no shared hypervisor
- All access blocked by default every exception granted individually and versioned
- Encrypted networks between all servers, even within the same data center
- Mutually authenticated TLS for internal services, unencrypted database connections are rejected
- Built consistently on IPv6 one address per service, enabling precise permissions and unambiguous logs
- Administrative access not reachable from the internet only through a separate access system
Identity & access
- Single sign-on for all systems operated in-house, not outsourced
- Mandatory second factor via security key or one-time code
- Server access by cryptographic key only password login is disabled server-side
- Restricted access to production systems limited to a few people and granted only for a specific need
- Credentials held centrally in a vault bound to the identity of the requesting service
- All credentials replaceable at short notice a growing share is rotated automatically and continuously
Software & supply chain
- Automated updates every working day an ongoing process instead of quarterly maintenance windows
- Dependencies pinned to exact versions no open version ranges
- Container images built reproducibly with a complete list of all included packages
- Changes only through signed commits and automated deployment
- Development and infrastructure strictly separated application development has no access to the infrastructure layer
- No credentials in source code or pipelines they are retrieved from the vault at runtime
Organization & operations
- Mandatory password manager no sharing of credentials by email
- End-to-end encrypted internal communication through a service we operate ourselves
- Central logging for all systems with IP addresses truncated
- On-call chain with defined response times with automated alerting
- Defined procedure for security incidents including reporting channels
- Regular restore tests actually carried out, not merely documented
Where your data is processed and stored.
Your data is processed exclusively in Germany. Our production systems, the databases and the backups of the virtual machines are located in data centers in Falkenstein, Saxony, operated by Hetzner Online GmbH, a German company.
In addition, we keep a further encrypted backup copy at a separate location in Germany, apart from the production environment.
A fixed rule applies to the procurement of storage and processing services: a European provider with a European legal form. Our encrypted database backups are held by a French provider within the EU. The backups are encrypted before they leave our systems, and the corresponding keys remain exclusively with us, offline and in a separate location. The provider cannot view the contents at any time.
We use Cloudflare for DNS and, where a client requests it, for upstream protection against denial-of-service attacks. It serves purely as a delivery and protection layer, and your data is not stored there permanently. Whether and to what extent this service is used for your environment is decided together with you. Operation entirely without this upstream service is possible.
Your users
- Upstream protection & DNS depending on client requirements optional
Dedicated infrastructure
Germany- Access & TLS
- Applications
- Database cluster · mTLS
Multi-tier backups
- Virtual machine backups Germany
- Encrypted database backups EU, keys remain with us
- Additional copy at a separate location Germany
Backups whose restoration demonstrably works.
A backup is only of value if it can be restored in an emergency. We therefore treat this area as a system in its own right and not as a by-product of operations.
Full backups of the virtual machines run automatically to dedicated backup storage in Germany. This storage is not tied to one location and can be relocated when needed without any change to the backup procedure. In addition, we keep a local copy. Databases are also backed up individually and encrypted on the originating system before they are transferred.
Backups can be written but not deleted. The credentials used to write backups have no right to delete or overwrite them. Taking over a production system therefore does not lead to the destruction of the backups. This is precisely the approach that characterizes current ransomware attacks, and it is precisely what this design is directed against.
Retention is tiered. We keep full database backups at close intervals for 90 days. Older states are thinned out on a schedule rather than discarded, so that the history reaches back up to five years.
We verify restores in practice, not on paper. Most recently, during a complete site migration, every single internal system was restored from backup and put into operation. In addition, we regularly test individual systems during ongoing operations.
Availability, monitoring and incident response.
Our operational target is 99.95 percent availability per year. In several years we achieved 100 percent, and in years with an incident we reached 99.98 percent.
All systems report metrics and logs to a central monitoring system. Anomalies automatically trigger a notification that is routed into a defined on-call chain. On this basis we contractually guarantee response times: two hours, without requiring any change to our setup, and a reduction to 30 minutes where operations require it. In our experience, the actual time to resolution is typically one to two hours after the initial response.
Because our entire environment is described as code, rebuilding a system is a practiced, routine procedure.
We deliberately highlight one point: the most effective element of our incident preparedness is that all credentials can be fully replaced at any time. A leaked credential is therefore not a state of emergency lasting weeks but a matter of minutes.
Up-to-date software as a permanent state, not a project.
Outdated software is the most common cause of successful attacks. For us, updating is therefore not a quarterly maintenance window but an ongoing, automated process. Every working day, an automated job checks all dependencies of our systems and applications for new versions and prepares the update. Non-critical updates go through automatically, while critical components such as databases are excluded and updated under deliberate supervision.
All dependencies are pinned to exact versions. We do not use open version ranges whose resolution can change over time. We build our own container images reproducibly, with a complete, versioned list of every included package. This allows us to state, for every release we have shipped, which software components it contained and in which version. For a review on your part, for example as part of a vulnerability assessment, we provide this list.
There is a strict separation between application development and infrastructure. Those who develop applications have no access to the infrastructure layer. Development triggers processes, and the infrastructure executes them. Credentials do not appear in application source code or in pipelines. They are retrieved from the vault at runtime and cannot be viewed by developers.
Companies that work on our behalf.
We deliberately keep the number of companies involved small. Listed here are all companies that may be engaged in the course of operating services for our clients. Tools used solely for internal administration, in which no client data is processed, are not listed.
| Company | Registered office | Service | Data location |
|---|---|---|---|
| Hetzner Online GmbH | Germany | Data center, dedicated servers, backup storage | Germany |
| Note Data centers certified to ISO 27001 | |||
| Scaleway SAS | France | Object storage for encrypted backups | EU |
| Note Contents are encrypted before transfer, the keys remain with us | |||
| Cloudflare | Delivery via EU locations | DNS and optional upstream protection | EU |
| Note Parent company in the USA, processing limited to EU locations. Use and scope are defined per client, and operation without this service is possible | |||
- Hetzner Online GmbH DE
- Registered office
- Germany
- Service
- Data center, dedicated servers, backup storage
- Data location
- Germany
- Note
- Data centers certified to ISO 27001
- Scaleway SAS FR
- Registered office
- France
- Service
- Object storage for encrypted backups
- Data location
- EU
- Note
- Contents are encrypted before transfer, the keys remain with us
- Cloudflare EU
- Registered office
- Delivery via EU locations
- Service
- DNS and optional upstream protection
- Data location
- EU
- Note
- Parent company in the USA, processing limited to EU locations. Use and scope are defined per client, and operation without this service is possible
All companies we engage process data within the EU. When selecting providers, we give preference to European ones. We notify our clients in advance of any changes to this list.
In addition to our employees, we occasionally engage freelancers. The same rules apply to them as to our own staff: a contractual obligation of confidentiality and data secrecy, being bound by our instructions, personal accounts through our single sign-on with a second factor, and access only within the scope of a specific task. There are no separate or weaker conditions.
Questions from vendor questionnaires and security audits.
Phrased the way IT security officers, data protection officers and legal departments actually ask them.
Where is our data processed and stored?
Does any data leave the EU?
Is our data used to train AI models?
Who at your company can access our production data?
How are your backups protected against ransomware?
How quickly do you respond to an incident?
How do you ensure that your systems are up to date?
Are you ISO 27001 certified?
What happens if a credential is compromised?
Do you use an upstream service such as Cloudflare?
Can we conclude a data processing agreement?
Can we obtain evidence or logs for our own audit?
What happens to our data at the end of our cooperation?
Reporting vulnerabilities
On all websites for which we are responsible, we publish a machine-readable contact file in accordance with RFC 9116 at /.well-known/security.txt. If you discover a vulnerability, please report it to the address given there.
Our commitment: we confirm receipt of your report, provide you with a technical assessment and refrain from legal action against anyone who reports a vulnerability in good faith and without exfiltrating data.
Open security.txtLast reviewed: September 23, 2026 This page is maintained on an ongoing basis and updated whenever our infrastructure changes.