How we protect your systems and data

Giving an outside company access to a system the business depends on is a risk. This page sets out how we keep that risk small: who gets access, how credentials and data are handled, and what happens if something goes wrong.

Last reviewed: 16 October 2026. We do not hold Cyber Essentials or ISO 27001 certification at present. What follows is how we work, and we are happy to answer a supplier security questionnaire or to work under your own security policies.

Access to your systems

  • Named accounts only. Everyone who works on your system has their own account. We do not share logins, and we ask you not to give us a shared or administrator account where a narrower one will do.
  • Least privilege. We ask for the access a task needs and no more: read-only access for an audit, access to test environments for development, and production access only for the people supporting it.
  • Multi-factor authentication. We use it wherever your platform supports it, and ask you to enforce it on the accounts you give us. It is also switched on for every CodeFirst account that can reach client systems or data: email, source control and cloud consoles.
  • Access ends with the work. When an engagement ends, or someone stops working on your system, we tell you which accounts to remove and confirm that our own copies of credentials have been deleted.

Credentials and secrets

Passwords, keys and connection strings are kept in a password manager or in the secret store of your own platform (for example Azure Key Vault, AWS Secrets Manager or the pipeline's protected variables), never in source code, documents or email. Where we find secrets committed to a codebase, we tell you and move them out as part of the work.

Please do not send passwords or keys by email. We will agree a secure way to exchange them.

Your source code

Your code lives in your repository, in an account you own. We work in it rather than in a copy of our own, so you always have the current version and the full history of who changed what. Every change goes through a pull request or commit that is recorded against the person who made it. If you do not have a repository yet, we set one up in your name.

We use an AI coding assistant, Anthropic (Claude), to help read, review and change code. Code sent to it is processed under commercial terms that do not allow the provider to train its models on the material sent. If you would rather we did not use it on your system, tell us and we will not.

Personal data in development and testing

Production data is not copied to developer machines unless you agree to it for a specific task, such as investigating a fault that cannot be reproduced any other way. Where we need realistic data for testing, we use anonymised or generated data. When we do hold a copy of your data, it is deleted once the task is finished.

Every device used for client work has full-disk encryption and locks when unattended. Client data that we store ourselves is kept in the UK or the European Economic Area.

Keeping the system safe to run

For the systems we support, we set up and maintain:

  • Backups that have been restored. A backup is not trusted until a restore has been tested. We record how long recovery takes and how much data could be lost.
  • Supported versions. Frameworks, libraries, databases and servers are tracked against their vendors' support dates, so upgrades are planned before security fixes stop. Our end-of-support guides show the dates we work to.
  • Dependency checks. Libraries are checked for known vulnerabilities, and updates are applied through the normal tested release process.
  • Monitoring. Errors and performance are monitored in production, with alerts, so that we often see a problem before your users report it.
  • Controlled releases. Changes are tested in a separate environment and released through a repeatable process, so that a release can be rolled back.
  • Protection at the edge. Where a system is exposed to the internet, we can put a web application firewall in front of it and tune it so that it blocks attacks without blocking real users.

If something goes wrong

If we find or suspect a security incident affecting your system or data, we contain it first, then tell you what happened, what is affected and what we have done. If personal data is involved, we tell you within 24 hours of becoming aware of it, so that you can meet your own 72-hour deadline to notify the regulator. We then help you investigate, put it right and stop it happening again.

Confidentiality

We sign your non-disclosure agreement before you share anything confidential, or provide our own. Everything we see while working on your system is treated as confidential, and we never name a client or describe their system publicly without permission.

Personal data and GDPR

When we work on a system that holds personal data, you remain the controller and we act as your processor. Our GDPR page explains what that means in practice and lists the services we use, and our standard data processing agreement sets it out in contract terms. We are equally happy to sign yours.

Questions

If your organisation has a security questionnaire, a supplier assessment or its own policies for third parties, send them to contact@codefirst.co.uk and we will complete them.