# 16 Secure development and change management policy

| | |
| --- | --- |
| Version | 0.1 draft |
| Owner | Change Approver |
| Review | Yearly |
| Applies to | Application code, infrastructure configuration, database schemas and scheduled jobs of every in-scope product |

## Environments

1. Development, staging and production are separate (CHG-06). Production hosts do not run development servers, experiments or interactive coding sessions.
2. Production data is not copied to development or staging unless masked, or under an approved time-limited exception.
3. Production configuration differs from development only through environment variables and the secrets store.

## Change process

1. **Every change is a pull request** to the protected default branch of a repository in the in-scope GitHub organization. Direct pushes to the default branch are blocked, for administrators too (CHG-01).
2. **Description:** what changed, why, how it was tested, and the rollback plan for risky changes.
3. **Review by someone other than the author** before merge (CHG-02). The reviewer reads the diff, not just the description. A coding agent cannot be the reviewer. When a coding agent wrote the change, the human who directed it is the author.
4. **Automated checks pass before merge** (CHG-03): unit and integration tests, dependency vulnerability scan, secret scan, static analysis. A failing check is fixed, not bypassed. Bypass needs the emergency procedure.
5. **Security-relevant changes** (authentication, authorisation, tenancy, cryptography, data flows to new vendors, logging of personal data) are flagged in the PR and reviewed with the [SOC 2 gate](/soc2/05-soc2-gate) and the [compliance ship gate](/playbook/05-ship-gate).
6. **Deploy only from the merged default branch, through the pipeline** (CHG-04). The pipeline records commit, actor, time and result. Editing files on a production server, copying builds by hand, or restarting a production process to pick up uncommitted code is not a deploy and is not allowed.
7. **Database migrations** are in the PR, reviewed, and run after a fresh backup or are reversible (CHG-08).
8. **Infrastructure changes** (firewall, DNS, Cloudflare tunnel and rules, cloud resources, cron jobs) are made as code in a reviewed repository where possible. Where a console change is unavoidable, it gets a change ticket with an approval before the change (CHG-07).

## Emergency changes

When production is down or data is at risk, a change may be merged or applied with whatever review is available. It is labelled `emergency`, committed to the repository the same day, and reviewed by a second person within 2 business days (CHG-05). An emergency change that never gets its review is a control exception.

## Secure coding

- Follow the security defaults in the [compliance prompt](/PROMPT.md) (OWASP ASVS Level 2 baseline).
- Dependencies are pinned. Automated update PRs are reviewed like any other change.
- Critical vulnerabilities in dependencies are fixed within 7 days, high within 30 (OPS-03).
- Tests guard compliance-critical behaviour: tenant isolation, authorisation, redaction, consent gating.

## Customer communication

Material changes to the service or to security commitments are announced to customers before or at release (COM-05).