Change Management Policy

Document control

Field	Value
Owner	Ron Benisty — CTO & CSO (ron.b@iontwrks.com)
Status	Approved
Version	1.0
Classification	Confidential
Approved by	Ron Benisty — CTO & CSO
Approval date	2026-05-25 (Monday)
Last reviewed	2026-05-25
Review cycle	Annual — next review due May 2027
Parent policy	Secure SDLC (SSDLC)

Satisfies ISO/IEC 27001:2022 A.8.32 (change management) and SOC 2 Type II CC8.1 (changes are authorized, designed, developed, tested, approved, and implemented). Closes Gap 2 of the SSDLC gap analysis.

---

1. Purpose

Ensure every change to production is risk-assessed, tested, approved, and reversible, and that each change leaves a durable, timestamped record an auditor can sample over the Type II window.

2. Scope — what counts as a "change"

Any modification deployed to production:

• application code,
• database schema / migrations,
• infrastructure-as-code,
• CI/CD pipeline configuration,
• production runtime configuration / feature flags.

Local development and non-prod experimentation are out of scope until promoted toward production.

3. The operating model — the Pull Request is the change record

S.E.T runs all changes through GitHub. Rather than a separate ticketing system, the Pull Request is the authoritative change record. The platform enforces the controls; the PR captures the evidence:

• Branch protection blocks direct pushes to main — every change is a PR.
• A PR template forces the required fields (risk, testing, rollback) on every PR.
• Required review + CODEOWNERS enforce approval and separation of duties.
• The merged PR + its CI run + the deploy log are the retained, timestamped evidence — collected automatically.

4. Change tiers

Tier	When	Process	Approval
Normal	All routine changes to in-scope items	PR with completed template (risk, testing, rollback)	≥ 1 CODEOWNER approval before merge
Emergency	Production-down or active security incident requiring an immediate fix	Expedited merge to restore service	Retroactive review within 1 business day, logged on the PR

There is intentionally no "low-risk / standard" tier — every production change is a PR, so there are no judgment calls about whether a record is required.

5. Required content of every change record (PR)

Enforced by the PR template (§10):

1. Summary — what changes and why; linked issue/finding.
2. Risk & impact — what it could affect (tenants, data, auth, availability).
3. Testing evidence — how it was verified (CI results, test notes, screenshots).
4. Rollback plan — the exact step to revert.
5. Tier — Normal or Emergency.

6. Approval & separation of duties

• The author may not approve their own change. At least one CODEOWNER review is required before merge (enforced by branch protection).
• This control also satisfies Gap 9 — Separation of Duties for the change path.

7. Rollback

Every Normal and Emergency change must state how to revert — typically "revert this PR" or "redeploy the previous image tag (vX.Y.Z)." Immutable, versioned container images make rollback a redeploy, not a rebuild.

8. Emergency changes

When production is down or a security incident is active:

1. Open a PR marked Emergency; merge may proceed on a single expedited approval (or self-merge if no reviewer is reachable).
2. A retroactive CODEOWNER review is completed and recorded on the PR within 1 business day.
3. If the emergency stemmed from an incident, link the Incident Response record (Incident Response Plan — Gap 14, forthcoming).

9. Evidence & retention

Evidence	Source	Retention
Change record	The merged PR (description + approvals + discussion)	≥ 12 months
Test evidence	CI run linked to the PR	≥ 12 months
Deploy record	Deploy workflow / deploy log	≥ 12 months

Retention follows the discipline in Supply Chain & CI/CD Security and Observability & Logging.

10. PR template (deploy to the application repository)

Add this file to the application repository at .github/PULL_REQUEST_TEMPLATE.md — GitHub then pre-fills it into every new PR:

## Summary
<!-- What does this change do and why? Link the issue/finding. -->
Closes #

## Change tier
- [ ] Normal
- [ ] Emergency (prod-down / security incident — retroactive review within 1 business day)

## Risk & impact
<!-- What could this affect? Tenants, data, auth, availability, migrations? -->

## Testing evidence
<!-- How was this verified? CI results, manual test notes, screenshots. -->

## Rollback plan
<!-- Exact revert step: "revert this PR" or "redeploy image tag vX.Y.Z". -->

## Pre-merge checklist
- [ ] CI green (lint, SAST, SCA, tests)
- [ ] No secrets or credentials in the diff
- [ ] CODEOWNER review requested (author is not the approver)
- [ ] Docs / runbook updated if behavior changed

11. Document change history

Version	Date	Author	Description of change	Approved by
1.0	2026-05-25	Ron Benisty (CTO & CSO)	Initial version — establishes the Change Management Policy (PR-as-change-record, two-tier model).	Ron Benisty (CTO & CSO)