LEGAL & TRUST

Security

Updated 9 September 2026 · AIONA Grade & AIONA Bookkeeping

1. Who we are

AIONA LTD, registered in England & Wales, company number 16606520. Registered office: 128 City Road, London, EC1V 2NX. Registered with the Information Commissioner's Office, registration number ZC189017.

2. Where your data lives

• Application and database: Fly.io, London, United Kingdom (region lhr).
• Documents you upload: Google Cloud Storage, europe-west2 (London).
• Document data extraction: Google Document AI, EU region.
• Marketing website: Netlify.
• Error monitoring: Sentry, EU region - reports are scrubbed of personal data before they are sent.

A full sub-processor register, including the purpose and location of each, is published in §5 of our Privacy Policy.

3. Practice and product access

AIONA Grade has its own sign-in pages and review workspace. Grade and Bookkeeping use the same underlying account and practice access controls. Grade provides Xero Assurance and the scorecard; Bookkeeping tools require the relevant product access. A separate portal does not mean a separate copy of your practice account.

Every firm's data is separated from every other firm's. That separation is enforced in two independent places: in application logic on every query, and by PostgreSQL row-level security policies on tenant tables, so a query that omits its tenant context returns nothing rather than returning another firm's records.

The application connects to the database as a least-privilege role that cannot create, alter or drop tables, and cannot bypass those row-level policies.

4. Bookkeeping ledger integrity

This is the control the product is built around, and it is enforced by the database itself rather than by application code that could be bypassed:

• A posted journal entry cannot be modified or deleted. Corrections are made by reversal, which leaves both entries visible.
• Audit events are append-only - they cannot be updated or deleted.
• Every posted journal carries a SHA-256 hash chained to the previous entry, so any later alteration is detectable rather than merely discouraged.
• The only permitted exception is a one-way anonymisation of a personal identifier when a data subject exercises their right to erasure, which is itself recorded in the audit trail.

5. Access and authentication

• Passwords are hashed with bcrypt. We never store them in a recoverable form and cannot see them.
• Two-step verification (a time-based code from an authenticator app, with single-use recovery codes) is available to every user and can be required for everyone at a practice by its administrator. A stolen password alone does not open an account that has it switched on.
• Role-based permissions: administrator, accountant, and read-only auditor.
• Repeated failed sign-ins temporarily lock an account.
• Self-serve sign-up is open. Each new practice gets its own isolated tenant, its first user is created as that tenant's administrator, the sign-in email address is verified with a one-time code before the account can be used, and passwords must meet a minimum strength requirement.

6. Encryption

• All traffic is served over TLS (HTTPS). The application is not reachable over plain HTTP.
• Data is encrypted at rest by the underlying platforms (Fly.io volumes, Google Cloud Storage).
• Third-party credentials you connect - such as accounting or banking integration tokens - are encrypted by us before storage, using a key held outside the database.

7. Backups and recovery

The database platform takes an automatic daily snapshot of the database volume, retained for five days. Separately, the application itself writes an encrypted export of the database every night to storage held with a different provider, in the UK and EU, keeping fourteen daily copies and the first copy of each of the last six months. Every export is checked before it is stored: the tables that must be present are confirmed present and not empty, the row counts written into the file are compared against the live database, and the file must carry the completion marker that proves it was not cut short. The stored copy is then read back and checked against its own fingerprint. If a night ever passes with no backup at all, an independent outside service raises an alarm, because a backup system that can only report its own failures cannot report its own silence. One stored backup has been retrieved, decrypted and checked by hand. We do not yet run a nightly test restore into a spare database, and we will not describe an untested backup as a tested one. The database platform also keeps a continuous archive: a full base backup daily and the write-ahead log shipped every minute to storage held with a third provider, giving point-in-time recovery to within about a minute across a rolling seven days. That archive was switched on and its first backup verified on 22 August 2026.

8. Monitoring

• Application errors are captured with full diagnostic context, scrubbed of personal data, and alert us by email.
• Every deploy is health-checked: a new release only takes traffic once it answers its health endpoint, and the previous release is kept running until it does.
• Automated code and dependency scanning, including secret detection, is configured to run on every change and weekly, alongside a scheduled availability probe. These checks depend on an external scheduler that is not currently running; the application-managed backup exports in section 7 run separately. until it is restored we do not claim continuous scanning or continuous availability monitoring. We do not yet run an independent external uptime monitor.

9. What is not in place yet

Stated plainly, because you will ask:

• No ISO 27001 or SOC 2 certification. We do not claim either. The controls above are real, but they have not been audited by a third party.
• Single production instance. We will move to redundant instances as the client base grows.
• No independent external uptime monitor. Point-in-time recovery is described in section 7; automated restore testing is not yet in place.
• Live HMRC submission is not enabled - VAT, RTI and CT600 output is prepared for you to file through your existing route while our HMRC software recognition is pending.

10. Service status and incidents

We do not yet publish a live status page or run an independent external uptime monitor (see section 8) - we tell affected practices directly. If the Service is materially unavailable or an incident affects your data, we email the named contact at your firm, and we will publish a written post-incident note on request. A personal-data breach is notified in line with our Data Processing Agreement and UK GDPR Article 33 timelines.

11. Reporting a vulnerability

If you believe you have found a security issue, please email support@aionatech.com with the details. We will acknowledge within two working days. Please give us a reasonable opportunity to fix the issue before disclosing it publicly. Our machine-readable policy is published at /.well-known/security.txt.

12. Your data is yours

You can export your ledger, documents and audit trail at any time from inside the product, in open formats, with no exit fee. See our Data Processing Agreement for deletion and return commitments on termination.