Security

Journl holds other businesses' financial records. This page says how we look after them, and how to tell us if you think something is wrong.

Reporting a security concern

If you believe you have found a vulnerability in Journl, or that an account or data has been accessed without permission, email security@journl.co.uk. It is read by the people who build the software, not a ticket queue.

• We will acknowledge your report within two working days and tell you what we are doing about it.
• Tell us what you found and how to reproduce it. Please do not access, change or download data that is not yours while demonstrating it, and do not test against other customers' books.
• We will not take action against anyone who reports a genuine concern in good faith and gives us reasonable time to fix it.

If there is a breach

If we discover that personal or customer data has been exposed, lost, or accessed without authority, we follow a written procedure:

1. Contain it. Revoke the affected credentials or sessions, close the route in, and preserve the logs.
2. Establish what happened: which data, which customers, since when.
3. Tell the people affected within 72 hours of becoming aware, with what we know, what we have done, and what they should do.
4. Tell the Information Commissioner's Office within 72 hours where personal data is involved, as UK GDPR requires.
5. Tell HM Revenue & Customs within 72 hours where the breach concerns data handled through Making Tax Digital, by logging a ticket on the HMRC Developer Hub with a named contact and telephone number.
6. Fix the cause, and write down what we learned.

How your data is protected

• Where it lives. Amazon Web Services, London region (eu-west-2). The database, backups and file storage are in the United Kingdom.
• In transit. Every connection to Journl is encrypted (TLS 1.2 or later). Browsers are told to use HTTPS only (HSTS).
• At rest. The database and backups are encrypted. HMRC access and refresh tokens are additionally encrypted with a key kept outside the database, so the database never holds a token that works.
• Separation. Each business's data is isolated at the database level: a query for one set of books cannot read another's.
• Sign-in. Passwords are stored only as one-way hashes. Two-factor authentication with an authenticator app is available to every user, and the time it was used is reported to HMRC with each filing, as their fraud-prevention rules require.
• Who can see what. Access to a set of books is by named role (owner, bookkeeper, accountant, read-only). Journl's own staff can see a customer's books only to provide support that customer has asked for, under confidentiality, and that access is logged.
• The record. Posted entries cannot be edited or deleted; a correction is a further entry. The audit trail shows who did what and when.
• Testing. The site and API are scanned with OWASP ZAP before each release, and the findings addressed. The software's HMRC integration passed HMRC's fraud-prevention header validation in the sandbox before production access was requested.

What we ask of you

• Use a strong, unique password, and turn on two-factor sign-in.
• Give people access to your books by role, and remove it when they leave.
• Tell us straight away if you think your account has been used without your permission.