Change Management & Deployment Policy

• Applies to websites, n8n workflows, custom code, connectors, and infrastructure we operate.
• Client-owned platforms follow this as a minimum alongside client rules.
• Covers code, config, data models, infrastructure, dependencies, and secrets.

• Requester: raises the change and explains the outcome needed.
• Implementer: builds, tests, and ships the change.
• Reviewer: peer checks risk, plan, and code. Not the Implementer.
• Approver: project lead or director; signs off high-risk items.

1. Request: open a ticket with goal, scope, risk, and rollback.
2. Assess: tag type (Standard/Normal/Emergency), set priority, and impact window.
3. Plan: steps, owners, test notes, comms, and success checks.
4. Review: peer review code/config and the plan.
5. Test: run in non-prod where possible; record results.
6. Approve: Approver signs off Normal/Emergency changes.
7. Deploy: use our change window; monitor live metrics.
8. Validate: run success checks; confirm with stakeholders.
9. Close: update docs and ticket; note any follow-ups.

• Prefer dev → test → live. Use feature branches and pull requests.
• Pin key versions; record upgrades and breaking changes.
• Tag releases; keep export files for n8n flows before and after deploy.

• Check data impact, downtime risk, rate limits, and upstream dependencies.
• Respect client trading peaks; avoid risky changes in peak windows.
• For personal data, confirm the DPA scope and sub-processor effects.

• Keep a point-in-time backup or export before Normal/Emergency changes.
• Document quick rollback steps and criteria to trigger rollback.
• After rollback, open a follow-up ticket and root cause review.

• Deploy via pipelines where available; avoid manual edits in live.
• Reviewer is different from Implementer for Normal changes.
• Admin access is temporary and logged (just-in-time if possible).

• Store secrets in a vault or platform secrets. Never in code.
• Rotate on role change, compromise, or vendor notice.
• Mask secrets in logs and screenshots.

• Tell stakeholders about planned downtime and client actions needed.
• During deploy, post start, key checkpoints, and finish times.
• If a deploy fails, inform stakeholders and execute rollback.

• Standard window: weekdays 09:00–17:00 UK for low risk; evenings for risky items.
• Gold SLA clients may use agreed out-of-hours slots.
• Emergency changes can proceed at any time with on-call approval.

• Keep change tickets, approvals, diffs, and exports for at least 12 months.
• Run a monthly review of failed or rolled-back changes.
• Feed lessons into runbooks and tests.

• Information Security Policy
• Backup & Restore Policy
• Incident Response & Breach Policy
• Service Level Agreement
• Data Processing Addendum

Questions about this policy?

Technophobia Ltd · Company No. 14898332 · VAT GB 495 7043 58
13B Devonshire Road Industrial Estate, Millom, LA18 4JS, United Kingdom
+44 1229 774591 • hello@technophobia.uk