Security

Access control and least privilege

Staff accounts in our CMS carry one of four roles, each with its own set of permissions, and the server checks the permission before any module opens. Within a module, per-record policies decide what each person may change. Invoices and payments are visible only to the owner and admin roles, and that is enforced on the server rather than hidden in the interface.

Client contacts sign in to the portal through a separate authentication realm from staff, with their own sessions and their own password rules. Every portal query is scoped to the contact's own organisation at the data layer, so one client cannot reach another client's records by changing an address.

Both staff and portal accounts support two-factor authentication with an authenticator app, and the secrets behind it are encrypted at rest. Sign-in is rate limited in both realms. In production, a new portal password is checked against known breached-password lists before it is accepted.

Credential handling

No secret lives in a code repository. Server credentials are held in the server's environment file, which is excluded from every deploy. Our CI holds deploy credentials and nothing else: no client data, no mail keys, no tax identifiers.

Passwords are hashed and cannot be recovered. Two-factor secrets and the signing secrets our monitoring uses are encrypted with the application key, and a signing secret is shown exactly twice in its life: when it is created and when it is rotated.

We have a written credential runbook covering where each kind of secret lives, how to rotate it without an outage, and which shared credentials to rotate when somebody leaves.

Encryption

Our CMS and client portal redirect every plain HTTP request to HTTPS. All of our sites send HTTP Strict Transport Security, so a browser that has reached us over HTTPS once will not use plain HTTP again.

At rest, the most sensitive fields are encrypted by the application itself: two-factor secrets, recovery codes, and integration signing secrets.

Monitoring and incident response

Our CMS receives signed error reports and regular heartbeats from the systems we connect to it, through our own agent packages. A heartbeat that stops arriving raises an incident on its own, so a system that has gone silent is noticed rather than assumed healthy.

Alerts reach a person, with quiet hours that hold low-priority alerts until morning and let critical ones through. Acknowledging an incident is recorded with a time, and response times feed the monthly report a client receives, where they cannot be edited after the fact.

We follow a written incident runbook: acknowledge, establish what is down, decide whether the client is told now, fix, resolve in the right order, and write down what changed.

Audit logging

Our CMS keeps an audit log of who changed what and when, across both staff and client portal accounts: invoices, payments, tickets, approvals, documents, settings and access changes.

Dependencies and secret scanning

Every deploy of our CMS and of this site runs an automated dependency vulnerability audit and a secret scan of the full repository history, and a finding stops the deploy.

Application hardening

This site sends a strict content security policy with a fresh nonce on every render, and the security headers that stop it being framed, sniffed or leaking referrers. Content from our CMS is rendered with raw HTML disabled.

Our CMS rate limits its public API, its sign-in, and its forms, and rejects header injection in contact submissions. Uploaded files are stored privately, renamed by the framework, checked against an allow-list of types and sizes, and only ever served after a permission check.

Where data lives, and who else handles it

Our website, CMS and client portal run on one hosting account with Namecheap, on a server in the United States. Every outside company that handles personal data for us is named in our privacy policy, with what it receives and where.

The full list is in our privacy policy.

Breach notification

If a breach affects personal data, we notify as the Data Protection Act 2019 requires: the Data Protection Commissioner for data we control, and the client without delay for data we process on a client's behalf. We tell you what happened, what it affected, and what we have done about it.