5.4 The NIST Framework Family: CSF Parts, Privacy Framework & SP 800-53

The NIST Framework Family: CSF Parts, Privacy Framework & SP 800-53

Quick Answer: Three separate ISC blueprint tasks sit in this section, all at the Remembering and Understanding level, and all phrased as closed lists. "Recall the three parts of the NIST CSF (Core, Tiers, Organizational Profiles)." "Recall the three parts of the NIST Privacy Framework (Framework Core, Framework Profiles, Framework Implementation Tiers)." And "Recall the purpose, applicability, target audience and organizational responsibilities of NIST SP 800-53." Note that neither parenthetical begins with "e.g." — by the blueprint's own stated convention, those lists are exhaustive and are meant to be memorized exactly.

---

1. The Three Parts of the NIST Cybersecurity Framework

The CSF is not a list of controls. It is a structure with exactly three parts, and a candidate who can name all three and say what each does has satisfied the task.

Part 1 — The CSF Core

The Core is the taxonomy of cybersecurity outcomes, organized in three descending levels:

• Functions — the six highest-level groupings in CSF 2.0: Govern, Identify, Protect, Detect, Respond, Recover. Govern was added in version 2.0 and sits across the other five rather than beside them.
• Categories — outcome groups within a Function (for example, Asset Management and Risk Assessment sit under Identify; Identity Management, Authentication and Access Control sits under Protect).
• Subcategories — the most granular outcome statements, each written as a result rather than as a required technology, which is what allows an organization to satisfy a subcategory with whatever control fits its environment.

The Core is deliberately outcome-based and technology-neutral. It tells you what result to achieve, never which product to buy.

Part 2 — Organizational Profiles

A Profile describes an organization's cybersecurity posture in terms of the Core outcomes it is achieving or intends to achieve.

• A Current Profile states which Core outcomes the organization is achieving today and how well.
• A Target Profile states the outcomes the organization needs in order to meet its own risk management objectives.
• The gap between the two is the prioritized action plan, costed and sequenced by management.
• CSF 2.0 also recognizes Community Profiles — a baseline Target Profile developed by a sector or an interest group for a shared use case, which is exactly the form NIST used for SP 800-61 Revision 3's incident response profile.

Part 3 — Tiers

Tiers characterize the rigor of an organization's cybersecurity risk governance and management practices on a four-point scale — Tier 1 Partial, Tier 2 Risk Informed, Tier 3 Repeatable, Tier 4 Adaptive. Section 5.1 describes each Tier in detail; for this task, what matters is being able to name all four and place them as the third part of the framework.

Exam trap: Tiers are not maturity levels and Tier 4 is not the goal for everyone. NIST is explicit that an organization selects a Tier that fits its risk appetite, threat environment, mission and resources. A small regional retailer operating deliberately at Tier 2 has made a defensible risk decision, not committed a deficiency.

---

2. The Three Parts of the NIST Privacy Framework

The Privacy Framework is structurally a twin of the CSF — Core, Profiles, Implementation Tiers — which is deliberate, so that an organization can run one governance process across both. The 2026 ISC blueprint removed the reference to a specific version, so learn the structure rather than a version number.

Part 1 — Framework Core

Five Functions, of which two are shared with the CSF and three are unique to privacy:

Beneath the Functions sit Categories and Subcategories, exactly as in the CSF.

Part 2 — Framework Profiles

Current and Target Profiles selected from the Core's outcomes, with the gap driving a prioritized privacy action plan — identical in mechanics to a CSF Profile.

Part 3 — Framework Implementation Tiers

Four Tiers — Partial, Risk Informed, Repeatable, Adaptive — describing the rigor of privacy risk management, again explicitly not a maturity ladder.

The Concept That Makes the Privacy Framework Distinct

The CSF addresses risks arising from unauthorized activity. The Privacy Framework addresses risks arising from data processing itself, including fully authorized processing. NIST calls these problematic data actions: an entirely lawful, intended, secure use of data can still produce embarrassment, discrimination, economic loss or loss of autonomy for an individual.

        Cybersecurity risks                      Privacy risks
     (unauthorized access, use,          (problematic data actions arising
      disclosure, disruption)             from authorized data processing)
              |                                        |
              +-------------- OVERLAP ------------------+
                     Privacy breaches caused by
                   a cybersecurity incident, e.g.
                    theft of personal information

A data breach sits in the overlap. Selling accurate customer location data to a broker in a way the customer never anticipated sits entirely on the privacy side and violates no security control at all.

---

3. NIST SP 800-53: Purpose, Applicability, Audience, Responsibilities

The blueprint limits eligible content to Chapters 1 and 2 of SP 800-53 Revision 5, plus the glossary terms used in those chapters — that is, the framing chapters, not the control catalog itself. Four questions define those chapters.

Purpose

SP 800-53 provides a catalog of security and privacy controls to protect organizational operations and assets, individuals, other organizations, and the Nation from a diverse set of threats and risks — including hostile attacks, human error, natural disasters, structural failures, foreign intelligence activity, and privacy risks arising from authorized data processing. The controls are outcome-based: Revision 5 deliberately rewrote them in a technology- and entity-neutral voice so the same control text applies whether the implementer is a federal agency, a hospital or a cloud provider.

Note the division of labor introduced in Revision 5: SP 800-53 is the catalog, while SP 800-53B holds the control baselines (low, moderate, high, plus a privacy baseline) and SP 800-53A holds the assessment procedures. Revision 5 also integrated privacy controls into the same catalog rather than isolating them in an appendix, and added a Supply Chain Risk Management (SR) family.

Applicability

Revision 5 removed the "federal" limitation from the title and text. The controls apply to any type of computing platform: general-purpose systems, industrial and process control systems, cyber-physical systems, Internet of Things devices, weapons and space systems, mobile devices, cloud and virtualized environments, and general-purpose enterprise IT. For non-federal organizations, adoption is voluntary; for federal information systems it is mandated through FISMA and the Risk Management Framework, and it flows to contractors through FedRAMP and contract clauses.

Target Audience

Chapter 1 names the audience by role rather than by employer:

• Individuals with system development responsibilities — architects, developers, integrators, systems engineers.
• Individuals with acquisition and procurement responsibilities — contracting officers, program managers buying systems and services.
• Individuals with system, security, privacy or risk management and oversight responsibilities — authorizing officials, CIOs, senior agency officials for privacy, system owners, information owners.
• Individuals with assessment and monitoring responsibilities — auditors, system evaluators, assessors, independent verifiers, analysts.
• Commercial entities — product developers, systems integrators and service providers building security and privacy capabilities into their offerings.

That fourth bullet is why the standard matters to a CPA: assessors and auditors are named audience members, not bystanders.

Organizational Responsibilities

• Integrate security and privacy requirements into the system development life cycle from the outset rather than bolting them on.
• Select and tailor an appropriate control baseline to the system's categorized impact level, documenting every tailoring decision and its rationale.
• Document the selected controls in a system security and privacy plan.
• Implement, assess, authorize, and continuously monitor the controls.
• Assign accountability for each control to a named organizational role.

Structure of the Catalog

Twenty control families, each with a two-character identifier — AC (Access Control), AU (Audit and Accountability), CM (Configuration Management), CP (Contingency Planning), IA (Identification and Authentication), IR (Incident Response), PM (Program Management), RA (Risk Assessment), SC (System and Communications Protection), SI (System and Information Integrity), SR (Supply Chain Risk Management), and others. Each control has a base statement, optional control enhancements that strengthen it, a discussion section, and related-control references.