Domain 4: Information Systems Operations and Business Resilience

Think of a hotel. Guests call one number, reception. Reception logs the request, fixes what it can, and sends the rest to housekeeping, maintenance or the kitchen. Behind the scenes, each team has its own process, and the manager tracks how quickly guests are looked after.

IT service management (ITSM) runs IT the same way. Frameworks such as ITIL and ISO/IEC 20000 describe the processes; COBIT gives auditors the criteria.

1. 1Logs every incident and request. Every single one.
2. 2Sets priority from impact and urgency.
3. 3Fixes what it can at first line; escalates the rest.
4. 4Keeps users informed.
5. 5Closes tickets only when the user confirms it's fixed.

Are processes documented and followed? Is everything logged? Are priorities set consistently? Are SLA reports accurate? Are repeat incidents linked to problems, and fixes to changes?

USB sticks and other removable media are an easy way for data to walk out of the door and for malware to walk in.

Controls: restrict or disable ports, allow only approved and encrypted devices, and log their use.

Vendor engineers working on production hardware have physical access to everything. Their visits should be scheduled, supervised where appropriate, and logged.

And keep your own record of hardware faults. If only the vendor logs them, you can't see the trends.

1. 1Parameters compared with policy.
2. 2Privileged account list reviewed.
3. 3Use of sensitive utilities logged and checked.
4. 4Patch status and logging configuration.
5. 5OS changes going through change control.

Sending a parcel abroad involves layers. You write the letter (application), translate it and seal it (presentation), agree to keep writing back and forth (session), number the boxes so none go missing (transport), address them to a city (network), hand them to the local van (data link), and the van drives the road (physical).

The OSI model splits network communication into those same seven layers.

A device can only filter what it can see. A hub sees bits, so it can't filter anything. A switch sees MAC addresses. A router sees IP addresses. An application firewall sees the actual web request.

1. 1IPv4 addresses are 32-bit; IPv6 addresses are 128-bit.
2. 2Private ranges (10.x, 172.16-31.x, 192.168.x) are used inside the organisation.
3. 3NAT translates private addresses to a public one at the edge.
4. 4Subnetting splits networks into segments, which helps segregation.

1. 1Table: rows (records) and columns (fields).
2. 2Primary key: the unique ID of each row.
3. 3Foreign key: a column pointing to another table's primary key.
4. 4View: a virtual table showing only selected rows or columns. Also an access control.
5. 5Stored procedures and triggers: code in the database that enforces rules.

Sometimes data is copied on purpose to make reports faster, common in data warehouses. That's denormalisation.

Fine, but now the copies can drift apart, so you need compensating controls: controlled update routines or regular reconciliation.

1. 1Users reach data through applications, not database tools.
2. 2Roles and views limit what each user sees and changes.
3. 3DBA and schema-owner accounts: named, few, monitored.
4. 4Service accounts get only what the application needs.
5. 5Keys, constraints and triggers enforce rules in the database itself.
6. 6Production data masked before use in testing.

Database activity monitoring (DAM) logs and alerts on suspicious activity: bulk extracts, direct changes to sensitive tables, privilege escalation, access at odd hours.

Software asset management compares licences owned with software actually installed and used. Too few licences is a legal and financial risk; too many is waste.

Restricting who can install software makes this far easier.

1. 1Change impact: what else will this change affect?
2. 2Incident diagnosis: which components are involved?
3. 3Problem management: what do repeat incidents have in common?
4. 4Recovery: what to rebuild, and in what order.
5. 5Security: which systems run the vulnerable version?

CMDB updates are part of closing every change. Automated discovery and regular audits check the records still match reality.

1. 1Jobs run in the right order at the right time.
2. 2Dependencies are enforced: no job starts on incomplete data.
3. 3Less manual operator intervention, so fewer mistakes.
4. 4A log of everything that ran.

When a job fails halfway, rerunning it from the start can process half the data twice. Reruns need approval, a restart from a checkpoint, and a check for duplicates.

When a pipe bursts, the first job is to stop the water and get the kitchen usable again. Working out why the pipe burst comes later.

An incident is any unplanned interruption or drop in service quality. Incident management's only goal is to restore normal service as quickly as possible.

Malware, breaches and unauthorised access follow the security incident response process (Domain 5). The service desk has to recognise them and route them correctly, because evidence must be preserved and legal or regulatory notification may apply.

A quick 'restart and close' can destroy the evidence.

Incident management mops up the water. Problem management goes into the ceiling to find the leaking pipe and replaces it, so you stop needing the mop.

A problem is the underlying cause of one or more incidents. Problem management finds root causes and removes them so incidents don't come back.

In a hospital, nobody changes a patient's medication on a whim. The change is requested, a doctor approves it, the pharmacy checks it, a nurse gives it, and it's all written in the chart.

Change management does the same for production systems. Its main goal: prevent or detect unauthorised changes to programs, configurations, parameters and data.

Automated application controls are usually tested once and relied on all year. That only works if nobody could change them unnoticed.

Weak change management means the auditor can't rely on automated controls, so substantive testing goes up.

1. 1A unique ID for every release (configuration management).
2. 2A definitive media library: a secure store of approved versions.
3. 3A deployment plan with timing and responsibilities.
4. 4A back-out plan, prepared before deploying.
5. 5Testing in an environment that mirrors production.
6. 6Checks after release that it worked.

Unpatched systems are a leading cause of breaches. Badly tested patches cause outages. The exam's balance: test before deploying, prioritise by risk, and use the emergency route when a vulnerability is being actively exploited.

Systems that can't be patched need documented risk acceptance and compensating controls such as isolation and monitoring.

1. 1Services covered and service hours.
2. 2Measurable targets: availability, response and resolution times.
3. 3How performance is measured, and from what data.
4. 4Reporting frequency and review meetings.
5. 5Responsibilities of both sides.
6. 6Escalation and service credits.

Is availability measured as users experience it, or for one component? Are exclusions like planned maintenance reasonable? Could the provider reclassify incidents to look better?

A restaurant needs enough tables for Saturday night, but not so many that half sit empty all week. And if a big party is booked next month, the manager needs to know now, not when they walk in.

Capacity management makes sure IT can meet today's and tomorrow's demand at a sensible cost. Too little means slow systems and outages; too much wastes money.

1. 1Monitor utilisation and response times, with thresholds and alerts.
2. 2Analyse trends, peaks and bottlenecks.
3. 3Tune systems to use existing resources better.
4. 4Manage demand, e.g. move batch jobs off-peak.
5. 5Forecast from trends AND business plans.
6. 6Keep a documented, reviewed and funded capacity plan.

Users notice slow systems before IT does. Emergency hardware purchases. Storage runs out without warning. No link between business plans and IT planning. In the cloud, auto-scaling with no limits brings surprise bills.

Every organisation has one: the spreadsheet only one person understands, which somehow calculates a number that ends up in the annual report.

End-user computing (EUC) means tools built and run by business users rather than IT: spreadsheets, desktop databases, macros, scripts, user-built reports and low-code apps. They're quick and flexible, which is exactly why they end up running important processes.

A final number can look perfectly reasonable while the formula behind it is wrong. Review the logic, not just the result.

Imagine your office floods overnight. Where do staff go in the morning? Which customers do you call first? Which systems must be back by lunchtime, and which can wait a week?

Business continuity planning answers those questions before the flood, while there's time to think.

1. 1Scope, objectives and assumptions.
2. 2Who can declare a disaster, and when.
3. 3Teams and roles, with deputies.
4. 4Contact lists: staff, suppliers, customers, authorities.
5. 5Recovery procedures in priority order, and the resources needed.
6. 6Communication, and how to return to normal.

Update the plan after changes to the organisation, people and contact details, systems, suppliers and premises, and after every test and real incident.

If your house were on fire and you had two minutes, what would you grab? Probably not the toaster. You'd grab the things that are irreplaceable or that you'd need tomorrow.

A business impact analysis (BIA) asks the same question of an organisation: which processes matter most, how quickly does the damage grow if they stop, and what do they depend on?

Process owners and key users supply the information; IT describes system dependencies; senior management approves the priorities. IT systems inherit their priority from the processes they support.

Lower RTO and RPO cost more. The auditor questions targets that aren't justified by downtime cost, and strategies that can't meet the targets set.

A recovery site must be far enough away not to be hit by the same event (flood plain, power grid, regional disaster), but reachable by staff if needed.

Copying everything every night would be the simplest approach. But for large systems, a full copy can take hours and fill a lot of storage.

So organisations take one full copy now and then, and in between they only copy what has changed. There are two ways to decide what "changed" means, and that gives us incremental and differential backups.

With incrementals, every link matters. Each one only holds one day's changes, so you need all of them in the right order.

Nightly backups mean you could lose up to a day of work. When the business can't accept that (a low RPO), other techniques copy data much more often.

Replication copies everything instantly, including mistakes. Delete a table by accident, or get hit by ransomware, and the copy is damaged within seconds too. You still need point-in-time backups, and at least one copy that attackers can't reach (offline or immutable).

Keeping your spare house key in the same drawer as the main one doesn't help when you're locked out. Keeping backups in the same building as the servers doesn't help when the building floods.

Backups need to be somewhere else, kept safe, kept for the right time, and proven to work.

1. 1Encrypt backups; keep the keys separately.
2. 2Label clearly, without revealing what's on it.
3. 3Locked containers and chain-of-custody records in transit.
4. 4Securely dispose of retired media.

Review backup logs and how failures are followed up. Reconcile the offsite inventory with backup records. Check the offsite facility. Above all, look at restore tests, and whether restore times meet the RTO.

1. 1Detailed enough for someone other than the usual admin to follow.
2. 2A named backup for every role.
3. 3Copies offsite, in a form you can reach when email and file shares are down.
4. 4Updated after changes to systems, people, suppliers, and after every test.
5. 5Staff trained in their roles.

A school doesn't wait for a real fire to find out the fire exit is blocked. It runs drills, starting with a talk-through and building up to everyone actually leaving the building.

Continuity tests work the same way. An untested plan gives very little assurance.

1. 1Time to recover each system vs its RTO.
2. 2Work processed at the recovery site.
3. 3Data accuracy vs RPO and integrity checks.
4. 4Share of the plan carried out successfully.

Business users, not just IT. The test should prove business processes can recover, not just servers. Internal audit may observe and review the results.

A test that finds nothing wrong probably wasn't realistic. Finding weaknesses is the point.

Insurance pays for losses. It doesn't bring service back, can't repair reputation, and may not cover regulatory fines. It complements a continuity plan; it never replaces one.

Cyber policies often add incident response, breach notification, extortion and liability. The auditor checks cover matches the risks, and that policy conditions (such as required controls) are actually met.

A building inspector doesn't just read the fire safety manual. They check the extinguishers are charged, the exits are clear, and the staff know where to go.

Auditing BCP is the same. The question is simple: could the organisation recover its critical processes within acceptable time and data loss? The plan document is only the start.

1. 1Reconcile the offsite backup inventory with backup records.
2. 2Review timed restore tests.
3. 3Read alternate site contracts: capacity, oversubscription, testing rights.
4. 4Compare the plan with recent system, staff and supplier changes.
5. 5Interview team members; call a sample of the contact list.
6. 6Observe a test if possible; check issues were fixed and retested.

The auditor evaluates and reports. They may advise while the plan is developed, but they don't write or own it. Doing so would impair their independence when they audit it later.