Security control frameworks and risk frameworks

No organization needs to invent its security program from scratch. Control frameworks and risk frameworks capture decades of collective experience about what to protect, which controls work and how to manage risk systematically. The 2024 CISSP outline names several by example: ISO standards, NIST publications, COBIT, SABSA, PCI DSS and FedRAMP for controls, and ISO, NIST, COBIT, SABSA and PCI for risk. You do not need to memorize every control in every framework, but you should know what each is for, who uses it and how they fit together.

Why frameworks matter

Frameworks give a program structure, a common language and a way to show that it meets recognized practice. They help answer questions that boards, auditors, customers and regulators ask: are we covering the important areas, how do we compare with peers, and can we prove it? They also support the prudent person standard from Lesson 2: following a widely accepted framework is strong evidence of reasonable care.

It helps to separate several kinds of framework. Some are management system standards that describe how to run a program, such as ISO/IEC 27001. Some are control catalogs that list specific safeguards, such as ISO/IEC 27002 and NIST SP 800-53. Some are outcome frameworks that describe what good looks like without prescribing controls, such as the NIST Cybersecurity Framework. Some are risk frameworks that describe how to identify, analyze and treat risk, such as ISO 31000 and NIST SP 800-37. And some are industry or contractual requirements, such as PCI DSS and FedRAMP. Many organizations use several together and map controls between them.

The ISO/IEC 27000 family

ISO/IEC 27001:2022 specifies requirements for an information security management system (ISMS): a set of policies, processes and responsibilities for managing information security risk continually. Its main clauses cover context, leadership, planning, support, operation, performance evaluation and improvement, following the plan-do-check-act cycle. Organizations can be certified against ISO 27001 by an accredited body, which makes it popular for demonstrating security to customers internationally. Certified organizations had until October 2025 to move from the 2013 edition to the 2022 edition.

Annex A of ISO 27001 lists reference controls, and ISO/IEC 27002:2022 gives guidance on each. The 2022 edition reorganized the controls into 93 controls in four themes: organizational (37), people (8), physical (14) and technological (34), and added new controls such as threat intelligence, information security for cloud services, data masking and secure coding. Organizations select controls through risk assessment and record their choices, with justification, in a statement of applicability. Other family members include ISO/IEC 27005 for information security risk management and ISO/IEC 27701 for privacy information management.

The NIST Cybersecurity Framework 2.0

The NIST Cybersecurity Framework (CSF) was first published in 2014 for critical infrastructure and became widely used by organizations of all kinds. Version 2.0, released in February 2024, broadened its scope to all organizations and added a sixth function. The six functions are Govern, Identify, Protect, Detect, Respond and Recover. Govern sits at the center: it covers organizational context, risk management strategy, roles and responsibilities, policy, oversight and cybersecurity supply chain risk management.

Each function contains categories and subcategories that describe outcomes, for example 'assets are inventoried' or 'incidents are contained'. The CSF does not prescribe how to achieve them; it points to informative references such as SP 800-53 and ISO 27002. Organizations use profiles to describe their current state and target state, and tiers (partial, risk informed, repeatable, adaptive) to describe how rigorous their risk governance is. Because it is outcome-based and free, the CSF is a common starting point for organizations building a program and a common language between technical teams and executives.

NIST risk management publications

NIST SP 800-37 Revision 2 describes the Risk Management Framework (RMF), used across US federal agencies and adapted by many other organizations. Its seven steps are prepare, categorize, select, implement, assess, authorize and monitor. Systems are categorized by the impact of a loss of confidentiality, integrity or availability (low, moderate or high, using FIPS 199); controls are selected from the SP 800-53 catalog, now in Revision 5, which covers twenty control families including access control, incident response and supply chain risk management; an authorizing official formally accepts the residual risk; and controls are monitored continuously.

NIST SP 800-30 Revision 1 is a guide to conducting risk assessments. It describes threat sources, threat events, vulnerabilities, likelihood and impact, and gives sample scales and tables for combining them. SP 800-39 addresses risk at the organization, mission and system tiers. Lesson 11 uses ideas from SP 800-30 in its worked examples.

Governance and architecture frameworks

COBIT 2019, published by ISACA, is a framework for the governance and management of enterprise information and technology. It defines 40 governance and management objectives, grouped into five domains: evaluate, direct and monitor (governance), and align, plan and organize; build, acquire and implement; deliver, service and support; and monitor, evaluate and assess (management). COBIT is popular with auditors and boards because it links IT and security activities to enterprise goals.

SABSA (Sherwood Applied Business Security Architecture) is an architecture framework that derives security requirements from business requirements. It uses a matrix of layers, from contextual and conceptual down to physical and component, crossed with the questions what, why, how, who, where and when. Its strength is traceability: every control can be traced back to a business need.

ISO 31000:2018 provides general principles and guidelines for managing any kind of risk, not just information risk. It describes a process of establishing scope and context, risk assessment (identification, analysis and evaluation), risk treatment, monitoring and review, and communication and consultation. Many enterprise risk management programs use ISO 31000 or the COSO enterprise risk management framework, and information security risk feeds into them.

FAIR (Factor Analysis of Information Risk) is a model for quantifying information risk in financial terms. It breaks risk into loss event frequency (threat event frequency multiplied by vulnerability) and loss magnitude (primary and secondary losses), and usually uses ranges and Monte Carlo simulation rather than single values. FAIR is an Open Group standard. Lesson 11 compares quantitative and qualitative approaches.

Industry and contractual frameworks

Some frameworks apply because of what an organization does or who it serves. The Payment Card Industry Data Security Standard (PCI DSS), maintained by the PCI Security Standards Council, applies to any organization that stores, processes or transmits cardholder data. Version 4.0.1 is current; the future-dated requirements introduced in version 4.0 became mandatory on 31 March 2025. PCI DSS is enforced through contracts with card brands and acquiring banks rather than by law, but non-compliance can bring fines and loss of the ability to accept cards.

Government and contractual frameworks differ by country. In the United States, FedRAMP standardizes security assessment and authorization of cloud services used by federal agencies, based on SP 800-53 baselines, and its FedRAMP 20x initiative, launched in 2025, aims to speed authorizations using automated evidence. Defense contractors face the Cybersecurity Maturity Model Certification (CMMC) 2.0: the program rule took effect in December 2024, the contract clause rule took effect on 10 November 2025, and requirements phase into contracts over about three years, with Level 2 based on the 110 requirements of NIST SP 800-171. Sector rules, such as HIPAA for health information, sit alongside these.

Choosing and combining frameworks

No single framework fits every organization. A regional bank might certify to ISO 27001 for international clients, use the NIST CSF to report to its board, follow regulatory guidance from its supervisor, comply with PCI DSS for card processing and use FAIR to quantify top risks. The key is to choose a primary framework for structure, map other requirements onto it, and avoid running parallel programs that duplicate effort. Common control frameworks, which map one set of controls to many requirements, make this practical.

Implementing a framework in practice

Adopting a framework is a project, not a document. A common sequence is to obtain executive sponsorship, define scope (the whole organization, a business unit or a specific service), assess the current state against the framework, agree a target state based on risk and obligations, and build a prioritized roadmap to close the gaps. Progress is measured against the framework's own structure, for example by CSF category or ISO control, which gives leadership a consistent view over time.

Gap assessments are where frameworks earn their value. A team scoring itself against the CSF might find that Protect outcomes are strong because of good endpoint tools, but Govern and Recover outcomes are weak: no board-approved risk appetite, no tested recovery plan. Those findings shift investment from buying more technology to building governance and resilience. Framework maturity should also be realistic. A small organization does not need every control in SP 800-53; it needs the controls that address its risks, documented well enough to show reasonable care. Mapping tools such as NIST's online informative references and the Cloud Security Alliance's Cloud Controls Matrix help organizations see how one control satisfies several frameworks at once.

When frameworks are updated, organizations need a transition plan. The move from ISO 27001:2013 to the 2022 edition, and from CSF 1.1 to 2.0, required organizations to map old controls to new ones, add new requirements such as threat intelligence and supply chain governance, and update their statements of applicability and profiles. Tracking framework changes is part of maintaining the program, not a one-time task.