Document Control
| Document ID | HL-ISMS-POL-08 |
|---|
| Document Title | Change Management Policy |
|---|
| Classification | Internal |
|---|
| Version | 2.0 |
|---|
| Status | Approved |
|---|
| Document Owner | Information Security Manager (ISM) |
|---|
| Approved by | Executive Management |
|---|
| Effective Date | 30.10.2026 |
|---|
| Next Review Date | Annually from effective date, or upon significant change |
|---|
| Applies to | Hamurlabs Elektronik Hizmetler Yazılım ve Ticaret A.Ş. (Istanbul, Türkiye) and Hamurlabs BV (Leuven, Belgium), together "Hamurlabs" |
|---|
1. Purpose and Scope
The objective of change management at Hamurlabs is to enable changes to be made with minimal or no disruption to the HaROS platform and to the services provided to customers, while keeping every change traceable, reviewed and reversible. This policy applies to changes to: production application code and configuration; cloud infrastructure (projects, networks, firewall rules, IAM, databases); corporate IT systems; and security controls. It applies to all personnel and to third parties implementing changes on behalf of Hamurlabs. The policy is owned by the ISM and approved by Executive Management.
2. Roles
| Change Requestor | Anyone raising a request for change (RFC) — via the ticketing/ITSM system or, for code, via a pull request. |
|---|
| Change Implementer | The engineer who builds, tests and deploys the change. |
|---|
| Change Approver | The engineering lead / CTO (or a designated senior engineer). For code changes, approval is given through mandatory peer review of the pull request. The implementer must not approve their own change wherever team size permits. |
|---|
| Emergency Approver | The engineering lead / CTO or, in their absence, the on-call senior engineer. |
|---|
3. Change Types
| Type | Definition | Approval required |
|---|
| Standard | Routine, low-risk, pre-authorised changes following a defined procedure — e.g. application deployments through the CI/CD pipeline with passing automated tests, dependency patch updates, scaling adjustments within approved limits. | Pre-authorised by this policy; peer review of the underlying code change still applies |
| Normal | Planned changes with potential service or security impact — schema migrations, infrastructure/network/firewall changes, IAM changes, new services, major releases. | Change Approver, before implementation; risk and rollback assessed in the RFC/PR |
| Emergency | Changes required immediately to resolve an incident or critical vulnerability. | Verbal/chat approval by Emergency Approver; full documentation and retrospective review within 2 business days |
4. Requirements for Every Change
- Traceability: every change is recorded — code changes through version control (commit, pull request) linked to a ticket where applicable; infrastructure and corporate-system changes through the ticketing/ITSM system.
- Review: code changes require peer review before merge to the production branch. Direct commits to production branches are disabled by branch protection.
- Testing: changes are tested in a non-production environment before production deployment, proportionate to risk; automated test suites must pass.
- Rollback: Normal and Emergency changes must have an identified rollback or recovery approach before deployment.
- Segregation: production deployment credentials are restricted per the User Access Control Policy; the reviewer must be different from the author wherever team size permits.
- Customer communication: changes expected to affect service availability or customer integrations are communicated to affected customers in accordance with the notice and maintenance-window commitments in the applicable customer contracts and SLAs.
- Security review: changes affecting authentication, authorisation, encryption, network exposure or personal data processing require explicit consideration of security and data protection impact in the review; significant changes to personal data processing trigger an assessment under the GDPR/KVKK compliance framework (e.g. DPIA screening).
- Post-implementation: failed or reverted changes are reviewed; recurring failures feed the continuous improvement of this process.
← All policies