Common Frameworks

Security frameworks proliferate, and the instinct is to treat them as interchangeable checklists of controls. They’re not — they differ in kind, and understanding what each is for is what lets you avoid implementing the same control seven times for seven audits. The useful distinction is not which controls each contains, but what role each plays.

A landscape that moves

Framework versions, control counts, and certification schemes change. This page is about the durable shape of each framework and how they relate; verify current versions and specifics before citing them in a real assessment.

Frameworks differ by kind

Sort them by what they actually are and most of the confusion clears:

• Voluntary frameworks you adopt to structure a program — NIST CSF, CIS Controls.
• Certifiable standards a third party audits you against — ISO 27001, SOC 2.
• Mandatory regimes required to operate in a market or sector — FedRAMP, PCI DSS.
• Control catalogs you draw from rather than certify against — NIST SP 800-53.

A framework’s kind determines how you use it. You adopt CSF, get certified against ISO, achieve authorization under FedRAMP, and select from 800-53. Treating a catalog as a checklist, or a voluntary framework as a certification, is a category error that wastes effort.

The major frameworks, by role

NIST CSF 2.0 — an organizing structure, not a control list. Its functions (Govern, Identify, Protect, Detect, Respond, Recover) are a way to reason about program coverage — where you’re strong, where you’re thin. Best used as the scaffold you hang everything else on, and CSF 2.0’s addition of Govern made explicit what was always true: governance is a function, not a byproduct.

NIST SP 800-53 — the deep control catalog underpinning US federal security, organized into families. You don’t “comply with 800-53” so much as select a baseline from it. It’s the vocabulary a great many other frameworks quietly map back to, which makes it the useful common denominator for crosswalks.

ISO/IEC 27001 & 27002 — the international certifiable standard. 27001 defines the management system (the ISMS — how you govern security as an ongoing process); 27002 is the control guidance. The distinction matters: 27001 certification is as much about having a functioning management process as about the controls themselves.

SOC 2 — a US attestation, common for SaaS, built on the Trust Services Criteria (security, plus optionally availability, confidentiality, processing integrity, privacy). The distinction that trips people up: Type I attests the controls are designed properly at a point in time; Type II attests they operated effectively over a period. Type II is the one customers actually want, because designed-but-not-operating is where most control failures live.

FedRAMP — authorization to sell cloud services to the US government, built on 800-53 baselines (low/moderate/high) with a heavy authorization process. Rigorous, expensive, and periodically modernized (the 20x/automation direction aims at the process cost). Mentioned here for shape; the specifics move.

CIS Controls and Benchmarks — prescriptive and practical. The Controls are a prioritized action list; the Benchmarks are specific hardening configurations. Where the others tell you what outcome to achieve, CIS often tells you the actual setting — which is why they double as posture baselines.

PCI DSS v4.x — mandatory for handling payment card data, prescriptive and enforced by the card brands rather than a government. Narrow in scope (cardholder data) and deep within it.

HITRUST and CMMC — sector-specific certifiable frameworks (healthcare-oriented, and US defense-contractor respectively) that bundle and map other frameworks’ requirements into a single certifiable program.

What they share, and why that matters

Strip the vocabulary differences and the major frameworks converge on the same control families: access control, change management, logging and monitoring, incident response, vulnerability management, encryption, and vendor risk. They are largely the same controls in different language, which is the entire foundation of the common-control approach — implement the control once, evidence it against many frameworks.

That convergence is also why the controls trace to the other pillars directly: access control is IAM governance, secure change management is AppSec SDLC, logging and monitoring is detection, and encryption is key management. A framework requirement is rarely a new thing to build; it’s usually a demand for evidence that something you should already be doing is being done and can be shown.

Choosing, without collecting them all

The mistake is pursuing frameworks for their own sake. The driver should be external: customers demand SOC 2, the government market demands FedRAMP, payment processing demands PCI, the sector demands HITRUST. Choose CSF or CIS as your internal organizing spine, add certifications as the market requires them, and lean on mapping so each addition is incremental rather than a fresh program. A team chasing certifications nobody asked for is spending security budget on paperwork.

Where this connects

Frameworks are the source of the control requirements the rest of the site implements — this pillar is where IAM, AppSec, detection, and cloud get their obligations. The mechanism that stops each framework being separate work is compliance mapping, and turning the whole thing from paperwork into pipeline is GRC engineering.