Hosting and data residency

SkyBridge is delivered as a managed cloud service. The application is served from a global edge network over HTTPS; application data is held in a managed PostgreSQL database in a single region, currently eu-west-2 (London).

Where a client requires data to remain in a specific jurisdiction, the database region is fixed at the start of the engagement and does not move without written agreement.

Sub-processors: Cloudflare (application hosting and edge delivery) and Supabase (managed PostgreSQL, authentication and object storage, hosted on AWS eu-west-2). Where a client enables email reminders, their chosen email provider is added. No other party processes client data.

Separation between clients

Each client operates as its own tenant. Company, division, learner, course and record data is scoped to the tenant, and no interface exposes another tenant’s data.

Access control

Access is enforced in the database itself, not only in the interface. Row level security is enabled across the production schema, and every table carries policies that decide which rows a given identity may read or write. A request that bypasses the user interface still cannot reach records it has no right to.

Roles

• Learner — sees only the learning assigned to them, and their own records.
• Administrator — manages divisions, learners, programs, courses and assignment within their company.
• Manager — reporting scoped to their own division only.
• Super administrator — branding, tenant settings and platform configuration.
• Verifier — an unauthenticated public page that confirms whether a specific certificate is genuine, and nothing else.

Server-side secrets

The privileged database key is held only in server-side function environment variables and is never sent to a browser. Browser code receives only the public anonymous key, which is subject to the same row level security policies as any other caller. Internal files — database migrations, import templates, server function source and setup documentation — are blocked from public access at the edge.

Audit logging

Administrative changes are written to an audit log readable only by super administrators, so a change to a learner record, a course assignment or a platform setting can be attributed after the fact.

Authentication

Administrators, managers and super administrators authenticate with email and password through a managed authentication service. Learners authenticate with a username and password issued by their administrator, through a server-side endpoint — useful for workforces where not everyone has a company email address.

Passwords must be at least 10 characters and use three of the four character classes, and cannot contain the account’s own username or email address. A password change requires the current password, not merely a live session. Sessions use an access token lifetime of 60 minutes with refresh-token rotation enabled and a 10-second reuse interval, so a stolen refresh token is detected and the session family revoked. Multi-factor authentication for administrative accounts is available on request — talk to us before rollout if it is a requirement.

Credential recovery has two routes. Where an account has an email address on file, a single-use link valid for one hour is sent. Where it does not — which is common for field workforces — the request is queued for a named administrator to action inside the portal. Neither route reveals whether an account exists, and requests are rate limited per account.

Data protection

SkyBridge holds personal data: names, contact details, job titles, division membership, assessment results and certificate records. Aero Digital Solutions acts as processor; the client remains controller of their own workforce data.

• In transit — all traffic is served over HTTPS with modern TLS.
• At rest — database storage and backups are encrypted by the managed database platform.
• Training content — manuals, video and imported courseware are held in private storage, not on a public URL. Every read is authorised against the requesting account and scoped to their tenant.
• Imported courseware — SCORM, cmi5, xAPI and AICC packages are third-party code and are served from a separate content origin, so a package cannot reach the signed-in application session. Content that reports results does so with a credential scoped to one learner, one activity and one attempt, and cannot write about anybody else.
• Retention — the life of the agreement plus seven years by default, which suits regulated training evidence; a shorter or longer period can be set per client.
• Deletion and export — on termination, client data is exported in a machine-readable format and deleted within 30 days.
• Subject access — a learner’s own record can be exported on request through their administrator.

Our data protection contact is [email protected]. A data processing agreement is available for signature before implementation begins.

Backup and recovery

The production database is backed up by the managed database platform on a daily cycle with seven days of retained backups. Point-in-time recovery is not enabled on this environment.

Daily snapshots and point-in-time recovery answer different questions — a snapshot returns you to last night, point-in-time recovery returns you to a chosen moment. Where an environment relies on daily snapshots alone, the worst case is the loss of everything since the last one, and we say so rather than implying otherwise.

• Recovery point objective — up to 24 hours on daily backups alone. Point-in-time recovery reduces this to minutes and is available as an upgrade; we quote the honest figure for what is running rather than the one the platform is capable of.
• Recovery time objective — four hours to restore and verify a database from the most recent backup.
• Restore testing — quarterly. No verified restore has been carried out on this environment yet; we will not claim one we have not performed. The first is scheduled before any client data is loaded.

We publish the date of the last verified restore rather than only the policy, because a backup nobody has restored is not a backup.

Your own copy of your own data

Platform backups answer what happens if we lose the database. They do not answer the three questions a client actually asks: can we have our data, can we undo a mistake, and can an auditor see the record as it stood on a date. A company administrator can take a tenant archive at any time — every row the company owns, as one file, with a SHA‑256 checksum over its own content.

• Verifiable — the checksum is computed over a canonical form of the content, so the same data always produces the same value. Verification runs offline and catches truncation, alteration, and an archive that has picked up another tenant's rows.
• Reported before it writes — a restore always produces a report first. Restoring what is missing never overwrites a row that changed since the backup; it tells you how many it left alone. Nothing is ever deleted.
• Redactable — an archive can be taken with names, usernames and contact addresses replaced by stable hashes, leaving every date, result and relationship intact, for cases where somebody needs the shape of the data but not the people in it.
• Recorded — every archive taken and every restore run is logged with its checksum and row count, which is the evidence an auditor asks for.

Two things are deliberately left out of an archive, and the file says which and why rather than leaving the gap to be noticed: password reset requests, because restoring them would revive tokens issued in the past, and the legacy snapshot table, whose content the normalised tables already carry.

Site nodes and offline data

Where a site runs an offline delivery node, a copy of that site’s course package, roster and assessment definitions is held on the node so learning continues without a connection. This is a deliberate extension of the data footprint and is worth understanding before rollout.

• A node holds only the roster and content assigned to that site — not the company-wide record.
• Head office remains the system of record. The node holds a working copy and a queue of events.
• Progress, attempts, attendance and notes queue locally and reconcile back when connectivity returns; conflicts are surfaced for a human decision rather than silently resolved.
• Node health, last sync time, queue depth and package status are visible from head office.
• Node enrolment uses a one-time token tied to a specific site identifier, so an unregistered device cannot pull a package.
• Device hardening and physical security at the site are the client’s responsibility; we specify the requirements during implementation.

Platform maintenance and updates

Application updates deploy continuously through the hosting platform. Database changes ship as versioned migrations with preflight and verification scripts run against the target environment before and after each change.

• Security patching — critical and high-severity patches within seven days of release; the managed platform applies its own database and runtime patching continuously.
• Maintenance window — Sundays 02:00–05:00 Central Africa Time, notified at least five business days ahead. Application updates deploy without downtime and do not need a window.
• Availability target — 99.5% monthly, excluding scheduled maintenance.
• Independent testing — no independent penetration test has been commissioned to date. We state that plainly rather than imply otherwise, and will commission one before or during implementation where a client requires it.

Support and incident response

Support runs 08:00–17:00 Central Africa Time, Monday to Friday, excluding Namibian public holidays, with an out-of-hours escalation path for incidents affecting access to required training. Requests are raised through the in-product support desk, which keeps the request attached to the person, their company and the course, or by email.

Response targets:

• Critical (nobody can sign in, or training records are at risk) — two business hours.
• High (a course or assessment is unusable) — four business hours.
• Normal — one business day.
• Low — three business days.

Escalation runs to the Aero Digital Solutions engagement lead, named in the service schedule at contract.

In the event of a security incident affecting client data, we notify the client’s nominated contact within 24 hours of confirming the incident, with what is known, what is affected and what we are doing. A written post-incident report follows within five business days.

Responsible disclosure

If you believe you have found a security issue in SkyBridge, please tell us before telling anyone else. Email [email protected] with the subject “SkyBridge security disclosure”, including enough detail to reproduce the issue.

We will acknowledge within three business days, keep you updated while we work on it, and credit you when it is resolved if you would like us to. We will not pursue action against anyone who reports in good faith and does not access, alter or retain data belonging to other people.