Change control, deployment discipline, and SDLC governance.
This chapter covers the controls that govern how systems are changed without creating new risk. ISC often tests this area by asking whether modifications were authorized, tested, documented, and moved into production in a controlled way.
Change-management questions should follow the change from request through approval, testing, migration, and monitoring. A technically correct change can still be a control failure if it bypasses segregation, evidence, rollback planning, or production safeguards.
| Change area | What to verify | Common ISC trap |
|---|---|---|
| Policies and procedures | Whether requests, approvals, documentation, and responsibilities are defined. | Treating informal approval as sufficient evidence. |
| Environment segregation and testing | Whether development, testing, and production are separated. | Letting developers move untested changes directly to production. |
| Patch management | Whether updates are prioritized, tested, deployed, and monitored. | Ignoring emergency-change documentation after urgent deployment. |
| CI/CD and DevOps | Whether automation still enforces authorization, testing, and rollback controls. | Assuming speed removes the need for change governance. |
| SDLC approaches | Which lifecycle model determines control points and documentation expectations. | Applying waterfall evidence expectations mechanically to Agile or DevOps facts. |
| Step | What to do | Why it matters on ISC |
|---|---|---|
| 1. Classify the change | Determine whether the change is routine, emergency, configuration-based, code-based, infrastructure-related, or vendor-driven. | Different change types require different approval and evidence expectations. |
| 2. Verify authorization | Check request documentation, business justification, risk assessment, and approval authority. | Unauthorized changes can undermine otherwise sound systems. |
| 3. Confirm testing and segregation | Review development, QA, staging, production separation, test results, and user acceptance evidence. | A change can be technically correct but still uncontrolled if testing or segregation is weak. |
| 4. Evaluate deployment safeguards | Consider migration controls, rollback plans, access restrictions, automated pipelines, and monitoring. | Deployment is where approved changes can become production risk. |
| 5. Retain evidence after release | Document emergency approvals, post-implementation review, defects, exceptions, and remediation. | Change control is not complete until the organization can show what changed and why it was safe. |
| Checkpoint | Exam use | What to avoid |
|---|---|---|
| Change type | Classify the change as routine, emergency, patch, configuration, code, infrastructure, or vendor driven. | Applying the same evidence expectations to every change without considering urgency and risk. |
| Approval evidence | Tie authorization to business purpose, risk assessment, approver authority, and segregation of duties. | Treating informal verbal approval as enough support for a production change. |
| Test environment | Confirm that development, QA, staging, and production are separated when the facts require segregation. | Letting the same person build, test, approve, and deploy without compensating controls. |
| Release safeguards | Check migration controls, rollback plans, monitoring, access restrictions, and automated pipeline controls. | Assuming automation is controlled merely because it is repeatable. |
| Post-release review | Retain evidence of deployment results, emergency approvals, defects, exceptions, and remediation. | Closing the change ticket before confirming what actually changed in production. |