Security and compliance

Sessions, the security log, organisation policy, and what the system does with your data.

Settings → Security.

Where I am signed in lists every live session with its browser, address and last use. Anything you do not recognise can be signed out on the spot, and "Sign out everywhere else" ends all of them but the one you are using.

Changing your password signs out everywhere else automatically. A password you changed because it was stolen is no use at all if whoever took it is still holding a live session.

Lockouts. Ten wrong passwords for one address within fifteen minutes locks that address for fifteen minutes. It is deliberately temporary: an attacker who cannot guess is stopped either way, and a permanent lock would hand them a way to lock you out of your own books. An owner can lift a lockout from Settings → Security.

Password rules. At least 12 characters. Length does the real work, so a long passphrase with no symbols is accepted while a short gnarly one is not. Common passwords, keyboard runs, your own name and your own email address are refused — those are the first things an attacker tries.

Organisation policy (owners only): require two-factor for everybody, and set how long a sign-in lasts. Requiring two-factor asks people to enrol at their next sign-in rather than locking them out, and you cannot switch it on until your own account has it — otherwise you would lock yourself out first.

The security log is separate from the audit log on purpose. Sign-ins, lockouts and permission refusals go here; invoice and ledger changes go to the audit log. Mixing them buries the signal that matters during an incident under a month of bookkeeping.

The compliance tab lists what the system actually does — encryption at rest, password hashing, session hashing, tenancy checks, browser headers — and names the file that implements each one, so it can be checked rather than believed.