← All policies

Change Management Policy

1. Purpose

To ensure that changes to the Cadences.work production environment, source code, and supporting systems are introduced in a controlled, traceable, and reversible manner, minimising the risk of unintended impact on confidentiality, integrity, or availability.

2. Scope

3. Roles

The Company is a one-person organisation; the Director performs every role in the change lifecycle. Four-eyes review is not achievable in this state and is replaced by the compensating controls in §3.1 below. If the Company engages additional personnel, the Author and Approver roles shall be separated for production changes affecting Customer Personal Data.

3.1 Compensating controls in lieu of four-eyes review

Where a multi-person review is not achievable, the following automated and procedural controls together provide assurance:

• CI gates that fail the build on type errors, lint violations, dependency vulnerabilities (npm audit severity-gated), and (planned) static-analysis findings (Semgrep CE);
• Database-level access controls — Supabase Row-Level Security enforces multi-tenant isolation independently of application code;
• Immutable history — Git commits, Vercel deployment records, and Prisma migration history form a permanent audit trail with no way for a single actor to silently revert it;
• Instant rollback — Vercel's deployment alias mechanism allows a bad change to be undone in under a minute;
• Continuous dependency monitoring — Renovate raises PRs for security advisories;
• Compliance-platform monitoring — once Sprinto/Vanta is engaged (Phase 4), automated controls verify that the configurations matching this Policy remain in place;
• External attestation — sub-processor certifications (SOC 2 / ISO 27001) cover infrastructure-layer security that the Company does not need to re-implement.

4. Categories of change

5. Change lifecycle

5.1 Proposal

Every change starts as a Git branch from main. A pull request opens the change for review. The PR description includes:

• What the change does and why;
• Risk and rollback assessment;
• Tests added or run;
• Affected systems / classification levels.

5.2 Pre-merge checks (CI)

The CI pipeline shall verify, at minimum:

• Type checking (tsc --noEmit);
• Lint;
• Unit tests where present;
• Dependency vulnerability check (npm audit with severity gate);
• Static analysis (Semgrep CE or equivalent — to be added in Phase 2);
• Build success.

A change is not merged if CI fails. Bypass is permitted only for emergency changes and is recorded with justification.

5.3 Review

The Reviewer examines the change for:

• Correctness against the stated purpose;
• Security implications (input validation, authorisation, secret handling);
• Compliance with this and other policies (data classification, access control, cryptography);
• Test coverage proportional to risk.

5.4 Approval and merge

The Approver merges the PR after CI passes and review is complete. Merge events are immutable in Git history.

5.5 Deployment

• Production deployments happen automatically on merge to main via Vercel's GitLab integration.
• Database migrations run as part of the production build pipeline using prisma migrate deploy.
• Configuration changes in Vercel or Supabase dashboards are recorded in this repository where possible (e.g. vercel.json); dashboard-only changes are noted in the change log.

5.6 Verification and rollback

After deployment:

• Smoke-test the affected functionality.
• Monitor logs and error tracking for at least 30 minutes for material changes.
• If unexpected behaviour is observed, use Vercel's Instant Rollback to revert.

6. Emergency changes

In response to an active incident or critical security advisory:

• The change may bypass the standard review window.
• Verbal approval from the Approver is sufficient at the time.
• Within 24 hours, a retrospective PR or change-log entry documents what was done, why, and what verification was performed.
• The change is then put through the standard review process to confirm correctness and to identify any tightening needed.

7. Production data protection during change

• Production data shall not be cloned to development or staging environments. Test data is synthetic or anonymised.
• Migrations that destructively alter production data require the Approver's explicit acknowledgement of the data-loss profile in the PR.
• Backups are verified to exist before any destructive migration runs (see BCP-001).

8. Audit trail

Every production change leaves a permanent record in:

• Git history (immutable, signed where possible);
• Vercel deployment logs;
• Database migration history (Prisma _migrations table);
• The change log in the Compliance Readiness Plan §13 Decision Log for material policy or architecture changes.

9. Compliance and references

ISO/IEC 27001:2022 Annex A: A.8.32 (change management), A.8.31 (separation of development, test and production environments), A.8.25 (secure development life cycle), A.8.28 (secure coding), A.8.29 (security testing in development and acceptance), A.8.30 (outsourced development).

GDPR Article 25 (data protection by design and by default).

10. Version history