SAMA ITGF Article 7.2 requires financial institutions in the Kingdom to conduct an annual cybersecurity audit. The requirement is clear. What is less clear, in most boardrooms, is whether the audit scope that lands in front of the audit committee will deliver genuine assurance or merely confirm that documentation exists.
The difference matters. An audit that tests whether controls are designed correctly but not whether they operate effectively under real conditions provides limited value. An audit that excludes third-party service providers ignores a boundary where many breaches originate. An audit report that lists findings without distinguishing design gaps from operational failures leaves management unsure where to direct resources.
This article presents three SAMA ITGF cybersecurity audit scope questions every audit committee should ask before approving the annual plan, and explains what evidence internal audit should present when answering each. These questions ensure the audit delivers assurance, not just a checklist.
Question One: Does the Scope Include Testing Detective Controls Under Real Attack Conditions?
Most cybersecurity audits verify that controls exist and are documented. Fewer test whether those controls actually detect threats when they occur.
The distinction is between design effectiveness and operating effectiveness. Design effectiveness asks: is the control configured correctly on paper? Operating effectiveness asks: does the control perform its intended function when adversarial activity occurs?
For detective controls—security monitoring, intrusion detection, log analysis, threat hunting—operating effectiveness can only be confirmed by simulating real attack conditions and observing whether the control triggers an alert, generates a log entry, or prompts a response.
What to Ask
Ask internal audit: "Will the audit test whether our detective controls identify actual attack techniques, or will it review configuration settings and policies?"
If the answer focuses on configuration review, policy documentation, or interviews with the security team, the audit will confirm design but not operation.
What Evidence to Expect
Internal audit should describe how operating effectiveness will be tested. Examples include:
- Executing a sample of MITRE ATT&CK techniques in a controlled environment and verifying that the SIEM generates alerts within defined timeframes.
- Reviewing a sample of security incidents from the past twelve months and tracing each back to the detective control that identified it, confirming that the control operated as designed.
- Testing whether endpoint detection and response tools identify malicious payloads when introduced under controlled conditions.
- Verifying that threat intelligence feeds are ingested, correlated with internal logs, and result in actionable alerts.
If internal audit lacks the capability to perform these tests, the scope should include external specialists who can execute adversarial techniques safely and measure detection coverage. The audit plan should state this explicitly.
Question Two: Are Third-Party Service Providers Included in the Audit Boundary?
SAMA ITGF requires financial institutions to manage cybersecurity risk across the entire technology ecosystem, including third-party service providers. Yet many annual audit scopes limit testing to systems and controls operated directly by the institution.
Third-party providers—cloud platforms, payment processors, core banking vendors, managed security service providers—introduce risk through their own control environments. An audit that excludes these providers from scope cannot provide full assurance over the institution's cybersecurity posture.
What to Ask
Ask internal audit: "Does the audit scope include testing controls at third-party service providers, or does it rely solely on their attestation reports?"
If the answer is that the audit will review SOC 2 reports or ISO 27001 certificates provided by vendors, the audit is accepting assurance from another auditor without independent verification. This may be appropriate for low-risk providers, but not for those with access to customer data, payment systems, or core infrastructure.
What Evidence to Expect
Internal audit should explain how third-party risk will be assessed within the audit. A risk-based approach might include:
- Identifying high-risk third parties based on data access, criticality to operations, and inherent risk.
- For high-risk providers, requesting evidence of specific controls relevant to the institution's risk—not just a generic attestation report.
- Testing the institution's own controls over third-party access, including privileged access management, monitoring of third-party activity, and incident response coordination.
- Reviewing contracts and service-level agreements to confirm that cybersecurity obligations are defined and enforceable.
- Where feasible, conducting on-site or remote testing of critical third-party controls, particularly for providers that do not produce independent attestation reports.
The audit plan should list the third parties in scope and the testing approach for each. If a provider is excluded, the plan should state the rationale—low inherent risk, recent independent audit, or contractual limitations—so the committee can assess whether the exclusion is justified.
Question Three: Will the Audit Report Distinguish Design Gaps from Operational Failures?
Audit findings are not all equal. A control that is poorly designed cannot operate effectively, even if staff follow procedures. A control that is well designed but fails in operation indicates a different problem—training, resource constraints, or process breakdown.
Many audit reports present findings as a flat list, rated by severity, without distinguishing whether the root cause is design or operation. This makes it difficult for management to prioritize remediation and for the audit committee to understand whether the institution's control framework is fundamentally sound or requires redesign.
What to Ask
Ask internal audit: "Will the audit report clearly identify whether each finding relates to control design or operating effectiveness, and will it explain the implication of each?"
If the answer is that findings will be categorized by risk rating only, the report will lack the detail needed for effective governance.
What Evidence to Expect
Internal audit should commit to structuring findings in a way that separates design from operation. A well-structured finding includes:
- Control objective: What the control is intended to achieve.
- Design assessment: Whether the control, as documented and configured, is capable of achieving the objective.
- Operating effectiveness assessment: Whether the control operated as designed during the audit period, supported by evidence from samples tested.
- Root cause: Whether the gap is due to design deficiency, operational failure, or both.
- Management response: The corrective action plan, with accountability and timeline.
For example, a finding might state: "The SIEM is configured to generate alerts for failed login attempts exceeding five attempts within ten minutes (design effective), but a sample of twenty alerts over the past quarter showed that fifteen were not reviewed within the defined four-hour timeframe (operating effectiveness deficient). Root cause: insufficient staffing in the security operations center during evening shifts."
This level of detail allows the audit committee to understand not only what is broken, but why, and to assess whether management's corrective action addresses the root cause.
The audit plan should confirm that findings will be documented in this format, and that the final report will include a summary distinguishing design gaps from operational failures across the control environment.
What This Means for Your Annual Audit Plan
These three questions shift the conversation from compliance—"Have we met the SAMA ITGF requirement for an annual audit?"—to assurance—"Will this audit tell us whether our cybersecurity controls actually work?"
Before approving the annual audit plan, the audit committee should expect internal audit to present:
- A testing approach that includes operating effectiveness for detective controls, with a clear explanation of how adversarial techniques will be simulated or how real incidents will be traced back to detection.
- A list of third-party service providers in scope, with a risk-based rationale for inclusion or exclusion, and a description of how third-party controls will be tested.
- A commitment to report findings in a way that distinguishes design from operation, with root cause analysis and management responses that address the underlying issue.
If internal audit cannot provide these elements, the scope is incomplete. The audit will produce a report, but it will not provide the assurance the committee needs to fulfill its oversight responsibilities.
How We Support Internal Cybersecurity Audits
We perform cybersecurity audits on behalf of, or alongside, your internal audit function—planned, executed and reported to internal audit standards, providing independent assurance for your audit committee by cybersecurity specialists.
Our approach includes risk-based audit planning, design and operating effectiveness testing, sampling and evidence review, rated findings with management responses, and follow-up audits. Each engagement follows a structured process: plan the scope, risks and audit program; conduct fieldwork through testing and evidence collection; produce a report with findings agreed with management; and verify corrective actions through follow-up.
Deliverables include an audit plan and program, working papers, an audit report for the audit committee, and a follow-up report. Each audit typically requires three to six weeks, depending on scope and complexity. We align our work to SAMA ITGF, SAMA Cybersecurity Framework, and NCA Essential Cybersecurity Controls.
If your internal audit function needs support in scoping, executing, or reporting the annual cybersecurity audit required under SAMA ITGF, we can help ensure the audit delivers the assurance your audit committee expects.
