Security

BranFillable holds documents people sign and identifiers they would rather not repeat. This page describes what we actually do — not an aspiration, and not a certification we have not obtained.

Keeping one customer out of another

Every record that belongs to an organization carries its organization's identifier, and two independent mechanisms enforce it: a global query scope applied at the model layer, so a query that forgets to filter is still filtered, and middleware on every authenticated request. A record reached by guessing its identifier in a URL is refused on the server.

Child records that cannot carry an organization identifier of their own — the questions inside an exam, the rows inside a list — are reachable only through their parent, and the parent's identity is asserted before the child is returned. A mismatch answers not found rather than forbidden, so a probe cannot use the response to learn that a record exists.

Encryption

• In transit — TLS on every connection to the application, and on every call to a sub-processor.
• At rest — full-disk encryption at the hosting layer, and on top of it, application-level encryption of Social Security and licence numbers, bank details and everything held in the confidential medical store. Keys live outside the database, so a database copy on its own does not yield those fields.
• Passwords — hashed with bcrypt, never stored or logged in a readable form, with a minimum length enforced on every path that sets one.

Access control

• An organization has exactly one administrator — the person paying for the plan — and the database enforces it with a unique index, so no code path can create a second one.
• Invited staff are staff. There is no route, form or field anywhere that accepts a role, so an invitation cannot be turned into an administrator account.
• Staff see only the contacts they created; an administrator sees the team's. This is applied to the data query, not to the buttons on screen.
• Removing a member deactivates them, rotates their token and deletes their sessions; any browser still holding one is signed out on its next request.
• Administrative screens live behind their own role and their own route group. Nothing in them is reachable by a customer user.

Support access to a workspace

We can open a read-only view of a customer workspace to diagnose a problem. It is constrained by the request method, not by a list of screens, so every write — including one added to the product tomorrow — is refused by default. Routes whose job is to hand a browser a capability outside the application, such as a payment portal session, are blocked explicitly. The session expires automatically, requires the operator to re-enter their own password, is rate-limited, and is written to the audit log at both ends. A banner on every page says whose workspace is being viewed.

Recipient links

A link sent to a recipient is cryptographically signed, valid once, and expires 24 hours after it is issued — enforced on the server, not by hiding a button. Expired, already used, revoked and never-existed links all render the same page, so a link cannot be used to probe whether a person is in the system. The recipient never has an account and never sets a password.

Logging and accountability

Privileged actions are written to an audit log with the actor, the time and the source address. Logs carry identifiers, never file contents and never a signed URL. Where a file request feature is used, the record of who opened which file, when and from where is kept as part of the customer's own account of access.

Files, and the ones we choose not to hold

Uploaded PDF templates, generated documents and thumbnails are stored on a private volume, never on a public one, and are served only through an authenticated route that re-checks the requesting user's organization and asserts that the stored path belongs to it. We do not use public storage links for tenant files: a signed public URL is transferable and carries no tenancy check.

Where a customer connects their own storage for file requests, the file content goes to that account and we keep the record rather than the file. The smaller the amount of sensitive material we hold, the smaller the consequence of any failure on our side — that is the point of the design.

AI features

AI calls send the structure of a document — field names, labels, option text, exam questions. They do not send a recipient's answers, a signature image or an uploaded file. Producing a completed PDF and stamping a signature are done with local tooling on our own infrastructure. Per-account and platform-wide spending ceilings are enforced before a run starts and again after every single API response, so a compromised session cannot turn an allowance into an unbounded bill.

How changes reach production

• Every change goes through a security review before release, covering injection, access control, cross-tenant leakage, authentication bypass and exposed secrets.
• The production image is built from source and immutable; nothing is edited on a running server, and a running container cannot pick up a changed file.
• Dependencies are installed from lockfiles, so a package that exists only on a developer's machine fails the build rather than reaching production.
• Production data is never copied into development or test environments. The test suite runs against its own schema.
• Secrets are held in the environment, never in the repository, and are rotated on suspicion.

What we do not claim

Buyers ask about these, and an honest answer is worth more than a badge:

If something goes wrong

We notify an affected customer without undue delay and within 72 hours of becoming aware of a breach of personal data we hold for them. Where Florida law applies to us as a third-party agent, the statutory deadline is 10 days under Fla. Stat. §501.171(6); the stricter of the two governs. Notifying the affected individuals is the customer's decision and duty as the controller of that data — we give them everything they need to make it. Our incident procedure is contain, assess, notify the customer, meet the statutory deadlines, then document the cause and the fix.

Reporting a vulnerability

Write to security@branfillable.com with what you found, how to reproduce it and what it affects. Please do not open a public issue.

Safe harbour. We will not pursue legal action against anyone who reports in good faith, stays within the minimum access needed to demonstrate the issue, does not access, modify, delete or retain another person's data, does not degrade the service, and gives us reasonable time to fix it before disclosing. We acknowledge reports promptly and will keep you informed until it is resolved. We do not currently run a paid bounty.