IT service management

Operations should run on defined processes for incidents, problems, changes, and service levels. An SLA between the IT service provider and the customer describes the service, documents service level targets and how they will be measured, and sets out each side's responsibilities. Auditors check that metrics such as SLA breaches are actually reviewed by management and that misses lead to corrective action.[2][3][4]

Operations logs and job scheduling

Scheduling establishes the sequence of computer job processing. An effective scheduling system aims for timely completion of all processing, avoids conflicting jobs, accounts for interdependencies between systems, and gives management current status and projected completion times. Operations logs should be reviewed by someone other than the administrator whose actions they record, which provides accountability, including confirming that logging is enabled.[5][6][7]

Backup strategy

The RPO (how much data loss the process can tolerate) drives backup frequency; the RTO drives the choice of recovery technology. Backup policy should set frequency and scope based on data criticality and how often new information is introduced. Backups should be stored offsite, protected to the data's own security requirements, and tested regularly to confirm files can be retrieved without errors. An untested backup is an audit finding, no matter how reliable the backup job looks.[8][9][10][11]

Business Impact Analysis (BIA)

Evaluates the impact of losing the support of any resource, establishes how that loss escalates over time, identifies the minimum resources needed to recover, and prioritizes recovery. The BIA is the first source for choosing recovery strategies and sets the system RTO, and acceptable downtime is determined with the business process owners, leadership and business managers, not by IT alone.[12][13][14]

Recovery site options

Hot site: configured with the necessary hardware, supporting infrastructure, and support personnel. Warm site: partially equipped. Cold site: space, power, telecommunications and environmental controls only; least expensive to maintain, but acquiring and installing equipment can take substantial time. Mobile sites are transportable shells; mirrored sites are the most expensive but give virtually 100 percent availability. A reciprocal agreement must be entered into carefully, because each party must be able to carry the other's workload on top of its own. A shorter RTO requires a more expensive recovery solution.[11][15][16][17]

Testing DR and BC plans

Common test types run from a checklist review of the plan, through a structured walk-through and a simulation, to a parallel test at the alternate site and a complete interruption test in which normal production is shut down. Results should be documented in an after-action report, with lessons learned fed back into the plan, and the plan reviewed on a defined schedule or after significant change. The auditor's core question: has the plan been tested recently, and were the issues found actually resolved?[18][19][20]

Incident management vs. problem management

Incident management restores service as quickly as possible, and a workaround is fine. Problem management investigates the cause of one or more incidents, which is usually unknown when the problem record is opened, to prevent incidents from recurring. When an incident is resolved without the root cause being identified, it should become a problem candidate; repeated incidents with no problem record opened is a classic audit finding.[21][22]

Incremental vs. differential backups

An incremental backup copies files created or changed since the last backup of any type: faster to create and lighter on media, but a restore may need the full backup plus every incremental since. A differential copies everything changed since the last full backup: it grows each day until the next full backup, but a restore needs only the full plus the latest differential.[23][24]

RTO vs. RPO

RTO is the maximum time a system resource can stay unavailable before the impact becomes unacceptable (time to recover). RPO is the point in time to which data can be recovered, a measure of how much data loss the process can tolerate, and it drives backup or replication frequency. A 4-hour RPO says nothing about how fast you must be back up.[8][9]