Skip to content
Authreads

Trust

Compliance, stated
as it actually stands.

A narrower, honest claim beats a broad one we can't back. Here's the posture, the data handling, and the incident process, in plain language.

See the roadmap
Stack of bound ledgers and folders on a desk under a reading lamp

Compliance posture, stated as it stands today

We'd rather publish an honest, narrower claim than a broad one we can't back. Authreads is built with HIPAA-aware design principles (tenant isolation, data minimisation, and audit trails, all enforced at the platform layer rather than left to each product to implement), but we do not currently hold a formal certification or third-party audit attestation, and we don't claim one. If a specific certification (SOC 2, ISO 27001, or otherwise) matters to your evaluation, tell us on the contact formand we'll tell you plainly where we stand.

How to read this page

Nothing on this page is a substitute for your own security review or a signed data processing agreement. Where we say something is planned rather than available, treat that as the current, honest answer: see the roadmap.

Data handling

How tenant data is handled

Tenant isolation

Enforced at the data layer, not only in application code: a request scoped to one tenant structurally cannot read or write another tenant's data.

Data minimisation

Only the fields a flow needs are collected and stored; free-text fields, like a contact-form message, are never logged into operational telemetry.

Audit trails

Security-relevant events (sign-in, recovery, session revocation, administrative changes) are recorded and attributable, with access restricted to what running the platform requires.

Retention

Retention windows are bounded by policy and enforced by an automated process, not run indefinitely by default. The one figure we publish outright, contact-form submissions, is on the privacy page.

Credential storage

Passwords are never stored in recoverable form. See the full breakdown on the security page.

Sub-processors

Any provider that could process personal data on Authreads' behalf (for example, outbound transactional email) is disclosed by category and purpose on the sub-processors page, which is a draft pending professional review. We name what a provider is used for; we don't name underlying infrastructure or vendor products in marketing copy, consistent with keeping implementation detail out of anything public-facing.

Small team gathered around a table reviewing information on a wall display

How we handle a security incident

If a security incident affects tenant data, the affected tenant is the first party notified. They own the relationship with their own end users and are best placed to decide what their users need to hear and when. We aim to notify without unreasonable delay once an incident is confirmed and its scope understood, and to give a tenant enough detail to make their own notification decisions.

To report a suspected vulnerability or incident yourself, see the security page: that's the single reporting path, whether you're a security researcher, a tenant, or an end user.

FAQ has direct answers to the questions security and procurement reviewers ask most. Roadmaptells you what's available today, in progress, and planned, without dates that would only go stale.

Need something this page doesn't cover?

Compliance questionnaires, DPAs, and specific control questions: ask directly.