CISA IT Operations: Components, Asset Management, Job Scheduling, Interfaces and End-User Computing

The processing environment an IS auditor reviews is built from a small set of back-end components, and each one carries its own risk because of what it does and what it stores. Knowing their roles lets you tell which device a control belongs on and which data a device holds when it is moved, repaired or retired.

In a three-tier application the presentation, application logic and data are separated: the browser talks to a web front end, the application server applies the business rules and the database server holds the data. A question that asks where the logic runs is asking about the middle tier.

Devices that look harmless can hold sensitive data. Any device with an internal disk (a copier, a network appliance, a storage shelf) is a storage device. While it is on site the organization's physical and logical controls protect what it holds; once it leaves the organization's custody, for any reason, those controls no longer apply but the data is still on the disk. That is why device disks belong in the asset disposal process (see the disposal section below), not only workstation and server drives.

A hardware maintenance program keeps equipment reliable by scheduling preventive maintenance to the vendor's specifications, prioritised by how critical the equipment is, performed by authorized parties and recorded so that it can be tested. Cost and sourcing decisions belong to management; they are not the control that keeps hardware working.

Evaluating maintenance

• Reliable evidence that maintenance happened is documentary, produced at the time of the work and issued by whoever performed it, such as a record of each service visit, compared with the planned schedule so that missed visits stand out. Evidence of what was agreed, what someone says happened, or what was paid for does not show that the work itself was done.
• A deviation from the vendor's schedule is not yet a finding. When practice departs from what the vendor specifies, the auditor first establishes whether the departure has affected reliability, using the equipment's own failure and outage history. Only then can the deviation be rated and a recommendation framed; a recommendation or escalation made before the effect is known is premature.

USB and other removable media

Removable storage creates two classic risks: data leakage (sensitive files leave on media the organization neither owns nor protects, and are exposed when a device is lost or taken) and malware introduction (untrusted media connected to corporate machines). Which one is greatest depends on the scenario: unrestricted copying of server files to personal drives is a disclosure problem; plugging in unknown media is a malware problem.

Preventive controls beat detective ones. When the business genuinely needs USB (for example, loading files onto machines with no network connection), the strongest approach is technical enforcement: device-control software that refuses any storage device except encrypted media the organization itself issues and manages. A control that only records copying finds the problem after the data has gone, a rule users are asked to follow depends on behaviour, and a control aimed at one risk (malware) does nothing for the other (leakage).

When testing device control, remember that the management console reports only on devices running the agent. To show the control operates across the whole estate, reconcile agent enrolment to the endpoint inventory (finding laptops never enrolled or with a broken agent) and attempt to use an unapproved drive on a sample of endpoints. Evidence of how the tool is configured or was rolled out shows only design.

IT asset management is the control of hardware, software and data assets across their life cycle (acquisition, deployment, maintenance, and retirement and disposal), and it starts with an accurate inventory. An organization cannot classify, protect, maintain, license or dispose of assets it does not know it has, so the first step in setting up the program is to identify and record IT assets in a register with attributes such as owner, location, configuration and status. Classification, replacement cycles and disposal procedures all build on that inventory.

Every asset needs an accountable owner. The owner decides the asset's classification, the protection it needs, who may use it and when it is retired. A register that records location and configuration but no owner leaves those decisions to no one, so protection may be inadequate and life cycle actions (contract renewal, patching, retirement) are missed. Many of the register problems an auditor finds later trace back to this one missing attribute.

When the auditor evaluates asset life cycle policies and practices, the questions follow the cycle:

• Acquisition goes through approved procurement so that the asset is recorded when it arrives.
• Deployment and change update the register (location, user, configuration) so that it stays accurate.
• Maintenance follows the hardware maintenance program, and software stays within license entitlements.
• Retirement and disposal include sanitization of any media and a record that reconciles each device leaving the organization.

Completeness and existence are opposite questions, and the direction of the test decides which one you answer. Completeness asks whether everything that exists is recorded; existence asks whether everything recorded is real.

Testing from the register to the floor can never reveal an omission, because an unrecorded device is never sampled. Testing from discovered devices to the register can never prove a recorded item exists.

Reconciling to another record proves completeness only if that record contains everything that should be in the register. A fixed-asset ledger in finance excludes items below the capitalization threshold, because those are expensed when bought. Laptops and phones often fall below it, yet they hold data and need tracking. So a register whose count agrees exactly with the ledger can still be missing many end-user devices; matching counts show the two records share the same scope, not that either is complete. Owner confirmations have the same weakness: owners confirm the entries they are shown, not the devices that were never listed. Neither a count comparison nor a confirmation gives item-level evidence of existence either.

Software license compliance means the copies installed or in use do not exceed what the organization is entitled to under its agreements, so the best evidence compares both sides: installations or usage measured by a discovery or metering tool, against purchased entitlements. A policy, purchase orders or a vendor's audit-rights clause each show only one side, or only intent.

Measure the metric the agreement actually licenses.

A count that exceeds the licenses on one metric is not automatically a breach on another. Where the agreement limits simultaneous use, the number of installed copies says little; the auditor first obtains the measure the agreement actually limits and only then concludes. A conclusion drawn from the wrong metric is premature.

Prevention addresses the root cause. If over-deployment happened because users can install software themselves, the recommendation that stops it recurring removes that ability and routes all software through a managed distribution process that checks entitlements before it installs. Remedies that fix only today's count, find the problem later or depend on users remembering a rule do not address the cause.

Any asset that leaves the organization with storage inside it (resale, recycling, donation, lease return or warranty replacement) is a disposal, and its media must be sanitized, with evidence for each device reconciled to the disposal records.

NIST SP 800-88, Guidelines for Media Sanitization (Revision 2, September 2025, which refers to IEEE 2883-2022 for technique-level detail), keeps three levels:

• Clear: logical techniques such as overwriting user-addressable storage, protecting against simple recovery tools.
• Purge: techniques that defeat laboratory recovery, such as the drive's built-in sanitize command, cryptographic erase on a self-encrypting drive (effective only when the encryption key covers all stored data), or degaussing for magnetic media.
• Destroy: shredding, disintegrating or incinerating so the media can no longer be used.

Choose the method by media type and by whether the device will be reused:

Evidence must be specific to each device. When a third party sanitizes media for the organization, the best assurance is device-level proof of sanitization, matched serial by serial against what the organization sent, which shows both that the work was done and that nothing went missing. Evidence about the provider's general management system or its promises speaks to intent, not to the outcome for these devices. In the same way, a control that only records or contractually restricts what happens to a device after it has left cannot stop the data on it being read; the protection has to be applied before it leaves.

Job scheduling software runs production jobs from predefined, approved job definitions (programs, parameters, dependencies and timing set up once), starts them automatically and records what ran, which reduces manual operator intervention and the errors that come with it and gives an audit trail.

Take the keystroke out of the process

If operators type a value such as the run date each time they submit a job, an error eventually follows. The preventive recommendation removes the keystroke: the value is supplied by the system itself, for instance from the scheduler's processing calendar, so the job runs the same way every time. Extra checking of a keyed value leaves the manual step in place, and reviewing results afterwards catches the mistake late.

Link dependent jobs by condition, not by clock

Where one job consumes another's output, timing alone is fragile: whenever the upstream job overruns, the downstream job reads incomplete or stale data. Defining a dependency in the scheduler makes the downstream job wait for the upstream one to finish successfully. An automated condition is preventive and does not depend on anyone remembering to check, which is why it beats any arrangement that relies on timing margins, a person or a later comparison.

Automation moves the risk; it does not remove it

Automation removes manual starts, keyed parameters and release-timing mistakes, and alerting can cover failed jobs. But the scheduler executes its definitions exactly, every night. Once manual checks such as run sheets are dropped, nobody compares what ran with what was intended, so an unauthorized or mistaken change to a job definition (a command, parameter or target) can run repeatedly without challenge. The control focus therefore shifts to who can change job definitions and how those changes are approved and reviewed.

Every change to the production schedule and every job run outside it must be authorized before it runs, performed by operations, and evidenced so that the auditor can trace what ran back to an approval.

Ad hoc jobs and exceptions

• If work outside the schedule can be started on an informal request, anyone able to ask can trigger production processing, including reruns that post data twice. The control is authorization in advance: each out-of-schedule run has a recorded request and an approval from someone entitled to give it before operations starts it. Recording requests after the run is detective and leaves the gap open.
• When the scheduler's execution log shows jobs that were not on the approved schedule, they are exceptions to investigate, not yet findings: reruns and authorized ad hoc requests are normal. The auditor next checks each one for a request, an approval and a business reason, and only then concludes or recommends.

Sampling direction for schedule changes

To test that all modifications were authorized, start from the population that captures every change actually made, which is the system-generated change history kept by the scheduler, and trace each change to its authorization. Sampling approvals and tracing to the log proves only that approved changes happened (an unauthorized change has no approval to sample), and an operations-prepared report may be incomplete.

Abnormal terminations and restarts

An abnormal termination (abend) should be recorded with its cause, the authorization for the rerun or restart and the outcome. Operating evidence (records showing this for each actual abend) beats design evidence about how restarts are supposed to work or summary trends. When an updating job fails partway, the updates already made stay in the data, so starting it again from the top applies them twice unless the data is first restored to its pre-run state or the job resumes from a checkpoint. Misstated data is an integrity risk, and integrity ranks above operational inconvenience.

Who may change the schedule

Segregation between development and production operations means operations or production control maintains the schedule, applying changes once approved. Developers, business data owners and DBAs should not edit it. Where developers must fix overnight failures, give them controlled emergency (break-glass) access: an individual checkout that is logged and reviewed after use. Access that exists only while it is needed is stronger than permanent access, even monitored permanent access, because monitoring finds misuse only afterwards.

The emergency path is only as good as its review. If the reviewer is the development team leader, the review is not independent of the people making the changes; it should be done by operations or another party outside development.

A system interface moves data between systems (system to system, partner to system or person to system), and the auditor's concerns are that every interface is known, that data arrives complete and accurate, and that only authorized parties can send it.

Start with the inventory

Many interfaces are undocumented. Before testing anything, the auditor obtains an inventory of interfaces recording each one's source, target, data carried, frequency and owner. That shows what exists and which interfaces carry the most sensitive or critical data, so the review can be scoped by risk. Detailed evidence about individual interfaces only becomes useful once the population is known.

Completeness and accuracy controls

So when the number of records agrees but values are wrong at the receiving end, the gap is a value-based total compared on both sides; a check that only confirms data arrived cannot see it. Controls that protect the file's confidentiality in transit or at rest are valuable but do not prove completeness or accuracy.

Rejected records need a suspense queue. A reconciliation that explains differences as rejects balances only if rejected records are held, corrected and resubmitted. If the error file is overwritten by the next run, rejected transactions vanish while the reconciliation still appears to balance, and revenue or postings are lost. This is serious precisely because the control appears to work when it does not.

Securing partner and API interfaces

To ensure that only a partner can submit data and that each submission is traceable to it, authenticate every call with a credential issued only to that partner and log the authenticated identity with each request. Restrictions based on network location identify where a request came from, not who sent it, so they supplement authentication rather than replace it.

End-user computing (EUC) is any application that business users build and run themselves, such as spreadsheets, desktop databases and scripts, and shadow IT is technology (often cloud services) acquired or used without IT's involvement; both bypass the requirements, testing, change control and version management that IT-managed systems receive.

The risk and the inventory

For a business-critical spreadsheet the greatest risk is an undetected formula or logic error that misstates the results the business relies on. Availability and access risks are real but narrower than wrong numbers the business acts on. Because EUC is usually undocumented, the auditor starts by finding out which EUC applications exist and ranking them by risk, then concentrates testing on the highest. Risk is driven by what depends on the result (financial reporting, regulatory filings, key decisions) and how intricate the calculations are (formulas, macros, links between files). Descriptive attributes of a file do not by themselves measure its risk.

Compensating controls for EUC that cannot be replaced

The preferred fix is to move critical EUC to an IT-managed system; until then, compensating controls must address the actual risk. Judge each one by which source of error it covers:

A review that only checks whether a result looks reasonable against the previous period is not designed to address the risk: an error present from the start, or one that keeps the result plausible, passes it. Strengthening the formalities around such a review does not fix its design; an effective review reconciles to source data or reperforms key calculations.

Discovering and governing shadow IT

Shadow cloud services escape procurement and installation records, so discovery needs sources that capture them independently: corporate card and expense transactions show what is paid for outside procurement, and web proxy or cloud access security broker (CASB) logs show which cloud services are actually used, including free tiers. Sources that rely on users volunteering information, or that record only what IT bought or installed, miss exactly what shadow IT is.

Shadow IT usually signals an unmet business need. The effective response is to assess the service's risk (data handled, security, contract terms) and then approve it with controls or provide an approved alternative. A response that leaves the business need unmet usually just moves the use somewhere less visible, and any response must also deal with the data already held in the service.