NIST CSF Alignment for Deployment Platforms: 7 Artifacts to Demand (and Why No Vendor Is "NIST Certified")

Key Points:

• No deployment platform can be "NIST CSF certified." The NIST Cybersecurity Framework 2.0 (NIST CSWP 29, published February 26, 2024) is a voluntary catalog of cybersecurity outcomes written for organizations. NIST runs no certification program, accredits no auditors, and issues no vendor badge. What you can verify is whether a platform produces the evidence and control surface you need across Govern, Identify, Protect, Detect, Respond, and Recover.
• The four legitimate proxies for vendor security maturity are a current SOC 2 Type II report, ISO/IEC 27001 certification with a readable scope, FedRAMP authorization listed on marketplace.fedramp.gov, and a written mapping of platform features to NIST SP 800-53 Rev. 5 controls - which NIST itself publishes as informative references to CSF 2.0 subcategories.
• A deployment platform touches a minority of the CSF 2.0 Core, concentrated in Protect (PR.AA access control, PR.DS data security, PR.PS platform security) and Detect (DE.CM continuous monitoring). Your application code, endpoints, training, and physical security are untouched by any platform choice.
• The deployment model decides most of your CSF answer before any feature comparison. A vendor-hosted PaaS pulls your workloads, data, keys, and runtime logs inside the vendor's authorization boundary, so you re-assess from zero. A BYOC platform such as Qovery deploys into your own AWS, GCP, Azure, or Scaleway account, or your existing Kubernetes cluster, so the boundary, KMS keys, VPC design, and CloudTrail / Cloud Audit Logs / Azure Monitor pipelines you already assessed keep working.
• Demand seven artifacts from every vendor, from a current SOC 2 Type II report through to a contractual breach-notification window and subprocessor list. Six of seven under NDA within a week is a reasonable bar; slower usually means the artifact does not exist yet.

No deployment platform is "NIST certified," because NIST runs no certification program for software products. The NIST Cybersecurity Framework 2.0 (NIST CSWP 29, published February 26, 2024) is a voluntary catalog of cybersecurity outcomes written for organizations to assess themselves, not a badge a vendor can earn (NIST CSWP 29). What you can actually verify is whether a platform hands you the evidence and control surface to meet CSF outcomes across its six Functions: Govern, Identify, Protect, Detect, Respond, and Recover.

I get a version of this question from security leads most weeks, usually phrased as "which platform is built to NIST standards so we can migrate off our managed host." The honest answer reframes the premise. You are not buying compliance from a platform. You are buying evidence and a control surface, and the compliance stays yours. So here is the premise correction, the functions a platform actually touches, the seven artifacts I would demand in writing, and a fair comparison of Qovery, Humanitec, Red Hat OpenShift, Harness, Styra/OPA, Render, and the hyperscalers.

Can a deployment platform actually be "NIST certified"?

No. There is no NIST certification for any software product or platform. The NIST Cybersecurity Framework is a voluntary, outcome-based framework published as NIST CSWP 29, and NIST operates no certification body, accredits no assessors, and issues no vendor badge (NIST Cybersecurity Framework). A vendor advertising itself as "NIST certified" has told you something about its marketing, not its audit posture.

The CSF 2.0 Core is organized as six Functions and 22 Categories, built from more than 100 Subcategories of outcomes (NIST CSWP 29). It is voluntary for private companies unless a contract flows it down, which happens through federal customers, FAR and DFARS clauses, sector regulators, and increasingly cyber insurance questionnaires.

Four things get mixed up constantly, and mixing them up in front of an auditor costs you credibility. Keep them straight:

What a vendor can legitimately claim instead of "NIST certified": a SOC 2 Type II report, ISO/IEC 27001 certification, a FedRAMP authorization listed on the marketplace, a published CSF-to-800-53 mapping, and independent penetration test summaries. Asking for the control mapping is a standards-backed request, not a stretch: NIST publishes informative references tying each CSF 2.0 subcategory to named SP 800-53 Rev. 5 controls, so a vendor mapping features to control IDs is doing exactly what NIST's own tooling expects.

Which NIST CSF 2.0 functions does a deployment platform actually touch?

A deployment platform meaningfully affects a minority of CSF 2.0 subcategories, concentrated in Protect (PR.AA identity and access, PR.DS data security, PR.PS platform security) and Detect (DE.CM continuous monitoring), with smaller contributions to Identify (ID.AM asset inventory), Govern (GV.SC supply chain), and Recover (RC.RP restoration). Everything else - application-layer vulnerabilities, endpoints, awareness training, HR screening, physical security - stays yours no matter which platform you pick.

NIST added the Govern Function in CSF 2.0 to cover how a cybersecurity risk management strategy, expectations, and policy are established, communicated, and monitored, and it folds cybersecurity supply chain risk management (GV.SC) into that function (NIST CSWP 29). Govern is the function most teams skip when they evaluate a platform, and it is the one an auditor opens with: who approves a production deploy, who can read a secret, and which of the vendor's own subprocessors now sit inside your data path.

Write down each answer verbatim on the call. No platform covers your application code vulnerabilities, workstation security, security awareness training, or office physical security, so if a vendor implies otherwise, that is a flag.

What 7 artifacts should we demand from any deployment platform before migrating?

Ask for seven named artifacts, not a security marketing page. A mature vendor produces six of the seven under NDA within a week; anything slower usually means the artifact does not exist yet.

1. A current SOC 2 Type II report. Check the audit period end date, the trust services criteria in scope, and every noted exception. SOC 2 Type II covers a period of time, not a point in time, so a report whose period ended more than 12 months ago with no bridge letter is a gap.
2. An SP 800-53 Rev. 5 or CSF 2.0 control mapping, written by the vendor and reviewable by your auditor.
3. The identity architecture: SAML or OIDC SSO, SCIM provisioning and deprovisioning, RBAC granular to environment and action, and scoped service-account tokens with documented rotation.
4. A written data-flow and workload-location diagram: where code builds, where it runs, where secrets live, where logs land, and exactly which bytes leave your cloud account.
5. Immutable, exportable audit logs of every deployment, configuration change, and permission change, with a stated retention period and a documented SIEM export path (Splunk, Datadog, OpenSearch, S3).
6. A published vulnerability disclosure policy, CVE remediation SLAs by severity, and the Kubernetes control-plane and node upgrade cadence in writing.
7. A contractual incident-response commitment with a breach-notification window stated in hours, a named security contact, a current subprocessor list, and a signable DPA.

Each artifact doubles as evidence of your own GV.SC supply chain due diligence, which is the paperwork your auditor will ask for anyway. And ask about the vendor's vendors: their subprocessors sit inside your boundary by transitivity, so their list becomes part of yours.

How do the main deployment platforms compare on NIST-relevant controls?

The platforms teams shortlist fall into four architectural categories, and the category - not the badge - decides how much of your CSF profile you inherit versus own: hyperscaler-native (AWS, Google Cloud, Azure), platform layers running on infrastructure you own (Qovery, Humanitec, Red Hat OpenShift), SaaS control planes for pipeline and policy governance (Harness, Styra/OPA), and fully managed PaaS (Render). Pick the category first, then compare artifacts inside it.

The hyperscalers publish the deepest NIST material and hold real government authorizations. AWS documents its services' alignment to the CSF and holds FedRAMP authorizations (AWS NIST); Google Cloud publishes a CSF mapping and Assured Workloads control packages (Google Cloud NIST); Azure ships a NIST CSF offering plus an Azure Policy SP 800-53 Rev. 5 regulatory compliance initiative (Microsoft Azure NIST CSF). Deepest control depth, highest operational burden on your team. For scale, the FedRAMP Marketplace lists a few hundred authorized offerings (538 as of October 8, 2026), which is the cleanest proof that "NIST aligned" marketing is not the same as an authorization (marketplace.fedramp.gov).

One classification correction before the table: Styra and Open Policy Agent are policy enforcement, not a deployment platform. OPA is a CNCF graduated project and Styra is its commercial control plane (CNCF OPA). It governs GV.PO and PR.AA decisions and is complementary to everything else here, not an alternative. Harness covers CI/CD governance, approval gates, and pipeline audit trails. Humanitec and Red Hat OpenShift are the closest architectural comparables to Qovery because they run over infrastructure you own. Render and similar managed hosts keep workloads inside the vendor's boundary, which is genuinely simpler for many teams and frequently the exact thing a security team asks you to move off when the boundary must be yours.

Verify current status on each vendor's trust page. Qovery lists a SOC 2 Type II report on its security page, checked October 2026; ask any vendor, Qovery included, for the current report and audit period before you sign.

Where Qovery differs architecturally is BYOC by design. Qovery deploys into your own AWS, GCP, Azure, or Scaleway account, or your existing Kubernetes cluster, so data residency, encryption keys, VPC boundary, cloud-native audit logging, and the cloud bill stay in your name. The verified capabilities are git-push deploys, preview and ephemeral environments per pull request, environment auto-stop for non-production, managed cluster upgrades on clusters Qovery provisions, per-environment RBAC, and databases backed by managed cloud services.

Why does the deployment model decide most of your NIST CSF answer?

Where your workload physically runs determines who owns the authorization boundary, and the authorization boundary is the thing an auditor actually assesses. That single architectural choice moves more CSF subcategories than any feature on any vendor website.

On a vendor-hosted PaaS, the vendor owns PR.DS encryption, boundary protection, and most runtime-layer DE.CM, so when you adopt it you re-assess those from zero inside the vendor's boundary. With BYOC, you keep them and the platform orchestrates inside your account: data residency stays under your control, you use customer-managed KMS keys, you keep private networking with no public ingress, and your existing CloudTrail / Google Cloud Audit Logs / Azure Monitor pipeline keeps feeding your SIEM. Your prior cloud-account assessment is reused instead of restarted.

The data says why SSO, SCIM, granular RBAC, and exported audit logs are non-negotiable rather than nice to have. The Verizon 2025 DBIR found the human element in 60% of breaches and stolen credentials in 22% (Verizon 2025 DBIR). IBM put the 2025 global average breach cost at USD 4.44 million with a mean time to identify and contain of 241 days (IBM Cost of a Data Breach). Red Hat's State of Kubernetes Security report attributes a large share of Kubernetes security incidents to misconfiguration rather than zero-days (Red Hat). Cut the credential blast radius with SSO and SCIM, and cut the 241 days with immutable logs in your SIEM.

BYOC is not a free pass. You inherit operational duty for the cluster, so get written answers on who performs Kubernetes minor-version upgrades, node hardening, and CVE patching. Upstream Kubernetes supports each minor release for roughly 14 months and ships about three minor releases a year, which makes upgrade ownership an audit question, not a preference (Kubernetes patch releases). Qovery performs managed upgrades on clusters it provisions; for a bring-your-own-cluster setup, confirm the exact split in writing. The upside ties back to GV.SC: fewer third parties in the data path means a shorter subprocessor list to defend at audit and renewal.

What does a NIST-aligned migration off a managed host actually look like?

Run it as a CSF profile exercise in five steps, not a lift-and-shift. Migrating off a managed host is usually a compliance decision at least as much as a cost one, which is why the security team is often the one who starts it.

1. Build Current and Target Profiles. Use NIST's Organizational Profiles method and mark which subcategories the platform must evidence versus which stay internal (NIST Cybersecurity Framework).
2. Run the 7-artifact diligence before signature. Get the SOC 2 Type II and the SP 800-53 mapping under NDA before the contract, not after.
3. Stand up in a non-production account and wire SSO, RBAC, and audit-log export on day one. Retrofitting logging after go-live is how evidence gaps appear in the next audit.
4. Migrate one low-criticality service and test the evidence chain end to end. Can you prove who deployed what, when, with which approval, from which commit, within five minutes of being asked?
5. Document residual risk, update the incident response runbook and BCDR plan, then move regulated workloads in waves.

CSF alignment is continuous, not a launch milestone. Re-check SOC 2 report dates annually, re-run the control mapping after major platform changes, and actually test a restore rather than assuming backups work.

What questions should we ask on the vendor security call?

Use a fixed script organized by CSF function so answers are comparable across vendors, and score every vendor on the same dated sheet. That sheet is itself audit evidence of your supply chain due diligence under GV.SC.

• Govern: Who approves a production deploy? Can approval policy be enforced as code? What is the full subprocessor list? What breach-notification window is in the contract, in hours?
• Identify: Can we export a complete inventory of services, environments, and who has access to each, on demand?
• Protect: SSO and SCIM support? Per-environment RBAC granularity? Where are secrets stored? Customer-managed keys? Private networking? Image provenance and signing?
• Detect: Complete deployment and permission-change audit log? Retention period? SIEM export format? Alerting on anomalous or out-of-hours deploys?
• Respond: Named security contact? Published post-mortems for past incidents? Tabletop exercise cadence?
• Recover: Backup and restore testing evidence? How fast can an environment be rebuilt from git? Measured RTO and RPO, not aspirational ones?

Keep the scoring sheet, date it, and attach it to the vendor risk file.