Skip to content

Security and sign-in

What follows is how the product works today, said plainly. Where something is not built, it says so.

What is left when the passwords are gone

One link, and it lives fifteen minutes. Nothing to reuse, nothing to reset, nothing to phish for.

Signing in

One door, and it is on the record.

  1. 01

    Type your work address

    d.reyes@mercy.org

  2. 02

    Open the link in your email

    Valid fifteen minutes, works once

  3. 03

    You are in

    Your tasks, nothing else

Emailed links, not passwords

Staff type their work address and receive a one-time link that lives fifteen minutes. There is nothing to reuse across sites, nothing to reset, nothing to phish for. Requests are rate-limited and answer the same way whether or not an address is known.

The link is checked against the record

A request answers the same way whether or not the address is known, so the page never says who works for you. The link is granted only to a person who is an active member of the organization at the moment they open it.

Second factor for the people with reach

Anyone who can change who gets in or how, your System Admin and our own administrators, must use Google Authenticator and enters a code at every sign-in.

Leaving closes the door

Removing somebody ends their access and their outstanding reading. Their next request for a link goes unanswered, and the record of what they did read stays.

0 min

is how long a sign-in link lives, and it works once

0

passwords held for your staff, so none can leak

0 roles

decide what a person may do, and the server checks every action against them

Access and the record

Every action checked on the server, and written down.

Roles decide what a person may do; the server decides whether they did; the audit log keeps the answer for whoever asks: an auditor, a surveyor, or you.

Audit log · today
  1. 09:14:02a.okaforpolicy.publish · POL-2026-014 v3.2
  2. 09:14:03systemacknowledgement.assign · 214 staff
  3. 09:41:37d.reyesacknowledgement.record · POL-2026-014 v3.2
  4. 10:02:55m.alvarezmember.roles · j.park → Approver
  5. 10:03:10m.alvarezmember.invite.batch_sent · 12 staff
  6. 11:27:48j.parkapproval.decision · POL-2026-031 · approved
  7. 13:00:00systemreview.remind · 4 owners · 30 days

Roles, not permissions to configure

Viewer, Author, Reviewer, Approver, Administrator, and the organization’s System Admin. A person may hold several. Every action is checked against the record on the server, never against what the browser claims.

Each organization on its own

Each organization’s data is its own. A person who works for two organizations chooses which one to open. Nobody at one can read another’s.

Audit log

Changes to policies, people and settings are written with who, when and what changed, retained, and exportable for a survey.

Encryption

Data is encrypted in transit and at rest on Google Cloud. Identity-provider secrets are held in a secrets manager, never shown again after entry.

Not built yet, said plainly

Signing in with a Microsoft work account: the code is written but we have not yet run it against a customer’s real directory, so we do not offer it and no organization is using it. Everyone signs in with the emailed link. We do not currently hold a third-party security certification; ask us and we will tell you exactly where things stand.