Security and compliance

We run on hardware in three data centers: Helsinki in Finland, and Falkenstein and Nuremberg in Germany. You choose the region when the service is created, and data isn't moved between regions unless you request it. Cross-region replication is opt-in, not something we switch on in the background to improve response times.

We use no sub-processors outside the EU. Concretely, that means: no American CDN in front of your pages, no product analytics sending session data across the Atlantic, no email relay in the US, no support system storing your tickets outside the EU. The full sub-processor list comes with the data processing agreement and is updated when it changes, with advance notice so you have time to object.

The honest line is drawn at traffic you initiate yourself. If your application makes a call to a third-party service in the US, or you send an email to a recipient with a US mailbox, that data leaves our control the same second. The same applies to the AI gateway: if you choose a model provider outside the EU, the prompt goes there. We mark which model routes stay within the EU so the choice is a conscious one.

• Regions: Helsinki (FI), Falkenstein (DE), Nuremberg (DE)
• No sub-processors outside the EU – list attached to the data processing agreement
• Data isn't moved between regions without a request
• Outbound traffic you initiate yourself is outside our control

We sign Article 28 data processing agreements with every customer who needs one, at every price tier, at no extra charge. For what you put into the services, you're the data controller and we're the processor. For account data, billing and support correspondence, we're the controller ourselves, and that processing is described in our privacy policy.

Deletion happens on request and on termination. By default, data is removed from primary storage within 30 days of the request, and disappears from backups once that generation falls out of the retention window. There's a technical truth that's often glossed over: we can't surgically pull a single row out of an encrypted backup generation. It disappears when the generation is pruned, not before. If you need a shorter window, that can be configured, with a corresponding reduction in recovery depth.

We solve data portability by not using lock-in formats. Postgres exports via pg_dump, object storage speaks the S3 API, files are files, git is git. There's no export queue to wait in line for and no fee for leaving. If you want a written deletion certificate when you're done, we'll send one.

• Article 28 DPA included, regardless of plan
• Deletion from primary storage within 30 days by default
• Backup generations are pruned per the retention window – not on a row-by-row basis
• Export in standard formats: pg_dump, S3 API, plain files, git

All external traffic runs over TLS, with TLS 1.3 where the client supports it and TLS 1.2 as the lowest accepted level. Older protocols and weak cipher suites are disabled. Certificates are issued and renewed automatically via ACME. Internal traffic between our nodes runs over a WireGuard-based private network, not the open internet.

At rest, object storage and backup data are encrypted. For VPS and dedicated servers, disk encryption is your choice: we can set it up, but someone has to unlock the volume on reboot, which in practice means either manual intervention or a key kept close to the machine. We don't pretend that problem goes away just because encryption is switched on.

Backups are encrypted client-side. Data is encrypted before it leaves your machine, with a key you hold. That means two things at once: we can't read your backups, and we can't restore them if you lose the key. That's a trade-off you need to make consciously, not something you discover during an incident.

Worth stating plainly: encryption at rest protects against a stolen or improperly discarded disk. It doesn't protect against an attacker who already holds valid credentials in a running system. Access control does more for your security than the encryption algorithm.

• TLS 1.3 where the client supports it, TLS 1.2 as the floor
• Automatic certificate management via ACME
• Client-side encryption for backups – the key stays with you
• Disk encryption on VPS and dedicated is an active choice, not the default

Console login goes through OIDC. We run our own identity service built on open source, and if you already have an identity provider that speaks OIDC, it can be federated so your staff never gets a separate SIAX password. Multi-factor can be enforced for the whole organization and supports both TOTP and passkeys.

Permissions are role-based and tenant-scoped with deny-by-default: whoever hasn't been granted a permission doesn't have it, and roles don't inherit upward between organizations. API keys are scoped to specific services and operations, can be rotated without downtime, and are listed with their last-used timestamp so dead keys are visible.

The audit log records who did what, when and from where — logins, permission changes, key rotations, deploys, deletions. It can be exported and forwarded to your own SIEM. One nuance: the log is append-only at the application layer and can't be edited from the console. It isn't, however, cryptographically anchored externally, so we don't claim it's tamper-proof against someone with full operational access. If you need that guarantee, external anchoring is the right solution, and we don't have it today.

• SSO via OIDC, federation with your existing IdP
• Enforced MFA per organization (TOTP or passkeys)
• Role-based, tenant-scoped access with deny-by-default
• Exportable audit log, append-only at the application layer

Backup costs from 19 kr per 100 GB per month and runs on a schedule with configurable retention. What matters isn't that the backup is taken but that it can be read back. We run restore tests on a schedule, log the results, and can hand over the report. A backup that's never been tested is a hypothesis, not a safeguard.

We recommend keeping backups in a different region than production, and that at least one generation is write-protected so a compromised production key can't delete the history. That's an extra cost, and we say so openly instead of leaving it in the fine print.

Recovery times depend on data volume and service type. We don't promise a recovery target in minutes for everything we operate. If you need a binding RTO and RPO, we'll write it into the agreement for the specific services after measuring how long an actual restore takes in your environment. Figures that don't come from a tested scenario are guesses.

• Scheduled restore tests with a report you can show
• Offsite backup in another region recommended – costs extra
• Write-protected generation as protection against a deleting attacker
• RTO and RPO are written in only after measurement in your environment

Many of our customers are covered by NIS2 directly, or as a supplier to someone who is. We contribute documentation, not compliance. What you get from us is documented backup procedures with verified restores, exportable logging, documented incident handling with agreed notification times, a record of where your data is located and which sub-processors are involved, and a named contact for security questions.

What you own yourselves is the rest, and that's most of it: the risk assessment, management's responsibility and training, business continuity planning, managing your entire supply chain where we're just one link, and reporting to the supervisory authority when something happens. No provider can sell you NIS2 compliance as a product, and anyone implying that should be read critically.

Sweden's implementation of NIS2 has moved slower than the EU's original timeline, and the details around supervision and reporting have been adjusted along the way. Check the current status with MSB before basing a decision on a timeline you read on a vendor's website, including this one.

• Documentation: backup with verified restores, exportable logs, incident procedure
• Notification to you without undue delay, no later than 24 hours after assessed impact
• You own the risk assessment, management responsibility, continuity plan and regulatory reporting
• Check the current regulatory status with MSB – the timeline has shifted

The platform is built on open source all the way down: Postgres for databases, S3-compatible object storage, restic for backup, Gitea for git and CI, an OIDC server for identity, Prometheus and Grafana for monitoring, an open gateway in front of the language models. You can read the code running your service. You can also run it yourself, with us or elsewhere, which makes leaving a real option rather than a threat you can never actually carry out.

That's a security property in itself. A provider you can leave behaves differently than a provider you're stuck with, and a component you can audit can be assessed before it goes into production rather than after.

Two nuances. Open source isn't automatically more secure — the fact that many people can read the code doesn't mean anyone has, and recent years' incidents in open supply chains show what it costs when no one does. And our own glue code, meaning the control plane and the console, isn't public today. We'd rather say that plainly than let the phrase "built on open source" be read as meaning everything we run is open.

• Postgres, S3-compatible storage, restic, Gitea, OIDC, Prometheus and Grafana
• No proprietary formats – leaving is technically feasible
• Open source provides auditability, not automatic security
• Our own control plane isn't public code today

SIAX is not ISO 27001 certified. SIAX is not SOC 2 audited, neither Type I nor Type II. We are not PCI-DSS certified — card payments are handled by our payment provider and card numbers never pass through our systems, but that doesn't make us certified. We have no external audit report to attach to a procurement process, and we don't run a bug bounty program. We're a small team, which gives us short decision paths but also means we don't have a staffed security department around the clock.

In practice, that means you can't replace your own vendor assessment with our certificate, because there isn't one. Instead, you can audit us directly: ask questions, read the code, request the restore report, write requirements into the agreement. That's more work for you, and more transparency than a certificate gives.

Choose a different provider if you have a hard requirement for ISO 27001 or SOC 2 in public procurement, if you're under financial supervision requiring audited sub-processors, if your procurement process only accepts third-party reports as evidence, or if you need PCI scope at the provider level. Those are legitimate requirements and we don't meet them. It's better you find that out here than in the final meeting.

One last thing, for balance: a certificate measures documented processes at a point in time, not the absence of vulnerabilities. That's an argument against over-interpreting certificates, not an argument for ignoring them. If your regulatory framework requires certification, then it requires it.

• No ISO 27001 certification
• No SOC 2 Type I or Type II
• No PCI-DSS certification – card data is handled by our payment provider
• No external audit report to attach to a procurement process
• No bug bounty program, no round-the-clock security staffing

If you've found a vulnerability in our services, email security@siax.io. Describe what you found, how to reproduce it, what impact you assess it has, and how to reach you. If you'd like to encrypt the report, get in touch and we'll send a key before you send the details.

We acknowledge a report within 24 hours on a business day, follow up with an initial technical assessment within 72 hours, and keep you updated at least once a week until the case is closed. We work with coordinated disclosure and ask for up to 90 days before publication, shorter if we manage to fix it sooner. If you'd like to be credited, we will; if you'd like to stay anonymous, we respect that. We don't pay a bounty today and don't promise to start.

We won't take legal action against anyone reporting in good faith who stays within reasonable bounds: only test against your own resources, don't extract other customers' data, don't run denial-of-service attacks, don't modify or delete anything that isn't yours, and don't direct social engineering at our staff or our customers. If you come across someone else's data by accident, stop, delete it, and tell us.

• Report to security@siax.io – key for an encrypted report on request
• Acknowledgment within 24 hours on a business day, assessment within 72 hours
• Coordinated disclosure, up to 90 days
• No bounty paid, but no legal action for good-faith reporting