Security measures

These measures apply to the production service that practices use, and to the systems we use to run it. They are described in terms of what the service does, not in terms of certifications. Where a measure is carried out by a provider that hosts part of the service, we say so, and the Sub-processors page names the providers.

2.1 THEMIS is a web application with a desktop app that loads the same service. The application runs as serverless functions in Dublin, Ireland. Records and files are held in a managed database and storage service in Ireland. Static public assets are served from a content delivery network.

2.2 There is one production service shared by many practices. The separation between practices is therefore a property of the software and the database, and clause 3 describes it.

2.3 The desktop app does not store practice records on the computer. It opens the practice's workspace over a secure connection. Files a person chooses to download are saved by the operating system like any other download.

3.1 Every record that belongs to a practice carries the identity of that practice, and the database enforces that a request can read and write only the records of the practice it is made for. This is row-level security, enforced inside the database, not only in the application.

3.2 The practice a request belongs to is derived on the server from the signed-in person's session, or from the unguessable token in a client, signing or sharing link. It is never taken from a value the browser could change.

3.3 A small number of operations, such as signing in and scheduled jobs, must work across practices. They are limited, run in a separate mode, and are written to touch only what they need.

3.4 We test separation between practices as a security property. A test that reads another practice's data and expects to see nothing is part of how we check changes.

4.1 Each person has their own account and a role. Roles decide what a person can see and approve, and the invitation screen states what each role can and cannot do. A practice can add custom combinations of access for a person where its work needs it.

4.2 Passwords must be at least 12 characters long. They are never stored. Only a salted, slow, one-way hash is stored, produced with scrypt.

4.3 Repeated failed sign-in attempts for an account, or from an address, are throttled, and the attempts are recorded.

4.4 A session lasts at most ten hours. The session cookie is signed so that it cannot be altered, is not readable by scripts running in the page, and is sent only over a secure connection.

4.5 A practice can lock staff accounts to its verified email domains. Invitations to join are personal to the email address they are sent to, expire after seven days and can be withdrawn.

4.6 Links given to clients, guests, signers and people receiving shared documents carry long random tokens. Each link reaches only the one matter, document or workspace it was created for. Links expire, can be revoked, and, for shared documents, can require an access code. Only a hash of each token is stored.

4.7 Staff sign-in does not yet offer a second factor. We say so in clause 17.

5.1 Money held in trust cannot be released by the person who asked for the payment. A second person with the right role must approve it.

5.2 Some acts are reserved to people and cannot be done by the assistant features, even when it is asked to. They include approving a payment, signing, filing with a registry and giving a legal opinion. This is enforced in the software.

5.3 Approving a document as the authorised conveyancer is limited to people who have been designated for it, and is recorded.

5.4 Actions that change records require the right role on the server. The user interface hiding a button is never the only control.

6.1 Information is encrypted in transit between a person's device and THEMIS, and between THEMIS and the providers it uses, using the transport security those providers support.

6.2 Information at rest is held by our database and storage provider, which encrypts stored data. Practice documents are stored in the database and are not held on the computers of our staff.

6.3 Secrets that the service needs, such as signing keys and provider credentials, are held in the hosting provider's protected environment. They are not stored in the source code or in the database. Practice-held credentials we generate, such as API keys, are shown once and stored only as one-way hashes.

7.1 Input from the browser is checked on the server before it is used, and database queries use bound parameters so that input cannot change the meaning of a query.

7.2 Files that are uploaded are limited in size and checked for type. Image files that can carry scripts are checked and refused if they do. Documents are served with headers that stop a browser from running them as pages.

7.3 The embedded document editors run under a content security policy that limits where they can load code and data from.

7.4 When the service sends a webhook to a practice's address, it refuses addresses that point to private or internal networks, does not follow redirects and limits how long it waits, to prevent the service being used to reach internal systems.

7.5 Access for programs through the API is limited per key by named permissions, by a rate limit, optionally by address, and by an expiry. Sandbox keys cannot read a practice's real records. Every request is logged against the key.

7.6 Changes to the service are made in version control and deployed by an automated pipeline. Changes to the database are applied as numbered migrations, each recorded in the repository.

8.1 Actions taken in a practice's account, such as opening a matter, approving a document or releasing a payment, are written to an audit trail. Each entry is chained to the one before it by a cryptographic hash, and entries cannot be changed or deleted by the application or by a practice administrator, so that tampering is detectable.

8.2 The practice can export the audit trail with a verification of its chain.

8.3 Sign-in attempts, requests made with API keys, emails sent and the use of assistant features are recorded with who and when, so that unusual activity can be seen and investigated.

8.4 Logs are kept for the periods in the Data retention schedule. Logs avoid recording the content of documents.

9.1 The assistant features propose. A person decides. Output is marked as unverified until a person has reviewed it, and answers cite the source passages they rely on, or say that the answer is not in the file.

9.2 Only the text needed to answer a request is sent to the model provider, and it is not authorised to use that text to train its models. Each request is recorded in the AI activity log.

9.3 The assistant works within the permissions of the person who is using it. It cannot read matters that person cannot read.

9.4 The practice's administrator can see the AI activity and can turn AI features down in the AI controls.

10.1 The service runs on infrastructure that provides redundancy across facilities within its region, and our database and hosting providers operate their own continuity and recovery measures.

10.2 Practice data can be exported by the practice at any time, so that a practice is never dependent on us for access to its own records.

10.3 We do not publish a recovery time objective or recovery point objective, and we do not promise one in this document. The Support and service levels document states what we do commit to.

11.1 We use a small number of providers, each for one function. They are named on the Sub-processors page with their purpose, the data they handle and their location.

11.2 Each provider is engaged under a written contract that limits its use of the data and requires security and confidentiality. We give notice of changes as the Data Processing Agreement provides.

11.3 We give a provider only the data it needs for its function.

12.1 Security concerns can be reported to security@olympuspay.co. We investigate every report.

12.2 When we become aware of a personal data breach affecting a practice, we tell the practice without undue delay, as clause 12 of the Data Processing Agreement describes.

12.3 After an incident, we find its cause, fix it, and change our controls so it is less likely to recur.

If you believe you have found a vulnerability in THEMIS, write to security@olympuspay.co with the details needed to reproduce it. Please do not access, change or delete data that is not yours, do not disrupt the service, and give us reasonable time to fix the issue before you disclose it. We will acknowledge your report, keep you informed and not take action against you for good-faith research that follows these rules.

Information is kept for the periods in the Data retention schedule and deleted when they end. On request, and after a practice leaves, we delete its content as clause 14 of the Data Processing Agreement describes. Each practice can export its content for 30 days after it leaves.

Security is shared. The practice's administrator controls who has an account, which role each person has, which domains are allowed, which clients and guests are invited, and which AI features are in use. Strong passwords, prompt removal of people who leave, and care about who is sent a link are the practice's part of keeping its information safe.

Access to production systems is limited to the people who need it to run the service. Where a person has access to information in a practice's account to give support the practice asked for, the access is limited to that purpose and the practice's confidentiality terms apply.

We want a practice to rely on what is true, so we state the limits of this document plainly.

• We do not hold ISO/IEC 27001, SOC 2 or a comparable certification, and we do not claim to.
• We have not published an independent penetration test report. We will say so here when one exists.
• Staff sign-in does not yet offer multi-factor authentication or single sign-on. We intend to add them, and until we do, a practice should rely on strong passwords and its domain lock.
• We do not promise recovery time or recovery point objectives, or an availability figure, in this document.
• Encryption at rest is provided by our storage provider. We do not currently offer keys held by the practice.
• No system is free of risk. These measures reduce risk. They do not remove it.

We update this document when our measures change, and we show the date at the top. We will not make a change that materially weakens the protection described here. For earlier versions, write to privacy@olympuspay.co.