Security and Data Overview

FR^NK, a trading name of Frank Online Ltd. Version 2, 2 October 2026.

For prospective customers and their security teams. Written from the codebase, not from a template. Section 8 lists what is not yet in place, with dates.

We are a small team. We have not completed a SOC 2 or an ISO 27001 audit and we do not claim one. What follows is a factual account of how the platform is built and run, including the parts that are not finished. Every statement here can be evidenced on request, and where a control sits with one of our providers we cite their documentation rather than ours.

1.  The company and the product

2.  Hosting and data location

3.  Encryption

• In transit to the browser: TLS, with a one year HTTP Strict Transport Security header in production and an automatic redirect from plain HTTP.
• In transit to the database: TLS. The managed database sits on the provider's private network and presents a self-signed certificate, so the connection is encrypted but does not verify that certificate against a public authority. We state this precisely rather than describing it as a verified connection.
• At rest: server-side encryption on every object written to storage. Database backups are additionally encrypted client-side with AES-256-GCM before upload, so a stored backup does not rely on the storage provider's key management alone.
• Passwords: stored only as bcrypt hashes. No password is recoverable.
• Not encrypted: individual database columns are not encrypted at the application layer. Disk encryption beneath the managed database is provided by the hosting provider.

4.  Access control

• Role based, with four persisted roles covering supplier administrator, supplier editor, customer viewer and customer editor.
• Accounts are per person. Access is granted by invitation, single use, expiring after seven days.
• Passwords must be at least twelve characters and are rejected if they are common or derived from the user's email address or the product name.
• Sessions are seven days, held in an httpOnly cookie marked secure in production, with no silent renewal. Disabling an account, resetting a password or changing a password terminates every other session for that user.
• Supplier administrators can access a customer workspace in order to support it. We treat that as a control that needs disclosure rather than one to leave implied, and the current limitation is at section 8.
• Report sharing uses a link protected by a password or an emailed code, with an optional expiry and immediate revocation, controlled by the customer.

5.  Resilience

• Backups run weekly on two independent layers. Our hosting provider takes a managed backup of the database volume, retained 27 days. Separately the platform streams its own encrypted copy off-platform every week, retained 63 days, with the first copy of each month retained 400 days.
• The off-platform pipeline applies five integrity checks before a run is recorded as good, including minimum table and row counts, a format signature check, a size floor, a regression floor against the previous run, and a byte count check after upload. The record of success is written last, so a partial run leaves no record claiming success.
• A restore has been tested. On 12 August 2026 a production backup was downloaded, decrypted and restored into an isolated database, and the row counts of the three recorded tables matched exactly. The result is logged.
• Point-in-time recovery is enabled on the managed database. Its window begins at the first base backup after enablement and is not retroactive.

6.  Development and change control

• Private repository, two authorised individuals.
• Continuous integration on every change to the main branch and on every pull request, covering type checking, the production build and the database-free test suites.
• The main branch blocks force pushes and branch deletion.
• Organisation level secret scanning across 46 internal repositories, watching commits for exposed credentials. No environment file has been committed across more than 760 commits.
• 136 test files, of which 36 are database backed integration suites, plus five end to end specifications. Tenant isolation, retention and cancellation behaviour are covered by tests.
• Written review procedures, architecture decision records and phase verification documents are version controlled alongside the code.

7.  Data handling

• A daily retention sweep issues hard deletes on a published schedule. Each rule runs in isolation, so a failure in one does not suspend the others.
• On cancellation a workspace becomes read-only for 60 days, during which the customer can read and export everything, and cannot generate new work. At the end of that period the workspace, its data and its files are deleted.
• Deletion is verified by tests that check the purged tenant is empty and every other tenant is intact.
• Encrypted backups are whole-database copies from which one customer cannot be extracted, so a deletion becomes final when the last backup containing it expires. We do not restore a backup to recover deleted customer data.
• The administrative activity log survives a workspace deletion with the customer link removed, on its own 365 day clock, because it is the evidence that the deletion happened.

8.  What is not yet in place

This section is the reason to trust the rest of the document. Each item carries the position as at 18 August 2026.

9.  Providers

The platform relies on hosting and data providers, each named in our data processing agreement with its purpose, the data it receives, where it processes and the transfer mechanism relied on. A current list is published, with a way to subscribe to changes, and we give 30 days' notice before adding or replacing a provider, with a right to object.

Provider certification status is a matter for each provider and we cite their own sources. In summary, our hosting provider declares SOC 2 Type 2 and SOC 3 with reports behind an access request; our storage infrastructure provider declares SOC 2 Type 2; our email provider declares SOC 2 Type II and certifies under the Data Privacy Framework with the UK Extension; and our search data provider publishes an ISO/IEC 27001:2022 certificate as a public document. We will make an access request on your behalf for any gated report.

10.  Incident response

• A documented procedure with four severity levels, worked examples, named roles, a six phase process, communication templates and an incident register.
• The regulatory clock runs from the point of knowledge, not from the end of an investigation. We notify with what we have if the picture is incomplete.
• Customer notification within 48 hours of becoming aware of a breach affecting their data, running alongside the regulatory clock rather than after it.
• A published security contact at [email protected].

11.  Privacy

• For personal data in your workspace, you are the controller and we are your processor, governed by our data processing agreement.
• We do not use customer data to train any model of our own. Our AI providers are engaged on paid terms under which they do not use what we send to improve their products.
• Requests submitted to AI providers carry website text, findings and keywords. They carry no account data: the request builders contain no email field and no user name field.
• The platform makes no automated decisions about individuals, and our contract prohibits a customer from using an output as the sole basis for one.

12.  What to ask us for next

Any of the following, on request, under a mutual non-disclosure agreement: our data processing agreement including the full technical and organisational measures annex and the sub-processor list; our completed security questionnaire; our incident response procedure; the restore drill record; and an access request to any provider whose assurance report you need.

Contact: [email protected].