Security detail

The SkySign application runs on Vercel, which serves the web application and runs its server-side functions and a daily scheduled job for reminders. The database, authentication service and file storage are provided by Supabase, a managed PostgreSQL platform running on Amazon Web Services.

• Primary data region: [Supabase project region — to be confirmed]. Customers with a data-residency requirement should raise it before onboarding.
• Preview and production deployments are separate environments with their own configuration and credentials.
• Uploaded documents are stored in a private storage bucket; they are never served from a public URL.

• In transit: all connections between browsers, the application and the database use TLS (HTTPS). Plain HTTP is not served.
• At rest: database storage and file storage are encrypted at rest by the hosting provider (AES-256).
• Document access: files are read through signed URLs that expire after one hour, issued only to signed-in members of the organisation that owns the file.
• Passwords: never stored or seen by SkySign; Supabase Auth stores a salted bcrypt hash.

Every record in SkySign carries the identifier of the organisation it belongs to, and the database enforces access at row level. SkySign uses database-level access controls and Row Level Security to ensure users can only access data belonging to their authorised organisation, whichever screen or API they use.

• Administrators see only their own organisation’s documents, people and records.
• Employees see only active documents that have been assigned to them, and their own acknowledgements.
• Role changes are guarded in the database as well as the application: no one can change their own role or grant a role at or above their own.
• Each customer organisation is a separate tenant. SkySign’s platform-operator role can provision organisations and view across them for support; that access is not currently written to the audit log.

• Sign-in methods: email and password, or sign-in with a Google account.
• Password policy: minimum 12 characters. No composition rules that make passwords harder to remember without making them stronger.
• Password storage: handled by Supabase Auth (bcrypt). Supabase Auth also rate-limits authentication endpoints.
• Sessions: secure, HTTP-only cookies, refreshed server-side on each request; disabled accounts are signed out on their next request.
• Roles: Employer (organisation administrator), Superuser (document and staff administrator) and Employee, with permissions enforced in the application and in database policies. A separate operator role is used by SkySign to provision customer organisations.
• Multi-factor authentication: not yet available; see the roadmap below. Google sign-in uses whatever protection the person’s Google account has, such as two-step verification, but an organisation cannot yet require Google sign-in in place of a password.

• The database is backed up automatically by Supabase. Backup frequency and point-in-time recovery depend on the Supabase plan in force; ask us for the current arrangement before relying on specific recovery objectives.
• The application tier is stateless and served from Vercel’s global network, so individual function failures do not affect stored data.
• SkySign does not publish RPO/RTO figures or an uptime SLA. Provider status pages are available for Vercel and Supabase.

Two kinds of record are kept:

• Acknowledgement records, one per person per document version: the exact statement accepted, the typed name, timestamp, document version, SHA-256 hash of the file, authentication method, browser details and IP address, and the result of any knowledge check. These records cannot be edited once made.
• Audit log entries for acknowledgements, manual reminders, document deletions, administrator password resets and organisation onboarding, each with the acting user and time. Scheduled reminders, document edits, user changes and exports are not yet logged, and the audit log cannot yet be exported.

Administrators can export acknowledgement records as CSV at any time, and download a certificate for any individual acknowledgement.

• While your account is active, documents and acknowledgement records are retained so that the audit history remains complete.
• Deactivating a document hides it from staff and keeps every record. Deleting a document removes the file and its acknowledgements, and is written to the audit log; we recommend deactivation where history must be kept.
• Leavers can be disabled, which keeps their acknowledgement history, or deleted, which removes it.
• Deleting the organisation (owner or employer only, with password confirmation) cancels billing and removes the organisation’s documents, records and users immediately. Copies held in provider backups expire according to the provider’s retention.
• Export of acknowledgement records is available at any time as CSV, so you can keep your own copy before any deletion.

SkySign offers two optional, administrator-triggered AI features: a plain-English summary of an uploaded PDF, and a writing assistant inside the document editor. Both are provided through Anthropic’s API.

• What is sent: the text extracted from the PDF being summarised (truncated for very long documents), or the text the administrator selects in the editor. Nothing is sent unless an administrator clicks the feature.
• What is never sent: employee names, email addresses, acknowledgement records, audit logs or account data.
• Training: customer documents and acknowledgement records are not supplied to generative AI models for training. Under Anthropic’s commercial API terms, content submitted through the API is not used to train Anthropic’s models.
• Opting out: nothing is sent unless an administrator triggers one of these features, so an organisation that does not want document text to reach an AI provider can simply not use them. An organisation-level switch to disable them is on the roadmap below.

SkySign uses a small number of carefully selected infrastructure providers to operate the service. Customer documents are not sold or used for advertising, and each provider’s access is restricted to what is required to provide the service. The full list, with what each provider processes, is kept on a dedicated page.

View the subprocessor list

SkySign maintains procedures for investigating and responding to security incidents. If we become aware of a breach affecting your organisation’s data we will investigate, contain it, and notify your designated contact without undue delay with what we know, what we have done and what we recommend.

• Report a vulnerability or suspected incident to security@useskysign.com. We acknowledge reports and keep reporters informed.
• Breach-notification timescales for processor obligations are set out in the Data Processing Agreement.

The flow below is the whole product, from your organisation’s people to the evidence an auditor asks for.

1. Your organisation

   HRIS sync on roadmap

   Departments, stations and people. Today: added by administrators or imported from a spreadsheet. Roadmap: synchronised from your HR system or directory.

2. SkySign users and groups

   Role-based accounts (Owner, Employer, Superuser, Employee) scoped to one organisation, with department and station membership.

3. Document distribution

   Policies, procedures, bulletins and messages are issued to groups or individuals with a due date, an acknowledgement statement and an optional knowledge check.

4. Employee notification

   Email notifications and scheduled reminders with a direct link. Nothing to install.

5. Authenticated acknowledgement

   The employee signs in, opens the document and accepts the statement. The exact wording, document version and file hash are captured with the record.

6. Acknowledgement evidence

   Records cannot be edited once made. Acknowledgements, manual reminders, document deletions and password resets are written to the audit log.

7. Compliance reporting

   Live completion status by document, department, station and person; CSV exports and per-record certificates for auditors.

The following are not available today. They are listed so that procurement and security teams can plan; none should be relied on until announced as live.

• Multi-factor authentication (authenticator app), with the option to require it for administrators.
• Single sign-on with Microsoft Entra ID and SAML 2.0 identity providers.
• Workday and other HRIS synchronisation: joiners created and assigned automatically; leavers disabled with history retained.
• SCIM provisioning.
• Organisation-level switch to disable AI features.

Discuss requirements with us