Secure development and change management policy

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 and the compliance 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 (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.