Sciro Security Overview

Last updated: 26 June 2026 · Version: 1.0

1. Purpose

This document explains how Sciro protects your data, what we store, and exactly what each integration accesses. It is intended for the security and procurement teams of prospective and existing customers. For the legal detail, see our Privacy Policy and Data Processing Agreement.

2. Hosting and infrastructure

The application is hosted on Vercel. The database, authentication, and file storage are provided by Supabase (PostgreSQL).
All data is encrypted in transit using TLS (HTTPS), and encrypted at rest by our infrastructure providers.
Sciro is built entirely on infrastructure that maintains recognised security certifications (Supabase, Vercel, Stripe, and OpenAI each hold SOC 2 and/or ISO 27001 certifications). Sciro itself is not currently independently certified to SOC 2 or ISO 27001; we apply the security controls set out in this document and build on the certified infrastructure above.

3. Tenant isolation and access control

Sciro is multi-tenant. Every record is tagged with an organisation identifier, and access is scoped to a user's own organisation.
Row-Level Security (RLS) is enabled at the database level, so one organisation cannot read another's data.
Tables holding sensitive operational data (audit logs, invitations, billing records, integration credentials) are not directly readable by client applications and are accessed only by trusted server-side code.
Access within an organisation is governed by role-based permissions (administrator, manager, and standard user), with granular permission controls.
API requests are authenticated and authorised before any data is returned, with checks on the user's organisation, role, and permissions as appropriate to the request.
Internal (Sciro) access. Operating the Services does not generally require Sciro personnel to access your data. A single, named super-admin account is used for limited platform administration and support. That access is gated server-side by verified account identity, so knowing the account identifier alone grants no access; an attacker would have to compromise the account's own authenticated login. The account is used only to operate and support the Services and is subject to confidentiality.
Sensitive endpoints are protected by rate limiting to prevent abuse.

4. How uploaded documents are stored

Receipts, invoices, and statements are stored in private storage buckets. They are never publicly accessible.
Files are served only through short-lived signed links that expire after one hour, generated for authorised users at the moment of access.
Account deletion removes both the database records and the underlying files from storage.

5. Authentication

Authentication is provided by Supabase Auth. Passwords are hashed and never stored in plain text.
We support email and password sign-in and single sign-on with Google and Microsoft.
Sessions are managed with secure cookies. A "remember me" option controls session length.
Users can delete their account and associated data at any time from within the product.

6. Integrations: exactly what we access

We request the minimum access needed for each feature, and nothing more. Each connection is made by your own administrator and can be revoked by you at any time.

Accounting software (Xero)

Authorisation: OAuth 2.0, connected by your administrator. We never see your accounting login credentials. We request only the scopes below.

Scope	Why we request it
`openid`	OpenID Connect sign-in. Returns the ID token that identifies the Xero user who authorised the connection (stored encrypted).
`profile`	OpenID Connect identity claim (the authorising user's name), returned as part of sign-in.
`email`	OpenID Connect identity claim (the authorising user's email), returned as part of sign-in.
`accounting.transactions`	Create the bill in Xero for an approved expense or invoice (the only write we make to your ledger).
`accounting.settings`	Read your chart of accounts, tax rates, and enabled currencies so expenses are coded and currency-matched correctly, and create a tax rate only if a required one is missing.
`accounting.contacts`	Set the contact (the claimant or supplier) on the bill so it posts against the right party; Xero creates the contact if it does not already exist.
`accounting.attachments`	Attach the original receipt or invoice file to the Xero transaction for your records.
`offline_access`	Obtain a refresh token so approved items can be posted later without the admin re-authorising every time.

What we do not access: payroll, bank feeds, or any data outside the scopes above.

Email import (Microsoft 365 / Outlook)

Authorisation: OAuth 2.0, connected by the user.

Scope	Why we request it
`Mail.Read`	Read-only access to the mailbox to list messages, identify those carrying importable attachments (PDFs and images), and download only the attachments the user chooses to import. We never send, modify, or delete email.
`offline_access`	Obtain a refresh token so the connection stays active without the user re-authorising every time.

How your mailbox data is handled:

Read-only, your mailbox only. Every request uses your own token against your own mailbox. We cannot send, modify, move, or delete email, and one user can never read another user's or another organisation's inbox.
Only emails that have attachments. We ask Microsoft to return only messages with attachments within the time window you choose, so attachment-less emails are never retrieved.
Only importable attachments are surfaced. Of those, only PDFs and images are shown for import; anything else is discarded server-side.
We never read full email bodies. Only a short preview is used to help you recognise an email; it is shown transiently and never stored.
We store only what you choose to import. Importing an attachment keeps the file (in private storage) and a document record. For bulk imports we also keep the email subject (sanitised) solely to avoid importing the same email twice. Senders, previews, and email bodies are not persisted.
You stay in control. Disconnecting removes the stored connection immediately. Tokens are encrypted at rest, scoped to you, and never sent to your browser.

HR system (Breathe)

Authorisation: an API key that you provide and can revoke at any time. Breathe issues a single key rather than granular OAuth scopes, so the table below lists the specific data we read and why.

Data we read	Why we request it
Employee directory (`GET /employees`)	Names, work emails, job titles, and line-manager relationships, used to create or update user accounts and build approval chains.
Absences (`GET /absences`)	Leave start and end dates, cached to route approvals around people who are away.

What we do not pull: salary, payroll, or any other HR data beyond directory and leave information.

How we protect integration credentials

Connection tokens and API keys are encrypted at rest using AES-256-GCM. The encryption key is held only in our server environment and is never sent to a browser.
Tokens are never returned to a client. They are decrypted and used only by trusted server-side code, never exposed through the website or API.
Database access to a stored token is restricted by Row-Level Security: a token record can only be read by the single account that created the connection, and only within its own organisation. Other users, and other organisations, cannot read it. The HR system API key is locked down further: it is not readable by any client at all, only by server-side code.
Every use of a connection is confined to the requesting user's own organisation.

What a user with integration access can and cannot do

A user who is granted access to an integration can only trigger the specific, predefined actions the product provides, such as syncing approved items, reading account codes and contacts for categorisation, or attaching a receipt to a transaction. They cannot:

view, copy, or extract the underlying access token or API key;
make arbitrary or direct calls to the connected system outside the operations Sciro performs;
exceed the limited permission scopes granted when the connection was made (listed above); or
access any other organisation's connected systems.

The access is therefore bounded on three sides: the limited scopes granted at connection, the specific operations in our code, and strict separation between organisations.

7. Artificial intelligence processing

Sciro uses OpenAI to read uploaded receipts and invoices and extract details such as vendor, date, amount, and line items.
Only the document being processed is sent for extraction. Access via the OpenAI API means the content is not used to train OpenAI's models and is retained only transiently in line with OpenAI's API data policy.
To suggest an expense category, Sciro also sends a short text summary of an expense (vendor, item descriptions, and an amount band) to Voyage AI (a MongoDB company) to generate a numeric embedding. No document images are sent.
AI extraction is an aid only. A person within your organisation reviews and approves every claim; no decision is made solely by automated means.

8. Sub-processors

We use a small set of vetted sub-processors, each under a data processing agreement: Supabase (database, authentication, storage), Vercel (hosting), Stripe (payments), OpenAI (document extraction), Voyage AI / MongoDB (expense-category embeddings), Resend (transactional email), Google Maps Platform (mileage distances and address validation), and Upstash (rate limiting). The current list is maintained in our Data Processing Agreement.

9. Data retention and deletion

We hold your data for as long as your organisation's account is active.
On account closure we delete your data, including uploaded files, within a reasonable period, except where law requires us to retain financial records for longer.
You can request an export of your data before deletion.

10. Logging, monitoring, and incident response

Key authentication and account events (sign-in, password changes, account deletion) are recorded in an audit log.
Application errors are logged for diagnostics; we do not use third-party behavioural analytics or advertising trackers.
In the event of a personal data breach affecting your data, we will notify you without undue delay in line with our Data Processing Agreement and applicable law.

11. Compliance posture

Sciro is designed to comply with the UK GDPR and the Data Protection Act 2018.
A Data Processing Agreement (UK GDPR Article 28) is available to all customers.
We are registered with the Information Commissioner's Office (ICO) under registration number [ICO REGISTRATION NUMBER].

12. Your responsibilities

Security is shared. You are responsible for managing your users and their permissions, removing access for people who leave, keeping credentials secure, and ensuring you have a lawful basis to upload personal data about your employees and contacts.

13. Contact

For security questions, or to request our Data Processing Agreement, contact us at legal@sciro.app.