A.8.32 Change Management
Control Objective
Changes to information processing facilities and information systems shall be subject to change management procedures.
Policy Statement
anDREa enforces a comprehensive, formal Change Management policy across its corporate frameworks, business processes, and cloud-native application architectures. This framework ensures that all modifications are systematically requested, evaluated for security and operational impact, formally approved, transparently communicated to stakeholders, and paired with verifiable fallback mechanisms to guarantee platform stability and continuity.
1. Scope of Change Management
Change management procedures are strictly partitioned by operational discipline:
- Information Security Management System (ISMS) Changes: Modifications to organizational security policies, core control definitions, or risk frameworks follow the strict planning procedures detailed within Clause 6.3 - Planning of Changes.
- Corporate & Business Process Changes: Operational workflow adjustments are evaluated jointly by Asset Owners (AO), Internal Control (IC), and People & Culture (P&C) via formal Management Decisions.
- Core Platform Changes (myDRE Environment): Technical code or deployment alterations follow structured engineering loops divided by source.
2. Platform Changes Requested by Customers
When a tenant or research user requests a platform expansion or out-of-SLA technical feature, the request progresses through an end-to-end audited pipeline:
[Customer Request via Ticket] ➔ [Triage to Innovation Lab] ➔ [SIA & Security Triage] ➔ [PBI Backlog Creation] ➔ [Sprint Planning & CI/CD]
- Intake & Submission: The local Research Support Team (RST) or user submits a request via the Zoho ticketing system. Initial refinement is discussed during bi-weekly support meetings.
- Innovation Lab Triage: Based on priority, scalability, and broad platform utility, the ticket is moved into the specialized Innovation Lab department queue within Zoho.
- Impact & Security Assessment: The Support & Assurance Team evaluates the request against specific vectors: Confidentiality, Integrity, Availability, Auditability, systemic risk to other Workspaces/the Core, financial costs, and structural architectural impact. Technical evaluations are logged following the Security Tasks Manual.
- PBI Generation & Traceability: If approved, a formal Product Backlog Item (PBI) is created within Azure DevOps. The PBI is permanently linked back to the original Zoho ticket to maintain end-to-end auditability.
- Sprint Ritual Integration: Implementation progress, resource allocation, and prioritization are tracked daily via standard Scrum rituals (Standups and monthly Sprint Reviews). If a request fails evaluation, it is formally denied or pushed back for requirement redefinition within Zoho.
3. Engineering & Internal Development Change Cycles
For changes originating internally during standard development, the engineering team operates strictly within the Scrum framework governed by A.05.37 - Documented operating procedures and A.05.25 - Assessment and decision on information security events:
- Case-by-Case Triage: Structural shifts in a PBI are evaluated dynamically with the Scrum Master and Operations Manager to detect downstream architectural dependencies.
- Risk Auditing & SIAs: Before executing a major change, a formal risk assessment must be performed under Clause 6 methodologies, and a completed SIA Instructions must be active.
- Supply Chain Interlocks: If a change requires the acquisition or replacement of a critical third-party software application or ICT utility, operations teams must complete the comprehensive supplier requirements framework defined under A.05.19 - Information security in supplier relationships.
- Branch Promotion Guardrails: Code promotion must strictly mirror the DTAP starting points outlined in A.05.25 - Assessment and decision on information security events, leveraging automated SonarCloud quality gates and mandatory architecture approvals prior to production deployment.
4. Technical Rollback and Recovery Procedures
To preserve infrastructure availability during an unexpected post-deployment failure, anDREa maintains deterministic, automated rollback strategies:
Application Layer Rollbacks
- Pipeline Reversion: If an application update degrades production environment stability, engineers refer to the Azure DevOps Pipelines engine to locate the $N-1$ successful pipeline run (where $N$ is the failed deployment build).
- Execution: Re-triggering the $N-1$ pipeline automatically deploys the last-known stable application state, overwriting the defective build.
Database Layer Rollbacks
- State Backups: Every structured SQL database update automatically initiates an uncompressed snapshot compile (.bacpac file) exported directly to secure Azure Blob Storage within the isolated myDRE System Subscription.
- Execution: In the event of a database update fault, operations teams pull the corresponding point-in-time snapshot from the Azure Blob repository and execute an absolute database restoration.
5. Customer Coordination and Release Management
To minimize research disruption and maintain transparency, platform changes are coordinated with the customer base using target-group isolation:
-
Audience Mapping: Prior to compilation rollouts, the technical release team identifies the exact scope of affected users (e.g., all global tenants, specific regions, or users leveraging specialized optional components like Azure Bastion).
-
Communication Matrix:
-
Standard Releases: Release notes are transparently integrated into the myDRE Feature Release and Roadmap log and immediately highlighted to active users via the Announcements feature inside the live myDRE portal.
-
Impactful / Breaking Changes: Local RST members and organizational Accountables must be notified at least 10 business days in advance via direct email channels or within scheduled Research Support sessions. For high-impact shifts, RST members are integrated directly into the staging/acceptance validation loop.
-
Emergency Security Patches: Executed immediately upon availability according to the timelines enforced by the A.08.08 - Management of technical vulnerabilities. Users are notified instantly post-deployment if manual configuration or endpoint actions are required.
-
Distribution Mechanics: myDRE updates are automatically pushed across the multi-tenant subscription fabric without requiring manual intervention from local administrators. Base VM Operating System updates are pulled seamlessly via native Microsoft Azure update infrastructure during off-peak windows defined in the Service Level Agreement.
6. Administration & Reference Registries
| Document / Asset Repository | Operational Purpose | Access Control |
|---|---|---|
| Zoho Ticketing Console | Inception logging, customer triage, and feature request histories. | Authorized Personnel Only |
| Azure DevOps Boards | Live PBI tracking, sprint metrics, and linked code repository hooks. | Authorized Personnel Only |
| Security Impact Assessments | Formalized risk, data protection, and architecture reviews for major changes. | Authorized Personnel Only |
| myDRE Feature Release & Roadmap | Public ledger of planned, active, and completed platform updates. | Public |
| Azure Blob System Storage | Backup node hosting emergency database (.bacpac) reversion files. | Authorized Operations Personnel |