# Change Management Policy

**Touch2Sign Ltd**  
**Version:** 1.0  
**Effective date:** 11 July 2026  
**Owner:** Robert — Engineering Lead  
**Approved by:** Robert — CEO / Managing Director  
**Next review:** 11 July 2027

---

## 1. Purpose

Ensure that changes to Touch2Sign production systems are planned, approved, tested, documented, and reversible. Supports SOC 2 CC8 change management criteria and reduces outage and security risk.

## 2. Scope

Applies to changes affecting:

- Production application code and configuration (AWS App Runner)  
- Database schema and migrations (`docs/MIGRATIONS.md`)  
- AWS infrastructure (RDS, S3, Cognito, CloudFront, IAM)  
- Secrets Manager values and environment variables  
- DNS and TLS certificates  
- Third-party integration settings (Stripe, IDV providers)  

Excludes: routine auto-scaling within configured bounds; Dependabot patch merges following standard PR process (still logged via Git).

## 3. Change categories

| Category | Description | Approval | Lead time |
|----------|-------------|----------|-----------|
| **Standard** | Pre-approved low-risk changes (dependency patch, copy fix) | 1 engineer + PR review | Same day |
| **Normal** | Feature releases, schema migrations, config changes | Engineering Lead | 24 hours notice |
| **Significant** | Architecture change, new sub-processor integration, IAM policy overhaul | Engineering Lead + Security Lead | 5 business days |
| **Emergency** | Active incident remediation, Critical CVE patch | Incident Commander | Immediate — retrospective review within 24h |

## 4. Normal change process

1. **Request** — Create change ticket with description, risk, rollback plan, and test plan  
2. **Review** — Peer code review via PR; Security Lead review if security-sensitive  
3. **Test** — Staging verification; `docs/QA_SIGN_FLOW.md` for production-bound releases  
4. **Approve** — Engineering Lead approves in ticket  
5. **Schedule** — Deploy via `scripts/rebuild-dev.sh` (dev) or `scripts/deploy-prod.sh` (prod) in agreed window  
6. **Implement** — Execute deploy; monitor CloudWatch and error rates for **30 minutes**  
7. **Close** — Update change log; link PR and ticket  

## 5. Emergency change process

Used when delay would increase harm (active exploit, P1 outage, data exposure):

1. Incident Commander or Engineering Lead declares emergency change  
2. Implement minimum fix to contain or restore service  
3. Notify Security Lead as soon as practicable  
4. Monitor continuously until stable  
5. **Retrospective within 24 hours:** document timeline, approver, actions, and permanent fix plan  
6. Complete normal change documentation retroactively within **3 business days**  

## 6. Rollback requirements

Every normal and significant change must define rollback before production deploy:

| Change type | Rollback method |
|-------------|-----------------|
| Application deploy | Redeploy previous tagged release via `deploy-prod.sh` |
| Database migration | Reverse migration script or restore from pre-change snapshot |
| Config / feature flag | Revert config in Secrets Manager or feature flag off |
| IAM / security group | Revert to documented previous policy version |

Pre-change RDS snapshot required for schema migrations affecting core tables (`documents`, `audit_log`, `recipients`).

## 7. Change log

All production changes recorded in the **Change Log** (ticket system + spreadsheet):

| Field | Description |
|-------|-------------|
| Change ID | CHG-YYYY-NNN |
| Date/time (UTC) | Implementation time |
| Category | Standard / Normal / Significant / Emergency |
| Description | What changed |
| Requester | Name |
| Approver | Name |
| PR / commit | Link |
| QA reference | QA_SIGN_FLOW checklist ID |
| Rollback performed? | Y/N |
| Outcome | Success / Failed / Rolled back |
| Incident link | If related |

Retention: **3 years** minimum.

## 8. Separation of duties

**Standard team (when staff > 1):**

- Developer who wrote the change should not be sole approver for significant production changes  
- Production Secrets Manager write access limited to release managers  
- Database migration execution logged with executor identity  

**Solo operator (current — Robert):**

Independent approval is not feasible. Compensating controls per [SOLO_TEAM_OPERATING_MODEL.md](../SOLO_TEAM_OPERATING_MODEL.md):

- All Normal/Significant changes logged in [CHANGE_LOG.md](../CHANGE_LOG.md)  
- [RELEASE_COMPLIANCE_CHECKLIST.md](../RELEASE_COMPLIANCE_CHECKLIST.md) completed before production deploy  
- Automated lint, build, and platform QA smoke  
- Significant changes: 24-hour cooling period before production  
- Git history + CHANGELOG.md provide audit trail

## 9. Customer communication

Notify customers when changes:

- Alter sub-processor list (30 days per DPA)  
- Cause scheduled maintenance downtime > 15 minutes  
- Change signature level behaviour or audit trail format materially  

## 10. Related documents

- Secure Development Policy  
- Business Continuity & DR Plan  
- Vulnerability Management Policy  
- Incident Response Plan  
- MIGRATIONS.md  

## 11. Review

Reviewed **annually** and after change-related production incidents.

---

**Approval**

| Name | Role | Signature | Date |
|------|------|-----------|------|
| Robert | CEO / Engineering Lead | Electronic | 11 July 2026 |