Compliance Frameworks Explained

CMDash ships a library of built-in compliance frameworks — from voluntary guidelines like NIST CSF to hard regulatory requirements like GDPR and DORA. This guide explains what each framework is, who needs it, how it is structured, and the practical trade-offs of pursuing it, so you can decide where to invest your compliance effort.

What Is a Compliance Framework?

A compliance framework is a structured catalog of security and privacy requirements — usually called controls, practices, requirements, or criteria depending on the framework. Each control describes something your organization must do (enforce MFA, encrypt data at rest, screen personnel, test your incident response plan) and, implicitly, the evidence you would show an auditor to prove you do it.

Frameworks fall into four broad types:

• Regulation — legally required if you are in scope. There is no "opting out" of GDPR, HIPAA, or DORA; the only question is whether you can demonstrate compliance. Enforcement is by regulators, with fines and legal exposure for failure.
• Certification — a third party audits you against the standard and issues a certificate (ISO 27001, CMMC, HITRUST, TISAX, FedRAMP). Certification is usually voluntary in law but often mandatory in practice because customers or contracts demand it.
• Attestation — an independent auditor issues a report describing your controls and their operating effectiveness (SOC 2). There is no pass/fail certificate; customers read the report and judge for themselves.
• Guideline — voluntary best-practice catalogs with no audit regime at all (NIST CSF, CIS Controls). These are excellent internal roadmaps and are frequently used as the "common language" that other frameworks map to.

How CMDash Tracks Frameworks

In CMDash, every framework is a set of controls under Compliance in the left sidebar. Every framework in the library is seeded for your tenant already — adding one to your scope (via Manage scope) is what makes it count toward your posture score, not a separate install step. For each framework in your scope, CMDash tracks:

• Control status — each control can be satisfied by connected integration data, uploaded manual evidence, or policy attestations, and rolls up into a per-framework and per-domain completion percentage.
• Assessments — point-in-time snapshots you can run against a framework to prepare for an audit, capture a baseline, or show progress quarter over quarter.
• Crosswalks — mappings between equivalent controls in different frameworks. CMDash uses NIST CSF as the crosswalk hub: when you satisfy a control in one framework, crosswalks show you the equivalent controls it advances in the others. Add a second framework and much of your first framework's evidence carries over automatically.

How to Choose

Work through three questions, in order:

1. What is legally or contractually mandatory? Regulations (HIPAA, GDPR, DORA, PCI DSS via card-brand contracts) and contract-mandated certifications (CMMC for DoD work, FedRAMP for federal cloud sales, TISAX for automotive) are not optional. Start there.
2. What do your customers ask for? In B2B sales, SOC 2 (North America) and ISO 27001 (international) are the two most common security questionnaire short-circuits.
3. What do you want as an internal roadmap? NIST CSF 2.0 and CIS Controls v8.1 are free, pragmatic, and map cleanly onto everything else via crosswalks.

Quick Comparison

Cost tiers are rough order-of-magnitude for external audit/assessment fees plus internal effort: $ minimal, $$ tens of thousands, $$$ low-to-mid six figures, $$$$ high six figures and up.

NIST Cybersecurity Framework (CSF) 2.0

What it is: The U.S. National Institute of Standards and Technology's voluntary framework for managing cybersecurity risk, released in February 2024 as the successor to CSF 1.1. It is the closest thing the industry has to a universal vocabulary for security programs.

Who it's for / when it's required: Everyone, and never. CSF is not audited or certified; it is a self-directed roadmap. U.S. critical infrastructure operators are strongly encouraged to adopt it, and many regulators and insurers reference it, but no one will ever demand your "CSF certificate."

Structure: Six Functions — Govern (new in 2.0), Identify, Protect, Detect, Respond, Recover — broken into 22 categories and 106 subcategories. The Govern function elevates risk governance, roles, policy, and supply-chain oversight to a first-class concern.

Pros:

• Free, vendor-neutral, and universally recognized — the lingua franca of security programs.
• Outcome-focused rather than prescriptive, so it fits any size or sector.
• The Govern function gives CISOs board-ready language for strategy and oversight.
• Maps to virtually everything else — ideal as your crosswalk hub.
• No audit means no audit cost; adopt incrementally at your own pace.

Cons / trade-offs:

• No certificate or report to hand a customer — it won't shorten a security questionnaire on its own.
• Deliberately non-prescriptive: it tells you what outcomes to achieve, not how.
• Self-assessed maturity claims are easy to inflate without external validation.
• Migrating existing CSF 1.1 mappings to 2.0's restructured categories takes real work.

In CMDash: Add it to your scope from Compliance → Manage scope. CSF 2.0 is CMDash's crosswalk hub — evidence mapped here propagates to every other framework in the library.

NIST CSF 1.1 (Legacy)

What it is: The 2018 predecessor to CSF 2.0 — five Functions (Identify, Protect, Detect, Respond, Recover), 23 categories, 108 subcategories. It lacks the Govern function and 2.0's expanded supply-chain coverage.

Who it's for / when it's required: Organizations with existing CSF 1.1 assessments, contractual references, or regulator mappings that haven't yet migrated. New programs should start on 2.0.

Pros:

• Preserves continuity for multi-year trend lines built on 1.1 assessments.
• Still referenced by some contracts, insurers, and state regulations.
• Nearly all of its content carries forward into 2.0, so migration is low-risk.

Cons / trade-offs:

• Superseded — NIST no longer updates it, and new crosswalks target 2.0.
• Missing the Govern function and modern supply-chain risk categories.
• Running 1.1 and 2.0 in parallel doubles mapping maintenance.

In CMDash: Available in the framework library for tenants with existing 1.1 assessments. CSF 2.0 is the recommended hub for all new mappings.

CIS Controls v8.1

What it is: The Center for Internet Security's prioritized catalog of defensive actions — 18 top-level Controls decomposed into 153 specific Safeguards. Where NIST CSF describes outcomes, CIS tells you exactly what to do, in what order.

Who it's for / when it's required: Never legally required, but the best on-ramp for small and mid-sized teams that want a concrete, prioritized to-do list. The three Implementation Groups (IG1 ≈ 56 safeguards of "essential cyber hygiene," IG2, IG3 = all 153) let you right-size the workload to your resources.

Structure: 18 Controls covering asset inventory, data protection, secure configuration, account and access management, vulnerability management, logging, email/browser protections, malware defense, recovery, network monitoring, awareness training, service-provider management, application security, incident response, and penetration testing — each broken into task-level Safeguards.

Pros:

• The most actionable framework available — each safeguard is a concrete task, not an abstract objective.
• Implementation Groups give small teams a defensible, prioritized starting point (IG1 first).
• Free, community-maintained, and backed by measurement data on attack-technique coverage.
• Excellent feeder for other frameworks: IG1/IG2 work directly advances SOC 2, ISO 27001, and NIST CSF via crosswalks.

Cons / trade-offs:

• No certification or attestation — customers can't "see" your CIS adoption.
• Technically focused; thin on governance, privacy, and organizational controls compared to ISO 27001.
• 153 safeguards is a lot of granular tracking if you jump straight to IG3.

In CMDash: Add it to your scope from Compliance → Manage scope (seeded as all 153 v8 safeguards across the 18 control groups). Crosswalks link safeguards to NIST CSF and onward to the audit-bearing frameworks.

SOC 2 Type II

What it is: An attestation report — not a certification — issued by a licensed CPA firm under the AICPA's Trust Services Criteria. A Type I report describes your control design at a point in time; a Type II report tests whether those controls actually operated effectively over an observation window (typically 3–12 months).

Who it's for / when it's required: The de facto entry ticket for B2B SaaS and service providers selling to North American enterprises. Not required by any law, but very frequently required by customer procurement and vendor-risk teams.

Structure: Five Trust Services Criteria categories — Security (the mandatory Common Criteria, CC1–CC9, built on the COSO internal-control principles), plus optional Availability, Processing Integrity, Confidentiality, and Privacy. Most first reports scope Security plus Availability and/or Confidentiality.

Pros:

• The single most-requested security artifact in North American B2B sales.
• Flexible scoping — you choose which criteria categories and systems are in scope.
• The narrative report format lets you explain how you meet criteria rather than checking rigid boxes.
• Annual renewal builds a continuous-compliance habit that feeds other frameworks.

Cons / trade-offs:

• Not a pass/fail certificate — sophisticated customers read the exceptions section, and a sloppy report can hurt you.
• The Type II observation window means your first credible report is 6–12 months away no matter how fast you move.
• Recurring cost: the audit repeats every year, forever.
• Little recognition outside North America — international buyers usually want ISO 27001 instead.

In CMDash: Add it to your scope from Compliance → Manage scope (seeded as the Trust Services Criteria across all five categories). Crosswalks to NIST CSF and ISO 27001 let SOC 2 evidence pull double duty.

ISO/IEC 27001:2022

What it is: The international standard for an Information Security Management System (ISMS), certifiable by accredited bodies. The 2022 revision restructured Annex A into 93 controls across 4 themes: Organizational (37), People (8), Physical (14), and Technological (34).

Who it's for / when it's required: The global equivalent of SOC 2 — expected in European, APAC, and multinational enterprise procurement. Legally voluntary, contractually near-mandatory for international B2B at scale.

Structure: Management-system clauses 4–10 (context, leadership, planning, support, operation, performance evaluation, improvement) define the ISMS itself; Annex A's 93 controls are the security catalog you scope via a Statement of Applicability. Certification runs on a 3-year cycle: initial two-stage audit, then annual surveillance audits, then recertification.

Pros:

• A genuine certificate — the strongest single answer to "prove you're secure" in international markets.
• The ISMS structure builds durable governance (risk assessment, management review, internal audit), not just point-in-time controls.
• Statement of Applicability lets you scope out controls that genuinely don't apply.
• Foundation for the ISO 27xxx family (27017 cloud, 27018 privacy in cloud, 27701 privacy management).

Cons / trade-offs:

• Heavier documentation burden than SOC 2 — the management-system clauses demand real process artifacts.
• 3-year cycle with annual surveillance means permanent audit overhead.
• Certification proves the management system works, not that any specific technical control is strong — scope games are possible and buyers know it.
• Certification body and consultant costs add up, especially for first-timers.

In CMDash: Add it to your scope from Compliance → Manage scope (seeded as all 93 Annex A controls, 2022 edition). ISO 27001 has the deepest crosswalk coverage in the library alongside NIST CSF.

CMMC Level 1

What it is: The U.S. Department of Defense's Cybersecurity Maturity Model Certification, Level 1 ("Foundational") — 17 practices across 6 domains, drawn from the FAR 52.204-21 basic safeguarding requirements, protecting Federal Contract Information (FCI) rather than CUI.

Who it's for / when it's required: Contractors that only handle Federal Contract Information, not Controlled Unclassified Information. It is a self-assessment-only level: no POA&M is permitted, and every practice must be fully in place before the annual self-assessment is submitted to SPRS.

Structure: 6 domains covering the fundamentals — access control, identification and authentication, media protection, physical protection, system and communications protection, and system and information integrity — containing 17 practices in total.

Pros:

• The lightest-weight CMMC level: no third-party assessor, no POA&M paperwork, a much smaller practice set than Level 2.
• Covers cyber-hygiene fundamentals most organizations already have in some form.
• A natural first step for a contractor that may later win CUI-bearing work and need to step up to Level 2.

Cons / trade-offs:

• No POA&M allowance — every one of the 17 practices must be met, not planned, before you self-attest.
• Only satisfies contracts limited to FCI; any CUI in scope means you need Level 2 instead.
• Self-assessment only, so there is no third-party certificate to hand a prime contractor as external proof.

In CMDash: Add it to your scope from Compliance → Manage scope (all 17 practices across 6 domains). See the dedicated CMMC Level 1, 2 & 3 Tracking guide for the full module walkthrough.

CMMC Level 2

What it is: The U.S. Department of Defense's Cybersecurity Maturity Model Certification, Level 2 ("Advanced") — 110 practices across 14 domains, drawn directly from NIST SP 800-171, protecting Controlled Unclassified Information (CUI).

Who it's for / when it's required: Mandatory for Defense Industrial Base primes and subcontractors that access, process, or store CUI, per DFARS 252.204-7021. Depending on contract sensitivity, Level 2 requires either a triennial third-party assessment by a C3PAO or an annual self-assessment.

Structure: 14 domains (Access Control, Awareness & Training, Audit & Accountability, Configuration Management, Identification & Authentication, Incident Response, Maintenance, Media Protection, Personnel Security, Physical Protection, Risk Assessment, Security Assessment, System & Communications Protection, System & Information Integrity) containing 110 practices. CMDash tracks Level 1 as its own separate 17-practice framework rather than a subset of Level 2 — see CMMC Level 1 above.

Pros:

• Non-negotiable market access: without it you cannot bid on or keep CUI-bearing DoD contracts.
• Built on NIST 800-171, so years of existing 800-171 self-assessment work carries over directly.
• The POA&M mechanism allows conditional certification with a limited set of open items.
• Strong overlap with FedRAMP and NIST CSF via shared 800-53 lineage.

Cons / trade-offs:

• Scoping CUI enclaves is genuinely hard, and over-scoping multiplies cost dramatically.
• C3PAO assessments are expensive and assessor capacity is constrained — book early.
• All-or-nothing stakes: assessment failure can mean lost contracts, not just a finding memo.
• Flow-down requirements mean your subcontractors' readiness becomes your problem.

In CMDash: Add it to your scope from Compliance → Manage scope (all 110 practices across 14 domains). See the dedicated CMMC Level 1, 2 & 3 Tracking guide for the full module walkthrough.

CMMC Level 3

What it is: CMMC's "Expert" tier — a set of enhanced security practices drawn from NIST SP 800-172, layered on top of the full Level 2 baseline, aimed at defending against advanced persistent threats. 32 CFR Part 170 selects 24 of the 35 enhanced requirements NIST SP 800-172 defines.

⚠ CMDash's Level 3 catalog is a DRAFT. Its enhanced-requirement identifiers are CMDash's own reconstruction, not a verified transcription of DoD's selection, and the Awareness & Training enhanced requirements the rule includes are missing. An earlier version carried two families — programme management and supply-chain risk management — that do not exist in NIST SP 800-172 at all; those are removed. Do not use this catalog as a compliance baseline until this notice goes away.

Who it's for / when it's required: DoD contractors on programs involving the highest-sensitivity CUI. Assessment is government-led (DIBCAC), not C3PAO. Only a small fraction of the DIB will ever need Level 3.

Structure: Level 2's 110 practices plus roughly two dozen 800-172 enhanced requirements covering areas like penetration-resistant architecture, damage-limiting operations, threat hunting, and cyber resiliency.

Pros:

• Unlocks the most sensitive (and often most valuable) DoD program work.
• 800-172 practices represent genuinely advanced defense — achieving them materially raises your security floor.
• Incremental on top of L2: the delta is small in count, so an L2-certified org has a clear runway.

Cons / trade-offs:

• Government-led assessment means less scheduling control and higher scrutiny than C3PAO.
• The enhanced practices (threat hunting, deception, resilience engineering) require capabilities most mid-size contractors don't have in-house.
• Costly to sustain relative to the number of contracts that require it — pursue only when a specific program demands it.

In CMDash: Add it to your scope alongside Level 2 from Compliance → Manage scope; the module displays L3's incremental practices on top of your L2 baseline, with crosswalks to NIST CSF.

NIST SP 800-171 Revision 3

What it is: NIST's May 2024 revision of the security requirements for protecting Controlled Unclassified Information (CUI) in nonfederal systems. It restates the requirements as 97, numbered 03.01.01 upward, in 17 families, and withdraws 33 Revision 2 requirements.

Who it's for / when it's required: Organizations whose contract or agreement cites Revision 3, and anyone planning the move from Revision 2. CMMC Level 2 is still assessed against Revision 2 — track that in the CMMC Level 2 framework.

Structure: 97 requirements in 17 families. Three families are new to 800-171: Planning, System and Services Acquisition, and Supply Chain Risk Management. Many requirements contain organization-defined parameters, values such as a time period that your organization decides and records.

Pros:

• NIST's own numbering and verbatim requirement text, so the catalog reads exactly like the publication.
• Each requirement's evidence line is the SP 800-171A list of documents an assessor examines.
• Lets you see Revision 3 beside your Revision 2 (CMMC Level 2) work before a contract requires it.

Cons / trade-offs:

• No crosswalk to CMMC Level 2 or to any other framework is seeded, so evidence does not carry across automatically.
• A Revision 3 status does not feed an SPRS score; SPRS is computed from CMMC Level 2.
• Organization-defined parameter values are yours to set; CMDash does not choose them.

In CMDash: Add NIST SP 800-171 Revision 3 from Compliance → Manage scope. Parameters appear in square brackets in each requirement's text. The System and Information Integrity, Cryptography and Key Management, and BYOD and Mobile Device policy templates map to the matching Revision 3 requirements.

PCI DSS v4.0.1

What it is: The Payment Card Industry Data Security Standard — the card brands' contractually mandated security standard for anyone who stores, processes, or transmits cardholder data. Version 4.0 modernized authentication, encryption, and monitoring requirements, and its future-dated requirements became mandatory in March 2025.

Who it's for / when it's required: Every merchant and service provider touching card data, enforced through acquiring-bank contracts. Validation rigor scales with transaction volume: Level 1 entities need an annual on-site assessment by a QSA producing a Report on Compliance (ROC); smaller entities complete Self-Assessment Questionnaires (SAQs).

Structure: 12 principal requirements spanning network security, secure configuration, cardholder data protection, encryption in transit, malware defense, secure development, access restriction, identification/authentication, physical security, logging and monitoring, security testing, and security governance — decomposed into several hundred testable sub-requirements at full ROC depth.

Pros:

• Crystal-clear scope trigger: touch card data, and you're in — no ambiguity about applicability.
• Highly prescriptive requirements leave little debate about what "done" means.
• v4.0's customized-approach option finally allows alternative controls that meet the stated objective.
• Aggressive scope-reduction strategies (tokenization, hosted payment pages, P2PE) can shrink the assessed environment dramatically.

Cons / trade-offs:

• Prescriptiveness cuts both ways: some requirements fit legacy architectures poorly, and the customized approach demands heavy justification.
• Annual validation plus quarterly ASV scans is a relentless cadence.
• Scope creep is the classic failure mode — one misrouted data flow can pull whole networks into scope.
• Non-compliance fines and, worse, post-breach liability shifts make failure expensive.

In CMDash: Add it to your scope from Compliance → Manage scope. CMDash seeds PCI DSS v4.0.1 at the ROC line-item level (the 12 principal requirements and their sub-requirements); crosswalks connect requirements to NIST CSF and ISO 27001.

HIPAA Security Rule

What it is: The U.S. Health Insurance Portability and Accountability Act's Security Rule — federal regulation governing the confidentiality, integrity, and availability of electronic protected health information (ePHI).

Who it's for / when it's required: Mandatory for covered entities (providers, health plans, clearinghouses) and their business associates — including SaaS vendors that touch ePHI, who must also sign Business Associate Agreements (BAAs). Enforced by HHS Office for Civil Rights, with penalties tiered by culpability.

Structure: Implementation specifications organized under Administrative, Physical, and Technical safeguards, plus organizational and documentation requirements. Specifications are either required or addressable — addressable means you must implement it or document why an alternative (or nothing) is reasonable, not that it's optional.

Pros:

• Flexible and scalable by design — a rural clinic and a national insurer can both comply proportionately.
• Risk-analysis-driven, which aligns naturally with a modern risk-register practice.
• Lighter direct audit burden than certification frameworks: no annual external audit requirement.

Cons / trade-offs:

• No certification exists — "HIPAA compliant" is a self-declared claim, which makes it hard to prove to partners (this gap is exactly what HITRUST fills).
• The rule's technology-neutral, 2000s-era language leaves teams guessing at modern expectations.
• "Addressable" is widely misread as "optional," a top source of OCR enforcement findings.
• Breach-notification obligations and OCR investigations mean the real cost shows up after an incident.

In CMDash: Add it to your scope from Compliance → Manage scope (seeded as the Security Rule implementation specifications across Administrative, Physical, and Technical safeguards). Crosswalks link to NIST CSF and HITRUST.

GDPR

What it is: The EU General Data Protection Regulation (2016/679) — the world's most influential privacy law, governing how personal data of people in the EU/EEA is collected, processed, stored, and transferred.

Who it's for / when it's required: Any organization processing EU/EEA personal data, regardless of where the organization sits — extraterritorial reach is the point. Fines run up to €20 million or 4% of global annual turnover, whichever is higher.

Structure: 99 articles across 11 chapters. The operationally significant core covers processing principles (Art. 5), lawful bases (Art. 6), data-subject rights (Arts. 12–23), controller/processor obligations (Arts. 24–43, including security of processing in Art. 32, breach notification in Arts. 33–34, and DPIAs in Art. 35), and international transfers (Arts. 44–50). CMDash seeds the ~50 key operational articles.

Pros:

• One coherent regime across all EU/EEA markets — comply once, sell everywhere in the bloc.
• Forces genuinely good data hygiene: minimization, purpose limitation, and records of processing pay security dividends too.
• The de facto global template — GDPR work transfers heavily to UK GDPR, Brazil's LGPD, and beyond.

Cons / trade-offs:

• It's a privacy law, not a security checklist — much of it (lawful bases, consent, DPO, transfers) needs legal counsel, not just a security team.
• No certificate to earn: compliance is a continuous legal posture, demonstrated through documentation and practice.
• Data-subject rights (access, erasure, portability) require real operational machinery with 30-day clocks.
• International transfer rules shift with court rulings and adequacy decisions, demanding ongoing legal attention.

In CMDash: Add it to your scope from Compliance → Manage scope (seeded as the key operational articles). Crosswalks connect Article 32's security obligations to NIST CSF and ISO 27001 controls.

DORA

What it is: The EU Digital Operational Resilience Act (Regulation 2022/2554) — binding regulation for the financial sector's ICT resilience, in application since January 2025.

Who it's for / when it's required: Mandatory for EU financial entities — banks, insurers, investment firms, payment and e-money institutions, crypto-asset service providers, and more — plus critical ICT third-party providers (including cloud providers) that serve them, who fall under direct EU oversight. Non-EU vendors selling into EU finance feel it through contractual flow-downs.

Structure: Five pillars: ICT risk management (governance and control framework), ICT incident management and reporting (classification and regulator notification timelines), digital operational resilience testing (up to threat-led penetration testing, TLPT, for significant entities), ICT third-party risk management (register of information, mandatory contract clauses, concentration-risk analysis), and information sharing. CMDash seeds the operative requirements across these pillars.

Pros:

• Harmonizes a previously fragmented patchwork of national financial ICT rules into one EU-wide regime.
• Management-body accountability gives CISOs unprecedented board leverage in financial institutions.
• Its third-party risk pillar finally puts contractual teeth into cloud and vendor oversight.
• Heavy overlap with ISO 27001 and NIST CSF work you may already have done.

Cons / trade-offs:

• The register of information and contract-remediation workload for existing vendor portfolios is enormous.
• TLPT obligations are costly and operationally invasive for entities designated as significant.
• Incident-reporting timelines are tight and require pre-built classification and notification machinery.
• Regulatory technical standards continue to evolve — compliance is a moving target.

In CMDash: Add it to your scope from Compliance → Manage scope (seeded as the operative DORA requirements across the five pillars). Crosswalks map requirements to NIST CSF and ISO 27001.

FedRAMP Moderate

What it is: The U.S. Federal Risk and Authorization Management Program — the mandatory security authorization regime for cloud services used by federal agencies, built on NIST SP 800-53 Rev 5 control baselines (Low, Moderate, High).

Who it's for / when it's required: Cloud service providers selling to U.S. federal agencies. No authorization, no federal cloud revenue. The Moderate baseline — the most common — covers the large majority of federal data, and CMDash seeds it as 328 controls spanning the 800-53 Rev 5 control families (AC, AT, AU, CA, CM, CP, IA, IR, MA, MP, PE, PL, PM, PS, RA, SA, SC, SI, SR).

Structure: The 800-53 Moderate baseline, assessed by an accredited 3PAO, documented in a System Security Plan, and culminating in an Authorization to Operate (ATO) — via an agency sponsor or the program office — followed by continuous monitoring (monthly scans, annual assessments, POA&M management).

Pros:

• Opens the federal market, one of the largest and stickiest cloud customer bases in the world.
• The most rigorous widely-adopted cloud security bar — a FedRAMP ATO impresses commercial buyers too.
• Continuous-monitoring discipline produces genuinely strong operational security.
• Reuse: one authorization serves many agencies, and StateRAMP/DoD IL levels build on it.

Cons / trade-offs:

• The most expensive and slowest framework in this guide: commonly 12–24+ months and high-six-figure to seven-figure total cost.
• Requires an agency sponsor or program-office pathway — demand-side dependency you don't fully control.
• Continuous monitoring is a permanent, staffed operational commitment, not an annual event.
• Often forces a dedicated, isolated government environment, doubling infrastructure surface.

In CMDash: Add it to your scope from Compliance → Manage scope (seeded as the full Moderate baseline, Rev 5). Crosswalks to NIST CSF let existing evidence pre-populate a meaningful share of the baseline.

TISAX (VDA ISA v6)

What it is: The Trusted Information Security Assessment Exchange — the automotive industry's mutual assessment scheme, governed by the ENX Association and based on the German VDA's Information Security Assessment (ISA) catalog, currently version 6.

Who it's for / when it's required: Suppliers and service providers in the automotive supply chain, especially anyone working with German OEMs — who routinely require a valid TISAX label before sharing prototypes, designs, or sensitive data. Contractually mandatory in practice.

Structure: The ISA catalog's information-security chapters cover IS policies and organization, human resources, physical security, identity and access management, IT and cyber security, supplier relationships, and compliance. Assessments run at three levels (AL1 self-assessment through AL3 on-site) depending on protection needs, producing labels valid for three years, shared with partners via the ENX exchange. CMDash seeds the ISA v6 information-security catalog (the Prototype Protection and Data Protection sub-catalogs are separate ISA modules).

Pros:

• Assess once, share everywhere: one TISAX assessment satisfies every participating OEM and partner.
• Three-year label validity — a lighter cadence than SOC 2's annual cycle.
• ISA is closely aligned with ISO 27001, so existing ISO work transfers heavily.
• Maturity-level scoring gives a more nuanced picture than pass/fail.

Cons / trade-offs:

• Zero relevance outside automotive — it buys nothing in other markets.
• The maturity-based scoring (target level 3 on a 0–5 scale) is stricter than it looks; "implemented" isn't enough without documented, managed process.
• Results live in the ENX exchange and are shared only with participants, not publicly citable.
• Higher assessment levels and prototype-protection scope add cost quickly.

In CMDash: Add it to your scope from Compliance → Manage scope (seeded as the VDA ISA v6 information-security controls). Crosswalks map ISA controls to ISO 27001 and NIST CSF.

HITRUST CSF v11

What it is: A certifiable framework that harmonizes dozens of authoritative sources — HIPAA, NIST, ISO 27001, PCI DSS, and more — into a single controlled catalog with a rigorous, centrally quality-reviewed assessment methodology. Born in healthcare, now industry-agnostic.

Who it's for / when it's required: Healthcare organizations and their vendors, where "HITRUST certified" has become the standard answer to HIPAA's missing certification. Payers and health systems frequently mandate it from vendors handling ePHI. Assessment tiers scale by rigor: e1 (essentials, 1-year), i1 (leading practices, 1-year), and r2 (risk-based, tailored, 2-year certification).

Structure: Control categories spanning the full security and privacy domain, with each requirement scored on implementation maturity. The r2 assessment tailors the requirement set to your risk factors. CMDash seeds the v11.2 r2 certification baseline (Implementation Levels 1 and 2) across 14 control categories — 207 requirements.

Pros:

• The only widely accepted way to prove HIPAA-aligned security to partners — solves HIPAA's no-certification gap.
• Assess once, report many: HITRUST results can generate mappings to NIST CSF, HIPAA, and other frameworks.
• Centralized quality assurance makes certificates more consistent than auditor-by-auditor attestations.
• Tiered e1/i1/r2 pathway lets you start small and step up.

Cons / trade-offs:

• r2 assessments are notoriously heavy — scoring every requirement across maturity levels is a major lift.
• Among the most expensive non-government certifications (assessor fees plus HITRUST's own fees).
• The maturity-scoring model has a steep learning curve and punishes thin documentation.
• Limited pull outside healthcare — most other industries will ask for SOC 2 or ISO 27001 instead.

In CMDash: Add it to your scope from Compliance → Manage scope (seeded as the v11 r2 baseline across 14 categories). HITRUST has the densest crosswalk coverage in the CMDash library, reflecting its harmonized design.

DISA STIGs

What they are: Security Technical Implementation Guides — DoD-published, per-technology hardening benchmarks (operating systems, databases, applications, network devices) with individual configuration checks graded by severity (CAT I/II/III). STIGs are configuration baselines, not a governance framework: they tell you exactly how to harden a specific product.

Who they're for / when they're required: Mandatory for DoD information systems; widely reused elsewhere by anyone who wants a rigorous, free hardening standard. CMMC and FedRAMP work often leans on STIG (or CIS Benchmark) baselines to satisfy configuration-management controls.

Pros:

• Extremely specific — each check is a concrete setting with a fix text, ideal for automation.
• Free, authoritative, and continuously updated by DISA.
• Directly satisfies secure-configuration controls in CMMC, FedRAMP, and CIS.

Cons / trade-offs:

• Per-technology, not organizational — hundreds of checks per benchmark, multiplied by every product you run.
• DoD-centric defaults can break commercial workflows without careful tailoring and documented deviations.
• Keeping pace with quarterly STIG releases is an ongoing operational task.

In CMDash: STIG benchmarks live on their own STIGs page (separate from the Compliance framework list), seeded with benchmarks such as the Application Security and Development STIG and the Red Hat Enterprise Linux 9 STIG, tracked check-by-check.

Which Should You Start With?

There is no universal first framework — there is a right first framework for your situation:

• B2B SaaS selling to North American enterprises → SOC 2 Type II (start the observation window early), with CIS Controls IG1/IG2 as your internal build checklist along the way.
• Selling internationally or to European enterprises → ISO/IEC 27001:2022, optionally alongside SOC 2 if you also sell in North America — the overlap via crosswalks is substantial.
• DoD supply chain handling only Federal Contract Information → CMMC Level 1 — a 17-practice, self-assessment-only floor.
• DoD supply chain handling CUI → CMMC Level 2 is non-negotiable; layer DISA STIGs for configuration evidence, and add Level 3 only when a specific program demands it.
• Selling cloud services to U.S. federal agencies → FedRAMP Moderate — but line up an agency sponsor and budget realistically before committing.
• Handling payment cards in any way → PCI DSS v4.0.1 applies today, regardless of what else you pursue. Prioritize scope reduction first.
• U.S. healthcare (provider, payer, or vendor with ePHI) → HIPAA Security Rule is the legal floor; add HITRUST (start with e1 or i1) when partners demand provable assurance.
• EU financial sector or its critical ICT suppliers → DORA now, with ISO 27001 as the natural supporting certification.
• Automotive supplier, especially German OEM supply chains → TISAX, ideally built on an ISO 27001-shaped ISMS.
• Processing EU/EEA personal data → GDPR applies regardless of your industry — treat it as a parallel legal track alongside your security framework.
• No external mandate yet, just building the program → adopt NIST CSF 2.0 as your roadmap and CIS Controls v8.1 (IG1 first) as your task list. Both are free, and everything you do maps forward through CMDash crosswalks when a customer or regulator eventually names a framework.

Whatever you choose, add it to your scope from Compliance → Manage scope, run a baseline assessment, and let crosswalks carry your evidence forward — the second framework is always cheaper than the first.