Security

Our approach

We are a development company, so most of our security work is not a policy document. It is the day-to-day practice of building software that does not create new risk for the people who run it. What follows describes how we work rather than a list of badges.

Where a client operates under a specific framework, whether that is SOC 2, ISO 27001, HIPAA, PCI DSS, or a sector regulator, we work to their control set and evidence requirements as part of the engagement.

Secure development

• Every change is reviewed. Nothing reaches a main branch without another engineer reading it. Reviews look for authorisation gaps and injection risks, not just correctness.
• Secrets never live in source control.Credentials are held in a managed secret store or the platform's environment configuration, and repositories are scanned for accidental commits.
• Dependencies are tracked and updated. We monitor advisories for the packages we ship and patch known vulnerabilities rather than letting them accumulate.
• Input is validated at the boundary. We treat everything arriving from a client, a queue, or a third-party API as untrusted, and we use parameterised queries rather than string-built SQL.
• Automated checks run on every pull request. Type checking, linting, and tests gate the merge.

Access control

• Access is granted on a least-privilege basis and tied to the specific engagement a person is staffed on.
• Multi-factor authentication is required on every account that can reach client systems, source control, or cloud infrastructure.
• Production access is separated from development access, and is granted only to the people who genuinely need it.
• Access is revoked when someone rolls off a project or leaves, as part of offboarding rather than as an afterthought.
• Company devices use full-disk encryption and automatic screen locking.

Infrastructure

• Traffic is encrypted in transit with TLS. Data at rest is encrypted using the storage platform's managed encryption.
• Environments are separated, so development and staging never share a database or a credential with production.
• Infrastructure is defined as code where possible, so changes are reviewable and environments are reproducible.
• Backups are configured for the systems we operate, and restores are tested rather than assumed.
• Logging and monitoring are in place so that unusual behaviour is visible rather than discovered later.

Handling client data

Our default is not to hold client production data at all. Where development requires realistic data we work with anonymised or synthetic datasets. Where access to real data is genuinely unavoidable, it happens inside the client's environment, under their controls, with the scope and duration agreed in writing beforehand.

Every person working on an engagement is under a confidentiality obligation. We sign non-disclosure agreements before commercially sensitive discussions, and we enter into a data processing agreement where we act as a processor. How that relationship works is described in our Privacy Policy.

At the end of an engagement we return or destroy client data and revoke our access, on the timeline the contract sets.

Incident response

If we detect or are told about a security incident affecting a client, we contain it first, then investigate scope and root cause, then remediate. We notify affected clients promptly and give them what they need to meet their own regulatory reporting obligations, including the 72-hour window that applies under the GDPR.

After an incident is closed we write it up honestly, including what we missed and what we changed, and share that with the affected client.

Reporting a vulnerability

If you have found a security issue in this website or in something we built, we want to hear about it. Email [email protected]with the subject line "Security" and include enough detail to reproduce the issue.

What you can expect from us:

• An acknowledgement within two business days.
• An assessment and a remediation plan, with updates as we work through it.
• Credit for the finding if you would like it.
• No legal action against you for research conducted in good faith under the guidelines below.

What we ask from you:

• Give us reasonable time to fix the issue before disclosing it publicly.
• Do not access, modify, or delete data belonging to anyone else, and stop as soon as you have confirmed a vulnerability exists.
• Do not run denial-of-service tests, send spam, or use social engineering against our team or our clients.
• If the issue is in a client system, report it to us and let us coordinate with them rather than contacting them directly.

We do not currently run a paid bug bounty programme.

Questions from procurement

If your security team needs to review us before an engagement, we are happy to complete a vendor questionnaire, walk through our practices on a call, and sign the agreements your process requires. Start at [email protected] or through our contact page.