We hold other people’s insurance paperwork. Here is how we protect it.

1Encrypted on the way and where it is stored

Every connection to Flora is encrypted with the current standard, and the disks under the database are encrypted by our hosting provider.

When you open Flora, your browser and Flora agree on an encrypted connection before a single word is exchanged. Older, weaker connection types are refused. If someone types the plain unencrypted address, they are sent to the encrypted one, and browsers are told to remember that for two years.

Our hosting provider, Railway, encrypts the storage under everything it runs for us, including the database that holds your documents, and manages the keys. Flora does not add a second encryption layer of its own today. Between Flora and its database, traffic stays on the provider’s private network, which is encrypted between services; the database has no public address at all.

Check it yourself: Look at the padlock in your browser on any Flora page, or read the connection details it shows.

2Where Flora runs

Flora runs on Railway in the United States, a hosting provider that holds its own SOC 2 Type II and SOC 3 reports.

Flora and its database run as two services in one Railway project, in Railway’s US West region in California. Your uploaded documents are stored inside that database; there is no separate file store.

Railway’s certifications belong to Railway, not to Flora. Railway publishes its SOC 2 Type II report, its SOC 3 report and an independent penetration test report through its trust center, and offers a data processing agreement.

Check it yourself: Railway’s trust center is public; the link is in the table of companies below.

3Signing in and staying signed in

Passwords are scrambled so that not even Flora can read them, and a sign-in expires on its own.

Flora never stores your password, only a one-way scrambled version of it, so Flora cannot read a password back and neither could anyone who copied the database.

When you sign in, Flora gives your browser a token that points to a record on our side. The record holds only a fingerprint of that token, so a copy of the database cannot be used to sign in as you. A sign-in ends after seven days without activity and after thirty days no matter what, and you can sign out of any device from your account page.

Repeated failed sign-ins lock that email address, from that location, for fifteen minutes, and every failure is written to the record. The Flora team signs in through a separate staff door.

Since September 19, 2026, Flora staff accounts, the ones that can see customer files, can turn on two-step verification: a code from an authenticator app plus a set of recovery codes. Once a staff account has turned it on, the password alone is no longer enough to get in.

Where we are honest: Two-step verification is switched on account by account, not required across the board, and customer accounts do not have a second factor yet. If your company needs it for its own users, say so; the code is already written and extending it is a short job.

4Who can see your file

Every company file belongs to one company, and one gate decides who can open it.

Every read and write passes through one gate that checks who you are and which company you belong to. An agent sees their own book, a carrier sees its own accounts, a business owner sees one policy, and the Flora team can see every file in order to run the service. That staff access is a separate sign-in, and every action is recorded.

Every page and every connection checks this for itself. The menu only hides what you cannot open; it is never the thing that protects it.

5A record that cannot be changed

Every change to a file is recorded, and the record cannot be edited or deleted.

Every change writes one line to a permanent record: who did it, what changed, when, and what it looked like before and after.

The database itself refuses to alter or remove those lines, and Flora checks that protection is in place every time it starts and every time it saves a change. If the protection were ever missing, Flora would refuse to save anything until it was back.

Check it yourself: The technical description of that protection is included in the security packet.

6Loss-run retrieval

Loss runs for clients and agents — 95+ carriers and growing — under written authorization, with an audit trail, and without storing portal passwords in the application database in this phase.

Loss runs are official carrier PDFs a business needs for bids, contracts, certificates, renewals, and coverage changes. With the insured’s (or agent’s) written authorization, Flora requests or retrieves that PDF and stores it in the company file. Flora is an authorized requester — not an insurer or appointed agent.

In this phase, Flora staff perform the retrieval under that authorization for 95+ carriers and growing. Access is limited to the pull. Who authorized, who executed, and whether it succeeded are written to the audit trail. Portal passwords are not stored in Flora’s application database.

Check it yourself: Ask for the authorization text on a loss-run request and the security packet for the wider program.

Where we are honest: Automated carrier login is not live. Flora has not completed its own SOC 2 audit, does not require a second sign-in factor for every account, and has not published a penetration test.

7Protection built into every page

Every page tells your browser exactly what it may run and load, and every form is protected against being submitted from another site.

Each page ships with a strict set of rules for the browser: only Flora’s own code may run, nothing from other companies loads, and the page cannot be embedded inside another website. No third-party scripts run on Flora.

Anything that changes data must come from Flora itself and carry a one-time token issued for your visit. Uploads are limited to PDF, JPG and PNG files, checked both by their name and by their actual contents, and capped at 15 MB. Card details are entered on Stripe’s pages, never on Flora’s.

Check it yourself: Open any Flora page and read the response headers in your browser’s developer tools.

8Your documents and the AI

The text of your documents is never sent to an AI provider.

Flora’s AI features run with the document-text setting switched off in production. That setting is checked by the very last step before anything leaves Flora. When the AI would need the text of a document, Flora answers from its own built-in checks instead; it does not send a trimmed version.

What can be sent is the facts on your checklist and the questions people type, after Social Security numbers, tax IDs, account numbers, email addresses, phone numbers and card numbers are removed. Each request is logged with the provider, the model, and a fingerprint of exactly what was sent, never the content itself.

The provider is Groq. Its contract with us says it may not use anything we send to train its models, and it does not keep what we send by default. Flora does not train models on customer data either.

Check it yourself: Groq’s services agreement and its “Your data” page are public; both links are in the table of companies below. Flora’s own request log is in the packet.

9How long we keep things, and deleting them

Files are kept for as long as the audit they support can be reopened, and erased within thirty days of a confirmed request.

Company files and documents are kept while the file is open and afterwards for as long as the audit it supports can still be reopened, which for most workers’ compensation policies is three years after the policy term ends. A carrier’s contract may set a different period for that carrier’s files.

Anyone can ask for a copy of their company file, or for it to be removed, through the contact page or the account page. A person confirms the request by email, and the Flora team then erases the company, its file and every document in one step, within thirty days. What is kept, deliberately: the permanent record described above, plus anything the law or a carrier contract requires us to keep. Sign-ins expire on their own and are cleaned up afterwards.

Check it yourself: The full item-by-item table is on our data page, linked at the end of this page.

Where we are honest: Erasure is a request handled by a person, not a self-serve button. There is no self-serve download of a stored document today either; a copy of your file is provided by the Flora team on request.

10Backups

The database is backed up continuously by our hosting provider, and we have practiced restoring from that backup.

Railway keeps a continuous backup of the database that can be wound back to any moment in roughly the last four weeks, plus daily and weekly snapshots.

On September 19, 2026 we practiced restoring twice. First we brought a full copy of the database back into a throwaway database: every table came back, every row count matched the live service, and every stored document was checked byte for byte against the fingerprint recorded when it was uploaded. Then we used the provider’s own wind-back tool to restore the live database to a chosen moment in a second throwaway copy: it was accepting connections in about six minutes, every table count matched the live service, and the copy was deleted afterwards.

Where we are honest: Two steps have not been practiced yet: restoring from the daily and weekly snapshots, and switching the live service over to a restored database, which we estimate would take ten to fifteen minutes in total. The backups also live with the same provider as the database. We do not hold a copy anywhere else today, so loss of the Railway account is a risk we have accepted knowingly while we are small.

11Companies we work with

Five companies can receive customer data, and each receives only what its job needs.

The table below is complete as of the date on this page. If we add a company, it appears here first.

12Keeping the software up to date

Every piece of software Flora depends on is pinned to an exact version, the build refuses to ship with type errors, and an automated test suite covers the protections on this page.

Flora’s dependencies are pinned to exact versions and updated deliberately, never silently. The build is strict and stops on type errors. An automated test suite covers sign-in, sessions, who can see what, the browser rules, the form protection and the pages on this site, and runs before each deploy.

Security reports go to the founder personally and are read first.

Where we are honest: Automated weekly dependency scanning is configured and switches on with our next push. A customer contract that requires it will move it to the top.

13Where we stand on audits

Flora hasn’t done a SOC 2 audit yet. We share our written security packet and our host’s SOC 2 reports instead.

Flora is a small company with one engineer. A SOC 2 audit costs more than a year of Flora’s hosting, so it will happen when a customer’s contract needs it, not before. Until then this page, and the packet behind it, are the audit: each claim names its evidence, and you can check most of them yourself.

What we can send today: this page’s claims with the evidence behind each, our written security policies, a description of how Flora is built, the list of companies we work with, the incident response plan, a completed security questionnaire, and Railway’s own SOC 2 Type II and SOC 3 reports through its trust center.

14Reporting a security problem

Security reports go straight to the founder and are read first. We aim to acknowledge within two business days.

Write to florawc.support@gmail.com, or use the contact page with the topic “Security report”. Include what you saw and how to reproduce it; do not include another person’s data. We also publish a standard contact file that security researchers’ tools look for.

Please give us a reasonable time to fix an issue before describing it publicly, and do not test against accounts that are not yours. We will not pursue anyone who reports in good faith and stays within those lines.