In English, as in German, "change management" names two disciplines that have nothing to do with one another. This entry is not about organisational change management, the practice of carrying people through a restructuring. It is about change control in IT, carried in IT service management as change control or change enablement and popularised by ITIL. If you came looking for phase models and change curves, you want the other term. If you want to know how a firewall rule gets assessed and approved, you are in the right place.
Why changes are a security topic
A substantial share of outages and misconfigurations does not come from attacks. It comes from intended changes with unintended side effects: a rule opened for a migration that stays open; a test account that travels into production; an update that switches logging off.
Change management addresses exactly that. It requires that somebody ask the impact question before implementation, that approval come from a person other than the implementer, and that afterwards it is traceable who changed what and when. For financial entities the link between a change and a risk assessment is expressly regulated. Under Article 8(3) of Regulation (EU) 2022/2554 (DORA), financial entities other than microenterprises carry out a risk assessment upon each major change to the network and information system infrastructure, or to the processes or procedures, affecting their ICT-supported business functions or assets. Article 8(6) attaches to the same trigger the duty to update the inventories. For that sector the chain change → risk assessment → inventory is no longer good practice; it is text.
The flow
- Request: what is to change, why, and which systems are affected?
- Assessment: business impact, security impact, fallback plan, testing needs.
- Approval: by the accountable role or a board, depending on risk and reach. In IT service management that board is the Change Advisory Board (CAB); it advises and recommends, while the decision stays with the named approving role.
- Test: in an environment that resembles production closely enough.
- Implementation: inside the planned window, with a defined rollback point.
- Follow-up: outcome, deviations from plan, updates to documentation and inventory.
Types of change
| Type | Characteristic | Security requirement |
|---|---|---|
| Standard change | Recurring, low risk, pre-approved procedure | Procedure assessed once and reviewed periodically |
| Normal change | Individual case with assessment and approval | Full security assessment before implementation |
| Emergency change | To avert imminent damage | Shortened approval, but full retrospective documentation and assessment |
The list of standard changes is the single most effective lever for acceptance: it frees everyday work from formality and directs attention to the changes where it is needed. For that it has to be maintained: a procedure approved once and altered since is no longer a standard change.
Freeze windows
Beside the question of whether a change is approved sits the question of when it may be implemented. Defined freeze windows (a change freeze) in which only emergency changes are permitted are common practice: around period-end and quarter-end dates, in the business's peak-load periods, during an audit or a migration, and around stretches when staffing is thin.
Two things decide whether a freeze holds. It has to be known in advance, so that work is planned around it rather than running into it. And it needs a defined exception route, or it will be circumvented through the emergency path, and the share of emergency changes rises for a reason that has nothing to do with the threat picture.
The security questions inside a change
A small, always identical set of questions should be answered before approval. Does the change alter access rights, network boundaries or encryption? Does it touch logging or monitoring? Are new external connections or third-party components being added? Will the system process different or additional data from now on? Is there a tested fallback plan? Do the protection needs change?
Carry those questions in the request form and you need no separate security procedure alongside the change process. That is worth stating plainly, because a parallel security review is the usual reason teams route work around the process rather than through it.
Emergency changes
The emergency path is necessary and is the one most often overstretched. Two rules keep it in bounds: retrospective documentation and assessment are mandatory and are tracked, and the share of emergency changes in all changes is reported as a metric. A high share points to a routine path that is too heavy, not to an unusually eventful period.
Telling it apart from the neighbouring disciplines
| Term | Relationship to change management |
|---|---|
| Patch management | a special case with its own trigger and its own deadlines by severity; usually runs as a pre-approved standard change |
| Configuration management | supplies the basis: without a known current state, the impact of a change cannot be determined |
| Release and deployment management | governs bundling and delivery; the approval decision stays with the change |
| Organisational change management | the same English words, a different profession: people and acceptance rather than systems and approvals |
Where the record comes from
What makes the whole thing demonstrable is the change record: request, assessment, approval, test result, time of implementation, person who carried it out.
Where deployment runs through an automated pipeline, the pipeline is usually the better record, because approvals, test results and deployment times are captured as a by-product of the work rather than typed into a form afterwards. What auditors then look for is the same thing in a different place: that approval and execution are separated, and that the record cannot be edited after the fact.
In an audit, a sample drawn from change records is one of the most productive there is, above all when it is reconciled against the systems that actually changed.
What a change pulls with it in Rizzqo
The uncomfortable changes are not the ones that go wrong but the ones that shift the protection need without anyone noticing. A system moves to the cloud, a service picks up an extra job, an application starts processing personal data. The duties change with it; the documentation does not.
In Rizzqo the duty list hangs on the object's classification, not on a document. Reclassify an asset and the newly applicable requirements are added while no-longer-applicable ones fall away; manually created attachments are preserved. Change the link to a primary asset and the inherited protection need changes too. What Rizzqo contributes is the knock-on effect on requirements that otherwise nobody follows up.