IT Operations and Service Management

IT Operations and Service Management (ITSM) is the umbrella term for everything involved in delivering and supporting IT services that meet the needs of the business. Think of it as the playbook that IT teams follow every day, from handling a password reset to rolling out a critical security patch across thousands of computers.

The most widely used framework for ITSM is the Information Technology Infrastructure Library (ITIL). ITIL provides a set of best practices organised around the service lifecycle: service strategy, service design, service transition, service operation, and continual service improvement. For the CISA exam, the key focus is on service operation because that is where the day-to-day controls live.

A core concept in ITSM is the "service desk." This is the single point of contact between users and IT. When an employee cannot access their email, they call or log a ticket with the service desk. The service desk categorises the issue, assigns a priority, and either resolves it directly or escalates it to a specialist team. The service desk is also responsible for communicating status updates to the user and documenting the resolution.

Another critical element is incident management. An incident is any unplanned interruption to an IT service or a reduction in its quality. For example, if a company's website goes down, that is a major incident. Incident management is the process of restoring normal service as quickly as possible and minimising the impact on the business. This process has a clear set of steps: detection, logging, categorisation, prioritisation, investigation, diagnosis, resolution, and closure.

Problem management is closely related but distinct. While incident management focuses on fixing the immediate symptom, problem management seeks to identify and eliminate the root cause. For instance, if the same server crashes every Tuesday at 10 a.m., that is a problem. The problem management team would analyse logs, identify the cause (e.g., a scheduled backup that saturates the disk), and implement a permanent fix (e.g., change the backup schedule).

Change management ensures that changes to IT systems are made in a controlled and authorised way. Every change, whether it is a minor configuration tweak or a major system upgrade, must go through a defined process. This includes submitting a change request, assessing the risk and impact, obtaining approval from a change advisory board (CAB), testing the change, and scheduling it during an approved maintenance window. After implementation, the change is reviewed to ensure it achieved its objectives without causing issues.

Configuration management is the process of identifying, controlling, tracking, and reporting on all the IT assets and their relationships. These assets are called configuration items (CIs). A CI could be a server, a network switch, a software licence, or even a document. The information about all CIs and their relationships is stored in a configuration management database (CMDB). For an auditor, the CMDB is a goldmine because it provides a single source of truth about what the organisation has and how it is connected.

Release management governs the deployment of new or changed software and hardware into the live environment. It ensures that releases are packaged correctly, tested thoroughly, and rolled out in a planned manner. A release might be a collection of several changes bundled together. Release management also covers back-out plans in case something goes wrong during deployment.

Finally, service level management is the process of agreeing on, documenting, and managing the level of service that the IT organisation provides. This is done through service level agreements (SLAs) which specify metrics like uptime percentage (e.g., 99.9% availability) and response times (e.g., critical incidents resolved within 4 hours). Service level management includes monitoring performance against SLAs, reporting on compliance, and taking corrective action when targets are missed.

For the CISA exam, you need to understand these processes not as isolated functions but as an integrated system of controls. An IS auditor evaluates whether these processes: exist (are they documented?), are followed (are people adhering to them?), and are effective (do they achieve their objectives?). The auditor will look for evidence such as change logs, incident reports, SLA dashboards, and CMDB reports. The key risks if ITSM is weak include prolonged service outages, unauthorised changes causing security vulnerabilities, and inability to recover from disasters.

An IT audit professional would typically review IT operations by examining a specific incident lifecycle. Here is a step-by-step walkthrough of how that audit might proceed.

The auditor begins by requesting a list of all incidents logged in the last month. They sample 20 incidents that were classified as "high priority" or "critical." For each incident, they check: was the incident logged within the defined time frame? Was the priority assigned correctly based on the impact and urgency definitions? Was there evidence of investigation (troubleshooting notes, logs reviewed)? Was the resolution documented, and was the user notified before closure?

Next, the auditor looks at how incidents were escalated. They check whether the escalation procedure matches what is written in the ITSM policy. For example, if one critical incident took 12 hours to resolve when the SLA promised 4 hours, the auditor digs into why. They might find that the on-call specialist was not contacted because the escalation tree was out of date (the specialist had left the company six months ago).

The auditor then moves to change management. They request a report of all changes implemented in the last quarter. They look for changes that were categorised as "emergency" or "normal." For normal changes, they verify that each had a change request form, a risk assessment, and approval from the CAB. For emergency changes, they check that the emergency process was invoked (e.g., a phone approval followed by written documentation within 48 hours). A common finding is that changes are often made without proper authorisation, which exposes the organisation to unplanned outages or security gaps.

The auditor then reviews the CMDB. They take a sample of servers from the network diagram and check whether each one is recorded in the CMDB with up-to-date information: its owner, operating system version, patch level, and location. If the CMDB is inaccurate, it can lead to failures in incident management (not knowing which servers are affected) and change management (approving a change that will impact an undocumented system).

Finally, the auditor examines service level management. They ask for the SLA reports for the past six months. They look for trends: is availability slipping? Are response times increasing? They also check how exceptions are handled. If an SLA was missed, was there a root cause analysis? Was a service improvement plan created? A typical finding is that SLAs exist on paper but are never actively monitored, so problems are only discovered after users complain.

Throughout this process, the auditor uses a set of tools: ticketing system reports, change logs, CMDB queries, and interview notes with IT staff. The goal is to gather sufficient evidence to form an opinion on whether IT operations are under control. The final audit report will list findings, risks, and recommendations for improvement.