Does NIST CSF 2.0 still apply when a cloud provider runs our systems?
Yes. NIST's CSF FAQs state that the framework applies whether an organization operates its own assets or another party operates them as a service, so a cloud-hosted workload stays inside the scope of your CSF alignment. NIST also offers no certification for CSF alignment and has no plans for a conformity assessment program. Your organization owns the controls, and if a customer needs assurance, an independent party must test them. Your cloud provider's own reports do not establish your alignment on their own.
The practical answer depends on three things: the provider model (infrastructure, platform or software as a service), the data your workloads process, and which outcomes the provider actually covers. A provider may run the physical environment and parts of the platform while you still own identity, configuration, data classification, logging and incident response. Start with a written responsibility matrix that maps each CSF Subcategory to a named owner, either you or the provider. GV.RM-04 is the outcome to anchor this, because its Implementation Example describes documenting the conditions under which shared responsibility models are acceptable.
Then check what the provider lets you see. DE.CM-06 has Implementation Examples covering monitoring of cloud services and other providers for deviations from expected behavior, so confirm which logs, alerts and notifications the contract gives you and how quickly. Ask for evidence of the provider's own control testing, and record where that evidence stops. Confirm these details with the provider and your contract rather than assuming them, since no mapping in this section replaces your own review.
How to monitor cloud providers under DE.CM-06
DE.CM-06 asks you to watch what external providers do with your systems and data, and NIST publishes two Implementation Examples for it. The cards below cover the monitoring points that matter most when your workloads run in a provider's environment. For each one, confirm the exact capability and contract terms with your provider, because what you can see depends on the service model and agreement you sign.
Provider administrative access monitoring
The first Implementation Example covers monitoring remote and onsite administration and maintenance that providers perform on your systems. Ask each provider which of its staff can reach your workloads, under what conditions, and whether you receive a record of those sessions. Confirm whether you can see provider-side administrative actions in logs you own, and how long those records are retained. Agree in writing how you will be notified before a provider engineer accesses your environment.
Deviations from expected provider behavior
The second Implementation Example covers monitoring cloud services, internet service providers and other providers for deviations from expected behavior. Start by writing down what normal looks like for each dependency, such as expected regions, API call patterns, uptime and data flows. Then decide which signals you will collect, such as provider status feeds or your own network and API telemetry, and who reviews them. Confirm which provider events reach your monitoring tools and at what level of detail.
Reviewing provider attestations and incident notices
Providers commonly publish independent audit reports, certifications and security bulletins. Under DE.CM-06, these documents are monitoring inputs, not proof that your own controls work. Set a schedule to obtain the current report, read its scope and exceptions, and check whether the services you use are in scope. Record who receives incident notices from each provider and how quickly those notices reach your incident response team. Confirm the notification path and contacts in writing.
Contractual evidence rights
Monitoring depends on what the contract lets you ask for. Before signing, confirm your right to receive audit reports, logs, incident details and change notices, and the format and timing of each. Check whether the provider allows you to run or commission your own security testing, and what limits apply. Agree on how the provider will notify you of material changes to subprocessors, data locations or service terms. Put these rights into the contract, because a general statement of compliance rarely gives you enough to monitor the provider.
Using the CSA Cloud Controls Matrix mapping to 95 Subcategories
NIST's CSF 2.0 Reference Tool export maps the Cloud Security Alliance's Cloud Controls Matrix v4.0 to 95 of the 106 CSF 2.0 Subcategories, using 193 distinct CCM controls. Treat this mapping as a starting point for cloud evidence, not a finished answer. For each cloud-hosted system in scope, pull the mapped CCM controls for the Subcategories that the system touches, then ask the provider for the artifacts that show those controls operate: audit reports, configuration baselines, identity and access exports, logging and retention settings, and backup and restore test records. Record which provider artifact supports which Subcategory so that an assessor can follow the trail without a meeting.
Eleven Subcategories have no CCM mapping in the export, so the mapping cannot be your only source for cloud evidence. Those gaps usually cover organization-side decisions that a provider cannot prove for you, such as your governance decisions, roles, and risk response choices. Build those from your own policies, risk register, and records of decisions. Confirm the exact list of unmapped Subcategories, and the specific CCM controls behind each mapped row, directly in the official export before you rely on either. Mapping versions change, and a row you copied from a secondary spreadsheet may not match the current NIST file.
Before you accept a CCM-based evidence package from a cloud provider, check whether the control it cites covers your tenant, your configuration choices, or only the provider's shared platform. A provider's independent report may satisfy a control on the platform side while your own settings, such as storage access policies or key ownership, remain your responsibility. Write that boundary into the Subcategory record next to the evidence, so the shared responsibility split is visible for each outcome rather than assumed.
Cloud Community Profiles to consider as a target
NIST's Profiles page lists community profiles built for cloud environments. Each one gives a starting set of CSF 2.0 outcomes that an organization can adopt as its Target Profile, then compare against its Current Profile. Neither profile is a requirement, and both need local tailoring before they describe your cloud risk.
Cloud Security Community Profile
This profile comes from the Cloud Security Alliance and is listed on NIST's Profiles page as a cloud-focused baseline. It is written for organizations that run workloads on services operated by others, so its outcomes focus on how you govern and monitor those services. Check which outcomes it sets for supplier oversight (GV.SC) and continuous monitoring (DE.CM), then decide which of them your own shared responsibility model actually supports. Treat it as a draft target to edit, not a finished list.
Financial Sector Cloud Services Profile
This profile comes from the Cyber Risk Institute and is listed on NIST's Profiles page. A regulated financial customer may adopt it when its supervisors, examiners or contracts ask for a documented cloud baseline, or when it wants a shared vocabulary for cloud risk across its institution. Adoption is a choice made by the organization, not a requirement set by NIST. Confirm with your regulator whether it accepts this profile as evidence before you build your target on it.
Starting from a community profile
A community profile is a draft target, and the work starts when you compare it with your environment. Map each outcome to the cloud services you use, mark the ones your provider handles, and mark the ones you must handle yourself, such as identity configuration, data classification and backup restoration tests. Record the reasons for each change so an assessor can follow the logic. Expect this comparison to take longer than adopting the document unchanged.
Shared responsibility in the target
A target profile should state which outcomes sit with the provider, which sit with you and which are shared. For example, the provider may run physical security and hardware maintenance, while you own access permissions, logging configuration and data security decisions. Write these splits into the profile notes and link each one to the contract or provider documentation that supports it. Without this, a Target Profile can claim outcomes that no one actually operates.
Evidence the profile will need
Each outcome you keep in the target needs evidence that an assessor can inspect, such as configuration exports, provider audit reports you have reviewed, monitoring alerts and restore test records. Ask which provider reports cover which outcomes, and whether they reach the scope of your own workloads. Gaps in this evidence tell you where the target is aspirational rather than achievable. Confirm the provider's reporting terms before you commit to any outcome that depends on them.
Questions buyers ask about cloud and NIST CSF 2.0
Does NIST certify cloud alignment with the CSF?
No. NIST states that it does not offer certifications or endorsements of CSF-related products, implementations or services, and it has no plans for a conformity assessment program. Any claim that a cloud environment is "NIST CSF certified" should be questioned. The organization owns its alignment, and the most credible evidence is a documented Current Profile, mapped controls and, where the contract requires it, a report from an independent assessor. Ask the assessor which standard or report type they issue, and ask the cloud provider which of its own attestations cover the services in scope. NIST CSF FAQs explains NIST's position on voluntary use.
What drives the effort of a NIST CSF review for a cloud-hosted environment?
The main driver is how many services and providers sit inside the boundary and how clearly responsibilities are split between you and each of them. Effort rises with the number of accounts, regions, managed services, SaaS tools and third-party connections, and with how many of those hold regulated or sensitive data. Each provider adds a shared responsibility question for every Subcategory it touches. Effort falls when the cloud estate is codified, inventoried and logged in one place, and when provider attestations and configuration baselines already exist. Ask for the effort to be broken down by account and by Function so that you can see where the time goes.
Can our own team map cloud controls to the CSF without outside help?
Often yes, provided someone owns the mapping and understands both the cloud architecture and the CSF Subcategories. The Reference Tool export links Subcategories to Implementation Examples and informative references, so an internal team can start from those rather than from a blank page. Outside help tends to add value in three places: testing whether the mapping holds up against real configurations, challenging weak evidence before an assessor does, and keeping the mapping current as services change. Before deciding, check whether your team can name the owner of each Subcategory and produce evidence for it on request.
What does the cloud team need to contribute to the mapping?
The cloud team supplies the facts the mapping depends on. In practice this means an accurate inventory of accounts, subscriptions, workloads and managed services; the identity model and privileged access paths; network segmentation and logging configuration; backup and recovery design; and the provider monitoring that covers remote administration and deviations from expected behavior. They also document the shared responsibility model for each service, including which party handles patching, key management and log retention. Ask whether the team can produce these items within an agreed window, because gaps in this input usually slow the whole exercise more than the framework work itself.
How long does the first pass usually take?
The duration depends mainly on the size of the cloud estate, the state of the existing inventory and documentation, and how many Functions the scope includes. A first pass over a small, well-documented environment can be much shorter than one that spans several providers and legacy systems, and no single timeline applies to every organization. NIST does not publish an effort estimate for CSF adoption in the sources used here, so treat any number quoted to you as a vendor assumption. Ask for a written scope, a list of assumptions about the estate, and milestones tied to deliverables before accepting a timeline.
What evidence should a customer accept for cloud-hosted controls?
A customer should accept evidence that is specific, current and traceable to the Subcategory it supports. Useful items include a Current Profile that names the cloud services in scope, a documented shared responsibility matrix, configuration exports or policy-as-code results, access review records, log samples from the monitoring stack, and backup restore test results. For provider-operated controls, accept the provider's independent assessment report only after confirming that it covers the specific services and regions you use and that its period overlaps your period of reliance. Reject a general statement that a provider is "compliant" with no scope or date.
What usually stalls cloud alignment work
Cloud alignment with NIST CSF 2.0 rarely fails on technology alone. It stalls on assumptions about who owns which outcome, on documentation that never gets written, and on evidence that never arrives from the provider. The four cards below cover the blockers we see most often and a practical step to avoid each one.
Assuming the provider's certification covers you
A provider's independent report or certificate describes the provider's own controls, not yours. Your configurations, identities, data classification and application logic sit outside that scope unless an assessor has tested them. Before relying on any provider attestation, list the Subcategories your team still owns, such as GV.SC outcomes and PR.AA access control, and confirm which of them the provider's report does not address. Ask the provider for the exact scope statement and its complementary customer controls.
Leaving shared responsibility undocumented
Many teams agree the split verbally and never write it down, so nobody can say who patches a managed database or who reviews its logs at 2 a.m. NIST's GV.RM-04 Implementation Example describes documenting the conditions under which shared responsibility models are acceptable. Build a responsibility matrix that names an owner for each Subcategory your workloads touch, and review it whenever the provider changes a service or your architecture changes.
Missing provider monitoring evidence
DE.CM-06 expects you to monitor cloud services and other providers for deviations from expected behavior, which requires data you can actually see. Teams often discover that the provider logs administrative actions but does not share them, or that retention is shorter than the period an incident review needs. Confirm in writing which provider logs you will receive, how often, in what format and for how long, and test that the feed reaches your monitoring platform before you need it.
Treating Community Profiles as mandatory
NIST's CSF Profiles page lists community baselines, including a Cloud Security Community Profile from the Cloud Security Alliance and a Financial Sector Cloud Services Community Profile from the Cyber Risk Institute. These are optional starting points that you can adopt or adapt as a target. Using one without comparing it to your own risk, regulatory duties and current Profile can add outcomes you do not need and miss the ones you do. Treat each profile as a draft, record which outcomes you excluded and why, and confirm with your regulator or customer whether they expect a specific baseline.
Who owns the controls, who prepares evidence and who issues assurance
The organization owns its cybersecurity outcomes, its risk decisions and the shared responsibility split with each cloud provider, even when an implementation partner builds the environment. Ownership stays with the organization for choosing which CSF 2.0 Subcategories apply to its cloud workloads, for accepting residual risk, and for deciding which controls the cloud provider covers and which it must cover itself. NIST's GV.RM-04 Implementation Example describes documenting the conditions under which shared responsibility models are acceptable, and that documentation is a leadership decision, not a deliverable an integrator can sign on the organization's behalf.
An implementation partner such as DeployOpen can prepare the working parts in the client's own cloud accounts: account structure, logging and monitoring configuration, identity settings, backup and recovery settings, and the records that show each configuration exists and was reviewed. That work produces evidence, but it does not produce assurance. Before the engagement starts, confirm in writing which accounts, subscriptions or projects are in scope, who holds administrator access after handover, and where the evidence will be stored and who may read it.
Only an independent auditor, assessor or certification body issues a report or opinion on the controls. NIST states that it does not offer certifications or endorsements of CSF-related implementations or services and has no plans for a conformity assessment program, so no document can claim CSF certification. If a customer asks for proof of cloud alignment, ask the assessor whether they will test your Current Profile and the shared responsibility records directly, and ask the cloud provider which attestation reports cover the services you use. Those reports describe the provider's side only.
How DeployOpen prepares cloud-hosted systems and evidence for NIST CSF
DeployOpen works on the parts of NIST CSF 2.0 that cloud services touch: which outcomes stay with your organization, which the provider delivers, and what evidence shows each. We plan and implement self-hosted open-source platforms inside your own cloud accounts, then document the shared responsibility split so an assessor or customer can follow it. Independent auditors, not DeployOpen, judge the result.
How we scope
- We agree a written scope listing which cloud accounts, workloads and providers fall inside the assessment.
- We map each in-scope GV.RM-04 and GV.SC outcome to the party that owns it: your team, the cloud provider or a managed partner.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work starts.
How we build
- We configure self-hosted open-source platforms in your cloud accounts, with logging and monitoring that cover provider activity under DE.CM-06.
- We document the shared responsibility model for each service, stating which controls your team operates and which the provider operates.
- We run security testing of cloud configurations and APIs, and record the findings and fixes as evidence for the relevant outcomes.
How we hand over
- We deliver a current profile and evidence index that maps each outcome to the artifact that shows it, such as configuration exports or log samples.
- We provide a register of provider monitoring actions, review cadence and escalation paths, so your team can run them after handover.
- We walk your staff through the evidence and gaps, and confirm with your assessor which artifacts they will accept before fieldwork.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, scoped in writing.
- We can refresh the shared responsibility documentation when you add a provider, change a service or adopt a new Community Profile.
- We help you track changes to NIST informative references and the CSF 2.0 Reference Tool, so mappings stay current.
