Security

Overview

This page describes the technical and organisational measures protecting the data iLawForms holds. It is Annex II to the Data Processing Addendum, and it is written to be usable as an answer to a vendor security review.

We may improve these measures over time. We will not make a change that materially reduces the overall level of protection.

Protecting the data itself

• In transit. All traffic is served over TLS, including between internal services. HTTP requests are redirected to HTTPS, and cookies carry the Secure attribute in production.
• At rest. Databases, object storage and backups are encrypted at rest.
• Passwords. Stored as salted hashes using a modern password hashing function. We cannot recover a password, only reset it.
• Tokens. Session tokens, email verification tokens and rights-request verification tokens are stored hashed, are single-use where the flow allows, and are time-boxed. A leaked database does not yield a usable link.
• IP addresses. In consent records and rights-request records, IP addresses are stored as salted hashes rather than as addresses — enough to correlate an abuse pattern, not enough to become a fresh pile of personal data collected in the name of privacy compliance.
• Payment data. Card numbers never reach our systems. Stripe collects them directly and we hold only its opaque customer and subscription identifiers.

Access control

• Every member of staff has an individual account. There are no shared credentials.
• Access to production data is limited to the people whose role requires it, and is reviewed when a role changes.
• Administrative action taken on a customer account is written to an append-only audit log recording who did what and when.
• Within the product, data is scoped to the organisation that owns it, and enforced at the query layer rather than in the interface — so a missing check in a page cannot expose another customer’s records.
• Production secrets are injected at run time by the deployment platform. They are never committed to the repository, and never present in a build artefact.

Building the software

• Changes are reviewed before merge, and continuous integration runs type checking, linting and the test suite on every change.
• Dependencies are scanned for known vulnerabilities, and security updates are applied on a priority basis.
• Development, staging and production are separate environments. Production personal data is never copied into a non-production environment.
• Error reports are scrubbed before they leave the process: cookies, authorisation headers, tokens, connection strings and sensitive query parameters are redacted, and user email and IP address are excluded by default.
• Forms that send email or create accounts are protected by a bot challenge, and the challenge is only rendered when the server holds the secret needed to verify it — a decorative challenge is worse than none.
• The document renderer is a pure function of its inputs, with no database access, no clock and no randomness. That is a correctness property first, but it is also a security one: a document cannot leak state it never had access to.

Availability, backups and recovery

• Hosted policy serving runs as a separate deployable from the product, on a cache-first path with no database dependency at read time. An outage in the product does not take a customer’s live legal document offline.
• Published documents are immutable and content-hashed, so an unexpected change to a served document is detectable rather than a matter of trust.
• Databases are backed up automatically on a 35-day rolling cycle. Backups are encrypted, stored separately from production, and restore-tested periodically.
• Infrastructure is defined in code and can be rebuilt from the repository and a backup.

Incident response

We have a documented incident response process with defined roles for detection, containment, eradication, recovery and review.

Where an incident involves personal data we process on your behalf, we notify you without undue delay and in any event within 48 hours of becoming aware of it, with the information set out in the Data Processing Addendum. We notify in phases rather than waiting to complete an investigation, because a late complete report is worse than an early partial one when your own notification deadline is running.

Where an incident affects personal data for which we are the controller, we notify affected individuals and the relevant supervisory authority as the law requires.

Sub-processors

Every third party that processes personal data on our behalf is listed, with its purpose and location, on the Sub-processors page. Each is engaged under a written contract imposing obligations no less protective than those we owe you, and is reviewed before engagement. Analytics and error tracking are self-hosted specifically so that no vendor receives that data at all.

What we do not have

We would rather say so plainly than let you discover it during a procurement review. Implying a certification we do not hold — by listing a framework we “align with”, or a badge that means nothing — is the kind of claim this product exists to argue against.

If your organisation requires an attestation before it can buy, tell us at security@ilawforms.com. We will tell you honestly where we are, and we will complete a security questionnaire in full.

Reporting a vulnerability

Report security issues to security@ilawforms.com. Please include enough detail to reproduce the issue. We acknowledge within two business days, keep you updated, and will credit you when the fix ships if you want us to. We do not currently pay bounties.