Security and reliability

Last updated: 2 October 2026

This page says how FSMCore protects the data companies put into it. Every statement here was checked against the code and the live server on the date above. What is not done yet is not listed.

1. Where your data lives

Application and database: one server at Hetzner Online GmbH in Falkenstein, Germany. The database (MySQL) runs on that same server and cannot be reached from the internet.
Files (photos, PDFs, certificates, logos): Backblaze B2, EU Central region, in a private bucket. A file opens only for a signed-in person of the company that owns it, through a link that expires after a few minutes.
Backups: Backblaze B2, EU Central region, in a separate bucket with its own access key.
Email: sent through Resend from its Ireland region (eu-west-1).
DNS: Cloudflare, for DNS only. Traffic goes straight to the server and does not pass through Cloudflare.

The full list of providers is on the Sub-processors page.

2. Each company is separate

Every company has its own web address (yourcompany.fsmcore.com), and the address decides which company a request belongs to.
Every business record carries the id of its company, and every list, search, document, file, export and API answer is limited to that company.
A signed-in person can open only the companies they are a member of. Roles and permissions are set per company.
This is checked by automated tests that run before every release. On the date above, 19 tests in 16 test files try to reach one company's data from another company (by web address, by record id, through the API, through the AI assistant, through an export and through company deletion) and require a refusal. Examples: SecurityAuditTest, ApiV1Test, AiActsAsUserTest, CompanyExportTest, IssuedDocumentHistoryTest.

3. Encryption

In transit: every page is served over HTTPS. Plain HTTP is redirected to HTTPS, and browsers are told to use HTTPS only for a year, subdomains included (HSTS).
Passwords are stored only as bcrypt hashes. Nobody, including us, can read a password.
Two-factor secrets, recovery codes and a company's AI key are encrypted in the database. An AI key is never shown again after it is saved: the settings page shows only its last four characters.
Files and backups are encrypted at rest by Backblaze (server-side encryption on both buckets). Each database backup is also an AES-256 encrypted archive with its own password.
Sign-in cookies are sent over HTTPS only and cannot be read by scripts in the page.

4. Sign-in

Two-factor sign-in is required for owners and admins of a company in the office and accountant areas. An owner or admin without it is sent to set it up before anything else opens. It is optional for everyone else.
Two methods: an authenticator app (with recovery codes) or a code by email.
Sign-in attempts are limited: five tries a minute from one address, then a wait.
Failed sign-ins are logged with the time, the IP address and the email typed (never the password). After ten failures on one account in 15 minutes, the company's owners and admins get a notice.
A person who leaves is archived by an owner or admin and can no longer sign in.

5. Backups and restore

Database: a full backup every night at 01:30 UTC, stored with a different provider (Backblaze) from the server (Hetzner). A check runs after it each night and alerts us if the newest backup is missing or too old.
Files: every new or changed file is copied to the backup bucket every night at 02:15 UTC.
How long backups are kept: every backup for 7 days, then one a day up to 16 days, then one a week for 8 weeks, then one a month for 4 months. That is about 7 months at most; after that a backup is gone.
Restore: the whole database can be restored from any backup that is kept. One company can also be restored on its own, without touching any other company. A restore of one company never rolls back or removes an issued invoice, estimate or crew invoice.
Last restore test of the whole database: 24 September 2026. That night's encrypted backup was restored into a separate database and every table had the same number of rows as the live database.

6. Audit trail

An issued invoice, estimate or crew invoice cannot be deleted. It can only be voided, and it keeps its number. This is enforced in the application and again by database triggers, so even a direct database command is refused. The one exception is the deletion of a whole company's data after its subscription has ended (section 7).
A closed document cannot be changed: a void invoice, an accepted, declined, expired or void estimate, and a paid or void crew invoice keep their lines as they are.
A change to an issued document that is still open is recorded. The person is asked to confirm first, and the document's History shows who changed what and when, with the old and new total. History entries cannot be edited or deleted in FSMCore.
Changes to clients, sites, jobs, time, payments, prices, settings and other business records are logged with the person, the time and the old and new values.
Changes made through the AI assistant are marked as such, with the person who approved them.

7. Your data is yours

Export: an owner or admin can download all company data at any time, also during the trial, as one ZIP: every record as CSV and JSON, every file, and every issued document as PDF.
When a trial or subscription ends, the company is locked. Its owners and admins can still export everything from the lock page, or delete it at once. Otherwise all its data is deleted 30 days after the lock. Copies in backups expire on the schedule in section 5.
GDPR roles: for the data a company puts into FSMCore, the company is the controller and FSMCore is the processor. See the Data Processing Agreement, the Privacy Notice and the Sub-processors list.

8. The AI assistant

Each company uses its own AI account. A company picks its provider and pastes its own key. FSMCore has no AI key of its own, so no company data goes to an AI provider unless that company set one up. A company can switch the assistant off.
FSMCore does not use customer data to train AI models.
Nothing is saved until a person approves it. Every change the assistant proposes is shown as a card with the old and new values, and is written only after the signed-in person presses Approve.
The assistant acts as the signed-in person. It can do only what that person may do in FSMCore, inside that person's company, under the same rules.
What it can do, with approval: create, change, archive and delete ordinary records (clients, sites, jobs, price list items and similar); write draft estimates and invoices; issue, send and void them; record a payment; approve time and crew invoices; add and manage members.
What it cannot do: delete an issued document, delete stored files or chats, remove a recorded payment, change its own settings or key, switch company features, reset two-factor sign-in, export or restore data, or reach another company.
Files, pasted emails and web pages given to the assistant are treated as material to read, not as instructions.

9. Payments

Payments are not open yet. When they open, Paddle.com Market Ltd will take them as Merchant of Record: card details are typed into Paddle's checkout and go to Paddle only. FSMCore never receives or stores card numbers.

10. Reporting a security issue

Email support@fsmcore.com. Please include what you found and how to repeat it. Our contact details for security researchers are also at /.well-known/security.txt.