Security, data residency and retention

1.Summary

• Your data is stored in the United Kingdom (AWS London) and kept apart from every other organisation's by the database itself.
• Every document is encrypted under a key that belongs to your organisation alone, before it is stored.
• Originals go into a write-once archive that nobody, including us, can alter or delete early.
• Every action is recorded in a hash-chained audit trail, signed every night with classical and post-quantum signatures.
• Records are kept for six years by default (longer if you choose), then deleted automatically unless you hold them.

2.Keeping organisations apart

Each organisation is a tenant. Every table holding customer data carries the organisation's id and is protected by PostgreSQL row-level security, forced on for every database role including the owner of the schema, so a query can only ever see the organisation it runs for. The services connect with restricted roles that cannot switch this off, and an automated test suite attacks every API operation with one organisation's credentials against another's data on every change.

3.Encryption and keys

• In transit: TLS 1.3 to the service, and TLS for every call the service makes to the archive and to providers.
• At rest: the database, archive, backups and secrets are encrypted with keys in AWS Key Management Service.
• Envelope encryption: each document and each stored credential (ledger and mailbox tokens) is encrypted with its own data key, wrapped by a key that belongs to your organisation, before it leaves the application. The storage service never sees plaintext.

4.Integrity: archive, seals and audit trail

• Originals are kept in Amazon S3 with versioning and Object Lock in compliance mode for six years: no one, including us or Amazon, can overwrite, shorten or delete a locked original.
• Each original is sealed on arrival: its SHA-256 and SHA-384 hashes are signed with Ed25519 and ML-DSA-65 (a post-quantum signature standard, FIPS 204).
• Every change is written to an append-only audit trail in which each event includes the hash of the one before. The chain is verified and its head signed every night, and the signed statement is copied to the write-once archive. You can verify the chain yourself from the Audit screen.

5.Signing in and access control

• Passwords of at least 12 characters, stored only as salted hashes; passkeys; two-factor authentication with one-time codes and backup codes.
• Sessions last 12 hours and end when you sign out; sign-in attempts are rate-limited.
• Six roles (owner, admin, finance, approver, viewer, auditor), checked on the server for every request.
• API keys are scoped, shown once, stored only as hashes and can be revoked at any time.
• Approvals follow the policies you set; changed supplier bank details are flagged and never approved automatically.

6.Application and AI safeguards

• Uploads are checked by their actual content, not their name, limited in size, and held in quarantine before they are archived. Executables and unexpected file types are refused.
• Documents are treated as data, never as instructions: the models that read them have no tools, their output must match a fixed schema, and every value is checked against the document's text and by arithmetic and VAT rules before it is trusted. A person approves every invoice before it is posted.
• Strict content security policy, cross-site request forgery checks and secure response headers.
• Emails we send carry no tracking and no document contents.

7.Operations and resilience

• Infrastructure is defined as code in AWS London; services run as non-root containers on read-only file systems.
• Dependencies and images are scanned on every change; released images are signed and carry build provenance.
• The database runs across two availability zones with point-in-time recovery for 35 days.
• Our recovery targets are a recovery point of 5 minutes and a recovery time of 60 minutes. We will confirm them with a timed restore exercise before general availability.

8.Data residency

Settings › Organisation in Paper Free Finance shows where your deployment stores records, reads documents and sends email, read from its live configuration. The full list of sub-processors is in Annex 3 of the Data processing agreement.

9.Retention and deletion

• Documents and invoices are kept for your organisation's retention period: six years by default, which is also the minimum because HMRC expects VAT records to be kept for at least six years (VAT Notice 700/21, section 2.4). An owner or admin can choose a longer period in Settings, for example to cover corporation tax records, which are kept for six years from the end of the accounting period.
• The period runs from the latest of the date a document was received, its invoice date and the date it was posted.
• An owner or admin can put any invoice or document on legal hold, with a reason, to keep it however old it is. Placing and releasing holds is recorded in the audit trail.
• Every night, records past their period and not on hold are deleted: the original's every stored version, the document, the invoice with its lines and approvals. Each deletion is recorded in the audit trail.
• The archive's lock is never shorter than the statutory record period. A record whose lock has not yet run out is kept and reported until it does.
• When your organisation leaves, erasure of the locked archive is done by destroying your organisation's encryption key, which makes the locked copies permanently unreadable.
• An owner can export everything at any time: a ZIP of every record and original, with a manifest we sign.

10.Testing and certification

• Automated security tests, dependency and secret scanning and a tenant-isolation attack suite run on every change.
• An independent penetration test by a CREST-accredited firm is scheduled before general availability; we will share its summary letter with customers on request.
• We are preparing for Cyber Essentials certification, then Cyber Essentials Plus.

11.Incidents and breach notification

We run an incident response procedure with defined severities. If a personal data breach affects your organisation's data, we tell your organisation without undue delay and within 48 hours, so it can meet its 72-hour duty to notify the Information Commissioner (see the Data processing agreement, clause 5).

12.Reporting a vulnerability

If you think you have found a security vulnerability in Paper Free Finance, please tell us at [security contact email: to be confirmed]. Our security.txt lists the same contact.

Please include

• what you found and where (the URL, endpoint or component);
• the steps to reproduce it, and the impact you think it has;
• how we can contact you, if you would like updates or credit.

What we ask of you

• Test only with accounts and organisations you created yourself. Never access, change or delete other people's data; if you reach any by accident, stop and tell us.
• Do not degrade the service: no denial-of-service, volumetric or automated testing that affects other users, and no social engineering or physical attacks.
• Give us reasonable time to fix the problem before you share it with anyone else.

What we will do

• Acknowledge your report within 3 working days.
• Tell you within 10 working days whether we can reproduce it, and how serious we think it is.
• Aim to fix critical issues within 14 days and high-severity issues within 30 days, and keep you informed.
• Credit you, if you would like, once it is fixed.

We will not take legal action against, or ask the authorities to act against, anyone who reports a vulnerability in good faith and follows this policy. This policy follows the NCSC's vulnerability disclosure toolkit. We do not currently run a paid bug bounty.