Security Overview

What SIVO Hub actually does to protect the data in it and, in the second half, what it does not do. This page is Annex 2 to the Data Processing Agreement, so it is a contractual statement rather than marketing.

Separation between customers

Every record belongs to exactly one workspace, and every request is checked against the workspace of the account making it, on the server, before anything is read or written. The check does not depend on what the browser sends: an administrator of one company who edits the identifier in a URL or in a request body is refused rather than served somebody else’s record.

This is tested by attacking it. On 7 September 2026 an administrator account in one company was used to make 23 deliberate attempts to read, change, delete and create records inside another company’s workspace, across pages and the API. Every attempt was refused and no record was altered.

Signing in

• Sign-in is by a six digit one-time code sent to a work email address, valid for ten minutes, with a limited number of attempts and rate limits on both the address and the requester. Codes are stored hashed, never in the clear.
• Alternatively, an organisation can sign in with Microsoft or Google using OpenID Connect with PKCE. Tokens are verified against the provider’s published keys, and a Microsoft sign-in can be restricted to named tenants.
• There are no passwords to steal, reuse or leak, because the product does not have any.
• The session cookie carries the __Host- prefix, so a browser refuses it unless it is secure and scoped to this host, and it lasts 14 days.
• Signing out ends the session on every device at once, and an administrator can end somebody else’s sessions the same way.

In transit

All traffic is carried over HTTPS. The service sends HTTP Strict Transport Security with a one year lifetime including subdomains, a Content Security Policy, X-Frame-Options: DENY, X-Content-Type-Options: nosniff, a referrer policy and a permissions policy. The public site loads no third-party script, font or tracker of any kind.

Email leaves over TLS or it does not leave at all. The sending domain is set to enforced TLS, so a message to a receiving server that will not negotiate an encrypted connection fails rather than being delivered unencrypted. This matters more here than it does for most services, because signing in is done with a code sent by email, and that code is a credential.

Files

Every uploaded file is scanned for malware before it can be downloaded. Until a file has been scanned and found clean, downloading it is refused. A pending or failed scan is treated as a refusal, not as a warning. Files stay locked to the ticket or asset they belong to, storage keys cannot be manipulated to escape their folder, and deleting a record removes its files and then removes the folders they were in, because those folders are named after customers and tickets.

Accountability

Significant actions (sign-ins, replies, status changes, permission changes, deletions) are written to an audit log with the acting account, the time, the IP address and the browser identifier. Your own administrators can read your workspace’s log. If we open a record in your workspace to investigate a fault, that is written to your log too.

Backups

• The database and the uploaded files are backed up every six hours, integrity checked as they are written, and kept for 30 days.
• An hourly copy is pushed to separate storage in Finland, in a different building from the server, and kept without automatic pruning.
• A further daily copy is pulled to storage the operator controls, which the server cannot reach and does not know exists.
• The freshness of the first two copies is monitored, and the platform reports an offsite copy that has stopped arriving rather than assuming it is still running.
• Restores are tested, not assumed. The last full restore test was on 3 September 2026.

Where things run

The application, the database, the uploaded files and the primary backups are hosted in the European Union, and the offsite copy is in Finland. The providers involved are named on the subprocessors page.

What we do not have

This section is here because a security page without one is a sales page. Everything below is a real gap. If any of it matters to your procurement, it is better that you know now.

• Certification. SIVO Hub holds no ISO 27001 certificate, no SOC 2 report and no equivalent, so please do not expect one in a supplier questionnaire. Both audits are priced and scoped for organisations with staff to run them, and buying a badge would tell you less about this service than the rest of this page does: every measure listed here is specific, dated, and something you can hold this service to. If your own client contracts require a certified processor, this is the point to say so before you sign up rather than after, and the honest answer today is that another supplier will suit you better.
• No independent penetration test. The service has not been tested by an external security firm. The isolation testing described above is our own.
• No multi-factor authentication of our own. Sign-in relies on control of the email inbox, or on your Microsoft or Google account. If you require enforced MFA, use the Microsoft or Google sign-in and enforce it there.
• No application-level encryption at rest. Data is protected by the access controls described above and by the hosting provider’s infrastructure. The database file itself is not separately encrypted by the application, and we do not claim that it is.
• No 24/7 monitoring or on-call rota. SIVO Hub is operated by one person. Alerts are seen when that person is awake.
• No segregation of duties. One person administers the platform, which means the controls above are not enforced by a second pair of hands.
• No bug bounty programme. Reports are still very welcome, and dealt with as below.

Reporting a vulnerability

Email [email protected] with enough detail to reproduce the problem. We will acknowledge within two working days and tell you what we intend to do. We will not take legal action over research that is carried out in good faith, does not access, alter or delete data belonging to anyone else, does not degrade the service for others, and is reported to us before it is reported anywhere else. Please do not test against another customer’s workspace under any circumstances.

If something goes wrong

Our handling of a security incident is described on the availability and support page, and our notification obligation to customers is in section 8 of the Data Processing Agreement: within 24 hours of becoming aware of a personal data breach, to the administrators on the account, even where the facts are still incomplete.