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:

• All Normal/Significant changes logged in CHANGE_LOG.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