Security

Who can read your work

Organisation administrators cannot read members’ documents — not their contents, not their titles. This is structural rather than a policy we promise to keep: the organisation tables hold no reference to documents or workspaces at all, so there is no path from an administrator’s console to a member’s writing. Administrators manage people, seats and billing.

Inside a workspace, its owner can reach the documents in it. That is what a shared workspace is for, and it is the opposite trust model from an organisation — which is exactly why the two are separate things rather than one bigger thing.

Encryption

In transit: TLS on every connection. At rest: full-disk encryption on the managed Postgres and object storage we run on.

Credentials you give us for your own model provider are encrypted at the application layer before they are stored, with a key held outside the database. No endpoint returns one — not masked, not partially. If encryption is unavailable we refuse to store the key rather than holding it in the clear.

Access on our side

Administrative actions inside an organisation are recorded in an audit log its administrators can read and export: who invited whom, who changed a role, who changed a setting, and when. The log deliberately contains nothing about what any member wrote, opened or edited — there is no document reference on that table.

Provisioning and sign-in

SCIM 2.0 provisioning is available on Institution. Tokens are stored as hashes, shown once, revocable, and each resolves to exactly one organisation.

Not yet available: SAML single sign-on. The schema exists; the flow does not. We would rather say so here than have you discover it during a procurement review.

Your data, and leaving

Any account can export everything it holds as a single file, at any time, without asking us. Closing an account is scheduled thirty days out and is reversible for all of them; nothing degrades in the meantime.

An organisation can set how long documents are kept. It is off by default, and members are told what it is set to.

When something goes wrong

Our commitment, in the order it happens:

• We tell affected customers within 72 hours of confirming an incident involving their data — including when we do not yet know its full extent.
• The first notice says what we know, what we do not, and what we are doing. We do not wait for a complete picture before telling you there is one.
• A written follow-up goes out within 14 days: what happened, what changed as a result, and what would have prevented it.
• Incidents affecting availability are posted on the status page while they are being worked on, not after they are resolved.

Reporting something

Found a vulnerability? Write to security@specio.space. We acknowledge within two working days. We will not pursue anyone who reports in good faith, tests only against their own account, and gives us a reasonable window before publishing.