IT Audit: Process, Controls and NCA/SAMA Requirements

An IT audit is an independent examination of an organisation’s information technology controls, infrastructure and processes, carried out to determine whether those systems safeguard assets, maintain data integrity, and operate effectively to achieve the organisation’s objectives. Where a financial audit asks whether the numbers are right, an information technology audit asks whether the systems that produce those numbers can be relied upon at all.

This guide covers what IT auditing is, the types of IT audit, the IT audit process end to end, and the control frameworks auditors test against. It then covers what most guidance leaves out: how IT audit actually works under the Saudi regulatory regime, where the National Cybersecurity Authority (NCA) and the Saudi Central Bank (SAMA) impose expectations that international frameworks do not describe.

What is an IT audit?

An IT audit provides assurance — an independent, evidence-based opinion on whether controls are designed appropriately and operating effectively. Three words in that sentence carry the weight:

Independent — the auditor does not own, operate or advise on the control being tested. Independence is what separates audit from consulting, and it is the first thing a regulator or external quality assessor will probe.
Evidence-based — a conclusion must rest on evidence a competent third party could re-examine and reach the same view on. An auditor’s belief is not evidence.
Design and operating effectiveness — two distinct questions. A control can be well designed and never actually run. It can also run faithfully and still not address the risk. Both must be tested.

The output is not a list of technical faults. It is an opinion on risk, expressed in terms the audit committee can act on.

IT audit versus adjacent disciplines

These are routinely conflated, and the confusion causes real scoping errors:

IT audit vs cybersecurity audit — cybersecurity audit is a subset. IT audit also covers change management, data integrity, capacity, availability and IT governance, which are operational rather than adversarial risks. See our breakdown of cybersecurity audit vs compliance audit.
IT audit vs compliance audit — a compliance audit asks “does this meet the requirement?” An IT audit asks “does this control the risk?” An environment can be fully compliant and materially exposed.
IT audit vs risk assessment — a risk assessment is forward-looking and owned by management. An audit is retrospective, independent, and tests what actually happened. See our IT risk management framework guide.
Internal vs external IT audit — internal audit reports to the audit committee and covers the full risk universe. External IT audit is usually scoped narrowly to what supports the financial statement opinion, or to a certification.

Types of IT audit

IT general controls (ITGC)

The foundation layer, and the most common engagement. ITGC covers the controls that apply across the IT environment rather than to one application: access to programs and data, program change, program development, and computer operations. If ITGC is weak, no application-level control can be relied upon, because the environment underneath it cannot be trusted.

Application controls

Controls embedded in a specific business application: input validation, calculation logic, interface completeness, segregation of duties within the application’s role model, and output reconciliation. Tested against the risk and control matrix for that process.

Infrastructure and network audit

Operating systems, databases, network segmentation, hardening baselines, patching, and increasingly cloud configuration. Our guides to system hardening and vulnerability management and data centre physical security cover the substance.

Third-party and cloud audit

Where the control operates outside your perimeter. The auditor tests the governance of the relationship — due diligence, contractual security obligations, right-to-audit clauses, assurance reports received and reviewed — rather than the provider’s controls directly. Under NCA this is a named domain, not an afterthought.

Pre-implementation and project audit

Reviewing a system before go-live, when findings are still cheap to fix. Requires care: the auditor advises on control design without assuming ownership of it, or independence is compromised for every future audit of that system.

The IT audit process, step by step

1. Risk-based planning and scoping

The audit universe should be an inventory of auditable entities scored on risk, not a list of systems or departments. Scope is then set by risk, materiality and regulatory obligation. A defensible scope statement says what is excluded as explicitly as what is included.

2. Understanding the environment: walkthroughs

Trace one transaction or one change end to end, with the people who operate the process. The purpose is to document what actually happens, which is frequently not what the policy says happens. Everything downstream depends on getting this right.

3. Assessing control design

Before testing whether a control works, establish whether it could work. Would this control, operating perfectly, actually mitigate the risk it is mapped to? A design gap cannot be fixed by testing harder — it means the control is the wrong control.

4. Testing operating effectiveness

Sample selection driven by control frequency and population size, tested against a documented methodology. Techniques run from inquiry (weakest) through observation and inspection to re-performance (strongest). Inquiry alone is never sufficient evidence for a conclusion. Our guide to testing and documenting IT controls covers sampling and evidence sufficiency in depth.

5. Evidence and working papers

Every conclusion traces to evidence held in the working paper, not in an inbox. The standard to meet: a competent reviewer with no involvement in the engagement can follow the paper from objective to conclusion and reach the same view. Preparer, reviewer and approver are distinct roles, and review happens during fieldwork rather than at the end.

6. Findings and management response

A finding states condition, criteria, cause, effect and recommendation. Cause is the one most often skipped, and it is the one that determines whether the finding recurs next year. Ratings should follow a documented rubric, not the auditor’s mood.

7. Reporting

The committee needs the few things requiring a decision separated from the many requiring awareness. Reports landing weeks after fieldwork closes describe a risk picture that has already moved. See quality assurance in IT audit reporting.

8. Follow-up to verified closure

The step that separates functions with credibility from functions without it. Remediation must be verified by someone other than the person who performed it. Self-verified closure is a status update, not assurance.

IT general controls in detail

Access to programs and data — joiner/mover/leaver processes, privileged access, periodic recertification, segregation of duties. Leaver revocation timeliness and orphaned privileged accounts are the two findings that appear most often. See access management controls.
Program change — authorisation, testing, approval and segregation between development and production. The classic finding is emergency-change processes used routinely to bypass approval. See change and patch management.
Program development — SDLC controls, data migration integrity, and go-live acceptance.
Computer operations — job scheduling, incident and problem management, backup and restoration. Backups that are taken but never test-restored are a control in name only. See incident management.

IT audit in Saudi Arabia: the NCA dimension

This is where international IT audit guidance stops being sufficient. Organisations operating in the Kingdom are audited against the National Cybersecurity Authority’s control catalogues, which carry their own structure, evidence expectations and scoping rules.

The core instrument is the Essential Cybersecurity Controls (ECC), organised into main domains covering cybersecurity governance, defence, resilience, third-party and cloud computing, and industrial control systems. Organisations operating critical systems face the additional Critical Systems Cybersecurity Controls (CSCC), with cloud and operational technology addressed by their own control sets.

What this changes for the auditor, practically:

Scoping is determined by system classification. Whether a system is designated critical drives which control set applies. Classification is therefore an audit-relevant control in its own right — get it wrong and the entire engagement is scoped wrong. See NCA critical system compliance.
Compliance is assessed against a defined maturity expectation, not a binary pass. Partial implementation must be evidenced and rated, not asserted.
Evidence expectations are explicit. NCA assessors expect documented, consistently applied methodology. “We do this in practice” without artefacts does not survive assessment.
Mapping to international standards saves duplicated effort — but only if the mapping is documented and defensible. Our guide to ISO 27001 vs NCA ECC covers where the two align and where they genuinely diverge.

IT audit for SAMA-regulated entities

Banks, insurers and fintechs supervised by the Saudi Central Bank work to a further layer. The SAMA Cyber Security Framework is structured around governance and leadership, risk management and compliance, operations and technology, and third-party cyber security — and it is assessed on a maturity model rather than a control-present/control-absent basis.

The maturity dimension is what catches auditors trained only on ISO or SOX. A control that exists, is documented, and operates is not automatically at target maturity: SAMA expects evidence that it is measured, reviewed and improved. Auditing to SAMA means testing the management system around the control, not only the control.

SAMA also maintains separate frameworks for IT governance, business continuity and counter-fraud, each with its own audit implications. See SAMA IT Governance Framework compliance and the SAMA Counter Fraud Framework.

Add PDPPL and personal data becomes a distinct audit dimension with its own lawful-basis, residency and subject-rights controls.

Regulatory control catalogues are revised periodically. Always verify scope and control references against the current official publication from the NCA, SAMA or SDAIA before relying on them in an engagement.

Frameworks IT auditors work to

COBIT 2019 — governance and management objectives for enterprise IT; the usual reference for IT governance audits.
ISO/IEC 27001:2022 — the certifiable information security management system standard, with Annex A controls.
NIST CSF 2.0 — outcome-based cybersecurity functions, useful for maturity conversations with boards.
ISO 19011 — guidance on auditing management systems: programme design, auditor competence, evidence sufficiency.
IIA Global Internal Audit Standards — the professional baseline for internal audit conduct and quality.

Where IT audits go wrong

Testing compliance instead of risk — producing a checklist result that satisfies the framework and misses the exposure.
Inquiry treated as evidence — “the administrator confirmed reviews are performed” is not a tested control.
Sample sizes chosen by habit rather than by control frequency and population.
Findings without a cause — guaranteeing the same finding returns next year.
Self-verified remediation — the single most common reason repeat findings persist.
Scoping from last year’s paper — the environment moved; the scope did not.

Our analysis of the most common IT audit missteps goes further, and internal audit practices covers the discipline that prevents them.

Frequently asked questions

What is an IT audit in simple terms?

An independent check of whether an organisation’s technology systems and the controls around them are designed properly and actually working — protecting data, keeping it accurate, and keeping systems available.

What are the main steps in the IT audit process?

Risk-based planning and scoping, walkthroughs to understand the environment, control design assessment, operating effectiveness testing, evidence and working papers, findings with management response, reporting, and follow-up to verified closure.

What is the difference between IT audit and cybersecurity audit?

Cybersecurity audit is a subset of IT audit focused on protection from malicious threats. IT audit additionally covers change management, data integrity, availability, capacity and IT governance — risks that arise without any attacker involved.

What qualifications do IT auditors hold?

CISA is the most widely recognised IT audit credential. CIA covers internal audit generally, CRISC risk, and CISSP security. In Saudi Arabia, familiarity with NCA and SAMA frameworks is often weighted as heavily as certification. Preparing for a role? See our IT audit interview questions with model answers.

How often should an IT audit be performed?

Coverage is driven by the risk-based annual plan rather than a fixed cycle, but high-risk systems are typically covered annually. Regulatory obligations may set a floor, and major changes — a migration, a significant incident, a new jurisdiction — should trigger coverage regardless of the plan.

Understanding IT Audit: A Comprehensive Guide to Information Technology Assurance

What is an IT audit?

IT audit versus adjacent disciplines