04 Nov 2026 By CISO Consulting team 0 views 5 min read

SAMA CRFR Remediation Dependencies: Map Before Assigning

Assigning SAMA CRFR findings to domain owners before mapping technical dependencies causes rework when infrastructure changes mid-program. This article sets out a dependency-mapping method for sequencing cross-domain remediation.

A programme manager and two colleagues at a table reviewing a printed dependency diagram in a bright office.
In this article
  1. Why dependencies matter in a CRFR program
  2. Five dependencies to map before assigning owners
  3. Three circular-reference patterns to look for
  4. 1. The evidence loop
  5. 2. The shared platform loop
  6. 3. The ownership loop
  7. A sensible order of work
  8. Governance that keeps the map useful
  9. How we help
  10. Next step

Most remediation programs begin the same way: the findings list is split by domain, each domain owner receives a set, and work starts. The problem appears weeks later, when a change made to satisfy one finding alters the systems, configurations or records that another finding depends on. Evidence already collected becomes stale, and the work is repeated. This article describes how to identify SAMA CRFR remediation dependencies before owners are assigned, so that the sequence of work protects the evidence rather than undermining it.

Why dependencies matter in a CRFR program

The SAMA Cyber Resilience Fundamentals Requirements (CRFR) set out expectations for cyber resilience at institutions regulated by SAMA. Findings raised against them rarely sit neatly inside one domain. A gap in one area often points to a control that is owned, built or evidenced elsewhere.

Assigning by domain is administratively convenient, but it treats findings as independent. They are not. If a finding in one domain relies on a control from another, the order in which the two are fixed decides whether the first fix survives the second.

Five dependencies to map before assigning owners

For each finding, record the following before any owner is named. The aim is a short, factual dependency note, not a long analysis.

  1. Technical platform dependency. Which systems, tools or configurations must change for the control to work? If another finding will change the same platform, the two should be sequenced together.
  2. Control dependency. Does the finding rely on another control being operational first, for example a monitoring control that presupposes a defined asset inventory or access model?
  3. Evidence dependency. What artefacts will prove closure, and could another remediation change or invalidate them? Evidence should be collected after the last change that affects it, not before.
  4. Process and ownership dependency. Which teams operate the control day to day? A control owned by one function but run by another needs both named before work is planned.
  5. Third-party and timing dependency. Are suppliers, procurement cycles, change freezes or regulatory deadlines constraining when the work can happen?

Access is a frequent hidden dependency. Findings that touch privileged access, joiner-mover-leaver processes or periodic access reviews often underpin evidence for several other controls, so they usually belong early in the sequence.

Three circular-reference patterns to look for

Circular references arise when finding A needs control B to be complete, and finding B needs control A. They are most common when one domain's findings point to controls that sit in another. We do not quote a figure for their effect on timelines; the practical point is that they stall work quietly, because each owner is waiting on the other. Three patterns recur.

1. The evidence loop

Finding A cannot be evidenced until control B is operating, but control B's own evidence depends on the output of control A. Each owner sees the other as the blocker. The resolution is to agree which control is stood up first in a minimum viable form, evidence it, then mature both.

2. The shared platform loop

Two findings require changes to the same platform, and each change assumes the other has already happened. Teams implement in parallel, and the second change overwrites or contradicts the first. The resolution is to merge the two into a single change with one owner and one test plan.

3. The ownership loop

A control is formally owned by one function, but the finding can only be closed by actions another function controls, which in turn waits on the first. The resolution is to name a single accountable owner for closure and record the supporting owner explicitly.

A sensible order of work

  1. Inventory the findings and tag each with the five dependency types above.
  2. Draw the dependency graph. A simple list of "depends on" pairs is enough. Look for cycles.
  3. Break each cycle using the resolutions above, and record the decision.
  4. Sequence by foundation first. Platform, identity and inventory-type controls precede the controls that rely on them.
  5. Assign owners only after sequencing, with each owner holding a coherent block of work rather than an arbitrary slice of the list.
  6. Schedule evidence collection last within each block, after the final change that affects it.
  7. Re-check the map whenever infrastructure changes are approved. The map is a living part of the program, not a start-up exercise.

Governance that keeps the map useful

A dependency map only helps if it is maintained. Keep it in the same place as the risk, assumption, issue and dependency log, review it at each status meeting, and ask a standing question of every proposed change: which open findings does this affect? Changes that touch the platforms behind several findings should be raised to the steering committee, not decided inside one domain.

How we help

Our Regulatory Compliance Remediation Program is built for exactly this stage. We run your remediation program after an assessment or regulatory review: prioritizing gaps, coordinating owners, implementing controls and building the evidence that closes each finding. The work follows four steps: Prioritize, Mobilize, Remediate and Prove. In the first, gaps are ranked by risk, regulatory deadline and effort, which is where dependency mapping informs the sequence. In Mobilize, owners, plans and governance are agreed.

During delivery, the program includes a program management office, control implementation support and evidence review before closure. Deliverables include a remediation roadmap, a weekly status and RAID log, evidence packs per control, a monthly steering committee report and a closure report for the regulator. The program covers SAMA CRFR alongside SAMA CSF and NCA ECC, and typically runs for 3–9 months on a retainer basis.

We work alongside your internal team, which is the usual model. We provide the program discipline and specialist depth; your teams own and operate the controls.

Next step

If your CRFR findings already sit with domain owners, a dependency review is a sensible first step before further work is committed. Speak with us about the Regulatory Compliance Remediation Program to map your findings, sequence the work and build evidence that a reviewer will accept.

Tags: SAMA CRFR Remediation Regulatory compliance Program management Evidence Cyber resilience
Readiness self-check

How ready are you? Find out in two minutes

Answer a few questions for your framework. You get a score, your biggest gaps and — if you want it — a detailed assessment from our team.

Ready to talk about your compliance?

Tell us where you stand. We will show you the shortest path to what your regulator expects.

Regulatory updates in your inbox

SAMA, NCA and SDAIA changes and what they mean for your institution — once a month.

E-mails in

We confirm by e-mail; unsubscribe any time. Manage your subscription · Past issues

Schedule a Free Assessment