How Key Dials and its partners protect your documents

Section 1

Where your data lives

Key Dials runs on Microsoft Azure rather than on servers of its own, so patching, hardening, network protection and physical security are handled by an organisation that does them at scale. The production environment is provisioned in the UK South region from a versioned infrastructure definition, and it is separate from the development environment in every respect — its own subscription, database, storage and keys — so testing never touches live customer data.

The API runs as a container on Azure Container Apps. The two web applications are static assets served by Azure Static Web Apps: there is no application server holding your data in the browser tier. The database is Azure SQL Database, a managed service that takes automated backups and retains them on a rolling basis, encrypted, within the United Kingdom.

Microsoft operates the underlying data centres to internationally recognised standards, including ISO 27001 and SOC 2. Current certification details are published on the Microsoft Trust Center and can be supplied on request.

Section 2

Encryption

In transit — every connection to Key Dials is encrypted using TLS 1.2 or later. The storage account and the database server both refuse older protocols, and 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 Azure 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 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.

Accounts are created by invitation from an organisation that already uses Key Dials, or when a plan is bought. A guest who has been sent a scoped link sees exactly what was shared with them and nothing else.

Sessions are short. An access token lasts fifteen minutes and is renewed quietly while you are working; an administrator’s renewal expires within a day. Signing out ends the session.

Unauthenticated visitors have no data access whatsoever. The public surfaces — the enquiry form, the plan catalogue and the pages of this website — are served from allow-listed projections that never carry tenant data, and are rate-limited.

Section 4

Your documents specifically

Stored privately, never publicly. The storage account does not permit public access to blobs, and 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 the API for a one-time upload link scoped to a single file, valid for fifteen minutes, and can do nothing else with it.

Downloads use short-lived signed links. A download link is generated only after the API 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: the file is resolved back to its action point, its dial and its owning organisation, and the requester’s membership and role are confirmed before a link is issued. Files attached through a restricted field are withheld from readers who cannot see the field.

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 only in the application.

Row-level security is enabled on every table holding organisational or product data — organisations, memberships, dials, sections, action points, statuses, files, conversations and commercial records among them. Each query is filtered by the database itself against the organisation the signed-in user is acting in. 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.

Everything is scoped to an organisation. Belonging to one organisation grants nothing in another. A commercial or hierarchical relationship between organisations — a partner, a licensee, a referrer — does not itself grant sight of anyone’s dial; sharing is explicit, per dial, per person, at a defined level, and can be withdrawn.

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

Every status change on an action point, section or dial is recorded with who made it and when, and the record is kept as the dial’s history rather than overwritten. Attribute changes keep their own history in the same way.

Support access is restricted and recorded. Where Key Dials staff need to view an account to resolve an issue, that capability is limited to designated platform administrators and is verified server-side on every use.

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 events received back from Stripe are signature-verified before they are acted upon, and each is recorded once, so forged or replayed messages are rejected.

Section 8

Independent penetration testing

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.

A full test runs every week against the live platform, 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. New functionality is tested by hand after every significant change, and findings are addressed as part of the normal development cycle and re-tested on the following run.

Section 9

How we keep it that way

Controlled schema changes. Every change to the database and its security policies is made through a versioned, reviewed migration — over 180 to date — rather than by hand on the live system.

Automated checks in the build. The test suite refuses a change that adds a tenant-scoped table without enrolling it in row-level security, or without the query filter that scopes it in the application, so a gap cannot be introduced by forgetting.

Secrets are never in code. Connection strings, signing keys and third-party credentials are held in Azure Key Vault and supplied to the running service by identity, not copied into configuration.