# Alderworks hosted services: security overview for IT reviewers

This covers the two hosted products Alderworks LLC runs on one platform: **Alderworks EMS** (equipment, calibration and maintenance records, at app.alderworks.dev) and the **hosted Alderworks Quality Suite** (SpecRun, ShiftHandover, RetainLog, PullPlan and CoverPlan in the browser with a shared team folder). The downloadable apps, which run on your own computers and send nothing to us, are covered in [hosted-vs-offline.md](hosted-vs-offline.md).

Every statement here is written from the code and configuration and was checked against it. Where something depends on a setting in a provider's dashboard or on a paid plan, it says so. Detailed answers to standard questionnaires are in [questionnaire-answers.md](questionnaire-answers.md). Questions: support@alderworks.dev.

## What we do not claim

Alderworks holds no SOC 2 report, ISO 27001 certificate or other third-party attestation, and has not had an external penetration test. The infrastructure we build on does publish its own: Supabase, Vercel and Stripe each have SOC 2 Type II reports, available from them under NDA, and Stripe is PCI DSS Level 1.

## Architecture in one paragraph

The application is a Next.js site hosted on Vercel. Data lives in one Supabase project: a PostgreSQL database, Supabase Auth for accounts, and Supabase Storage for files. Stripe takes payments on its own pages, and Resend delivers account and reminder email. Those four are the only companies that handle customer data. Vercel serves requests, and the application stores no customer records there.

## Access and identity

- **Accounts.** Everyone signs in with their own account: an email address and a password. The sign-up and password pages require at least 8 characters; the minimum on the sign-in service itself is a project setting. Supabase Auth stores the password as a one-way hash. A workspace is created only for a confirmed email address. People join an existing workspace only when one of its admins adds them.
- **Two-step sign-in.** Anyone can turn on two-step sign-in with an authenticator app, such as Microsoft Authenticator or Google Authenticator. A workspace admin can **require it for everyone** in the workspace. The requirement is enforced by the database, not just the screens: a session that has not completed the second step can read nothing in that workspace. Members who have not set it up are walked through setup at their next sign-in. An admin can reset it for someone who has lost their phone.
- **Single sign-on.** SAML or OIDC single sign-on (Microsoft Entra ID, Google Workspace) is not available yet. It is on the roadmap and needs a platform upgrade. Ask us if it is a requirement.
- **Roles.** The EMS has four roles: administrator, manager, technician and viewer. The hosted suite has admins and staff. Roles are checked on the server and in the database, not just in the interface.
- **Sessions.** A sign-in token lasts one hour (the platform default) and is renewed while the person is active. Renewal tokens are rotated on use. An admin can set the workspace to **sign members out after 15 minutes to 8 hours idle**, with a warning first. Anyone can **sign out of every device** at once.
- **Offboarding.** Removing a person from a workspace ends their access to it immediately, because the database checks membership on every request. In the EMS, deactivating someone who belongs to no other workspace also locks their account. Account provisioning through SCIM is not supported.
- **Abuse limits.** Supabase Auth limits sign-in and sign-up attempts per IP address. The application adds its own limits on public and account routes, such as starting a purchase, public certificate downloads, invitations and workspace creation.

## Separation between customers

- Every record belongs to one workspace. Row-level security is on for **every** table, and the policies check workspace membership, role and two-step sign-in on each request.
- Files are stored under their workspace, and the storage rules check that on every request. The hosted suite's team-folder bucket has no public or user access at all. The server moves bytes only after the database has approved the specific read or write. Download links last **60 seconds**.
- The key that bypasses these rules exists only on the server. We checked that it is not in any file sent to the browser.
- Isolation is tested: 500 database checks in the repository cover cross-workspace access, roles, locked evidence, the team folder, rate limits and sign-in rules. They run against a test database before database changes ship; the application's unit tests run on every change.

## Data protection

- **In transit.** HTTPS only, with HTTP Strict Transport Security for two years including subdomains. The .dev domain is also on browsers' built-in HTTPS-only list.
- **At rest.** Supabase encrypts databases, backups and stored files at rest (AES-256).
- **Location.** Data is stored in the region of our Supabase project and served through Vercel. Ask us for the region in writing. Custom data residency is not offered.
- **Backups.** The database is backed up daily by Supabase. Seven days of backups were available when we last checked. A full restore to a separate project was tested on 2026-08-24, including a certificate PDF from storage. Point-in-time recovery is a paid add-on that is not currently enabled.
- **Leaving.** Records stay readable and exportable after a trial ends or a subscription is cancelled. What stops is adding new work. The EMS exports CSV and PDF. The suite's team folder holds your own workbooks and documents in their standard formats (xlsx, html, pdf, csv and the like). A one-click download of the whole folder is not built yet; until it is, ask us and we export it for you. A suspended workspace is kept for 30 days, then permanently deleted rather than archived.

## Audit trail

- The **activity log** records:
  - sign-ins and account events for the workspace's members, as Supabase Auth logged them, with the IP address where it was recorded;
  - people and role changes;
  - changes to sign-in settings;
  - in the EMS, the work itself;
  - in the hosted suite, every file saved to or removed from the team folder, with who, when, the file and its version.
- Admins and managers can filter the log and **export it as CSV**.
- Nobody in a workspace can edit or delete a log entry, whatever their role. Entries written from a signed-in session are stamped by the database with that person and the database's own time.
- Calibration approval history and issued certificates cannot be rewritten.

## Application security

- The browser security headers are:
  - an enforced Content Security Policy (no scripts from other domains, no framing by other sites, no plugins);
  - HSTS;
  - X-Frame-Options;
  - X-Content-Type-Options;
  - Referrer-Policy;
  - Permissions-Policy;
  - Cross-Origin-Opener-Policy.
- **Cross-site request forgery.** The API authenticates with a bearer token sent by the application, not with cookies, so another site cannot make requests in a signed-in user's name.
- **Inputs and errors.** Inputs are validated on the server. Error answers describe the problem without internal details.
- **Dependencies.** The dependency audit is clean, and it is re-run automatically.

## Operations

- **Reporting a vulnerability.** Write to support@alderworks.dev. The address is published at /.well-known/security.txt, and the Security page says how reports are handled.
- **Breach notification.** If a breach affects your data, we will tell you what happened, what it affected and what we are doing about it (privacy policy, section 8). Contractual notification terms can be agreed in a data processing agreement.
- **Data processing agreement.** Available on request.
- **Availability.** No contractual uptime commitment is offered today. Status and incidents are handled by direct notice to affected customers.