Security & trust

Access to your systems

The rule is: named people, least privilege, nothing shared, nothing kept.

• Every engineer uses their own named account on your GitHub/GitLab, AWS and SaaS tools. We never ask for a shared login or a root/owner credential.
• Cloud access is through scoped IAM roles, not long-lived access keys. For audits the role is read-only; for operations it is limited to the services in scope.
• Servers are reached through AWS Systems Manager Session Manager or an equivalent audited channel. We do not ask you to open SSH to the internet, and we do not keep SSH keys to your hosts.
• Production database access runs through the same audited tunnel, with per-person database users where the engine supports it.
• Access is granted for the engagement and revoked the day it ends. We send you the list of what to revoke so nothing is forgotten.

Our own accounts and devices

• Multi-factor authentication is enforced on every account that touches client work: GitHub, AWS, email, password manager, Slack.
• Credentials you share with us live in a team password manager with per-person access, never in chat, email or a document.
• Work laptops have full-disk encryption, screen lock, and automatic OS and browser updates.
• No client code or data is stored on personal devices or consumer cloud drives.
• When an engineer leaves the team, their access to every client system is removed the same day, and the client is told.

Your code and data

• Code lives in your repository from the first commit. We do not keep private forks of client code after an engagement ends.
• Production data stays in production. For development and testing we use synthetic or anonymised data; if a real dataset is unavoidable for a specific task, we agree it in writing first and delete it when the task is done.
• Secrets are never committed. Anything that was committed before we arrived is rotated as part of the first sprint.
• We use AI coding tools and say so. They are configured not to train on your code, and no production data, credentials or personal data is pasted into them.

How changes reach production

This is the part healthcare and SOC 2 clients care about most, and it is how we work for everyone.

• Every change goes through a pull request in your repository that you can read and approve. Nobody deploys from a laptop.
• Production changes ship with a written plan, automated tests where they exist, and a rehearsed way to roll back. Larger changes — database upgrades, migrations — get a runbook and a go/no-go checklist, as in our published RDS upgrade runbook.
• Infrastructure is defined in code or documented step by step, so a change can be reviewed before it happens and reproduced after.
• Monitoring and alerting are part of every system we operate: you should hear about an incident from us, not from a user.

Incidents

• If we cause or discover a security incident affecting your systems or data, we tell you within 24 hours of confirming it, in writing, with what we know and what we are doing.
• Incidents on systems we operate get a written post-incident review: timeline, cause, what changed so it does not recur.

Compliance support

• We are a small company and do not hold a SOC 2 report of our own. We do operate client infrastructure under a client's SOC 2 programme and close the findings their Drata dashboard raises; see the SOC 2 Remediation Sprint.
• We will complete your vendor security questionnaire, sign a data processing agreement, and provide the evidence a reasonable auditor asks for about our access to your environment.
• Our handling of personal data from this website is described in the privacy policy.