Access control
Who can sign in, what each person can open, and how the product checks it. This is our policy, and each part of it is something the product does.
Roles, checked on our servers
Every request a person makes is checked on our servers against the account it belongs to and the role of the person making it. A system that is closed to a role is refused by the server, not only left out of the menu.
A seat is a member, a viewer or a manager. A member works in the account. A viewer reads and changes nothing. A manager also invites and removes seats. An account can define up to forty roles of its own, each opening the systems it names, with four permissions: change records, take files out, see pay, and invite people. The owner can close more to a single seat than its role does, and the owner of an account is never restricted.
Pay rates and pay runs are closed to a seat until the owner opens them for that seat.
Signing in
- Two-step sign-in, on every plan. After the password, a six-digit code from an authenticator app, which changes every thirty seconds and works once. The key it is set up with is shown once and stored sealed. Ten recovery codes are shown once and kept only as hashes, each good once.
- Trusted browsers. A browser can be trusted for thirty days so the code is not asked for each time. Changing the password ends every trust at once.
- Failed sign-ins. Five that do not match in fifteen minutes pause that name from that address, for longer each time, up to a day. The pause says the same whether or not the name has an account.
- The lock screen. After the minutes each person chooses without input (five, fifteen, thirty or sixty), the session is locked on our servers and asks for the password or a code before anything else is shown or done.
- Sessions. Each person sees every place they are signed in and can end one or every other. Changing the password signs out every other session.
The owner of an account can require two-step sign-in for everybody on it, set the longest a session may stay unlocked, see who has two-step on, and end a person's sessions.
What is written down
Every sign-in, failed sign-in, change to two-step, use of a recovery code, lock and ended session is a line in the account's history, and each person can read their own last fifty sign-ins and security changes. No code, key or password is ever written to a log.
API keys
API keys on the Capture and Enterprise plans are shown once, stored as a hash, and can be replaced from the account page, which revokes the old one.
The rest of the Trust Portal
- Trust PortalWhat is true today, in one list.
- How data is keptWhere documents sit, who can read them, and what goes to an AI model.
- Backups and their encryptionWhat the nightly copy holds and how it is locked.
- Incident responseWhat we do when member data may have been reached.
- Vulnerability disclosureHow to report a weakness, and what is in scope.
- Outside servicesThe kinds of service that touch member data.
- Security questionnaireAsk for it, under a non-disclosure agreement.
- Security and privacyThe whole of what is stored, in one page.