Security Overview · Version 1.0 · July 2026
How Key Dials and their Partners protect your documents
A plain-English summary of the security measures, hosting arrangements and access controls that protect the information you hold in your dials.
Penetration tested every week by an independent specialist.
Key Dials is built on the principle that your documents are yours, and nobody sees them unless you have explicitly said so. The platform runs on enterprise-grade infrastructure operated by Vercel and Supabase, hosted on Amazon Web Services in Ireland (EU), behind their managed firewalls and DDoS protection. All traffic is encrypted in transit, and all stored data — including every uploaded document — is encrypted at rest.
Critically, access control is not a feature of the app that could be bypassed by a clever browser trick: it is enforced inside the database itself, on every single request, using PostgreSQL Row Level Security. Documents are held in private storage that cannot be browsed or linked to publicly, and are released only through short-lived, individually authorised download links. There is no public sign-up — accounts exist only by invitation — and there are no passwords to be stolen, guessed or reused.
None of this is taken on trust. The live platform is penetration tested every week by an independent, specialist testing service, with additional targeted testing run by hand after any significant change.
Section 1
Where your data lives
Ireland (EU) — AWS eu-west-1
PostgreSQL 17 (managed, Supabase Pro)
Vercel global edge network
Private object storage, EU region
Key Dials uses two specialist hosting providers rather than self-managed servers, so that patching, hardening, network protection and physical security are handled by organisations that do it at scale:
Vercel delivers the web application. Every request passes through Vercel's edge network, which provides automatic TLS certificate management, always-on DDoS mitigation and a managed edge firewall. The application itself is served as static assets — there is no application server holding your data.
Supabase, running on Amazon Web Services, holds the database, the document storage and the authentication service. The production environment sits in the AWS Dublin region, so your data does not leave the EU in the course of normal operation.
Both providers maintain independently audited security programmes, and AWS operates the underlying data centres to internationally recognised standards including ISO 27001 and SOC 2. Current certification details are published on each provider's trust pages and can be supplied on request.
Section 2
Encryption
In transit — every connection to Key Dials is encrypted using TLS. HTTP requests are redirected to HTTPS at the edge; there is no unencrypted route into the platform.
At rest — the database, its backups and all uploaded documents are encrypted on disk by the hosting platform using AES-256.
In use — document downloads are served over expiring signed links (see section 4), so a URL captured from a browser history or a forwarded message stops working shortly afterwards.
Section 3
Who can get in, and how
No public sign-up. The platform will not create an account for an unrecognised email address. Accounts exist only where an administrator has invited them.
No passwords. Sign-in uses a six-digit, single-use code sent to your registered email address. Because no password is ever set, there is nothing to be reused from another breached website, guessed, or phished in the usual way — an attacker would need live access to your email inbox.
Sessions are time-limited and are held in your own browser. Signing out ends the session.
Unauthenticated visitors have no data access whatsoever. The anonymous database role holds no privileges on any table. Someone who has not signed in cannot read, count, guess at or enumerate organisations, users, dials or documents.
Section 4
Your documents specifically
Uploaded evidence and supporting documents are handled deliberately differently from ordinary web files:
Stored privately, never publicly. Document buckets are marked private at the storage platform. There is no public URL for a document, and no directory that can be listed.
Unguessable storage paths. Every file is stored under a randomly generated identifier rather than its original filename, organised by owning organisation. Filenames themselves are never exposed in a URL.
Uploads are brokered server-side. The browser never holds a general key to storage. It asks a server-side function for a one-time upload link scoped to a single file, and can do nothing else with it.
Downloads use short-lived signed links. A download link is generated only after the database has confirmed that the requesting user is entitled to that specific file, and it expires within the hour.
Entitlement is checked per file, on every request, by a dedicated database function that resolves the file back to its action point, its dial and its owning organisation, and confirms the requester's membership before allowing access.
Section 5
How access is enforced
This is the part that matters most, and it is where Key Dials is deliberately conservative. Access control is enforced in the database, not in the application.
Row Level Security is enabled on every table holding organisational or product data — organisations, memberships, dials, sections, action points, responses, files, audit records and commercial records among them. Each query is filtered by the database itself against the identity of the signed-in user. The practical consequence is that even a flaw in the user interface, or a user manipulating requests directly, cannot return data they are not entitled to — the database simply returns nothing.
On top of that:
Everything is scoped to an organisation. There is no global access and no cross-organisation visibility. Belonging to one organisation grants nothing in another.
Sharing is explicit, never inherited. A commercial or hierarchical relationship between organisations — a partner, a licensee, a referrer — does not itself grant sight of anyone's data. A dial must be deliberately shared before it can be seen.
Access is granted per dial, per person, at a defined level (view, edit, admin or backup contact), and can be withdrawn.
Permissions are data, not code. What each role may do is held in a locked-down table that no user, administrator or part of the application can modify; it can only be changed by a reviewed database migration.
Client-side state grants nothing. The organisation shown in your browser is a display convenience only. It confers no rights whatsoever.
Section 6
Accountability and audit
Immutable audit trail. Changes to action points — status changes, responses, approvals and file activity — are written to an append-only audit log recording who did what, and when.
Support access is restricted and recorded. Where Key Dials support staff need to view an account to resolve an issue, that capability is limited to designated platform administrators, is verified server-side on every use, and every attempt — successful or refused — is logged.
Financial records are protected against tampering by database rules that block silent edits and deletions.
Section 7
Payments
Card payments are handled entirely by Stripe, a PCI DSS Level 1 service provider. Card details are entered on Stripe's own hosted checkout and are never transmitted to, processed by or stored on Key Dials systems. Payment confirmations received back from Stripe are cryptographically signature-verified before they are acted upon, so forged payment messages are rejected.
Section 8
Independent penetration testing
A full penetration test every week — roughly fifty a year.
Security claims are only worth as much as the testing behind them. Key Dials is penetration tested on a continuous basis by AppCheck, a specialist UK-based security testing provider, rather than relying on a single annual assessment that is out of date within weeks.
Weekly testing against the live platform. A full penetration test runs every week, probing the application for the OWASP Top 10 categories — injection, broken access control, misconfiguration and the rest — together with a continuously updated database of known vulnerabilities.
Additional manual testing after every significant change. New functionality is not left to wait for the next scheduled cycle. Whenever a major change is released, a further test is run by hand against it.
Findings are triaged and addressed as part of the normal development cycle, and re-tested on the following run to confirm the fix.
The practical effect is that the platform is re-examined by an outside party roughly fifty times a year, and never goes more than a few days without being tested.
Section 9
How we keep it that way
A written, authoritative security model. The access-control design is documented as a binding engineering standard; any change touching Row Level Security, permission checks or new access paths must be reviewed against it before release.
Controlled schema changes. Every change to the database and its security policies is made through a versioned, reviewed migration — nearly 200 to date — rather than by hand on the live system.
Separate development and production environments, so testing never touches live customer data.
Automated security checks run against the production database to flag any table left without Row Level Security or any policy weakened by mistake. The production database currently reports no errors of this kind.
Managed daily backups are taken by the hosting platform and retained on a rolling basis, encrypted, within the EU region.
Questions, or a security review to complete?
We are happy to answer specific questions from your IT or compliance team, and to provide further detail on any of the above. Please contact your Key Dials representative in the first instance.
Get in touchKey Dials Ltd · Security Overview v1.0 · July 2026
This document describes the platform as configured at the date of issue and is provided for information; it does not form part of any contract.