Appendix A: Security Frameworks and Controls Reference

A defender who cannot navigate the major control frameworks is a defender who reinvents the wheel at every audit, builds controls nobody asked for, and misses the ones that mattered. This appendix is the field reference for the four framework families a working security professional meets most: NIST Cybersecurity Framework (CSF) 2.0, NIST Special Publication 800-53, the CIS Critical Security Controls v8, and ISO/IEC 27001/27002. It gives you each framework's structure, the vocabulary auditors use, a high-level cross-mapping, and — the part most reference tables omit — guidance on when to reach for which.

Two warnings before the tables. First, these frameworks describe controls; they do not, by themselves, make you secure. As Chapter 28 argues at length, compliance is the floor, not the ceiling — a fully mapped control set can still describe a system an attacker walks through. Use these frameworks as scaffolding, then build above them with your risk process. Second, control numbers drift between framework revisions and are easy to misremember; this appendix names control families and areas precisely and gives example identifiers only where they are stable and well known. When you cite a specific control to an auditor, pull the number from the live published catalog, not from memory.

All four frameworks named here are Tier 1 sources (see _style-bible.md §7): NIST CSF 2.0 (2024), NIST SP 800-53, CIS Controls v8, and ISO/IEC 27001/27002. The examples involving Meridian Regional Bank are Tier 3 constructed illustrations.

A.1 NIST Cybersecurity Framework (CSF) 2.0

The NIST CSF is an outcome-oriented, voluntary framework — a common language for organizing and communicating a security program rather than a prescriptive control list. It is the framework a CISO uses to talk to a board, because it is readable by non-specialists and describes what outcomes to achieve without dictating exactly how. CSF 2.0 (published 2024) made two changes that matter: it added a sixth Function, Govern, recognizing that security is a governance problem before it is a technical one; and it broadened the framework's stated audience from critical-infrastructure operators to organizations of all sizes and sectors.

CSF is organized as a hierarchy: Functions (the six highest-level outcomes) → Categories (groups of related outcomes) → Subcategories (specific, discrete outcome statements). You assess yourself against the Subcategories, rate where you are versus where you want to be, and build a roadmap to close the gap. CSF certifies nothing; it organizes.

The six Functions

A useful mnemonic for the order: Govern wraps the other five; then Identify what you have, Protect it, Detect what gets through, Respond to it, and Recover from it. The flow mirrors the lifecycle of a defense that assumes breach (Theme 4): you protect knowing some attacks will land, so you also detect, respond, and recover.

Categories within each Function

The Categories are where the Functions become concrete. CSF 2.0's Category set (names below; exact Category counts and identifiers should be confirmed against the live NIST CSF 2.0 reference, as they are the kind of detail that shifts between drafts and revisions):

Note on supply-chain risk. CSF 2.0 places Cybersecurity Supply Chain Risk Management (C-SCRM) under the Govern Function — a deliberate signal that the vendor and software-dependency risk you studied in Chapter 29 is a governance responsibility, owned at the strategy level, not an afterthought bolted onto procurement.

CSF also includes two cross-cutting constructs you will hear in maturity discussions: Tiers (1–4: Partial, Risk Informed, Repeatable, Adaptive — describing the rigor of your risk-management practices, not a score) and Profiles (a "Current" profile describing where you are and a "Target" profile describing where you want to be; the gap between them is your roadmap). Do not confuse a Tier with a grade — Tier 4 is not "secure," it is "your risk practices are adaptive."

⚠️ Common Pitfall: Rating yourself "achieved" on a Subcategory because the capability exists. "Anomalous activity is detected" can be marked done because you own a SIEM — while your detection rules miss the techniques an attacker would actually use (Chapter 22's whole subject). CSF describes outcomes at a high altitude; a self-assessment measures presence, not effectiveness. Pair every "achieved" with the honest question: against the adversary we actually face?

A.2 NIST SP 800-53 — the control catalog

Where CSF tells you what outcomes to achieve, NIST SP 800-53 (Security and Privacy Controls for Information Systems and Organizations) is the deep catalog of specific controls to achieve them. It is mandatory for U.S. federal information systems and widely adopted voluntarily elsewhere as the most comprehensive control catalog in existence — hundreds of controls organized into control families, each identified by a two-letter prefix. SP 800-53 is far too large to implement wholesale; in federal practice it is applied through baselines (Low/Moderate/High impact) that select an appropriate subset, a tailoring concept defined in the companion SP 800-53B.

You will not memorize SP 800-53, and you should not try. What a defender needs is to recognize the family prefixes so that when an assessor or a system security plan references "AC-2" or "the IR family," you know the territory. The families:

Each family contains numbered controls (e.g., the Access Control family includes account management, least privilege, and remote-access controls), and many controls have enhancements that add rigor for higher-impact systems. SP 800-53 also formally separates security controls from privacy controls and integrates them into one catalog — the PT and parts of other families carry the privacy weight, reflecting the same governance-of-data concerns explored in Part VI.

🔗 Connection: SP 800-53 is the implementation depth beneath CSF's outcome breadth. NIST publishes an informative mapping from CSF Subcategories to SP 800-53 controls; in practice many organizations use CSF to communicate posture to leadership and SP 800-53 (or a lighter catalog like SP 800-171 for controlled-but-unclassified information) to actually engineer and assess the controls. If you work with the U.S. federal government or its contractors, expect SP 800-53 baselines and the Risk Management Framework (RMF, SP 800-37) to govern authorization.

A.3 CIS Critical Security Controls v8

If SP 800-53 is the encyclopedia, the CIS Controls are the prioritized field manual. Maintained by the Center for Internet Security, the CIS Critical Security Controls v8 distill defense into 18 controls containing a manageable set of Safeguards (the v8 term for the individual sub-actions, formerly "sub-controls"). Their defining virtues are prioritization and actionability: the controls are ordered roughly by impact and prerequisite, and each Safeguard is a concrete, implementable action — making CIS the framework many practitioners reach for first when the question is "what do we do, in what order?"

CIS v8 reorganized around activities rather than who owns the device, which is why "Inventory and Control of Enterprise Assets" — knowing what you have — sits at number one. You cannot protect, patch, or monitor an asset you do not know exists.

The 18 Controls

Implementation Groups (IG1 / IG2 / IG3)

CIS's most practical innovation is the Implementation Group (IG) — a way to scope the Safeguards to an organization's size, resources, and risk, so a small business is not held to the same bar as a defense contractor:

The IGs are cumulative: IG2 includes all of IG1, and IG3 includes all of IG2. IG1 — "essential cyber hygiene" — is the single best starting point for an organization that does not know where to begin. It is a short, concrete list, and it maps to the controls that stop the overwhelming majority of common attacks.

🛡️ Defender's Lens: CIS Controls are ordered the way an attacker's path runs, which is why the order is a defense in itself. You cannot do anything downstream — patch, monitor, respond — without Controls 1 and 2 (asset and software inventory), because every other control acts on assets and software. When a team asks "where do we start?", the honest answer is almost always "inventory," and CIS makes that the literal first control. An attacker's reconnaissance builds an inventory of your estate; if you do not have a better one, you are at a disadvantage from the first move.

A.4 ISO/IEC 27001 and 27002

The ISO/IEC 27000 family is the international standard for managing information security, and it splits the job across two companion documents that are routinely confused:

• ISO/IEC 27001 is the certifiable standard for an Information Security Management System (ISMS) — a documented, risk-driven system for managing security. It cares less about any single control and more about whether you have a living process: defined scope, risk assessment and treatment, a Statement of Applicability (which controls you selected and why, and which you excluded), management commitment, internal audits, and continual improvement (the Plan-Do-Check-Act cycle). You can be formally certified against 27001 by an accredited body, producing a certificate recognized worldwide. The certifiable requirements live in the main clauses (organization context, leadership, planning, support, operation, performance evaluation, improvement).
• ISO/IEC 27002 is the guidance companion — the catalog of controls (and implementation advice) you choose from when treating the risks your 27001 ISMS identified. 27002 is not certifiable on its own; it is the menu, while 27001 is the discipline that decides what you order and proves you operate it.

The 2022 revision of ISO/IEC 27002 restructured its controls into four themes, replacing the older fourteen-domain structure. A defender should know the themes, because they are how modern 27001/27002 audits are organized:

The 2022 revision also tagged each control with attributes (such as control type — preventive/detective/corrective; security property — confidentiality/integrity/availability; and which CSF-like Function it supports), which makes ISO 27002 controls far easier to cross-map than they used to be. If you maintain a crosswalk (the subject of §A.6), the 27002 attributes are a gift.

⚠️ Common Pitfall: Treating ISO/IEC 27001 as "a list of controls to implement." Certification is about the management system — the process for choosing, operating, and improving controls — not about any particular control being present. An organization can hold a valid 27001 certificate and still be breached through a risk it assessed as low, a control it excluded with a documented (and reasonable-at-the-time) justification, or a gap that opened the day after the auditor left. The certificate proves your process works; it does not prove the controls you chose are sufficient against a determined adversary.

A.5 High-level cross-mapping

This is the table practitioners want most: a single control domain, viewed through all four frameworks at once, so one implemented control and one piece of evidence can answer to several frameworks. Read it as areas, not exact identifiers — the CIS control numbers are stable (v8), the CSF Function/Category areas are named per CSF 2.0, the ISO column names the 27002 theme, and the SP 800-53 column names the family prefix. Always confirm a specific control number against the live catalog before citing it in an audit.

A worked reading, the way a GRC analyst uses this table. Take multi-factor authentication on remote and administrative access — the same example Chapter 28 crosswalks. One control, one piece of evidence (a conditional-access policy export plus a sign-in-log sample showing MFA actually enforced), satisfies a requirement in every framework column: CSF's Protect/Identity area, CIS Controls 5 and 6, ISO 27002's Technological access-control theme, and SP 800-53's IA and AC families. Build a row like this for each of your controls and your separate framework efforts collapse into one maintained table. But the cells are not identical — each framework frames and scopes the control slightly differently, and a careful analyst notes the differences, because a control that satisfies one framework's intent may need a tweak to fully satisfy another's. And, the recurring warning: every cell can read "satisfied" while the MFA itself is a phishable push notification an attacker defeats with fatigue. The crosswalk proves the control exists across frameworks; it is silent on whether the control is good.

A.6 When to use which

Frameworks are tools, and the question is never "which is best" in the abstract but "which fits this organization, this obligation, and this moment." A decision guide:

A few patterns recur in mature programs:

• CSF + CIS is a common, complementary pair. CSF gives the language and structure for leadership and risk conversations; CIS gives the prioritized, concrete actions the engineers execute. Many organizations use CSF as the organizing skeleton and CIS Safeguards as the muscle.
• CSF + SP 800-53 is the federal/regulated pattern. CSF for posture and communication; SP 800-53 baselines for the authoritative control set and assessment.
• ISO 27001 is the certification play, especially for organizations selling internationally, where a customer in Frankfurt asks for a certificate the way a customer in San Francisco asks for a SOC 2 Type II (Chapter 28).
• You will often run more than one at once. This is normal and is exactly why crosswalking exists. The frameworks overlap enormously — nearly all of them require access control, encryption, logging, change management, incident response, and vulnerability management — so the work is to map them once and reuse the evidence.

🚪 Threshold Concept: A framework is a map of controls, and the map is not the territory. A fully populated CSF profile, a clean ISO certificate, a complete SP 800-53 baseline, an all-green CIS assessment — each is a representation of security, and a representation can be accurate and still describe something inadequate against the adversary you actually face. The mature defender uses frameworks for what they are genuinely good at — common language, prioritization, baselines, budget leverage, audit readiness — while building, above and beyond them, the controls that defeat the real attacker. Once you see frameworks as the floor you stand on to reach higher rather than the ceiling you stop at, you will never again confuse a green dashboard with a defended organization.

A.7 Quick reference card

A one-screen summary to reread before an exam or an audit.

The six CSF 2.0 Functions, in order: Govern · Identify · Protect · Detect · Respond · Recover.

The CIS starting point: Controls 1 (asset inventory) and 2 (software inventory) come first; IG1 is "essential cyber hygiene."

The ISO distinction: 27001 certifies the management system (the process); 27002 is the control catalog (the menu).

The unifying truth: every framework here answers "do controls exist and are they documented?" None answers "do they stop your actual adversary?" That second question is yours, and it is the whole of real security.

🔗 Connection: This appendix is the framework half of the compliance picture. Appendix E maps the regulatory and compliance regimes (PCI-DSS, HIPAA, GDPR, SOC 2, GLBA) against common control domains, and Chapter 28 walks the live skills — crosswalking, scoping, gap assessment, and surviving an audit — that turn these reference tables into a working compliance program.