IS operations is where IT governance meets reality. Domain 4A covers the components, processes, and daily management of the IT environment — and the controls that keep it running reliably. Domain 4 is the joint-largest domain at 26%.
The daily machinery of IT — and the controls that keep it honest
This is the daily machinery of IT — and the controls that keep it honest. Domain 4 is worth 26% of the exam (tied with Domain 5 for the heaviest weight), and Part A is the operations half. It runs from knowing what you operate (components and assets) through how work gets done (batch jobs, interfaces), how services stay available (capacity, SLAs), and how the environment is kept under control (incident, problem, change, patch, log, and database management). The through-lines: a complete inventory, reconciliation of data and licenses, and independence — especially for the DBA. You can't audit, control, or recover what you can't see.
Learning Objectives
By the end of this lesson you will be able to…
Identify and assess IT components across hardware, software, network, and cloud categories.
Evaluate IT asset management programs for completeness, accuracy, and lifecycle coverage. Bloom: Evaluate
Assess job scheduling, automation, and system-interface controls for completeness and error handling. Bloom: Evaluate
Identify and assess risks associated with shadow IT and end-user computing.
Evaluate systems availability, capacity management, and IT service-level management. Bloom: Evaluate
👈 Read the term, recall the definition, then click or press Enter to check yourself.
Lesson Content
Study the material
1
IT Components
IS operations begins with knowing what you run. Auditors expect a complete, current inventory of every component, because you can't control or recover what you haven't inventoried.
Network: segmentation (DMZ, production vs. development), topology (LAN/WAN/SD-WAN), DNS/DHCP.
Cloud: IaaS/PaaS/SaaS shared-responsibility implications; hybrid and multi-cloud.
Auditor: comprehensive inventory; configurations compared to baselines; end-of-life/end-of-support components identified and risk-assessed.
2
IT Asset Management
Asset management tracks each component through its lifecycle — and two of its controls (license compliance and secure disposal) are frequent exam material.
Asset register: owner, location, classification, lifecycle stage, support status.
Disposal controls: media sanitization (NIST SP 800-88), certificates of destruction, chain of custody for media.
💡 Exam TipSoftware license compliance is both a financial and a legal risk. Over-deployment exposes the organization to vendor audits and penalties; unused licenses are wasted spend. Auditors look for regular reconciliation between installed software and licensed entitlements.
3
Job Scheduling & System Interfaces
Much production work runs unattended — batch jobs and system-to-system interfaces. The controls here ensure work completes and that data moving between systems is complete and accurate.
Job scheduling
Batch processing of grouped transactions; enterprise schedulers manage dependencies and execution windows.
Controls: job authorization (only approved jobs in production), monitoring (failure/late-start alerts), restart/recovery procedures, exception reports to business users.
Auditor: execution log with completion status; failures detected and resolved; schedule changes under change management; production separated from dev/test.
System interfaces
Types: file transfer (SFTP/FTP), API (REST/SOAP), message queue (MQ/Kafka), real-time (ESB).
💡 Exam TipInterface reconciliation is a common topic. Watch for data transferred between systems with no reconciliation — errors could pass through undetected. The auditor's concern is completeness and accuracy of the transfer, not just connectivity.
4
Shadow IT & End-User Computing
When technology operates outside IT's governance — unsanctioned cloud tools, or business-built spreadsheets running critical calculations — control gaps multiply.
Shadow IT risks: no change control, backup, or security review; regulated data in unauthorized cloud services; key-person single points of failure.
EUC risks: critical spreadsheets without version or access controls; no audit trail for formula changes; manual-entry integrity risk.
Controls: inventory critical EUCs; version control for critical spreadsheets; access controls and change logs; independent validation of EUC outputs.
💡 Exam TipShadow IT findings often span domains. A department using an unknown cloud tool that stores customer data is simultaneously a governance (policy), privacy (uncontrolled data), and operations (no backup/recovery) finding.
5
Availability, Capacity & Service-Level Management
Operations exists to keep services available, performing, and within agreed service levels — and to see trouble coming before it lands.
Availability = Uptime / (Uptime + Downtime). “Five nines” (99.999%) ≈ 5 minutes of downtime per year. Eliminate single points of failure with clustering, load balancing, and failover.
Capacity management: planning, thresholds and alerts, performance trending to catch degradation early.
Service-level management: SLAs (availability, performance, support hours, priorities, penalties), plus OLAs and underpinning contracts.
Auditor: SLAs documented and signed; metrics monitored continuously (not just reported after the fact); breaches documented and remediated; capacity plans reviewed at least annually; SPOFs in the risk register.
🔎 In practice
An ERP reporting 99.7% availability “above SLA” can still mislead if planned-maintenance downtime is excluded. The auditor checks whether the SLA actually defines that exclusion — and whether it reflects real business impact.
Try it — from “nines” to minutes of downtime
Availability sounds abstract until you turn it into downtime. Set how reliable one component is, how many must work in a chain, and how much redundancy you add — and watch the system’s uptime, its “nines,” and the minutes it’s dark each year. A chain multiplies failures; redundancy divides them.
Interactive · adjust & explore
Design the service
One component, a chain of them, some redundancy.
99.00%
How reliable a single component is on its own.
4
Every one must be up for the service to work (series).
1 (none)
Parallel spares remove single points of failure.
The result
System availability
—
“Nines”
—
Downtime / year
—
Meets 99.9% SLA?
—
——Adjust the design to see the downtime.
Downtime vs. redundancy
Yearly downtime on a log scale (each grid line is 10× less) as you add redundant copies. Your operating point (●) is at your current redundancy — each spare roughly buys another nine.
Downtime at your settings Your operating point
🔎 In practice
The math assumes component failures are independent — real outages often aren’t (a shared power feed, a bad change, one data center). That’s why the auditor looks past the headline percentage to whether single points of failure are in the risk register and whether the SLA’s downtime exclusions hide the real business impact.
6
Incident & Problem Management
ITIL draws a sharp line: incident management restores service fast; problem management eliminates the root cause so it doesn't recur.
Escalation: functional (to higher technical skill) vs. hierarchical (to management for severe or prolonged incidents).
Major incident management: a documented P1 process, war room, and post-incident review.
Auditor: all incidents logged and categorized; SLA timeframes met; repeat incidents trigger problem management; post-incident reviews for major incidents.
7
Change, Configuration & Patch Management
In operations, change and patch management are where availability and security risk concentrate. Patch management in particular is one of Domain 4's highest-frequency topics.
Change (operations view): change-freeze periods (month-end, year-end); high emergency-change volume is a quality signal of poor planning.
Emergency change: a legitimate but controlled path — expedited approval (a designated approver or emergency CAB), the change still documented, and a mandatory post-implementation review to retro-validate and record it. “No time, so no process” is never acceptable; the auditor samples emergency changes for after-the-fact approval and review. (see Lesson 9 — the emergency-change trap)
Patch management: discovery (vendor bulletins, CISA KEV, NVD), risk assessment (CVSS, business impact), testing before production, deployment windows and approval, compliance monitoring.
Auditor: a defined patch policy with SLAs by severity; patches tested before production; compliance tracked and reported; exceptions documented with compensating controls; end-of-support systems risk-managed.
💡 Exam TipClassic patch-management findings: (1) no SLA for critical patches, (2) patching production without testing, (3) no tracking of non-compliant systems, (4) end-of-life systems with no compensating controls. Any one of these is a finding.
🔎 In practice
Cloud shifts who patches what. Under the shared-responsibility model, in IaaS the customer still patches the guest OS and apps; in PaaS the provider patches the platform and the customer owns code and configuration; in SaaS the provider patches almost everything. Because misconfiguration — not a missing patch — is the dominant cloud risk, operations rely on configuration baselines and CSPM (Cloud Security Posture Management) to detect drift. The auditor confirms responsibilities are documented per service model and that CSPM findings are triaged and remediated.
📚
Explore furtherConfiguration Management — an interactive module on baselines, patching, and change control.
Requirements: completeness (required events captured), integrity (tamper-evident — subjects of logging can't alter their own logs), retention (regulatory/forensic), availability for investigation.
SIEM: centralized collection and correlation, alerting on use cases (impossible travel, brute force, privilege escalation), long-term search.
Auditor: critical logs captured and retained; administrators can't modify or delete logs undetected; logs reviewed regularly with documented follow-up; retention meets regulation. (also Lesson 2 — data-retention & classification governance)
9
Database Management
Databases hold the crown jewels, and the DBA holds the keys. The recurring exam control: the DBA may have the ability to access production data but should not routinely do so — and their access must be independently reviewed.
Security controls: least-privilege access to objects, separation of DBA from application-user access, database activity monitoring, encryption at rest, preventing direct production DBA access to application data.
Auditor: DBA activities logged and independently reviewed; least-privilege production accounts; application users can't bypass app controls via direct DB access; backups verified by restoration testing; sensitive data encrypted at rest.
💡 Exam TipDBA independence is a classic topic. The DBA should be able to access production data but not routinely do so for business purposes. Key control: DBA access is logged, and those logs are reviewed by someone other than the DBA. If the DBA reviews their own logs, the control is ineffective.
Scored Knowledge Check
Test your Domain 4A judgment
Select the best answer for each question, then submit for your score and the rationale for every item. Watch the completeness, reconciliation, and independence themes.