A SAMA CSF security architecture review checklist is most useful when it is used before production, while a design can still change without a project delay. Too often the review happens after build, and it ends up checking generic controls rather than the risks specific to the system. A core banking platform, a payment switch and a treasury system each have different trust boundaries, data flows and failure modes.
This checklist gives twelve design questions grouped into four areas. They are written for solution architects, infrastructure managers and CISOs, and they relate to the kind of evidence the SAMA Cyber Security Framework (SAMA CSF) expects to see in its first domain, which covers cyber security leadership and governance. For each question, note the answer, the document that proves it and the owner. If any of the three is missing, treat that as a finding.
How to use this checklist
Run it as a working session with the architect, the infrastructure lead and the application owner in the room. Bring current diagrams, data-flow documents and the design specification. Mark each question as answered with evidence, answered without evidence, or open. Items in the last two states go onto the pre-go-live action list.
Group A: Boundaries and identity
- Network segmentation boundaries. Can you show, on a diagram, which zones the application, database, management plane and external connections sit in, and what traffic is permitted between them? Why it matters: flat or loosely defined zones let a compromise of one component reach the entire platform, and this is the first thing an assessor will ask to see.
- Service account scope. For every service account, is the owner named, the permitted systems listed and interactive logon disabled? Why it matters: payment switches and core banking batch jobs often run under accounts with far more reach than they need.
- API authentication model. Does each internal and third-party API authenticate the calling system, authorize each action and limit request rates? Why it matters: integrations are where trust is most often assumed rather than enforced.
- Privileged access workflow. Is administrative access to production requested, approved, time-limited and recorded, with no standing shared credentials? Why it matters: treasury and core banking administrators hold the ability to move value, so their access needs a traceable path.
Group B: Data protection
- Database encryption at rest and in transit. Which data stores hold sensitive or card-related data, how is each encrypted, and who controls the keys? Why it matters: encryption without clear key ownership gives little assurance and is hard to evidence.
- Session management. What are the session timeout, re-authentication and concurrent-session rules for operator and customer-facing interfaces? Why it matters: treasury dealing screens and back-office consoles are high-value targets for session hijacking.
- Secrets rotation. Where are passwords, API keys and connection strings stored, and how often and by what process are they rotated? Why it matters: secrets embedded in code or configuration files tend to stay unchanged for years.
- Certificate lifecycle. Is there an inventory of certificates with expiry dates, owners and a renewal process? Why it matters: an expired certificate on a payment interface is an availability incident, and a weak one is a confidentiality risk.
Group C: Visibility and resilience
- Logging pipeline. Do application, database, authentication and administrative events reach a central platform, with protected storage, synchronized time and defined retention? Why it matters: if the events are not captured by design, detection and investigation cannot be added cheaply later.
- Backup isolation. Are backups stored where a compromised production account cannot alter or delete them, and have restores been tested? Why it matters: backups reachable from production credentials are exposed to the same attack as the systems they protect.
- Disaster recovery RTO. Is the recovery time objective for the system defined, agreed with the business, and supported by a recovery design that can actually meet it? Why it matters: a stated target with no supporting architecture is an assumption, not a control.
Group D: Governance of change
- Change approval gates. Does the design define who approves production changes, what security checks must pass first, and how emergency changes are reviewed afterwards? Why it matters: the secure design at go-live is only as durable as the change process that follows it.
Turning answers into evidence
For each of the twelve items, keep three things together: the design artifact (diagram, standard or configuration extract), the decision record showing who accepted any residual risk, and the date of the review. This pack is what you present when an internal auditor, a regulator or a board risk committee asks how the system was assessed before it went live.
Some patterns are worth watching for across systems:
- Answers that rely on "the vendor handles that" without a contractual or technical record.
- Diagrams that differ from what was actually built.
- Exceptions granted for go-live with no owner or closure date.
- Controls that exist for production but not for disaster recovery or test environments holding production data.
Scoping the review by system type
Not every question carries the same weight on every platform. For a core banking deployment, spend the most time on service accounts, privileged access and batch interfaces. For a payment switch, concentrate on segmentation, certificate lifecycle, API authentication and availability design. For a treasury system, focus on session management, dealer and approver separation, and the integrity of data flowing to and from market and settlement connections. Use the same twelve questions, but let the system's own threats set the order.
How we can help
If you want an independent view before go-live, our Security Architecture Review looks at new and existing systems and network designs, covering segmentation, identity, data flows, integration and resilience, and recommends practical improvements. The work follows four steps: we collect diagrams, data flows and design documents, model threats against key components and flows, assess controls against secure design principles, and advise on options, trade-offs and agreed actions.
You receive an architecture review report, a threat model for key flows, prioritized design recommendations and reference security patterns. The assessment takes 2–4 weeks per system, and it is aligned to SAMA CSF and NCA ECC.
Start by running the twelve questions internally. Whatever remains open after that session is the scope worth bringing to a review.
