Change Management Policy

This policy establishes the controls for system, infrastructure, and process changes at Tanqory to ensure safety, predictability, and auditability. The English version is authoritative; if any translation conflicts arise, the English governs.

1) Purpose and Scope

This policy is designed to prevent availability, security, and legal/contract risks from uncontrolled changes by requiring clear approval paths and tested rollback plans. It preserves stability across all environments (Production, Staging, Test) and protects critical transaction, customer, and merchant data. It defines roles, responsibilities, and Segregation of Duties (SoD) between requester, approver, and implementer. Coverage includes applications (Platform, APIs, Mobile), infrastructure (Cloud, Network, Database), security systems (IAM, WAF, secrets management), data (schema/ETL/analytics), and configuration/feature flags. It applies to employees, engineering/operations/security/data/infrastructure teams, and authorized suppliers. It links to Backup/DR, BCP, Access Control Policy, and the Incident Response Plan (IRP). Review at least annually or after major incidents; while focused on Production, apply similar rigor in Staging/Test (with possible approval relaxations but complete evidence).

2) Governance & Roles

Change Owner manages the RFC (Request for Change), prepares details, test plan, and rollback plan, and seeks approval. Change Approver (Team Lead/Service Owner/delegated executive) approves based on risk and impact. CAB (Change Advisory Board) reviews Normal/Major changes with engineering, security, ops, QA, and business representation. ECAB (Emergency CAB) of at least 2 (e.g., Eng Lead + Security Lead or CTO/CISO) approves emergency changes. Implementer executes deploy/config and should be separate from the primary approver for higher-risk changes to preserve SoD. Release Manager coordinates the change calendar, freeze windows, and communications. Comms Lead prepares customer/status notifications (Status Page) per SLA. Audit/Compliance reviews approval/test evidence and retains records for at least 3–5 years or longer per law/contract.

3) Change Classification

• Standard Change: Low risk, repeatable, pre-approved (e.g., content updates/SSL renewal/routine patches with runbook).
• Normal Change: Medium risk; RFC/test/rollback required; CAB approval before execution.
• Major Change: High/ broad impact; requires impact analysis, cutover plan, DR readiness, and executive approval.
• Emergency Change: For crises (P1 incident, zero-day, outage); ECAB approves urgently; must record and do a Post Implementation Review (PIR) within 48 hours.
• Security-Sensitive Change: Any change affecting IAM, encryption, network boundary, payments/PII requires Security Lead approval regardless of type.
• Data/Schema Change: Requires backup/restore/replication checks, staging migration test, and RPO/RTO verification before Production.
• Third-party/Integration Change: Check contracts/regulations (PCI/PDPA/GDPR) and have integration-specific rollback/feature flag.

4) Risk & Approval Criteria

• Assess impact on availability, confidentiality, integrity, compliance, and revenue/customer obligations.
• Mandatory RFC form: change details, affected systems, risks, test plan, rollback plan, change window, communications, approvers.
• Approvals must use traceable channels (change ticketing with time/approver logs); no verbal/unlogged approvals.
• If personal data/financial data is affected, include Legal/Privacy/Compliance review.
• Change freezes during peak business or crises require Release Manager/CAB approval to override.
• Emergency changes must log rationale, risk, mitigations, and be endorsed by ECAB (≥2) before execution.

5) Change Workflow

• Minimum steps: create RFC → impact/risk assessment → approval (CAB/ECAB per type) → schedule → test/package → execute → monitor/verify → close with evidence/lessons learned.
• Every step requires evidence (ticket/repo/log/approval/test results/monitoring screenshots) for audit.
• Pre-Prod testing: Staging/Test with synthetic data; QA/automation required according to risk.
• Rollback plan must be tested in prior environment and include clear stop/rollback criteria.
• After execution, monitor for at least the system SLA (e.g., 30–120 minutes) and verify health/logs/alerts.
• Close with PIR for Normal/Major/Emergency: outcomes, anomalies, actual downtime, improvement actions.

6) Scheduling & Communication

• Use a central Change Calendar showing test/deploy times, freezes, and conflicts.
• Select change windows with minimal customer impact and consistent with SLA/contracts.
• Internal comms: circulate tickets/notices to relevant teams (Eng/Ops/Security/Support/CS) with impact and rollback details.
• External comms (if customer impact): Status Page/email/in-app banner with advance notice per contract; for P1, set update SLA every 60–120 minutes until resolved.
• Provide on-call contacts for unexpected issues during change for immediate escalation.
• For regulated content (PCI/PDPA/GDPR, etc.), Comms Lead/Legal must review messages before release.

7) Testing & Quality

• Set test levels by risk: Unit/Integration/System/Performance/Security (SAST/DAST), key regression before Production.
• Infra/network changes: test in lab/staging, perform dry-runs for large changes, verify impact on monitoring/alerts/backup/replication.
• Take backups/snapshots before execution and confirm recovery within relevant RTO/RPO.
• Record test results and QA/Service Owner approvals in the RFC/ticket.
• Check for config drift post-change (e.g., IaC drift detection) and align baselines.

8) Segregation of Duties & Security

• Primary approver should not be the deployer for Normal/Major/Emergency unless a written exception is granted.
• Change privileges must be controlled via RBAC and MFA.
• Apply least privilege and just-in-time access for temporary change access.
• Log key activities (approvals, code/config changes, deployments, Production access).
• Security-sensitive changes require security review every time.
• Use secrets management (e.g., KMS/HSM); do not embed secrets in code/scripts; verify no exposure after change.

9) Emergency Changes

• Use for critical events: P1 incident, zero-day, outage with material service/security impact.
• Steps: create brief RFC/notify ECAB → approval by ≥2 (Eng Lead/Sec Lead/CTO/CISO) → execute/validate → monitor → PIR within 48 hours.
• Record rationale, risks, rollback, and results even under urgency.
• If personal/financial data is implicated, notify Legal/Privacy/Compliance immediately and consider statutory notification duties.
• Check for side effects and roll back if targets are not met or new impact emerges.

10) Documentation & Audit

• Retain RFCs, approvals, test results, deployment logs, monitoring evidence, PIRs in access-controlled storage.
• Retention: minimum 3–5 years or longer per legal/customer contract requirements.
• Periodic internal audits of policy adherence; remediate findings.
• KPIs/metrics: changes by type, success/failure rate, change-induced incidents, MTTR, adherence to change window.
• Report to leadership and use data to improve process/tooling.

11) Review & Updates

• Review at least annually, or after major events/lessons from PIR/incidents.
• Announce material changes to stakeholders and update Version History.
• If laws/industry requirements change, adjust approvals/testing/evidence promptly.
• Train staff on the policy and supporting tools for consistent execution.

Appendix A: Change Type Criteria (Sample)

Appendix B: Sample RFC (Abbreviated)

• Change name, date/time, requester, implementer, change type
• Affected systems/services, expected impact, risk assessment (C/I/A/Compliance)
• Execution plan, test plan, rollback plan (stop/rollback criteria)
• Change window, expected downtime, approvers/dates, internal/external comms plan

Appendix C: Glossary

• API (Application Programming Interface) Interface for system/service integration.
• RTO/RPO (Recovery Time/Point Objective) Maximum acceptable time/point to restore.
• SLA (Service Level Agreement) Service level commitment.
• SoD (Segregation of Duties) Separation of roles to reduce fraud/error risk.
• IAM (Identity and Access Management) Identity/authorization management.
• WAF (Web Application Firewall) Web application protection.
• CAB/ECAB (Change/Emergency Change Advisory Board) Boards for normal/emergency changes.
• PIR (Post Implementation Review) Post-change review.
• MTTR (Mean Time To Restore) Average time to restore service.
• IaC (Infrastructure as Code) Managing infrastructure via code.
• RBAC (Role-Based Access Control) Role-based access control.
• KMS/HSM (Key Management Service/Hardware Security Module) Encryption key management.

Appendix D: Version History