Definition

ITGC (IT General Controls) audit scope defines the universe of access, change management, computer operations, and program development controls tested to support financial statement opinions (SOX Section 404), service trust principles (SOC 2 CC6–CC9), and regulatory security baselines (SAMA CSF 3.2, SAMA ITGF). Scoping a single ITGC universe that satisfies all three frameworks avoids triple-testing of the same control population. Key standards include PCAOB AS 2201 (SOX ITGC), AICPA TSP 100 (SOC 2), and SAMA ITGF domain IT-2.

Why it matters

The pressure on IT Audit 360 programmes is shifting in specific, observable ways:

• PCAOB AS 2201.39 requires external auditors to evaluate ITGC as part of integrated audit; inadequate ITGC scope means reperformance at year-end, adding AED 200,000–600,000 in incremental external audit fees.
• SAMA ITGF and SAMA CSF 3.2 jointly mandate documented ITGC scope aligned to critical financial and operational systems; regulators cite scope gaps as high-severity observations.
• SOC 2 Type II users — large enterprise customers and insurers — contractually require CC6.1 through CC9.2 control coverage; missing systems in scope trigger customer audit rights clauses.
• A unified ITGC scope matrix reduces control-testing effort 20–35% compared to separate SOX, SOC 2, and SAMA programmes running in parallel silos.

Evidence sources to capture

What an auditor or reviewer will sample for — wire each source into your evidence repository before the next review cycle:

• System inventory linked to financial processes — GL, AP, AR, payroll, consolidation tools — with criticality and SOX in-scope flag.
• SOX risk-and-control matrix (RCM) — process-to-system-to-control mapping with control frequency and PCAOB key-control designation.
• SOC 2 trust services criteria mapping table — TSP CC6.1 (logical access), CC8.1 (change management), CC7.2 (system monitoring) linked to each in-scope system.
• SAMA ITGF domain assessment workbook — IT-2 (access management) and IT-4 (change management) control statements mapped to evidence artefacts.
• Application owner attestations — business process owner confirmation that system is in scope and data classification is accurate.

Recommended next actions

A 90-day plan, sequenced so each step produces evidence the next step depends on:

• Day 0-30: IT Audit Lead builds a unified ITGC scope matrix listing each in-scope system once, with columns for SOX applicability, SOC 2 TSP mapping, and SAMA ITGF domain.
• Day 31-60: Rationalise test scripts so each control is tested once with the resulting evidence reused across frameworks; document reliance positions with external auditors.
• Day 61-90: Present unified scope to external auditor and SAMA relationship manager for pre-agreement; capture approvals in the engagement planning memo.
• Day 90+: Execute ITGC testing using the rationalised script set; share working papers with external auditor under an agreed reliance protocol to minimise duplication.
• Ongoing: Update scope matrix within 30 days of any new system going live or financial process change; obtain CISO and CFO re-approval annually.

Example metrics

Instrument these and report them monthly to the executive sponsor; sustained adverse trends become board-level conversations:

• ITGC scope matrix covers 100% of SOX key systems and ≥95% of SAMA ITGF IT-2/IT-4 in-scope systems.
• External auditor reliance on internal ITGC work ≥60% of key controls tested — target by Year 2.
• ITGC deficiencies rated significant deficiency or material weakness: target 0 at year-end SOX opinion.
• Time to update scope matrix after new system go-live ≤30 calendar days.
• Duplicate control testing effort (same control tested twice across frameworks) ≤10% of total ITGC test hours.

A the next two quarters working plan

MAST Consulting Group runs this IT Audit 360 work in four moves. Each move is short, evidence-producing, and signed off by a Lead Practitioner before the next begins.

• Frame (week 1). Confirm scope, regulators in play, and the decisions the work has to enable — referenced against the ITGC universe (access, change, operations, SDLC). Without that framing, the rest becomes a documentation exercise the audit committee will not read.
• Diagnose (weeks 2–4). Walk through deficiency evaluation and ITGC scope memo as they exist today. Capture not just gaps but the design decisions behind every existing control — those are usually where audit findings hide.
• Design (weeks 5–8). Make the contested choices early and pre-clear them with SOX-equivalent regulators in listed jurisdictions. Document the rationale; IT Audit 360 reviewers care more about reasoned decisions than perfect ones.
• Operate (weeks 9–12). Move evidence collection into audit-analytics for population tests and ServiceNow / Jira for change evidence. A control that depends on a separate GRC tool nobody opens will fail within two cycles.

Pitfalls we keep seeing

Across MAST Consulting Group's IT Audit 360 portfolio, the same recurring failure modes show up cycle after cycle. None are exotic; all are expensive when they reach the audit report.

• Pattern: key reports not subjected to completeness and accuracy testing. What good looks like: the same control evidenced inside the workflow it governs, not separately for the audit.
• Pattern: access reviews completed without independent reviewer or evidence of action. What good looks like: the same control evidenced inside the workflow it governs, not separately for the audit.
• Pattern: change tickets without approval evidence linkable to deployment. What good looks like: the same control evidenced inside the workflow it governs, not separately for the audit.
• Pattern: privileged users not reconciled to HR for terminations within the agreed cadence. What good looks like: the same control evidenced inside the workflow it governs, not separately for the audit.

Tooling we actually reach for

MAST Consulting Group is deliberately tool-agnostic, but in practice the same shortlist keeps appearing on IT Audit 360 engagements because the integrations are cheap and the evidence is defensible:

• audit-analytics for population tests — used not because it is fashionable, but because the audit trail it generates is one the reviewer accepts on the first ask.
• ServiceNow / Jira for change evidence — used not because it is fashionable, but because the audit trail it generates is one the reviewer accepts on the first ask.
• Entra / Okta for access governance — used not because it is fashionable, but because the audit trail it generates is one the reviewer accepts on the first ask.

How MAST Consulting Group can help

MAST Consulting Group runs IT Audit 360 programmes for banks, insurers, healthcare networks, payments providers, telcos and government entities across the UAE, KSA, India and the wider GCC. We bring Lead Practitioners, sector specialists, and a working library of policies, risk methodologies and evidence templates that have passed audit at firms recognisable to your board.

If anything in this playbook is relevant to a programme you are scoping or rescuing, the fastest next step is a 30-minute working session with the practice lead. We will look at your specific situation, share what we have seen work for IT Audit 360 programmes at similar scale, and tell you honestly if the work is something you should bring to us or run in-house.