SAMA CSF Level 3 is an evidence problem

We have prepared both kinds of team for a review against the SAMA Cyber Security Framework, and both scored below Level 3 for opposite reasons. The first team was technically strong: fast patching, sharp monitoring, tight access control, and almost none of it written down, approved, or checked on a schedule. The second had a shelf of well-formatted policies, signed and dated, describing a way of working that the systems did not actually follow. One team did the right things with no proof. The other had proof of things it did not do.

Level 3 is where that gap becomes expensive, because it is the minimum SAMA expects of its member organizations and the bar an assessor measures you against. Reaching it has less to do with buying controls than with being able to show, for any date someone picks, that a given control was documented, approved, running, and watched.

What Level 3 is actually measuring

The framework applies across SAMA-regulated member organizations, banks, insurers, finance companies and others, and it organizes controls into four domains: cyber security leadership and governance; cyber security risk management and compliance; cyber security operations and technology; and third party cyber security. Maturity is scored from Level 0 to Level 5, and member organizations are expected to reach at least Level 3.

The sentence that trips teams up is the definition of Level 3 itself. A control sits at Level 3 when it is documented, approved, implemented, and compliance with it is monitored. Read that as four separate tests, because an assessor does. The control must exist in writing. Someone with authority must have approved it, with a date. It must actually run in the live environment. And there must be ongoing checking that it keeps running, with a record of that checking.

This is why the technically strong team failed. Their patching was real, but there was no documented standard that said how fast, no approval of that standard, and no record that anyone verified it month to month. From the assessor’s chair, an undocumented good habit and an absent control produce the same result, because both are missing the one thing being measured.

Take a concrete control to watch the four tests bite. Suppose you patch critical vulnerabilities within fourteen days, and you genuinely do, every time. The first test asks for the written standard that states fourteen days; if the number lives only in the team’s habits, you fail it. The second asks who approved that standard and when, because an unapproved standard is a preference rather than a control. The third test you pass easily, because the patching actually happens. The fourth asks for the record that someone checked, month after month, that the fourteen-day window was met and acted when it slipped. Most strong teams clear tests one through three on this control and lose it on the fourth, because nobody kept the proof that the monitoring itself happened.

The checklist below is the whole bar, control by control. If you cannot tick all of it for a given control, that control is below Level 3, however well it runs.

• There is a written control or procedure that states what must happen.
• A person with authority has approved it, and the approval carries a date.
• The control is operating in the live environment, and not only on paper.
• A scheduled check verifies it keeps operating, and keeps a dated record of each check.
• You can retrieve that record for a date the assessor picks, not one you pick.

How assessors sample, and why it decides your score

The most important thing to understand about an assessment is that nobody asks to see a control work once. The assessor picks samples, usually specific dates or specific records, and asks you to show the control operating for those. Show me the access review for the second quarter. Show me the change ticket for this deployment. Show me the scan report from March and the tickets that closed its findings.

Evidence has to exist for any month in the period under review, and that only happens when the work produced it on its own.

That sampling method destroys the two-weeks-before approach. A team that spends the two weeks before an assessment taking screenshots can prove the control worked on the day of the screenshot and nothing about the other eleven months. When the assessor asks for a random Tuesday in March, there is no record, and the sample fails. Evidence has to exist for any month in the period under review, which only happens when the evidence was a natural output of the work rather than something assembled for the occasion.

Sampling is not the only method an assessor uses. They also interview, and the interview is where a mismatch between the document and the practice surfaces fastest. If your policy says a security committee reviews risk every quarter and the committee chair cannot recall the last meeting, the artifact and the testimony disagree, and the assessor writes down the disagreement. The leadership and governance domain is mostly evidenced this way, through approved policies, dated committee minutes, and a risk appetite the board has actually signed, so keep those records as deliberately as you keep a scan report. A governance control that lives entirely in a slide deck nobody approved sits below Level 3 for the same reason a patching habit does.

Write procedures to match the work for the same reason. The policy-binder failure comes from documenting how the work should be done in a perfect world rather than how it is done in this one. When the written process and the real process diverge, the assessor finds the gap the moment they compare a policy to a ticket, and now the finding reads that your control is not operating as described. That is a worse place to be than a thin policy honestly written, because it implies you either do not know your own process or chose not to describe it. If the real change process has an emergency path, document the emergency path. If access reviews happen quarterly and not monthly, write quarterly.

Make evidence a by-product, not a project

Teams that pass comfortably do not collect evidence. They file it, because the work already created it. A change went through the ticketing system, so the ticket is the evidence. An access review ran and its output was exported and stored, so the export is the evidence. A vulnerability scan ran on a schedule and kept its dated reports, so the reports are the evidence. None of it was produced for an assessor, which is exactly why it is believable and exactly why it exists for any date.

What separates evidence that passes from evidence that does not comes down to three properties. It is dated, so the assessor can tie it to the sample period. It is attributable, so it is clear who produced it and under which control. And it is repeatable, meaning you could produce the equivalent record for any other month without special effort. A screenshot taken in assessment week fails all three: it carries whatever date the clock happened to show, it names no author, and it exists only because someone made it that once. A ticket, an export, or a scheduled report tends to carry all three by construction, which is why the by-product beats the artifact every time.

The flow below is the shape of a Level 3 control. Each step leaves a trace, and the final step is the test the assessor actually runs.

1. 01Documented controlthe standard exists in writing and says what must happen
2. 02Approvedsomeone with authority signed it, with a date
3. 03Implementedthe control runs in the live environment
4. 04Monitoreda scheduled check confirms it keeps running
5. 05Artifact filedeach check leaves a dated record where the owner can find it
6. 06Sampledthe assessor picks a date; you retrieve that date’s record in minutes

Keep an evidence register

The artifact that holds all of this together is an evidence register: a living map from each control to the thing that proves it, who owns it, and how often it refreshes. It turns an assessment-week scramble into a lookup.

Control area	Evidence artifact	Owner	Refresh
Access reviews	Quarterly review export, signed off	IT Security	Quarterly
Vulnerability management	Dated scan reports, remediation tickets	Infrastructure	Monthly
Change management	Change tickets with the approval trail	Platform team	Continuous
Backup and recovery	Restore test results, dated	Infrastructure	Quarterly
Third party oversight	Vendor assessments, signed security clauses	Procurement and Security	Annual, and on onboarding

The register does two useful things at once. It tells you, before an assessor does, where your evidence is thin, and it gives every control a named owner. That second part fixes the most common root cause of a missed sample, which is that everyone assumed someone else held the record. An owner who knows they will be asked for a specific month tends to make sure the month exists.

The risk management and compliance domain tends to produce evidence that is easy to create and easy to let go stale. A risk register exists, but the dates on it show it has not moved in a year, which tells the assessor the monitoring step stopped running. Treat the register itself as a control with a refresh cadence, and keep the minutes of the meeting where risks were reviewed and re-rated. A living document with recent dates is worth more than a thorough one that was clearly written once and filed, because the recent dates are the thing that proves the control is still operating rather than having operated once.

Third party is the row that fails

In our experience the thinnest row in almost every register is third party cyber security, and the reason is structural. The proof lives partly with someone else. You can document that you require a security assessment of a vendor before onboarding, approve that requirement, and run it, but the monitoring step, the part that proves the control keeps operating, depends on a supplier who has their own priorities and their own calendar.

Evidence that domain the way you evidence your own controls. Keep the dated vendor security assessment from onboarding. Keep the signed contract clauses that give you the right to audit, require breach notification within a stated window, and set security obligations. Keep a record of the periodic review you run against active vendors, with the date it ran and what it found. When a provider hosts a payment path or holds customer data, the assessor will sample this domain, and a contract with the right clause and no record of a review since signing is a documented control that is not being monitored. That lands you below Level 3 on the one domain teams most often forget to treat as a control in its own right.

Map one artifact to SAMA and NCA

NCA’s Essential Cybersecurity Controls, in the ECC-2:2024 update, overlap heavily with the SAMA framework in the evidence they ask for. A scan report, an access review export, a vendor assessment, each tends to satisfy a requirement in both. Collecting the artifact once and mapping it twice saves a large amount of duplicated effort, and it keeps your evidence consistent instead of letting two separate hunts produce two slightly different stories.

One artifact you already produce	Where it lands in SAMA CSF	Where it lands in NCA ECC-2:2024
Quarterly access review export, signed	Operations and technology (identity and access)	Identity and access management
Dated vulnerability scan plus remediation tickets	Operations and technology (vulnerability management)	Vulnerabilities management
Board-approved cyber security policy	Leadership and governance	Cybersecurity governance
Vendor security assessment plus contract clauses	Third party cyber security	Third-party and cloud cybersecurity

Treat the mapping at the level of theme, as above, and confirm the exact control alignment against both official texts rather than a table in an article. The point of the table is operational: it tells your owners that one well-kept artifact is doing double duty, so they keep it well.

A 90-day plan

If you are starting from a register that lives in people’s heads, three months is enough to change the result, provided you spend the first month on honesty rather than polish.

Window	Focus	What exists at the end
First 30 days	Build the evidence register; assign one named owner per control	A register that shows, in writing, where evidence is thin
Days 31 to 60	Fix the thin rows, third party first; rewrite procedures to match real work	Vendor evidence collected; procedures that match the tickets
Days 61 to 90	Run an internal sample test on dates you did not choose; close what fails	A dry run that mirrors how the assessor samples

The dry run in the last month is the step most teams skip and the one that tells you the truth. Pick five controls you are confident you operate well, then try to produce the evidence for a date an assessor might choose rather than one you would choose. Wherever you cannot, you have found the exact distance between doing the control and being able to show it. Close those gaps and you are not guessing at your score going into the review.

One scheduling point is specific to regulated entities here. Assessments and regulatory reporting tend to cluster, and the quarter you are preparing evidence in is often the same quarter your team is closing books and handling seasonal transaction peaks. Building the register as a by-product means the evidence is ready regardless of when the review lands, which matters a great deal when the review window overlaps a period your engineers cannot spare two weeks to spend taking screenshots. The whole argument for making evidence a side effect of normal work comes due on exactly the months when you have no slack to produce it any other way.

Sources

1. SAMA Rulebook: Cyber Security Framework, Saudi Central Bank (SAMA), 2024.