Security and privacy in Auditee — practices, not certificates

Identity and access

Auditee never stores a password.

Authentication is OAuth2 and OpenID Connect against an identity service that Effiware runs and that keeps only a salted hash. Any standard identity provider works over OpenID Connect or SAML, and platinum customers can configure their own.

Permissions: Five distinct permission shapes, derived per request from the token, plus a per-resource check on every detail page and every mutation.
Sessions: Held in memory only and never written to disk: restarting the session store signs everyone out. The session identifier is rotated at login and tokens are refreshed server-side.
No public sign-up: There is no registration form on the sign-in service. People join by invitation; new organizations sign up through a separate service.
Invitations: Reusable for at most 72 hours.
One-time sign-in links: An administrator can send a person a link that signs them in without a password. It works exactly once: the moment it is used it is invalidated, so a used link cannot be replayed, and an unused one expires after 30 minutes.
Onboarding: One email, one click: the invitation sets the password, captures the name, joins the organization and lands the person in the right place.
Auditees need no email address: A supported shape, not a gap — it is what makes shop-floor and field workforces possible. Auditors and reviewers do need one, because they receive alerts.

Data

Scoped to the organization, versioned on every change.

Your audit data is stored and processed in the EU. Every row is scoped to its organization, and every stored file key is prefixed with it — so removing an organization is a single prefix operation rather than a hunt.

History that survives erasure

Versioned history tables record organizations, teams, audits, answers, tasks, assignments and evidence sets, written inside the same transaction as the change. Those rows are designed to stay interpretable after a user is erased, which is what lets an erasure request coexist with keeping an audit trail.
Files behind a permission check

Served as presigned links valid for 24 hours, minted only after the check passes. Uploads are validated by sniffing the file itself, never by trusting the browser, and SVG is refused everywhere.
Logs that do not identify you

Request logs record the method, path, status, size and duration. No IP address and no user identifier is written to them.
User content cannot inject markup

Markdown written by users goes through CommonMark in safe mode, raw HTML is dropped, then an explicit allowlist applies. Only https links with a real host and mailto: survive, and every external link carries noopener noreferrer.

Operations

Running several copies never doubles anything.

Multi-instance from day one

Background work is serialised with database advisory locks, so running several application instances never doubles an email or a scheduled round.

A transactional outbox

All outbound email goes through an outbox with retry and deduplication. A reminder is never sent twice, and an outage never produces a late blast.

Observable

OpenTelemetry tracing and Prometheus metrics throughout, so a support question has an answer rather than a guess.

The honest part

What we will not claim.

Things vendors in this category often assert, and we do not.

Three things we do not claim

No certificate yet. Certification of our information-security practices is in progress. Until it completes, we describe practices rather than hold badges.
Not end-to-end encrypted. Data is encrypted in transit and at rest by the hosting platform. The service has to read your data to score, report and notify, so it is not end-to-end.
On the shared plans, separation is logical, not physical. On silver and gold the hosted service is one identity store and one database, with every row scoped to its organization. Platinum and uranium get their own database and identity store.

Where a separate deployment fits The anonymity limits, in the same spirit

Accessibility

What is true today.

In the application

Every page declares its language, matching the interface language in use. Icon-only controls carry labels, and those labels are translated. Sortable tables announce their sort state and popovers announce whether they are expanded.

Charts ship an invisible data table alongside the visual, so a screen reader gets the numbers. Status is never carried by colour alone — pass and fail pair an icon with a word. Unavailable actions are shown greyed with an explanation rather than hidden.

Not yet

There is no accessibility statement and no conformance target yet.

If any of that blocks you, tell us — knowing which parts matter to a real deployment is what moves them up the list.

Send us the security questionnaire.

We would rather answer it precisely than have you guess from a marketing page. Vulnerability reports go to the address in our security.txt.

Talk to us Terms