Your evidence is the most sensitive thing we hold.

AuditSquire is multi-tenant: many organizations share one database. The property that matters most is that one of them can never read another's evidence, and that property is not left to application code.

• Every table has row level security enabled, and every policy that grants a signed-in user access is keyed on organization membership. The only tables with no such policy are ones no signed-in user can read at all.
• The app issues every customer-facing query as the signed-in user. It does not hold a bypass key for those paths; a mistake in a page handler is contained by the database, not by the developer having been careful.
• Membership checks run through pinned, definer-security helper functions so that no policy can be bypassed by recursion, and no function is callable anonymously.
• Views used for readiness math run with the caller's permissions, so a dashboard query across 584 requirements is still scoped to your organization.
• Uploaded evidence is stored under a path that begins with your organization's id, and the storage policy keys access off that path segment. The bucket is private; there are no public URLs.

One exception exists and is worth naming: the code that records subscription changes reported by our payment provider uses a server-only administrative client, because those events arrive with no user session. It touches billing state only and never reads or writes a compliance record.

• In transit. TLS on every request, with HTTP Strict Transport Security set for two years including subdomains, so a browser will not downgrade even if asked to.
• At rest. The database and the evidence file store are encrypted on disk by the hosting provider, in AWS us-east-2.
• Credentials you give us. Cloud and identity-provider credentials for automated evidence collection are encrypted with AES-256-GCM before they reach the database. The key lives only in the application server's environment, so a database leak alone yields ciphertext and an environment leak alone yields nothing to decrypt.
• Collectors are read-only by design: AWS wants a SecurityAudit-scoped credential, Okta a read-only token, GitHub a scope limited to the repositories you name, Microsoft 365 an app registration holding only read permissions, Azure the Reader role, CrowdStrike an API client with read scopes only, and Jira a token for a browse-only account. We cannot change anything in your environment because we never ask for the right to.

Most damage to a web application starts with a script that should not be running. The session and the response headers are configured to make that script as useless as possible.

• Session cookies are HttpOnly, Secure and SameSite. Nothing in the browser can read the session token, because nothing in the browser needs to: every authenticated call runs server-side.
• A Content Security Policy restricts scripts, styles, images and connections to this origin and the database host. The app cannot be embedded in another site (frame-ancestors 'none'), which closes clickjacking against the dashboard.
• Content type sniffing is disabled, referrers are trimmed to origin on cross-site navigation, and camera, microphone and location are declared unused.
• New passwords are checked against known breach corpora at sign-up and reset, and rejected if they appear in one.
• Two-factor authentication with an authenticator app is available to every account, and an owner can require it for everyone in the organization. A session that has not presented the second factor cannot open the product or call any action.
• SAML 2.0 single sign-on connects your identity provider (Entra ID, Okta, Google Workspace and others) so your people sign in under your own authentication policy, and join your organization automatically by email domain.
• Policy text authored in your workspace is escaped before rendering, with no raw HTML passthrough, so a document shown to your whole workforce has no stored script path.

Roles are enforced by database policy, not by hiding buttons. A member cannot open the controls page by typing its address, and an auditor cannot change a status by crafting a request.

The auditor role exists so an external assessor can read the evidence where it lives rather than receiving screenshots. It is read-only everywhere and can do exactly one thing beyond reading: raise an evidence request against a requirement, which the owning person answers by attaching what is already on file. Each request records who asked, who answered, what was attached and when.

The activity log is written to on every approval, status change and upload, with the actor and a timestamp, and assessors are shown it directly. The readiness report is printable and written to be read by an assessor, so both sides start from the same numbers.

Read how one company ran fieldwork this way

• Export the readiness report to print or PDF, or the underlying data as JSON, at any time and on any plan.
• If you stop paying, the workspace becomes read-only and nothing is deleted. Compliance records outlive subscriptions: a company that leaves in March and is audited in June still needs its evidence, and will find it here.
• Ask and we delete the organization. Every record is removed and every uploaded file is purged from storage, and it is confirmed to you in writing.
• Uploaded evidence belongs to you. We do not train on it or use it for anything except showing it to the people you have given a role, and supporting you when you ask.

Scan explanations deserve a sentence more. When you upload a vulnerability scan, the parsed findings are sent to Anthropic's API to be rewritten in plain language. Hostnames and IP addresses are replaced with placeholders before the request leaves, and the model is never the source of a number: CVE identifiers, scores and counts come from the parser and are rendered directly. This step is optional and runs only when you upload a scan.

In August 2026 an external reviewer performed a black-box security assessment of the served application on an authenticated session: response headers, cookie flags, client-side exposure of the session, and the client bundle. It raised findings on session cookie flags and missing response headers. Both were remediated within the week, and the review's remaining recommendation, an audit of every row-level policy, was carried out at the same time.

In September 2026 we ran a full internal security assessment ourselves: every server action, every row-level policy and database function, every upload path and every outbound request, cross-checked against the live configuration. It found four issues we rated High, all within the tenant boundary rather than across it, and fixed them the same day along with the rest of the list. It is a white-box review by the people who built the system, so it is not a penetration test and we do not present it as one; it is the starting document we hand to the independent tester.

The database platform's own security advisor is run against production. As of the date at the top of this page it reports no table without row level security and no policy open to anonymous users. Its remaining notes describe the tenancy and workflow functions being callable by signed-in users, which is how they are designed to work, and one billing-events table that no signed-in user can read.

A trust page that lists only strengths is a marketing page. These are the gaps a careful buyer will find, listed so you do not have to.

If you find a security problem in AuditSquire, email hello@auditsquire.com with “Security” in the subject. It reaches Chris Foster, the founder, not a queue. You will get a human reply, a fix or a timeline for one, and credit if you want it. We ask that you avoid accessing another organization's data if you find a way to; report it and we will reproduce it in a test tenant.