Most of the advice written about NCA assessments is written by people preparing for one. Very little of it is written by people who have sat in the other chair, read the evidence pack, and weighed it against the control text.
In 2023 I conducted ECC and TCC audits, and cloud service provider reviews against CCC, as an NCA representative. I prepared the working papers and the findings reports. What follows is what that work actually involves: a composite of how the engagements I worked ran, not a statement of NCA procedure; practice varies by engagement and evolves. No entity is named, nothing here is drawn from a specific engagement, and nothing described goes beyond what any organisation that has been through an assessment already watched happen in its own meeting rooms.
If you are preparing, the useful thing is not a longer checklist. It is understanding what the person opposite you is doing with their time.
How the engagement gets scoped
In the engagements I worked, scope was settled before anyone arrived, and it was settled twice.
The first version is the one the entity submits. Its applicability statement, its list of critical systems, its sites, its declared boundary. That version is a claim.
The second version is the one the assessor builds by testing the first against the entity’s own records. If the applicability statement says a control is not applicable, there has to be a reason in the record, not a sentence in a covering letter. If the critical systems list has four systems and the asset inventory has a database that carries the same data with a different owner, the scope has just moved. If an outsourced function sits outside the declared boundary but the service it supports is in scope, the boundary was drawn for convenience.
This is the single most common place a program loses control of its own assessment. The entity assumes scope is a negotiation held at the opening meeting. It is not. It is an inference the assessor draws from the inventory, the contracts, the network diagram, and the org chart. If those four documents do not agree with each other, expect the scope to drift to the widest reading, because the narrower one cannot be evidenced.
Scoping also fixes the sample. Access reviews are not assessed in the abstract; a period is chosen and specific systems and specific users are pulled. Change records are not assessed in the abstract; particular changes are traced end to end. Do not expect to be told in advance which ones; that is what sampling is for.
What the assessor reads before day one
By the time the opening meeting starts, the reading is done. In rough order of what it is worth:
Prior findings and their closure evidence. This is the highest-value document in the pack and the one entities underestimate. A finding that was closed with a policy amendment, when the finding was about an operating practice, tells you the entity’s remediation habit. Repeat findings are read as a governance signal, not a control signal.
The asset, data and service inventory. Everything downstream depends on it. Owner, classification, criticality, and the date it was last refreshed. An inventory with no refresh date is an inventory that was built for the last assessment.
The policy set, with approval and review dates. Read for two things: whether the clauses are enforceable, and whether a procedure exists underneath them. “The organisation shall ensure appropriate protection” cannot be tested, so it cannot be evidenced, so it will not help you.
The org chart against the access lists. More on that below.
The self-assessment. Where the entity has rated itself fully compliant, the assessor now has a specific claim to test. Where the entity has rated itself honestly short, the assessor spends less time there. Overstating a self-assessment does not buy a better result. It redirects scrutiny to exactly the controls you least want examined.
The third-party readiness report, if one is offered. Read for the assessor’s own benefit: it shows what the entity has already been told, and it shows which controls the readiness reviewer chose not to look at.
The evidence that gets rejected, and why
Evidence is rejected far more often for form than for substance. The control is frequently in place. The artefact just cannot prove it.
The recurring patterns:
Screenshots with no timestamp, hostname, or logged-in user. A cropped console window showing a setting proves that a setting existed somewhere, at some point, on something. It does not prove it exists in production today, on the system in scope. Same problem with tool reports where the filter bar and date range have been cut out of the image.
Policies with no approval date, no review date, and no version history. A policy that has never been reviewed is not evidence of governance; several standards require periodic review, so an undated policy is itself the finding.
Org charts that contradict access lists. This one is close to universal. The chart shows a role that no longer exists, or shows an approver who left, while the privileged access list still carries their account. Or the chart shows a segregation of duties that the entitlements do not implement: the same person approves the change and deploys it. When the two documents disagree, the access list wins, because it is the live system state. The chart is a drawing.
Evidence created the week the window opened. A quarterly review with four records all produced in the last nine days is not a quarterly review. Recurring controls need recurring artefacts, spaced across the period.
A single artefact offered as proof of a recurring control. One completed access review, one backup restore test, one awareness session. The control text usually specifies a cadence. One instance evidences one instance.
Approvals that are asserted rather than recorded. A ticket showing a request and a completion, with the authorisation step invisible because it happened verbally or in a chat. If the workflow does not capture the approval, the approval is not in place, however real it was.
An English policy set with no Arabic operating procedure. Where the workforce operates in Arabic, the documents pass reading and fail at the point of use. Staff interviews expose the gap quickly.
None of this is pedantry. An assessor’s conclusion has to survive being challenged by the entity, and later re-read by someone who was not in the room. If the artefact does not carry its own provenance, it cannot carry a conclusion.
The gaps third-party readiness reviews consistently miss
Readiness reviews are useful. But the ones I read while assessing missed the same things, and they missed them for structural reasons.
They test the document, not the operation. A readiness reviewer maps a control to a policy clause and marks it covered. An assessor asks who performed it, when, on what, and asks to see the output. Coverage on paper and evidence of performance are different findings.
They accept the entity’s scope. The reviewer is engaged by the entity and works from the boundary the entity supplies. That means the systems most likely to be out of compliance, the ones nobody wanted to declare, are often outside the review by construction.
They score on presence, not on effect. The control exists, so it is green. Whether it produced anything, whether anyone acted on what it produced, whether the exceptions it generated were ever closed, is a different question and usually not asked.
They ignore cadence. Periodicity is where mature-looking programs fail. Reviews performed once. Tests performed once. Logs reviewed until the person who reviewed them changed jobs.
They skip the exception register. Exceptions are the most informative document in a program. A register full of items with no expiry, no compensating control, and no risk acceptance signature is a program running on permanent waivers. The readiness reviews I saw rarely opened it. Assessors open it early.
They stop at the boundary of a supplier or a cloud tenancy. The contract clause, the shared responsibility split, the entity’s own configuration of the platform. Readiness reviews treat the supplier’s certificate as the answer. A certificate covers the supplier’s controls, not the entity’s use of them.
They accept the GRC tool’s output as evidence. A dashboard reporting compliance is reporting what was keyed into it. The assessor traces two or three records from the dashboard back to source and forms a view of the whole population from what comes back.
What a findings report contains
Not a score, and not a narrative. The reports I worked on were a chain of traceable observations, each of which had to stand alone.
Per finding: the requirement as written in the standard; the scope element it applies to; what was examined, named specifically, with dates; what was observed; the gap stated as a difference between requirement and observation, not as an opinion; the risk that follows; a recommendation; and the accountable owner. Behind each finding sit the working papers: the artefacts examined, who provided them, when, and the interview notes that corroborate or contradict them.
Two things about that structure matter to anyone being assessed.
First, a finding is a comparison, not a judgement. The strongest response to a draft finding is evidence that changes the observation. The weakest is disagreement with the conclusion while the observation stands.
Second, the report is written to be re-read by people who were not present, including your own board and, later, a different assessor. That is why provenance on evidence matters so much. An assessor cannot write a defensible finding on an artefact they cannot describe, and cannot write a defensible pass either.
Three KSA-specific realities
Three things shape Saudi programs that international playbooks miss.
Data-handling habits predate the PDPL. Staff practices formed before the law and its Implementing Regulations persist long after both are in force. Awareness programs that assume a blank slate fail; the ones that work start from the habits people actually have.
Hierarchy is an asset. A named executive sponsor, a steering cadence, and clear sign-off chains accelerate adoption when used deliberately. Programs that fight the org chart lose to it.
Sequence with the inspection calendar, not the project plan. Known assessment and examination windows anchor the plan, and ad-hoc regulator requests arrive whenever they arrive. The rollout moves; the calendar does not wait.
And one principle that spans all three: declare your translations. Programs built on ISO or NIST work in KSA only when the tailoring to NCA and SAMA obligations is explicit. Hidden relabeling reads as ignorance, and declared translation reads as fluency.
What to have ready before the window opens
Practical, and in the order I would do it:
- A named coordinator with authority. One person who can obtain any document without escalation. Assessments slow to the speed of whoever has to ask permission.
- An evidence index, control by control. For each applicable control: the artefact, its location, its owner, its date. Building this index is the readiness exercise. It will find your gaps faster than any review will.
- Dates on everything. Approval date, review date, next review date, version. If a document cannot carry a date, it cannot carry a control.
- The recurring evidence, spread across the period. Access reviews, log reviews, vulnerability cycles, backup restore tests, awareness delivery, supplier reviews. Spaced, not batched.
- The exception register, cleaned. Every open item with an owner, a compensating control, a risk acceptance, and an expiry date. Expired items either closed or re-accepted deliberately.
- Prior findings, with closure evidence that matches the finding. If the finding was operational, the closure evidence has to be operational.
- Arabic procedures for anything staff perform. Then check that staff can describe what they do, because they will be asked.
- Read-only access arranged in advance, with an escort. Live system views settle in minutes what document trails argue about for days.
- The right people in the building on the right days. The person who runs the control, not only the person who owns the policy.
Do those nine things and the assessment becomes an examination of your program rather than a search for your filing.
The other side of the table
I now sit on the other side of this table. My work is inspection readiness inside a regulated institution, which means everything above has become a description of what is coming for me rather than what I am bringing. The change is smaller than I expected. The habits that make an assessment go well are the same habits that make a control work: someone owns it, it runs on a cadence, it produces an artefact with a date on it, and the artefact matches what the person actually does. Programs that build for that are not preparing for assessments. They are operating, and the assessment is a sampling of something already true. Programs that build for the assessment produce a filing exercise every cycle, and the assessor can tell the difference in the first hour.
Educational, not legal advice. Nothing above describes any specific organisation or engagement. Verify against official NCA sources.