Security and backups

Hosting and backups

The free service is run by Waivern on Railway, in its EU West (Amsterdam) region. The application and its PostgreSQL database are shared by the organisations that use it, kept apart as described below.

• The database is backed up daily, on a schedule run by Railway, so after a failure it can be brought back to the most recent backup.
• Because the database is shared, a restore brings back every organisation’s records together. It is there to recover from a failure, not to undo one organisation’s change; the audit trail and version history are how a change is understood and put right.
• The application reaches its database over the hosting provider’s private network, and you reach the application over HTTPS.
• The records are held in the EU, not the UK. That is lawful - the EU holds UK adequacy, so the transfer needs no further safeguard - but if your organisation needs its records kept in the UK, a dedicated instance can be.
• The tool is built to hold decisions about processing rather than the personal data being processed. Some registers, such as data protection requests, complaints and breaches, do hold details of the people involved; they are protected in the same way as everything else.

Signing in

There are no passwords to steal or reuse. People sign in with their Google account, so two-step verification and password rules are Google's and, for a Google Workspace account, the ones your IT team already sets.

• Signing in with a valid account is not enough on its own: the address must belong to someone invited to an organisation, or to an email domain the organisation has verified. Public domains such as gmail.com cannot be claimed.
• Google accounts whose email address Google has not verified are refused.
• A sign-in lasts 12 hours, then the identity provider is asked again.
• What a person may do is looked up afresh on every request, so removing somebody's access takes effect on their next click, not when their session ends.
• The no-password sign-in used for local development refuses to start in production.

Who can see and do what

Access is given by role, and a role can cover the whole organisation or a single legal entity within it. Someone working for one company in a group sees that company's records and no other's.

• Only approvers and owners can decide approvals or accept a risk.
• Every change is checked against the person's role on the server, whatever the screen in front of them shows.
• Organisations cannot remove their last owner, so an organisation is never left with nobody able to manage it.

Keeping organisations apart

Many organisations share the hosted service, so keeping their records apart is not left to the application remembering to filter. The database does it.

• Every table holding an organisation's records has PostgreSQL row-level security. Work for an organisation runs as a restricted database role that can only reach that organisation's rows, so a query that forgot its filter still sees nothing else.
• An automated test attacks one organisation from another, reading, changing, linking and listing records, and fails if any function that touches an organisation's records is left out of it. It runs on every change before the change can be released.

A record that cannot be quietly changed

Every change is written to an audit trail in the same database transaction as the change itself, so there is no change without its record and no record of a change that did not happen.

• The trail is append-only. The database refuses any attempt to edit or delete an entry; a mistake is put right by recording a correction, not by rewriting history. Assessment revisions, risk acceptances, incidents and training records are protected the same way.
• Entries are chained: each carries a SHA-256 hash of its contents and of the entry before it, so altering one entry breaks every entry after it.
• The exported trail carries instructions a recipient, such as an auditor or the ICO, can follow to check the chain for themselves.
• Exports and file downloads are themselves recorded.

Keys and secrets

The credentials the tool holds for other systems are encrypted in the database with AES-256-GCM, using a key that is kept outside it. A copy of the database alone yields no working credentials.

• This covers the keys for an organisation's chosen AI model, the secrets used to sign traffic with other tools, and Cookie Consent Analyser tokens.
• Links that let somebody without an account contribute to an assessment are stored only as a hash, open one assessment, and expire after 14 days unless set otherwise. They can be withdrawn at any time.

Uploaded files

Signed agreements and other supporting files can be attached to records, up to 10 MB each.

• Only PDF, Word (.docx), Excel (.xlsx), plain text, CSV, PNG and JPEG are accepted. Nothing a browser would run, including HTML and SVG, is accepted, and nor are the pre-2007 Word and Excel formats (.doc and .xls), whose files are a common way of carrying macro viruses.
• Each file's fingerprint is recorded when it is uploaded and checked whenever it is downloaded; a file that has changed is refused.
• Files are always handed back as downloads, never opened in the page, and only to people allowed to read the record.
• A file's contents are checked against the type it claims to be, so a program renamed to look like a PDF is refused.
• Files are not scanned for viruses. Open them with the care you would give any attachment.

Forms open to the public

An organisation can publish a form for people to make a data protection request. It is the one part of the tool open to anyone, so it carries its own protections.

• Its address is random and can be withdrawn and replaced.
• Submissions are limited to 5 an hour from one internet address and 50 an hour to one form, and forms filled in faster than a person could are refused.
• Internet addresses are kept only in a scrambled form, for a day, to apply those limits.

Connecting other tools

Other systems send records in and take approved facts out through a versioned API. Every request is signed with a secret unique to the connection.

• A request whose signature is wrong, or more than 5 minutes old, is refused.
• Each connection can reach only the parts of the API its kind needs, and a batch is limited in size.

The AI assistant

The assistant is off until an organisation's administrator turns it on, and then it uses the AI provider, model and account the organisation chooses. Waivern supplies no model and no fallback, so nothing is sent to an AI provider your organisation has not picked.

• Email addresses, National Insurance numbers, card numbers, phone numbers and similar are removed from what people type before it is sent. This catches common patterns; it is not a guarantee, so do not paste personal data into it.
• Conversations are deleted after 30 days.
• It drafts and explains. It cannot change a record or make a decision; a named person always does.

Open, tested code

Waivern Governance Tool is open source under the AGPL-3.0 licence, so anyone can read exactly how it handles your records rather than taking our word for it.

• Every change is type-checked, linted, and run against the full automated test suite on a real PostgreSQL database, including the tests that keep organisations apart, before it can be merged.
• Logs record the shape of what happened, such as sizes, durations and counts, not the content of your records.
• Every page carries a Content-Security-Policy that lets only scripts the tool issued for that page run, and no other site may show the tool inside a frame. Browsers are also told not to guess at file types, to pass other sites only the tool's address rather than the page someone came from, that the camera, microphone and location are never used, and, in production, to reach the tool only over HTTPS.

A dedicated instance of your own

Everything above comes free with the shared service, and nothing in the software is held back for paying customers. If your organisation needs more control over where and how its records are kept, we can set up and run a separate instance for you alone. It is the same software; what changes is how it is hosted, and that is agreed with you.

Your own servers and database

Your organisation's records alone, on an application and database that no other organisation uses.

Where it is held

A region you choose, including the UK, for organisations that need their records to stay there.

Backups to your requirements

How often the database is backed up and how long backups are kept, agreed with you, with restores that bring back your records alone.

Your sign-in only

Sign-in limited to your own Google Workspace, so nobody outside it can even ask for access, and an address of your own if you want one.

Your own keys

An encryption key for stored credentials that belongs to your instance alone.

Updates when you are ready

New versions applied on a timetable agreed with you, rather than as they are released.

Email alerts for your people

Alert and action emails to the people who ask for them: new work, overdue work, mentions and decisions. They are not offered on the shared service.

Help when you need it

Technical support, training for your staff, and changes to fit how your organisation works, if you want them.

The arrangements are set out in writing before anything is moved. To talk about it, email info@waivern.com.

Reporting a security problem

If you think you have found a weakness, please email info@waivern.com rather than raising it in public, so we can fix it before it can be used. Tell us what you found and how to see it; we will reply and keep you told what we are doing about it.