Technology and Security · Topic 2 of 7
Operations Management (Change, Assets, DevOps, Problems, Incidents)
CRISC IT operations risk: change enablement and change types, configuration and IT assets, DevOps and CI/CD, incident versus problem management, ITIL 4.
- 4 min
- ITIL 4 change types: standard (pre-authorized), normal, emergency.
- Emergency changes need after-the-fact documentation and review.
- Incident management restores service; problem management removes root causes.
What it is
IT operations management is how technology is run day to day: changes are made, assets and configurations are tracked, services are monitored, and incidents and problems are handled. Many real losses come from operations, such as a badly tested change or an incident that is fixed but never investigated.
ITIL 4 is the most common reference for these practices. The risk practitioner does not run operations but checks that these practices exist, operate and produce evidence.
How it works
Change management
ITIL 4 calls this practice change enablement. Its purpose is to maximize successful changes by assessing risk, authorizing changes and managing the schedule.
| Change type | Description | Control |
|---|---|---|
| Standard | Low risk, pre-authorized, repeatable | Follows an approved procedure; no individual approval |
| Normal | Needs assessment and authorization | Approved by the right change authority according to risk |
| Emergency | Must be implemented urgently, such as a security fix | Expedited approval, documented and reviewed after the fact |
Key controls include segregation between developers and production, testing before release, approval by an authority matched to the risk, a back-out plan, and post-implementation review. Unauthorized changes, detected by comparing production with approved change records, are a strong KRI.
Configuration and IT asset management
Service configuration management keeps information about configuration items and their relationships, usually in a CMDB. IT asset management tracks the financial and lifecycle side: purchase, licences, support and disposal. Together they let teams see the impact of a change and find affected systems quickly when a vulnerability is announced.
DevOps and CI/CD
DevOps combines development and operations to deliver changes quickly and often. A continuous integration and continuous delivery (CI/CD) pipeline automates building, testing and deploying code. DevSecOps builds security checks into that pipeline.
| Traditional control | DevOps equivalent |
|---|---|
| Manual change approval board | Automated checks and peer review in the pipeline, with approval rules by risk |
| Separate test team | Automated unit, security and integration tests |
| Separation of developers from production | Pipeline deploys; developers do not change production directly |
| Change record | Pipeline logs and version control history |
The risk is not speed itself but missing controls. The practitioner checks that the pipeline enforces review, testing and segregation, and that pipeline settings are themselves change controlled.
Incident and problem management
| Incident management | Problem management | |
|---|---|---|
| Goal | Restore normal service as quickly as possible | Find and remove the root cause of incidents |
| Timing | During the disruption | During and after, often across many incidents |
| Output | Service restored, workaround | Known error, permanent fix |
An organization that only fixes incidents will see the same incidents again. Problem management, with root cause analysis, reduces recurring risk. Security incidents follow the same principle with an added focus on containment, evidence and notification.
Other operational controls
Capacity and performance management, job scheduling, backup and restore, logging and monitoring, patch management and service level management all carry risk. Each should have an owner, procedures and metrics such as backup success rate and patch compliance.
A worked example
An online retailer suffers three checkout outages in two months. Each time, the service desk restarts the payment service and closes the incident.
The practitioner reviews the records and finds no problem record was ever raised. Problem management is started, and root cause analysis links all three outages to a database connection limit changed during an emergency change that was never reviewed afterwards. The limit is corrected through a normal change, post-implementation review is enforced for emergency changes, and the number of emergency changes without review becomes a KRI.
How the exam asks about this
- "What is the GREATEST risk of emergency changes?" Bypassing normal testing and approval, so they must be documented and reviewed afterwards.
- "Which is the BEST way to detect unauthorized changes?" Compare production configurations or deployments with approved change records.
- "Recurring incidents have the same symptoms. What should be done FIRST?" Raise a problem record and perform root cause analysis.
What to remember for the exam
- ITIL 4 change types: standard (pre-authorized), normal, emergency.
- Emergency changes need after-the-fact documentation and review.
- Incident management restores service; problem management removes root causes.
- DevOps needs the same control objectives, delivered through the pipeline.
- The CMDB supports impact analysis and fast vulnerability response.
Speed is not the risk in DevOps; uncontrolled change is. The BEST answer keeps review, testing and segregation inside the automated pipeline rather than banning DevOps.
Common mistakes
Closing recurring incidents without root cause work. The same failure returns.
Letting emergency changes skip review forever. They become a back door around change control.
Assuming automation removes the need for segregation. Pipeline permissions must still separate who writes code from who can deploy unreviewed code.
Check yourself
What is the difference between incident and problem management?
Incident management restores service quickly; problem management finds and removes the root cause so incidents do not recur.
What controls should apply to emergency changes?
Expedited approval by an authorized person, documentation, and a post-implementation review to confirm the change was appropriate.
How can DevOps meet change control objectives?
By enforcing peer review, automated testing, approval rules and segregation in the CI/CD pipeline, with logs serving as change records.
Topic 2 of 7 in Technology and Security
Test yourself on Technology and Security
The full ISACA CRISC question bank has 1,000 questions, with timed practice exams and an explanation for every answer.
This study guide is independent and is not affiliated with, endorsed by, or sponsored by ISACA. Vendor names, certification names and exam codes are trademarks of their respective owners and are used for identification only.