CISSP - Security Operations - Section 7.9

Understand and participate in change management processes.

Describe the change management process including change requests, impact assessment, approval process, implementation, and rollback planning. Recognise how bypassing change control increases the risk of unintended security regressions in production environments.

change managementchange controlapproval processrollback

Practice question for this objective

Free sampleSecurity Operationseasy

During a scheduled change window, a database administrator applies an approved schema update to a production system. Twenty minutes after the change, the application team reports that a critical reporting feature is failing for end users and customer-facing dashboards are showing errors. The change ticket includes a tested rollback procedure. What is the BEST next action for the change owner?

AKeep the schema change in place and instruct the application team to develop a hotfix in their code so customer dashboards work again as soon as possible.
BPause and convene a full root-cause analysis meeting with all stakeholders before deciding whether the production change should be reversed or left running.
CExecute the approved rollback procedure to restore the previous known-good state, notify stakeholders, and schedule a post-implementation review of the failed change. Correct
DMark the change as successful in the change record because it deployed without technical errors and open a separate incident ticket for the reporting issue.

Recognise that invoking the pre-approved rollback to restore a known-good state is the correct response when a change causes production impact. A rollback plan is a mandatory element of any change record because production changes can fail in ways that testing did not surface. When user impact is observed within the change window, the change owner restores service by executing the rollback first and then drives investigation and re-planning through the post-implementation review.

Why A is wrong: Layering an emergency code fix on top of a failing change feels productive but extends customer impact, introduces an unreviewed change on top of another change, and bypasses the rollback that was already approved as part of the original request.

Why B is wrong: Root-cause analysis is essential after the incident is contained, but holding a meeting while customers are visibly impacted prolongs the outage; the rollback exists precisely so the service can be restored first and analysed afterwards.

Why C is correct: When an approved change causes a production impact, invoking the pre-approved rollback to return the system to a known-good state is the correct response; it restores service quickly and feeds the failure into a structured post-implementation review.

Why D is wrong: A change that breaks the business outcome it was meant to support has not succeeded, and recording it as such hides the real result; the linked incident must drive a rollback decision, not a paperwork tidy-up.

See more CISSP practice questions with worked answers.

More in this domain

Back to all Security Operations objectives, or the CISSP cert hub.

Examworthy is not affiliated with or endorsed by (ISC)2. Original, blueprint-aligned practice material only.