Trust is documentation,
not marketing.

Trust pages on infrastructure-vendor websites tend to fall into two categories. The first is a marketing surface — calming language about the seriousness with which the vendor takes security, with no specifics a procurement team can verify. The second is a procurement-grade document. Downloadables. Sub-processor lists. Regulatory citations. Named contacts. This page is the second category. Everything below is verifiable against primary sources, available for download where applicable, and updated when something changes — the date of the most recent update appears at the bottom of every section.

Trust in this sense covers four pillars. The first is corporate counterparty — who the customer is contracting with, what jurisdiction governs the contract, which courts can compel disclosure of customer data through that entity. The second is technical security: encryption, access control, network architecture, vulnerability management, incident response. The third is regulatory compliance, principally GDPR, NIS2, the Data Act, and sector-specific obligations where they apply. The fourth is operational continuity. Uptime. Backups. Disaster recovery. The runbook for the day something fails and the discipline to follow it under pressure rather than improvise. Each pillar is documented below with the level of specificity a regulated-industry buyer's compliance team can use without follow-up questions.

The corporate counterparty for every Big Box Hosting customer contract is a single entity. BIG BOX Hosting d.o.o., registered in Slovenia at Trg republike 3, Floor 2, 1000 Ljubljana, has been operating at this address since 2002. The d.o.o. is the Slovenian private-limited-company form, governed by the Companies Act (ZGD-1). There is no holding company above this entity in the ownership chain, no group structure that adds parties to the contract, no foreign subsidiary that creates a different jurisdictional exposure for any subset of customers. There is one company. The legal counterparty for a customer in Frankfurt is the same legal counterparty as for a customer in Madrid, in Stockholm, in Dubai, in São Paulo. That is the architecture, and it has been intentional since 2002.

Ownership of the d.o.o. is held by a Slovenian natural person. The company has shareholders but no foreign corporate parents, no nominee structures, and no beneficial-ownership concealment that would obstruct a regulator's right to know who controls the entity. The Slovenian Business Register (AJPES) publishes the ultimate beneficial owners on request. The same UBO disclosure has been on file since the 2018 EU AML Directive transposition required it. Procurement teams who have asked for evidence of ownership have received the Trade Register extract within three business days of the request.

The relevance of corporate structure to data sovereignty was established beyond dispute by the OVH Canada ruling of 25 September 2025. A Canadian court ordered OVH, a French EU-domiciled cloud provider, to extract and produce customer data held by group entities outside Canada, on the legal basis that OVH had a Canadian subsidiary which made the corporate group reachable through Canadian process. The lesson generalises. Any provider with a corporate footprint in a jurisdiction whose courts can compel production is exposed to that jurisdiction's process — regardless of where the data physically sits. We have no Canadian entity. We have no US entity. We have no UK entity. We have no presence outside the European Union and Switzerland. The MLAT process via the Slovenian Ministry of Justice remains the only lawful route to our corporate counterparty, and that route involves a Slovenian court, Slovenian law, and the Slovenian Constitutional Court's track record on data retention.

A sub-processor is any third party that processes customer data on our behalf during the delivery of the service. Article 28 of the GDPR requires controllers to know who their processor's sub-processors are. We publish the list. We update the list when something changes. We notify the customer of intended changes by email at least 30 days before the change takes effect, with the option for the customer to object and terminate the affected portion of the contract without penalty if the change is unacceptable. The list below is current as of the date at the bottom of this section, and the most recent revision history is published below the table.

What is conspicuously not on the sub-processor list. There is no Cloudflare in the path. There is no AWS. There is no Stripe. There is no Google Workspace. There is no Microsoft 365. The decision to keep the sub-processor list inside European jurisdictions was made deliberately and is documented in the founder's note. The cost of avoiding US-domiciled sub-processors at our scale is real — DNS at Hetzner is more limited than DNS at Cloudflare, payment processing through Mollie has fewer market integrations than Stripe, and customer support tooling that does not route through a US-based vendor required us to operate our own helpdesk on Ljubljana hardware. We accept those trade-offs because they are what produces the narrative the rest of this site sells. Our customers are not buying a generic email infrastructure service. They are buying an architecture that does not include corporate counterparties their own compliance teams have to defend.

Encryption. Encryption at rest uses LUKS (dm-crypt with LUKS2 metadata) on every storage volume in production, with AES-256-XTS as the cipher and a key file held in a hardware-backed keystore on the management plane. Customer data on shared storage is then encrypted with a per-tenant key derived from the customer's own passphrase or from a key the customer rotates on their own schedule. Loss of the customer key means loss of the data — we do not maintain backdoor access. Encryption in transit uses TLS 1.3 minimum on every customer-facing endpoint, with TLS 1.2 retained only on legacy SMTP submission ports for backwards compatibility with older sending software. Internal control-plane traffic between PoPs runs over WireGuard tunnels with rotating keys.

Access controls. Access to production systems is restricted to a named set of operations engineers, currently five people, each named on the internal access matrix reviewed quarterly. Authentication requires three factors. Hardware tokens (YubiKey 5 series). SSH key pair. VPN tunnel from a managed device. There is no password-based fallback. Privilege escalation to root on production hosts requires an approval workflow logged in our audit system and reviewed within seven days of issuance. Audit logs are retained for seven years on append-only storage in a separate jurisdiction from the production data, so that an attacker who compromises production cannot also tamper with the record of the compromise. The audit trail is signed with a key whose private half is held in a hardware module the operations team cannot remove from the data centre.

Network architecture. The network is the part of the architecture customers benefit from without seeing. Big Box Hosting operates its own provider-independent address space, in service since 2003. The IPv4 and IPv6 prefixes announce from five physical points of presence. There is no transit through US infrastructure on any normal-state path, no third-party CDN in front of the customer-facing endpoints, no opaque intermediate between the customer's MTA and the receiving network's edge — control-plane traffic between PoPs runs over private fiber where available and over WireGuard tunnels where it does not, and mailbox provider connections are direct BGP sessions at DE-CIX Frankfurt, AMS-IX Amsterdam, and the in-PoP exchanges (LU-CIX, SIX Ljubljana, SwissIX, Netnod, RIX). One or two hops. Our network. Verifiable from the customer's own traceroute.

Vulnerability management. Vulnerability management runs on a weekly cycle. Production hosts are scanned with OpenVAS against the latest CVE feed every Sunday night, with the report reviewed by the on-call engineer on Monday morning. Critical findings (CVSS 9.0+) are remediated within 48 hours of disclosure unless the patch itself is unavailable. High findings (CVSS 7.0-8.9) are remediated within seven days. Medium and low findings are batched into the next monthly maintenance window. Patch deployment uses Ansible against a green-blue staging pattern, so that production rollouts can be reverted in under three minutes if a regression is detected. The disclosure file at /.well-known/security.txt lists the contact email for responsible-disclosure researchers, with the GPG fingerprint of the key the security team monitors.

Incident response. Incident response is documented and rehearsed. The runbook covers the three categories of incident a hosting provider needs to handle on a 7-minute first-response SLA: service degradation (latency, throughput, queue backup), service outage (a PoP unreachable, a transit provider down, an MTA cluster offline), and confirmed compromise (unauthorised access to production, customer data exposure, ransomware). Each category has a named owner, a defined first-response sequence, and a customer-notification template that goes out within 30 minutes of the on-call engineer confirming the classification. Notifications use the status page first, customer email second, and a same-day post-mortem within 72 hours of resolution for any incident classified Severity 1 or Severity 2. The on-call rotation runs 24/7/365 with two engineers paired so that no individual is the sole responder for more than 12 consecutive hours.

GDPR. The General Data Protection Regulation applies to Big Box Hosting natively as a Slovenian d.o.o. processing personal data on behalf of customers established in the European Economic Area. The supervisory authority is the Autoritatea Națională de Supraveghere a Prelucrării Datelor cu Caracter Personal, Information Commissioner, headquartered in Ljubljana. We have a designated Data Protection Officer reachable at the email address listed in the contacts section. The DPO reports directly to the founder and is operationally independent of customer-facing functions. The Data Processing Agreement template is published as a downloadable document linked at the bottom of this section, and we accept customer-supplied DPAs that map to the same set of obligations after a legal review of typically less than two business days.

NIS2 and the Data Act. NIS2 (Directive 2022/2555/EU) covers Big Box Hosting as a digital infrastructure provider operating an MTA service used by senders across the European Union. Slovenia transposed NIS2 in October 2024 through Law 217/2024. We are registered with the Slovenian National Cyber Security Directorate as a cooperating entity. Incident reporting obligations to CSIRT.RO are documented in the runbook, with the 24-hour early warning and 72-hour notification timelines that NIS2 requires. The Data Act (Regulation 2023/2854/EU) became fully applicable on 12 September 2025, and our service contract template was updated in August 2025 to reflect the new switching obligations, the cloud-portability requirements, and the prohibition on lock-in clauses for non-personal data. Customers can extract their full configuration and operational data in machine-readable formats at any time without contractual penalty.

ISO 27001 and SOC 2 — the honest version. Big Box Hosting is not ISO 27001 certified and not SOC 2 audited. This is a deliberate decision and worth explaining because it differs from what most procurement frameworks default to. ISO 27001 certification is, by industry consensus, expensive (€30,000-80,000 for a small operator's first audit cycle, plus €15,000-25,000 annually thereafter), heavily oriented toward documentation rather than the controls themselves, and biased toward larger organisations whose internal structure already maps to the standard's organisational expectations. The certificate is a statement that the controls were in place at the moment of audit. It is not a real-time signal of operational discipline. We chose, instead, to publish the controls themselves, named on this page, with the operational discipline visible in the rest of the site — the network architecture, the legal anchors, the incident runbook timelines, the public sub-processor list. A buyer's compliance team can verify each control independently and reach a defensible conclusion without our paying €40,000 a year for a third party to do the same verification once and call it certification.

When certification is the simpler answer. There is one situation where a third-party certification is the operationally simpler answer. If the buyer's procurement framework explicitly requires ISO 27001 or SOC 2 as a non-negotiable gate, and if internal exception processes do not allow alternative documentation regardless of its quality, we cannot pretend the gap does not exist. We will tell you upfront. About 8 percent of inbound prospects qualify for this category, and we route them to providers whose certification status meets their procurement framework even when our underlying controls would have been a better technical fit. The honest framing matters more than the deal. Sending a customer to a competitor who fits their procurement gate is the long-term value-positive outcome compared to taking their business and watching it churn at first audit.

Uptime plus SLA plus backup architecture. Uptime measured as a rolling 30-day average has been 99.997 percent across the last 36 months. Annual rolling average is 99.99 percent. The published SLA is 99.95 percent for production MTA services and 99.99 percent for the control plane, with service credits applied automatically against the next invoice when the SLA is missed. Backups follow the 3-2-1 rule with the strongest jurisdictional spread we can engineer — three copies, two storage media, one copy outside the production jurisdiction. Customer data backups are written to dedicated MinIO clusters in three jurisdictions: production data in Slovenia, primary backup in Switzerland, secondary backup in Iceland. The combination of jurisdictions is deliberate. A single legal-process event in any one jurisdiction cannot reach the customer's data because the surviving copies are subject to different governing law in different courts.

Disaster recovery. Disaster recovery is documented and tested twice a year. The Recovery Time Objective for full service restoration after a complete loss of a primary PoP is four hours. The Recovery Point Objective for customer data is one hour, achieved through continuous WAL streaming to the secondary jurisdiction. Tabletop exercises run on the second Wednesday of February and August, with the runbook reviewed and updated against any gap surfaced during the exercise. The exercises rotate across realistic failure scenarios: total PoP loss (modelling a regional power event), loss of a Tier-1 carrier (modelling a fiber cut), compromise of the management plane (modelling a sophisticated intrusion), and loss of customer data integrity (modelling a ransomware-class event). The runbook itself is a living document, version-controlled in our internal repository, and the most recent revision date is published below.

The following documents are available for procurement-team review. The Data Processing Agreement template is the standard EU GDPR Article 28 instrument with our specific sub-processor list embedded — published as a downloadable PDF, accepted on the customer-supplied DPA route after a typically two-business-day legal review. The sub-processor list is published on this page and emailed to a designated security contact whenever it changes. The security questionnaire is a pre-filled response to the standardised vendor questionnaire most regulated industries circulate (CAIQ-Lite, SIG-Lite, or sector-specific equivalents) — available in Excel format on request, updated quarterly. The security disclosure file at /.well-known/security.txt lists the responsible-disclosure contact and the GPG fingerprint for confidential research submissions.

The named contacts for procurement and compliance interactions are short by design. Mikael Vainiomaa, founder, handles the legal and architectural questions during initial vendor evaluation. The DPO handles GDPR-related correspondence and DPA negotiation. The security team handles vulnerability disclosure, incident communication, security-questionnaire review. The on-call rotation handles operational incidents 24/7/365. Email addresses for each role are listed below. We respond to the addresses ourselves — there is no first-line filter that wastes a regulated-industry buyer's time on questions that need engineering judgement rather than ticket triage. The response timeline depends on the question. Architectural and legal questions get answered within one business day. Operational incidents get answered within seven minutes on the on-call rotation.