Security

Someone else's money deserves proof, not adjectives.

SutorBooks is a book of record. Most software answers a security question with a list of nouns — encryption, backups, two-factor — and everyone has those. So here is what is specifically true today, and, further down, a plain list of what we do not claim.

The three worth leading with

These are the ones competitors struggle to match, and all three are in production now.

Three independent walls

Not one safeguard that has to be right every time. Three, at different layers, so a mistake in any one is caught by another.

Re-proven on every code change

The build refuses code that would weaken customer data isolation. It is a gate, not a review somebody can skip — and not an audit once a year.

Locking an account is instant

Most systems hand out a session token and honour it until it expires — suspend someone and they keep working for another hour. Ours re-checks on every request.

Keeping your books separate from everybody else's

The thing customers actually worry about: you share a system with other businesses, and nobody else may ever see your books.

Layer 1

The database refuses

Records are hard-linked to the business that owns them. A line item cannot point at an invoice belonging to a different business, because the database rejects the write — not the application.

Layer 2

Every reference is verified

When a request names a customer, vendor, product or account, the system confirms that record belongs to your business first. A reference to someone else's returns "not found" — deliberately identical to a record that does not exist, so the response cannot be used to probe what does.

Layer 3

Every query is monitored

Every query the application runs is examined before it reaches the database, and any query touching customer data without naming which customer is flagged. This layer reports rather than blocks while we collect a month of evidence across a month-end close. The two layers above do refuse.

Signing in

Passwords are hashed with bcrypt at cost 12 — slow by design, so a stolen database is not a stolen password list. Plaintext is never stored.
Two-factor authentication with any authenticator app, plus ten single-use backup codes, stored hashed and shown once.
Passkeys, so there is a way in that isn't a password at all.
Refresh tokens rotate, and replay is detected. If an old token is reused — the signature of a stolen one — the entire login family is revoked and every session in it dies.
Session cookies are HttpOnly, Secure and SameSite=Strict — unreadable by JavaScript, so a script injection cannot steal your session, and unsendable cross-site.
Sign-in failures don't leak. A wrong password, a locked account and a missing authenticator are indistinguishable from outside, so the form cannot be used to find out who has an account.
Every attempt is recorded with its outcome, IP and device — and you can see your own active sessions and end them.

The integrity of the books

For a book of record, "nobody can quietly change a number" is a security feature. Accountants care about this more than they care about headers.

Closed periods are locked. Once a period is closed, entries in it cannot be altered.
Posted entries are immutable. Corrections are made by posting a reversing entry, so history is never rewritten.
Debits must equal credits — enforced at the moment of posting, not checked afterwards.
A retried or double-clicked request returns the original result rather than posting twice.
Simultaneous edits cannot silently overwrite each other. The second save is refused rather than quietly discarding the first person's work.
The audit trail keeps both values — what a figure was as well as what it became, and who changed it. When our staff access an account to help, that records who, when, which business and why, in a separate trail from your own activity.

Your data, and getting it back

Stored third-party credentials use AES-256-GCM — authenticated encryption, so tampering is detected rather than merely undecryptable.
All traffic is HTTPS, with HSTS for a year including subdomains, so browsers refuse to downgrade.
The application refuses to start with insecure configuration. A missing or default signing key stops the service in production rather than running weakened — a misconfigured deploy fails loudly instead of quietly.
Automated daily backups, with a restore procedure that has been tested rather than assumed.
Deployments keep a rollback and revert automatically if a new version fails its health check.
You can export everything, whenever you want. A full export of your company data — so choosing us is not a decision you are stuck with.

What we don't claim

Being straight about limits is the point. An accountant is trained to distrust a vendor with no caveats, and a page that overstates one thing puts every other sentence on it in doubt.

No SOC 2 report. Not started. If you require one, that is a real gap — tell us and we'll talk about timing.
No third-party penetration test has been carried out. We won't imply otherwise.
No certifications of any kind at this time, so you will not find ISO or PCI badges here either.
Backups are not yet stored off-site. Daily backups with a tested restore, yes; geographically separate copies, not yet.
The third isolation layer reports; it does not block. Two layers refuse. The third is collecting evidence.
Two-factor is optional for customers. It is required for our own operator accounts, which is a different statement and we won't blur them.
Ending one session is not instantaneous. Signing out a device stops it renewing, but the token it already holds lives until it expires. Locking the account, suspending it or changing the password are immediate.
We publish no uptime figure we have not measured.