How do we decide which changes to systems need approval, and handle emergency changes, under ISO 27001?

Start

A live system is about to change, and the change must be controlled

Change management makes changes deliberate: assessed, approved, tested and reversible. The auditor samples changes from request to approval, test and release, and asks for the emergency changes that were never approved afterwards. The decision is how much control each kind of change needs.

• Then: Can anyone change production outside the recorded route?

Decision

Can anyone change production outside the recorded route?

A console change, a direct database edit or a supplier pushing an update with no record is a change the sample will not find. Check every way a change can reach production: tickets, pull requests, consoles, vendor updates and patches. If you have not checked, answer yes.

• No: Sort changes into standard, normal and emergency
• Yes, or not known: Close the side routes, or record those changes after the event

Step

Close the side routes, or record those changes after the event

Remove standing rights that bypass the route. Where a side route must stay, such as a break-glass account, record every use and review it afterwards. The pack treats emergency use of such accounts the same way.

• Then: Sort changes into standard, normal and emergency

Step

Sort changes into standard, normal and emergency

A standard change is a repeat of a known low-risk type, approved once in advance. A normal change is assessed and approved each time. An emergency change must go now to stop harm and is reviewed after the event. Three kinds are enough for most teams.

• Then: Is it a repeat of a pre-approved type, such as the monthly patch?

Decision

Is it a repeat of a pre-approved type, such as the monthly patch?

The monthly patch cycle is the pack's model of a standard change: one approval for the cycle, run through rings with a rollback plan. If the change is new or differs from the approved type, answer no.

• Yes: Run it under the standing approval and keep the cycle record
• No, or not known: Assess impact and risk, including security, and plan test and rollback

Step

Run it under the standing approval and keep the cycle record

Keep the approval for the type, the calendar and the result for each run. Review the list of standard types on a schedule you set (this is the flow's advice, not a pack rule), so a type that has become risky does not stay pre-approved.

• Then: Do suppliers change services you depend on without asking you?

Step

Assess impact and risk, including security, and plan test and rollback

Say what the change touches, who is affected, what could go wrong, how it will be tested and how it will be undone. Include a security view: new access, new data flows, changed logging. Scale the depth to the risk of the system.

• Then: Must it go now to stop harm that is already spreading?

Decision

Must it go now to stop harm that is already spreading?

Emergency means harm is happening or imminent, such as an exploited flaw. A deadline or a launch is not an emergency. If you cannot say what harm waiting would allow, treat it as a normal change.

• Yes: Approve first if you can, otherwise within a working day
• No, or not known: Is the approver someone other than the person making the change?

Step

Approve first if you can, otherwise within a working day

The pack's emergency patch procedure approves the change before the mitigation starts, unless waiting would let harm spread; then approval follows within 1 working day. The approver is never the person who deploys it.

• Then: Test, release, check it worked and roll back if it did not

Decision

Is the approver someone other than the person making the change?

Approval by the author is a self-check. Where there are only a few people, another person can still approve, or a peer review can stand in. If the only approver is the author, answer no.

• Yes: Test, release, check it worked and roll back if it did not
• No: Find another approver, or add an independent review after release

Step

Find another approver, or add an independent review after release

Name a second approver for each system, even if from another team. Where none exists, record an independent review of the change after release and treat it as a compensating control.

• Then: Test, release, check it worked and roll back if it did not

Step

Test, release, check it worked and roll back if it did not

Run the test you planned, release in the planned window and confirm the result. If it fails, use the rollback you planned and record that. A change with no way back needs an approver who knows that.

• Then: Record the request, approver, tests and outcome in one place

Step

Record the request, approver, tests and outcome in one place

The record is the evidence: who asked, what changed, who approved, what was tested and what happened. Pull requests and deployment logs count if they hold those fields and can be retrieved for the audit period.

• Then: Has an emergency change been made since you last reviewed them?

Decision

Has an emergency change been made since you last reviewed them?

Review every emergency change after the event: why it could not wait, who approved it and when. Also count them each quarter. A rising number points to a capacity or planning problem, and emergency changes used as the normal route are a mistake the Library names. If you have not reviewed them, answer yes.

• Yes, or not known: Review each one afterwards, confirm approval and fix the cause
• No: Do suppliers change services you depend on without asking you?

Step

Review each one afterwards, confirm approval and fix the cause

For each emergency change, record why it could not wait, who approved it and whether it was approved after the event. Then deal with the cause: planning, capacity or a missing standard type.

• Then: Do suppliers change services you depend on without asking you?

Decision

Do suppliers change services you depend on without asking you?

Software-as-a-service providers change features, models and settings. The pack treats a provider's change of model as a trigger for review within a set time of the notice. If your contract has no notice term, answer yes.

• Yes, or not known: Agree notice terms and treat their notice as a change to assess
• No: Trace a sample of changes from request to release

Step

Agree notice terms and treat their notice as a change to assess

Ask for advance notice of changes that affect security, data location or access, and write it into the contract. When a notice arrives, run it through your assessment like any other change.

• Then: Trace a sample of changes from request to release

Step

Trace a sample of changes from request to release

Take a handful from the last quarter, including at least one emergency change. For each, find the request, the approval, the test and the release. The auditor samples them the same way.

• Then: Did the sample find a change with no approval or no record?

Decision

Did the sample find a change with no approval or no record?

Any gap shows the route is not yet reliable. Emergency changes that were never approved after the event are the pack's named challenge. If you did not sample, answer yes.

• Yes, or not known: Fix the route, record what was missed, then sample again
• No: Change control decided, followed and sampled

Step

Fix the route, record what was missed, then sample again

Close the gap that let the change through, add the missing record and take a fresh sample. Repeat until a sample passes.

• Then: Trace a sample of changes from request to release (back to an earlier step)

Outcome

Change control decided, followed and sampled

Keep the change procedure, the list of standard types and the sample result. Do not say all changes are approved if the sample did not include emergencies, and do not describe a pull request as a change record unless it carries the approval and test.