SAMA CSF is written for an organisation rather than a server, so somebody has to translate it into infrastructure requirements. This is that translation, arranged by control area: what each objective asks for, the evidence an assessor will want to see, and a clear split between what a provider supplies, what is shared, and what stays yours regardless of who runs the platform.
One structural point before the tables, because it decides how much of this list is actually your work. Every control below falls into one of three buckets: things the provider does and evidences, things where the provider supplies a capability and you operate it, and things no platform can do on your behalf. Assessors ask about all three, and organisations routinely credit the middle bucket to the provider when it is shared.
Accuracy note. Control objectives and supervisory expectations change. Use this as a working checklist for infrastructure scope, and verify each item against SAMA's current published text and your own supervisory correspondence. This is not legal advice.
The Division of Responsibility
Start here, because getting it wrong produces either duplicated effort or an uncovered gap. Three categories:
The provider's, evidenced by certification. Physical security, environmental controls, hypervisor and storage layer integrity, network isolation, the provider's own personnel screening and change management. You verify these by reviewing certifications and reports, not by testing them yourself.
Shared. Encryption, where the provider supplies the capability and you configure and manage it. Logging, where the platform emits events and you retain and review them. Patching, where the provider handles infrastructure and you handle guest operating systems and applications unless the service is managed.
Yours, always. Governance, risk methodology, policy, awareness training, access approval decisions, data classification, and the evidence that all of it operates. No platform delivers these.
The most common mistake is assuming a certified provider covers the shared column. It does not; it covers its own side and gives you the capability for yours.
Identity and Access
| Requirement | Evidence to keep |
|---|---|
| Unique named accounts, no shared credentials | Account inventory with owner per account |
| Multi-factor authentication on all administrative access | Configuration screenshot plus authentication logs |
| Least privilege, with role definitions | Role-to-permission mapping, approved |
| Privileged access approved before grant | Approval records tied to named requester and approver |
| Periodic access review | Dated review records with sign-off and actions taken |
| Joiner, mover, leaver process executed | Revocation records with timestamps against HR events |
| Session timeout and lockout on failed attempts | Policy configuration export |
The item that fails assessments is the periodic review. Organisations grant access correctly and then never revisit it, so privilege accumulates. A quarterly review with a dated record and evidence of removals is straightforward to run and is exactly what an assessor asks for.
Cryptography
| Requirement | Evidence to keep |
|---|---|
| Data encrypted in transit on all external paths | TLS configuration and a current scan result |
| Data encrypted at rest | Storage encryption configuration and stated algorithm |
| Approved algorithms and key lengths only | Cryptographic standard document, approved internally |
| Documented key management, including rotation | Key management procedure plus rotation records |
| Keys separated from the data they protect | Architecture description showing separation |
| Certificate inventory with expiry tracking | Certificate register and renewal evidence |
Key management is where this domain is usually thin. Encryption at rest is a checkbox on most platforms; who holds the keys, how they rotate, and who could decrypt the data is the question that actually gets asked. Decide whether you need to hold keys yourself, because retrofitting customer-managed keys later is disruptive. For higher assurance, a hardware security module keeps key material in dedicated hardware.
Logging and Monitoring
| Requirement | Evidence to keep |
|---|---|
| Security-relevant events logged across the estate | Log source inventory mapped to systems |
| Centralised collection | Architecture diagram and ingestion evidence |
| Logs protected from modification and deletion | Access controls on the log store, immutability where used |
| Defined retention period, met in practice | Retention policy plus a query proving depth |
| Time synchronised across all sources | NTP configuration |
| Alerts reviewed by a named function | Triage records showing decisions, not just alert volume |
The distinction that matters is between collecting logs and monitoring them. A platform that ingests everything and alerts nobody satisfies the first half and fails the second, and the second is what the framework asks for. If you have no capacity to staff review, SOC services exist for exactly this gap, and outsourcing it is an accepted answer provided the arrangement is governed like any other third party.
Resilience and Recovery
| Requirement | Evidence to keep |
|---|---|
| Documented recovery point and recovery time objectives | Approved RPO and RTO per system, by criticality |
| Backups taken to schedule | Backup job history |
| Backups stored separately from primary data | Architecture showing separation, ideally another site |
| Restoration tested, not assumed | Dated restore test records with outcome and duration |
| Continuity plan exercised | Exercise report including what failed and what changed |
| Redundancy appropriate to criticality | Failover design plus evidence it was tested |
Two items carry disproportionate weight. A tested restore, because an untested backup is an assumption and assessors know it. And a continuity exercise that records failures, because an exercise where everything worked perfectly reads as an exercise that was not really run.
Recovery objectives deserve a real decision rather than an aspiration. Writing a fifteen-minute RTO for a system whose recovery has never been timed creates a documented gap between the stated objective and demonstrable capability, which is worse than an honest longer figure.
Vulnerability and Change Management
| Requirement | Evidence to keep |
|---|---|
| Regular vulnerability scanning | Scan schedule and reports over time |
| Remediation within defined timeframes by severity | Timeframe policy plus closure records against it |
| Documented exceptions with risk acceptance | Exception register with named acceptor and expiry |
| Periodic penetration testing | Test reports and remediation evidence |
| Changes approved before implementation | Change records with approval and rollback plan |
| Segregated environments for development and production | Architecture and access evidence showing separation |
The exception register is the item most often missing. Every estate has vulnerabilities that cannot be remediated on schedule, and that is acceptable when the risk is documented, accepted by someone with authority, and given an expiry date. Undocumented, the same situation is a control failure.
Third Party and Cloud
| Requirement | Evidence to keep |
|---|---|
| Due diligence before engagement | Assessment record with certifications reviewed |
| Security terms in the contract | Executed contract with the security schedule |
| Incident notification obligations and timeframes | Contractual clause, and a tested contact path |
| Audit or assurance rights | Contract clause, plus reports actually obtained |
| Data location known and recorded | Statement of where data is stored and processed |
| Ongoing oversight, not onboarding only | Periodic review records across the contract life |
| Exit plan and data return or destruction | Documented exit provisions and evidence they are feasible |
| Regulatory notification where the arrangement is material | Correspondence or record of no objection |
The last row is the one that derails projects. Where an arrangement counts as material outsourcing, regulatory notification or no objection may be required before proceeding, and confirming that at the point of provider selection costs nothing. Confirming it after signing can mean unwinding a migration.
The exit plan is the row people write and never test. If the exit provision assumes you can extract all data in a usable format within a defined period, establish that this is actually true while you have a working relationship with the provider.
What MassiveGRID Supplies, and What It Does Not
Being precise about this is more useful than a compliance badge.
Supplied and evidenced. An ISO 27001 certified control environment with SOC 2 Type II audit coverage, which shortens the due diligence row above. Encryption in transit and at rest. Role-based access with multi-factor authentication. Audit logging. Resilience through Proxmox high-availability clustering with automatic failover, over Ceph storage replicating every block three times across independent drives. Physical and environmental controls at the facility level. Managed patching where you take a managed service.
Available as a service. Log review and alert triage through SOC services, infrastructure monitoring through NOC services, backup with verified restores through backup services, and key protection through a hardware security module.
Not supplied by anyone. Your governance, risk methodology, policy set, data classification, access approval decisions, and the maturity assessment itself.
The placement question. MassiveGRID deploys into partner facilities operated by Equinix, Digital Realty, Sparkle and NTT, a published footprint of more than 700 datacenters across 85 metros, 30 countries and six continents, and infrastructure can be ordered in any of them, so the data location row above usually has a good answer, and it is a real answer rather than a nearest-region compromise. Saudi Arabia is not currently among the listed metros, so establish early whether your data carries an in-Kingdom residency obligation, confirm availability directly, and treat colocation or a private cloud in a local facility as the fallback. This changes the shortlist rather than the configuration. Our guide to Saudi PDPL and data residency covers how to tell which data is affected.
See the SAMA CSF infrastructure alignment, or start with what SAMA CSF is and how its maturity model works.