# Your data stays yours.

> We work inside your environment, with the least access the job needs, and we leave nothing of yours behind. This page explains how that works, in practice and without the marketing.

Last updated October 26, 2026.

## The basics, stated plainly.

- **Encrypted in transit** This website is served only over HTTPS, with certificates managed by our hosting provider. Traffic to and from the site is encrypted.
- **Nothing stored that we don’t need** Contact-form messages are validated on our server and delivered to us by email. We don’t keep a separate database of submissions.
- **No long-lived cloud keys** The site sends email using short-lived, federated credentials. There are no static cloud access keys sitting in the code or the repository.
- **Spam and bots kept out** The contact form is protected by a captcha that is verified on the server, and every field is length-limited and checked before anything is sent.

## When you contact us, here is what happens.

1. **You submit the form** — Over HTTPS, from your browser to our hosting provider.
2. **We verify it** — The captcha token is checked server-side, and every field is validated and size-limited.
3. **It is emailed to us** — The message is sent through Amazon SES to a CodeScapes inbox, using short-lived credentials.
4. **A person replies** — A principal engineer reads it and writes back. We don’t add you to mailing lists.

## Four commitments we hold ourselves to.

- **You own it.** Code, infrastructure and data live in your accounts from day one. We work in your environment, not in a copy of it.
- **Least privilege.** We ask for the access a task needs, scoped to that task. If we need more, we ask — we never assume.
- **Nothing in the wrong place.** Your data stays out of personal accounts, chat threads and test environments unless we have agreed otherwise in writing.
- **Written down.** Access granted, exceptions taken and decisions made are recorded, so you can always see what we touched and why.

## Security isn’t a step. It runs the whole way through.

- **Before we start — Agree the ground rules.** What we will see, where it lives and who can access it is agreed in the engagement agreement before any access is granted.
- **Diagnose — Read-only first.** The diagnosis runs on read-only, time-boxed access, so nothing changes in your systems while we learn them.
- **Build & run — Scoped and reviewed.** Changes ship through your pipelines as reviewed code. Secrets stay in your secret manager — never in repositories or chat.
- **When we finish — A clean exit.** Access is revoked when the engagement ends, and we confirm it in writing. Nothing of yours stays with us.

## Habits that keep systems safe.

- **Review before release** Changes go through code review. Every new dependency has to justify itself, which keeps the attack surface small.
- **A way back, tested** No release goes out without a tested rollback. Observability and alerting ship on day one, not after the first incident.
- **Secrets stay secret** Credentials live in a secret manager or a federated identity, never in code, tickets or chat. We prefer short-lived access over long-lived keys.
- **Decisions on record** Significant architecture and access decisions get a written record, so the reasoning survives and can be audited later.
- **Boring where it counts** We choose proven tools for the security-critical parts. Fewer moving parts means fewer places to get it wrong.
- **Data minimised** We take only the data a task requires and avoid copying production data into other environments.

## A plan before we need one.

1. **Detect** — Monitoring and your own alerts surface the issue; anyone on the engagement can raise it.
2. **Contain** — We limit the impact first — revoke access, rotate credentials, isolate what’s affected.
3. **Tell you** — We notify you without undue delay once we confirm an issue that touches your data, with what we know and what we’re doing.
4. **Learn** — We work with your team on recovery and write up what happened and what changes so it doesn’t repeat.

## Your policies set the bar.

Every organisation has its own security standards. We adapt to yours rather than ask you to adapt to ours.

- We’ll complete your vendor security questionnaire.
- We’ll sign your NDA or data processing agreement before any access is granted.
- We’ll follow your access, change-management and data-handling policies.
- We’ll work within your regulatory constraints, and tell you early if a requirement is outside what we can meet.

## Found a problem? Tell us.

We welcome good-faith reports of security issues. Please give us a reasonable time to fix a problem before you share it publicly, and avoid accessing other people’s data or degrading the service while you test. We won’t pursue legal action over research that follows these guidelines.

- **Report a vulnerability** Email a description and how to reproduce it. We acknowledge reports and keep you updated until it’s resolved.
- **Security and compliance questions** Send us your questionnaire or requirements. A principal engineer will answer them directly.

Our machine-readable security contact details are also published as a security.txt file. [security.txt](https://www.codescapes.dev/.well-known/security.txt)

Contact: hello@codescapes.io

> We will never ask for your passwords, access keys or one-time codes by email, chat or phone. If someone claiming to be us does, don’t share them — tell us.

## What security teams ask us first.

### Will you sign our NDA or data processing agreement?

Yes. We are happy to sign yours before any access is granted, and to work to your security requirements.

### Where will our data live?

In your environment. We do not copy production data to our own systems; work happens in your accounts, behind your controls.

### Who on your side can see it?

Only the engineers staffed on your engagement, with a named principal accountable for who has access and why.

### How do you handle credentials and secrets?

In your secret manager or through federated, short-lived access. They are never committed to repositories or shared in chat.

### What happens if something goes wrong?

We tell you promptly, as soon as we confirm an issue that touches your data, and work with your team on containment and follow-up.

### What happens to access and data when we finish?

We revoke access at the end of the engagement and confirm it in writing. Because the work lives in your accounts, there is nothing of yours for us to return or delete.

## Have a security review to run?

Send us your questionnaire or your requirements. A principal engineer will answer them directly. [Contact us](https://www.codescapes.dev/contact.md)