Security, built in layers.

LtdRecord is not end-to-end encrypted. Our servers process structured records, generate documents and call selected providers, so the service must be able to read data while doing that work. Staff or provider personnel may also need tightly limited access to operate, secure or support the service.

Security therefore comes from layered controls: authentication, company and role authorisation, transport encryption, scoped storage encryption, private service credentials, input limits, abuse controls, logging and a clear incident process. No single sentence makes the system secure on its own.

Keep the mailbox or Google account used for sign-in secure. If you believe someone else has access, sign out, secure the identity provider and contactinfo@9s-labs.com.

• In transit: production browser and API traffic uses HTTPS/TLS. Connections from the application to managed providers also use their encrypted transport endpoints.
• Structured records: account, company, transaction and workflow data lives in a managed PostgreSQL service with application credentials kept on the server. It is protected by provider and application access controls; it is not covered by the per-company R2 envelope described next.
• Generated files and uploads: new objects written through the configured production R2 path are sealed with AES-256-GCM. Each company has a random 256-bit data-encryption key, and that key is itself wrapped by a separate server-side master key. Stored object bytes are not publicly addressable through the application.
• Payments: Stripe hosts the card-entry and payment layer. Full card numbers do not pass through LtdRecord’s servers.

Envelope encryption limits what a storage-layer disclosure reveals, but it does not protect content from a compromised running application that can legitimately unwrap the relevant key. That is why identity, authorisation, secrets and monitoring remain separate controls.

For a bounded task, LtdRecord may send OpenAI text, an image or document extract, transaction descriptions, relevant company facts and a limited amount of recent Operator context. We avoid sending unrelated company history. OpenAI’s business controls and our privacy notice explain the provider boundary in more detail.

• Model output is checked by deterministic rules where the workflow has a rule that code can enforce.
• Evidence, facts and authority remain separate states. A plausible model answer is not a filing receipt or director approval.
• LtdRecord does not ask for or store Government Gateway passwords, Companies House authentication codes or Companies House personal codes as part of guided filing steps.
• Do not place passwords, card security codes, authentication codes or private keys into a prompt, mail upload or support message.

• Security-sensitive and expensive routes use rate limits, including sign-in, evidence upload, document generation, exports and outbound email. The limit and identity key vary by route.
• Supported upload paths enforce file-size and file-type allowlists and do not accept active formats such as HTML or SVG as ordinary evidence. This is validation, not a claim that every malicious file can be detected.
• Print and render links use signed, scoped and time-limited tokens where a background renderer cannot carry the user’s browser session.
• Production response headers include transport security, clickjacking protection, content-type protection, referrer controls and a Content Security Policy.
• Important security and record actions produce structured logs designed to contain stable identifiers and outcomes rather than passwords, one-time codes or raw record content.
• Server secrets, storage credentials, payment keys and AI credentials are kept out of client-side bundles.

LtdRecord relies on managed infrastructure providers for parts of database and storage resilience. We do not currently publish a contractual recovery-time or recovery-point objective. Keep independent copies of source statements, statutory records and filing receipts that your company is required to retain.

Account deletion first identifies the companies owned by the account, attempts to cancel live Stripe subscriptions, removes associated database records and then sweeps each company’s object-storage prefix. Removing the company row removes its wrapped file key. A failed external-storage deletion requires an operational retry; provider logs and backups can age out on separate schedules.

An invited user leaving a company does not erase the company’s record. Their access is removed and personal author pointers are cleared or replaced where the company must keep the underlying business event.

We investigate credible security or personal-data incidents, work to contain the issue, preserve the facts needed to understand it and document the outcome. Where a personal-data breach is likely to create a risk to people, we notify the ICO within the period required by law where feasible. Where the risk is high, we also notify affected people without undue delay and explain practical steps they can take.

These are legal thresholds, not a promise to keep an incident quiet when it falls just below one. We can communicate sooner where doing so helps a customer protect its company or account.

• LtdRecord is not end-to-end encrypted.
• Per-company AES-256-GCM applies to supported object-storage files written through the configured production path; it is not a claim that every database field uses the same envelope.
• We do not currently claim ISO 27001 certification, SOC 2 attestation or an independently certified penetration-test programme.
• Rate limits, file checks, encryption and logging reduce risk; none proves that a vulnerability or incident cannot happen.
• This public page is not a customer-specific security schedule. Enterprise customers can discuss requirements and evidence during discovery.

Email info@9s-labs.com with Security report in the subject. Do not access another person’s data, degrade the service, use social engineering, retain downloaded personal data or publish a vulnerability before we have had a reasonable chance to investigate.

We aim to acknowledge a credible report promptly and keep the reporter informed as the facts become clear. We do not publish a fixed response-time SLA or an unlimited safe-harbour promise on this page.

Personal-data concerns can instead follow the complaint process in our privacy notice. The UK government’s current baseline for software vendors is also available in its Software Security Code of Practice.