Change management policy

1. Purpose

This policy establishes mandatory requirements for planning, authorising, testing, implementing, and reviewing changes to HLD Group production systems, infrastructure, applications, and supporting services. Its purpose is to ensure that changes are made in a controlled and predictable manner that protects the confidentiality, integrity, and availability of information and services.

Uncontrolled change is one of the most common root causes of outages, security incidents, and data loss. This policy exists to reduce the likelihood and impact of change-induced failures, to preserve an auditable record of who changed what and why, and to satisfy the change management commitments we make to customers and to our certification bodies.

2. Scope

This policy applies to all personnel, contractors, and third parties who request, approve, implement, or review changes to systems within HLD Group’s control, and to all environments that host or support production services.

• Application code, configuration, and feature flags affecting production behaviour
• Cloud infrastructure, networking, and infrastructure-as-code definitions
• Databases, schemas, and data migrations
• Identity, access, and security control configurations
• Third-party and SaaS integrations that process or transmit company or customer data
• CI/CD pipelines, build systems, and deployment tooling
• Customer environments operated by HLD Group under a managed service agreement, subject to any stricter customer change process

3. Definitions

• Change — any addition, modification, or removal that could affect a production service or its security posture
• Standard change — a pre-authorised, low-risk, repeatable change performed under an approved runbook
• Normal change — a change requiring assessment and approval before implementation
• Emergency change — a change that must be implemented rapidly to restore service or contain a security incident
• Change Advisory Board (CAB) — the body or delegated approvers who authorise normal and review emergency changes
• Rollback — the pre-planned procedure to return a system to its last known good state
• Freeze — a defined period during which only emergency changes are permitted

4. Policy statement

All changes to systems in scope must be requested, risk-assessed, authorised, tested, documented, and reviewed in accordance with this policy. No change may be applied to production without an approved change record and a documented rollback plan, other than an emergency change made under section 9, which is authorised and reviewed retrospectively.

Change management is not a bureaucratic gate for its own sake. Controls are proportionate to risk: low-risk repeatable work flows through lightweight pre-authorised paths, while high-risk change receives commensurate scrutiny.

5. Change categories and authorisation

6. Change lifecycle

• Request — raise a ticket describing the change, its purpose, affected systems, and the requester
• Assess — evaluate risk, security impact, customer impact, dependencies, and effort
• Plan — document the implementation steps, test plan, rollback plan, and communication plan
• Review — obtain peer review of code and infrastructure-as-code, and independent approval proportionate to risk
• Test — validate in a non-production environment with automated and, where relevant, manual checks
• Approve — obtain the authorisation required for the change category
• Implement — apply the change within an approved window, following the documented steps
• Verify — confirm success against defined acceptance criteria and monitor for regression
• Close — record the outcome, and trigger a post-implementation review for failed or emergency changes

7. Environment separation and segregation of duties

Development, staging, and production are maintained as separate environments with distinct credentials and data. Production data is not copied to lower environments unless masked or synthesised. This gives effect to the segregation of duties expected under SOC 2 CC8.1, ISO/IEC 27001:2022 Annex A control 8.31, and SOX IT general controls.

• Developers do not deploy to production without secondary approval or an automated pipeline gate that enforces review
• Production database changes require a database administrator or delegated reviewer independent of the requester
• The person who authors a change does not solely approve their own change into production
• Privileged pipeline credentials are held by the pipeline, not by individuals, and are rotated and audited

8. Testing and quality gates

• Automated continuous integration checks — linting, unit tests, dependency and secret scanning, and security static analysis — must pass before merge
• Test evidence is attached to or linked from the change record
• Schema and data migrations are tested against a representative dataset and are reversible or forward-fixed by design
• Material customer-impacting changes are validated in staging that mirrors production configuration
• Feature flags are used to decouple deployment from release where practicable, enabling controlled rollout and rapid disablement

9. Emergency change and expedited response

When a service is degraded or failed, or a security incident is active, the on-call engineer may implement an emergency change with authorisation from the on-call approver. Safety controls are never bypassed silently: the change is logged in real time to the extent possible, and a complete change record, including cause, action taken, and validation, is produced within 48 hours and reviewed by the CAB.

Emergency changes that touch security controls, access, or customer data are additionally reviewed by the Chief Information Security Officer or delegate.

10. Change freezes and communication

Change freezes may be declared around periods of elevated risk or reduced staffing, such as major customer events, end-of-period processing, or holidays. During a freeze only emergency changes are permitted.

Material customer-impacting changes are communicated in advance through the agreed customer channels, and maintenance windows are scheduled to minimise disruption and honour contractual notice periods.

11. Documentation, evidence, and records

• Every change is ticketed with description, risk assessment, approver, test evidence, and rollback plan
• Change records are retained for a minimum of 24 months, or longer where a customer contract or legal hold requires
• Approvals are captured in a system that provides an immutable audit trail
• Failed and emergency changes trigger a documented post-implementation review
• Change records are made available to auditors and, on reasonable request under contract, to customers

12. Framework alignment

• SOC 2 Trust Services Criteria CC8.1 (change management)
• ISO/IEC 27001:2022 Annex A controls 8.31 (separation of environments) and 8.32 (change management)
• NIST SP 800-53 Rev. 5 control family CM (Configuration Management), notably CM-3, CM-4, and CM-5
• SOX IT general controls for change management and segregation of duties
• ITIL 4 change enablement practice

13. Roles and responsibilities

14. Exceptions

Exceptions to this policy require documented approval from the CISO or delegate, a business justification, a risk assessment, compensating controls, and an expiry date. Exceptions are logged and reviewed at least quarterly.

15. Enforcement

Deploying to production outside this policy is a serious breach that may result in revocation of deployment privileges and disciplinary action up to termination, and contractual remedies for third parties. Repeated unauthorised change is escalated to leadership.

16. Review

This policy is reviewed at least annually and after any significant change-induced incident, technology change, or change in certification scope. Version history is maintained in the compliance repository.