You Cannot Adopt a Law: CISSP 3.3, and the Eleven “Frameworks” That Are Six Different Kinds of Thing

In the spring of 2014, Target filed its annual report with the Securities and Exchange Commission. Buried in it was a sentence about the largest retail card breach in American history, and the sentence is the most useful thing in this entire article.

The Senate Commerce Committee’s majority staff quoted it in their “Kill Chain” analysis of the breach, published 26 March 2014:

A PCI DSS assessment is a test of a declared cardholder data environment, and the attack path did not run through the declared cardholder data environment.

In its recently filed 10K, Target states that in the fall of 2013, “an independent third-party assessor found the portion of our network that handles payment card information to be compliant with applicable data security standards.”

Read it again, slowly, and notice the clause that does all the work: the portion of our network that handles payment card information.

That is not a hedge Target’s lawyers snuck in. It is an accurate description of what a Payment Card Industry Data Security Standard assessment actually is. A merchant defines a cardholder data environment. An assessor tests inside it. The report says the inside was compliant. It says nothing whatever about the outside — and the attackers came in through the outside, via an external billing system that the Senate report notes “is not technically related to Target’s POS system,” using credentials taken from a heating and refrigeration contractor.

Forty million card numbers. Personal information on up to seventy million people. And a defensible compliance certificate covering a boundary that the breached party had drawn itself.

Hold on to that idea, because it turns out to be the thing that unites almost everything in CISSP Domain 3, section 3.3. Every regime on the syllabus tests you inside a boundary. The only question that matters — the question the book never asks — is who drew the boundary. For ISO/IEC 27001 you draw it, and you file a Statement of Applicability explaining your exclusions. For PCI DSS you draw it, and call it your cardholder data environment. For FedRAMP you draw it, and it is literally called your authorization boundary. For NIST SP 800-53 there is no boundary because there is nothing to be compliant with. And for HIPAA, SOX and FISMA you do not draw it at all: Congress drew it, it is drawn around you, and no amount of scoping gets you out from under it.

That is the difference between a law and a standard, and the book’s Table 3-11 files them in the same column.

What the exam actually asks, which is nine words

Before the book, the syllabus. The ISC2 CISSP Certification Exam Outline, effective 15 April 2024, states this objective in full as:

3.3 Select controls based upon systems security requirements

That is the entire text. No parenthetical examples, no sub-objectives — not even the “(e.g., …)” that objective 3.2 gets. Domain 3, “Security Architecture and Engineering,” carries an average weight of 13% of the adaptive exam, and this line is one of six objectives inside it.

So the single subsection you are about to read about — 3.3.1, “Security Control Frameworks” — is the CISSP book’s pedagogy laid over nine words. That matters twice over. It tells you the depth ISC2 is signalling, which is conceptual. And it means everything in the book’s treatment is an authorial choice that can be judged on its merits rather than a specification that must be obeyed.

Judged on its merits, the choice is a good one with one serious flaw. The good part: a candidate genuinely does need to recognise these eleven names and know roughly what each is for, and the book’s table does that in about a thousand words. The flaw is that filing statutes, a card-brand contract, a certifiable management standard, a government authorisation programme, a control catalogue and three governance frameworks under one heading called “Security Control Frameworks” teaches a category error that will follow the reader into their working life. It produces the professional who says “we need to be compliant with 800-53,” which is not a thing, or who asks whether the company should “adopt HIPAA,” which is not a decision anyone gets to make.

What the book says, fairly

The CISSP book’s core concepts for 3.3.1 are three lines:

Security control frameworks aid with the control selection process.
Security control frameworks provide guidance, based upon best practices.
Features from multiple frameworks can be used to meet the needs of an organization.

The argument around them is sound and worth stating properly, because a lot of this article is spent correcting the book and the corrections would be cheap if the frame were wrong. The frame is right. The book puts control selection downstream of decomposition and valuation:

Components should be protected based upon value, which drives the selection of controls. All this activity is predicated on risk management.

That is the correct order of operations and it is the half most compliance programmes skip. You do not start with a framework. You start with what you have, what it is worth, and what could go wrong; the framework is a source of candidate controls once you already know what you are protecting and why. The book’s example is deliberately small — a security professional “pondering how to protect a certain system component, like a storage device, CPU, or piece of memory” — and the framework’s job there is to “offer insight into appropriate controls to consider.”

Then a hint aimed straight at the exam:

Understand the major frameworks at a high level, especially ISO 27001/02, which is an internationally recognized framework

And then Table 3-11: COBIT, ITIL, NIST SP 800-53, PCI DSS, ISO 27001, ISO 27002, COSO, HIPAA, FISMA, FedRAMP, SOX. Eleven rows, one heading.

The section closes with a passage called “Rationalizing Frameworks,” which contains the book’s second good idea and its most dangerous sentence in the same paragraph:

Most organizations choose to use different ones for various contractual or legal reasons. Then they combine these and attempt to develop one overarching and simplified framework. It doesn’t make sense to test a very similar control multiple times. As such, controls are merged, rationalized, and then tested once. This is the approach most organizations take.

The good idea is that a hospital lands under HIPAA and PCI DSS simultaneously and has to do something coherent about it. The dangerous sentence is “controls are merged, rationalized, and then tested once,” offered without a single word about when that is safe. NIST has published a methodology for exactly this question, it types every mapping into five relationship categories, and testing once is only defensible for two of them. We get there at the end; it is the best material in the section and the book leaves it out.

Part I — The category error, and why it costs money

Here is the claim, stated as plainly as I can put it.

The eleven items in Table 3-11 are six different kinds of object. They differ in who obliges you, in what “compliance” physically consists of, in what happens when you fail, and in whether you can decline. “Selecting a control” means a different act in each row. A single heading hides all four differences.

This is not pedantry about taxonomy. It is the difference between a conversation you can have with your general counsel and one you cannot.

Category	In the book’s table	Who obliges you	What “compliance” physically is	What failure costs	Can you decline?
Law / regulation	HIPAA, SOX, FISMA	Congress, enforced by a regulator — HHS Office for Civil Rights; the SEC and PCAOB; OMB and agency Inspectors General	A legal state you are either in or out of. There is no certificate. Nobody issues you one.	Civil money penalties, settlements carrying corrective action plans, criminal exposure under SOX	No. It attaches to who you are and what you hold.
Contractual standard	PCI DSS	The card brands, reaching you through your acquiring bank’s contract. Not a government and not a statute	Validation sized to your merchant level: a self-assessment questionnaire, or a Report on Compliance from a qualified assessor	Fines levied by the brands and passed down by your acquirer, worse rates, ultimately loss of card acceptance	Yes — by not taking cards.
Certifiable standard	ISO/IEC 27001 (with 27002 as its implementation guidance)	Nobody, until a customer or a tender demands it	An accredited body audits your information security management system against a scope you declare, with a Statement of Applicability recording which controls you excluded and why	Loss or suspension of the certificate. Commercial, not legal	Yes. Entirely voluntary.
Government authorisation programme	FedRAMP	Statute plus OMB policy, for a specific class of federal use	An assessed package, an agency authorisation, and then continuous monitoring that never stops	Removal from the FedRAMP Marketplace and ineligibility for the federal cloud work it gates	Yes — by not selling cloud services to agencies.
Control catalogue	NIST SP 800-53	Nothing, on its own	Nothing. There is no such thing as “being compliant with SP 800-53.” It is a catalogue that other regimes point at	None directly	Yes — but if FISMA or FedRAMP reaches you, the thing that reaches you invokes it.
Governance / management framework	COBIT, ITIL, COSO	Nobody	Adopt, adapt, assess your own maturity. Not pass/fail	None	Yes.

Six columns, six answers, every time.

The sharpest one: SP 800-53 is a catalogue, not a regime

If a candidate takes one distinction out of 3.3, take this one, because it is the one most often got wrong by people who have been in the industry for a decade.

NIST SP 800-53 is currently at Revision 5. Its abstract, on NIST’s own publication page, opens like this:

This publication provides a catalog of security and privacy controls for information systems and organizations to protect organizational operations and assets, individuals, other organizations, and the Nation from a diverse set of threats and risks, including hostile attacks, human errors, natural disasters, structural failures, foreign intelligence entities, and privacy risks.

A catalog. The word is NIST’s, in the first eight words of the abstract, and it is the correct word. SP 800-53 organises its controls into twenty families, and it does not tell you which of them apply to you. It cannot, because it does not know who you are. Selection happens elsewhere: FISMA reaches a federal system through the Risk Management Framework, which categorises the system and then selects a baseline out of the catalogue; FedRAMP reaches a cloud service through its own baselines, which are also drawn from the catalogue.

So “we are 800-53 compliant” is a sentence with no truth value. The honest versions are “we have an authorisation to operate under the Risk Management Framework,” or “we hold a FedRAMP authorisation at Moderate,” or “we have implemented the Moderate baseline as a voluntary internal standard.” Those are three different claims with three different amounts of evidence behind them, and the vague version conceals which one you actually mean.

The same test applies to the two ISO documents in the table, and here the book gets it exactly right: you can be certified against ISO/IEC 27001; ISO/IEC 27002 is implementation guidance for 27001’s controls and nobody certifies against 27002. That distinction is worth an exam mark and it is worth more than that in a vendor meeting.

The second sharpest: you cannot adopt a law

HIPAA, SOX and FISMA are in Table 3-11 alongside COBIT and ITIL, and the effect of that layout is to suggest they are all things an organisation might choose from a menu. They are not.

There is no HIPAA certificate. There is no SOX certificate. There is no FISMA certificate. There is no accreditation body, no auditor’s stamp, no wall plaque, and no vendor who can sell you one — and every vendor claiming to sell “HIPAA certification” is selling you an attestation of their own devising, which is a product they invented and not a status the statute recognises. What exists instead is a legal state, assessed after the fact by a regulator who is usually looking at you because something has already gone wrong.

The mechanism of enforcement is therefore completely different in kind. An ISO 27001 auditor arrives on a schedule you agreed, examines a scope you declared, and issues findings you can plan around. The HHS Office for Civil Rights arrives after a breach report, examines whatever it likes, and issues a settlement. Which brings us to the case.

Where that distinction is worth $16 million

On 15 October 2018, HHS announced a HIPAA settlement with Anthem, Inc. From the department’s own press release:

Anthem, Inc. has agreed to pay $16 million to the U.S. Department of Health and Human Services, Office for Civil Rights (OCR) and take substantial corrective action to settle potential violations of the Health Insurance Portability and Accountability Act (HIPAA) Privacy and Security Rules after a series of cyberattacks led to the largest U.S. health data breach in history and exposed the electronic protected health information of almost 79 million people.

The release says the $16 million “eclipses the previous high of $5.55 million paid to OCR in 2016” — roughly a threefold jump in the ceiling. The attack itself is depressingly ordinary: OCR records that Anthem discovered the intruders had come in “through spear phishing emails sent to an Anthem subsidiary after at least one employee responded to the malicious email and opened the door to further attacks.”

Now the part that belongs in a control-selection article. OCR did not fine Anthem for being breached. Read what it actually cited:

In addition to the impermissible disclosure of ePHI, OCR’s investigation revealed that Anthem failed to conduct an enterprise-wide risk analysis, had insufficient procedures to regularly review information system activity, failed to identify and respond to suspected or known security incidents, and failed to implement adequate minimum access controls to prevent the cyber-attackers from accessing sensitive ePHI, beginning as early as February 18, 2014.

Four findings, and every one of them is a process failure rather than a technology failure:

No enterprise-wide risk analysis.
Insufficient procedures to regularly review information system activity.
Failure to identify and respond to suspected or known security incidents.
Inadequate minimum access controls.

Not “no next-generation firewall.” Not “unpatched server.” The first item is the foundational obligation of the entire Security Rule, and it is the same obligation the book states in its own frame — controls are selected on value, and all of it “is predicated on risk management.” Anthem’s penalty is what it looks like when an organisation skips step one and buys controls anyway.

Note also the last clause: beginning as early as February 18, 2014. The failures OCR cited pre-date the breach report by more than a year. That is a regulator reaching backwards through time to a period when nothing had gone wrong yet, which is a thing no certification body will ever do to you and a thing a statute does routinely.

And a small correction to the book while we are here. Table 3-11 says HIPAA “focuses on the protection of protected health information (PHI) of individuals.” The Security Rule — the part of HIPAA that concerns control selection — governs electronic protected health information specifically. OCR’s release says ePHI five times and PHI never. The Privacy Rule covers PHI in any form including paper and speech; the Security Rule covers ePHI. If you are selecting technical controls, the second is your scope, and the distinction is examinable.

One more thing about HIPAA that a reader in 2026 should know and that no printed prep book can keep current: HHS has proposed a substantial rewrite of the Security Rule. The notice of proposed rulemaking was published at 90 FR 898 with the comment period closing in March 2025, and it runs to 125 pages of proposed amendments — including, from its own table of contents, adding a definition of “Multi-Factor Authentication” to the regulation. It is a proposed rule. I found no final rule. Do not study from it, do not build a programme on it, and do watch for it.

Two of its section headings are worth reading even so, because they are the regulator’s own diagnosis of everything this article is about. One is “Regulated Entities’ Compliance With the Requirements of the Security Rule Is Inconsistent.” The other is “The Secretary Must Develop Standards for the Security of ePHI Because None Have Been Developed by an ANSI-Accredited Standard Setting Organization.” Sit with the second one. The reason healthcare security in the United States is governed by a statute rather than by a certifiable standard is that, in HHS’s telling, the standards bodies did not produce one — so the government wrote a law instead. The category of a framework is not a fact of nature. It is a historical accident with consequences.

Part II — Five corrections, and one is the headline

The house rule on this series is that the book gets checked rather than paraphrased. The CISSP book is a good book and section 3.3 is a thousand words long, so there is less to check here than in 3.2. Five things did not survive.

Correction 1: the ISO 27001 Annex A structure in the book is the previous one

This is the important one, it is directly examinable, and a candidate who memorises the book’s list will have memorised something that no longer exists.

Table 3-11’s ISO 27001 row is headed with the correct current version number. It describes 27001 correctly. Then it says:

Annex A of the standard contains the following domains:

and lists fourteen: information security policies; organization of information security; human resource security; asset management; access control; cryptography; physical and environmental security; operations security; communications security; system acquisition, development, and maintenance; supplier relationships; information security incident management; information security aspects of business continuity management; compliance.

That is the 2013 structure. Fourteen domains, 114 controls. The 2022 revision restructured Annex A completely. It now has four themes and 93 controls, numbered as clauses A.5 through A.8:

Theme	Clause	Controls
Organisational	5	37
People	6	8
Physical	7	14
Technological	8	34
Total		93

Eleven of the 93 are new controls with no 2013 counterpart, and the list of them reads like a summary of what changed in the world between the two editions: threat intelligence, information security for use of cloud services, ICT readiness for business continuity, physical security monitoring, configuration management, information deletion, data masking, data leakage prevention, monitoring activities, web filtering, and secure coding. The total dropped from 114 to 93 not because controls were deleted but because many were merged.

This is not a version-history quibble. The two structures answer different exam questions. “Which Annex A theme contains access control?” has one answer under the old structure and a different one under the new. A candidate reciting fourteen domains is reciting the wrong list.

Now the sourcing, stated honestly, because that is part of the standard of this series. ISO’s own text is paywalled and iso.org defeats automated retrieval; I did not open the standard itself, and nobody writing publicly about Annex A for free has either. So this correction is confirmed by convergence, and here is exactly what it rests on.

The primary I could open closest to authority is NIST’s own SP 800-53 Revision 5 publication page, which lists among its supplemental material a “Crosswalk: 800-53 Rev. 5 to ISO/IEC 27001:2022 (OLIR)”. That establishes that the 2022 edition is the current one that a US federal standards body maps against, which is the half of the claim the book gets right.

The structure itself comes from GRC Solutions (formerly IT Governance), whose “Your Guide to ISO/IEC 27001:2022” states:

Annex A of ISO 27001 lists 93 information security controls that support the implementation and maintenance of an ISMS.

and then:

The controls are grouped into four themes:
5 Organisational (37 controls)
6 People (8 controls)
7 Physical (14 controls)
8 Technological (34 controls)

That firm led the world’s first certification to BS 7799, this standard’s British predecessor, which makes it about as close to the inside of the standards world as a freely readable source gets. Five further independent sources — Drata, Sprinto, Scrut, GAICC and Mindset Cyber — publish the identical breakdown including the per-theme counts and the clause numbering, and I found none that disagreed. The eleven new controls are named identically across the same set.

I am telling you the provenance rather than asserting the fact, because “93 controls in four themes” is the kind of number that circulates without anyone checking, which is precisely how the book ended up printing the fourteen.

And a bonus that comes free with the same page, which will matter in Part III:

You don’t have to implement all 93. Instead, you should carry out a risk assessment to determine which controls you need. You should also justify why you exclude other controls.

That is the Statement of Applicability, described without the jargon. Annex A is a checklist of things to have a reasoned position about, not a list of things to install.

Correction 2: ISACA is an Association, and it does not use the name any more

The book says COBIT

was created by Information Systems Audit and Control Assurance (ISACA)

Two errors in six words. The A is Association, not Assurance — the organisation incorporated in 1969 as the EDP Auditors Association, and audit associations are the sort of thing that gets called an association. Worse, the expansion is retired. From ISACA’s own history page:

Previously known as the Information Systems Audit and Control Association®, ISACA now goes only by its acronym to reflect the broad range of IT governance professionals we serve.

So the correct sentence is the shortest one: COBIT is ISACA’s. Not “ISACA, which stands for…”. The organisation deliberately dropped the expansion because it stopped describing the membership, and a security professional writing “Information Systems Audit and Control Assurance” in a document is announcing that they did not check.

ISACA currently publishes COBIT 2019.

Correction 3: FISMA’s operative text is the 2014 Act

The book’s row reads “Federal Information Security Management (FISMA) Act of 2002.” The 2002 Act is not the operative law. The Federal Information Security Modernization Act of 2014, Public Law 113-283, amended chapter 35 of title 44 of the US Code

by striking subchapters II and III

and inserting a new subchapter II at 44 U.S.C. §§ 3551–3558.

Same acronym, different middle word, replaced text. That is the whole correction and it needs no further history — but it does need saying, because a reader who goes looking for their obligations in the 2002 subchapter is reading something that was struck out.

Correction 4: FedRAMP’s scope is much narrower than “any cloud service”

The book says:

Any cloud services that hold US federal government data must be FedRAMP authorized.

That is not the rule, and the error runs in the expensive direction: it will make a reader tell a client they need an authorisation they do not need.

FedRAMP describes its own statutory basis this way:

FedRAMP was established in the law to provide a standardized approach to the assessment and authorization of cloud computing products and services that process unclassified information used by agencies.

Three limits in one sentence. Unclassified — classified and national-security systems are governed elsewhere. Used by agencies — this is about executive-agency consumption of commercial cloud, not about anyone who happens to touch federal data. And cloud computing products and services — not software generally.

Then the exclusions, which are the part that really breaks the book’s “any.” FedRAMP publishes the categories that are specified as outside its scope:

Information systems that are only used for a single agency’s operations, hosted on cloud infrastructure or platform, and are not offered as a shared service or do not operate with a shared responsibility model;
Social media and communications platforms used in accordance with agency social media policies;
Search engines;
Widely available services that provide commercially available information to agencies, but do not collect Federal information;
Ancillary services whose compromise would pose a negligible risk to Federal information or information systems, such as systems that make external measurements or only ingest information from other publicly available services; and
Any other categories of products or services identified for exclusion by the FedRAMP Board, with the concurrence of the Federal CIO.

A single-agency system, hosted in the cloud, holding federal data, not offered as a shared service, is out of scope by name — and that alone falsifies “any.”

There is a further subtlety that the exam will not test but your job will. FedRAMP says:

Only a federal agency can determine if their use case for a cloud service falls within the scope of FedRAMP. Cloud service providers may reference this when considering whether to pursue a FedRAMP Certification but the specific agency use case for adoption is what matters, not the service itself.

Scope is a property of the use case, not of the product. The same SaaS product can be in scope for one agency’s deployment and out of scope for another’s. And FedRAMP adds, flatly, that it “does not support or provide ‘equivalency'” — which is aimed squarely at the vendors who market themselves as FedRAMP-equivalent.

Correction 5: Enron explains why SOX was drafted; WorldCom explains why it passed

The book says the Sarbanes-Oxley Act

is a direct result of the wild financial fraud at “Enron”.

Incomplete in a way that removes the lesson. Enron created the appetite for a law. It did not create the votes, and the law that Enron alone would have produced is not the law that exists. The legislative record is public and unambiguous:

What happened	The record
The House passed its bill — the Corporate and Auditing Accountability and Responsibility Act, H.R. 3763 — on 24 April 2002, by 334 to 90. Historians of the period treat this as the weaker of the two proposals.	House Clerk roll call vote 110 of 2002
Senator Sarbanes’ stronger bill, S. 2673, sat.	—
On 26 June 2002 the SEC filed suit against WorldCom, charging it “with a massive accounting fraud totaling more than $3.8 billion.”	SEC Litigation Release No. 17588
On 15 July 2002, nineteen days later, the Senate passed S. 2673 by 97 to 0.	Senate roll call vote 176
On 25 July 2002 the Senate agreed to the conference report on H.R. 3763 by 99 to 0.	Senate roll call vote 192

A chamber that could not move the bill in June passed it unanimously three weeks after WorldCom. The historians’ consensus — and I state it as consensus, not as a proven causal claim — is that WorldCom is why the strong Senate version prevailed over the weak House version in conference rather than the other way round.

Why does a security article care about the legislative history of an accounting statute? Because it explains the shape of the control obligation you inherited. SOX section 404 exists in its strong form, requiring management assessment of internal control over financial reporting and an auditor attestation for larger filers, because a second fraud landed while the first was still being legislated. Every IT general control your finance systems carry — access provisioning, change management, segregation of duties — descends from a three-week window in July 2002.

Part III — One real case per category

The book’s table gives eleven names and no evidence. Here is what each category looks like when it meets the world. I have tried to take each case from an official finding rather than from press coverage, and where no case exists I say so.

Contractual standard: Target, and the boundary you drew yourself

We started here, so let us finish it properly.

The Congressional Research Service, in The Target Data Breach: Frequently Asked Questions (report R43496), states the compliance fact in the most careful available wording:

Target has testified that its systems were reviewed in September 2013 and certified as compliant.

Note the construction: Target has testified. The CRS is not asserting that Target was compliant; it is reporting sworn testimony that an assessment was done and passed. That is the right level of confidence for this fact and it is the level I will keep.

The Senate Commerce Committee’s kill-chain report quotes Target’s chief financial officer testifying that the company “had in place multiple layers of protection, including firewalls, malware detection software, intrusion detection and prevention capabilities and data loss prevention tools,” and then, one sentence later, that Target had been certified in September 2013 as PCI DSS compliant.

Then the breach. From the CRS summary:

On December 19, 2013, Target confirmed that some 40 million credit and debit card account numbers had been stolen. On January 10, 2014, Target announced that personal information, including the names, addresses, phone numbers, and email addresses of up to 70 million customers, was also stolen during the data breach.

And the sentence from the 10-K that we opened with: an assessor found “the portion of our network that handles payment card information” compliant.

Here is the lesson, and it is not the lesson usually drawn. The usual reading is “compliance is worthless, Target was compliant and got breached anyway.” That reading is lazy, and worse, it is unfalsifiable — it lets you dismiss any control regime by pointing at any breach.

The precise reading is better and more actionable. A PCI DSS assessment is a test of a declared cardholder data environment, and the attack path did not run through the declared cardholder data environment. The Senate report traces the initial access to credentials belonging to a heating and refrigeration contractor, used against an external billing system which the report notes “is not technically related to Target’s POS system.” The assessor tested the room. The attacker came in through the corridor.

That is not an indictment of PCI DSS as a control set. It is an indictment of treating a scoped assessment as a statement about an estate. And it generalises to every certifiable regime in Table 3-11, which is why it is the spine of this article rather than a footnote in one section.

The practical question to carry into your next assessment is therefore not “did we pass?” It is “what did we exclude from scope, who approved the exclusion, and what would an attacker with access to the excluded part be able to reach?” For Target in 2013, the honest answer to the third part was: the point-of-sale estate.

Certifiable standard: ISO 27001, and why I am not giving you an anecdote

The standard move here is to name a company that held an ISO 27001 certificate and got breached anyway. I looked, and the widely circulated example rests on a single opinionated standards-industry blog with no independent corroboration. I could not verify it, so it is not in this article. An unverified anecdote would also have been weaker than the structural point, which needs no anecdote at all.

The structural point is this. An ISO/IEC 27001 certificate attests that an information security management system conforming to the standard exists and operates within a scope the organisation itself declared. Two consequences follow, and both are on the certificate:

The scope statement. Every ISO 27001 certificate carries one. It names the activities, locations and services covered. Read it. A certificate scoped to “the provision of hosted payroll services from the Manchester data centre” says nothing about the London office, nothing about the sales CRM, and nothing about the acquisition completed last year. Buyers routinely file the certificate without reading the scope line, which is the single most common due-diligence failure I would expect a CISSP-level professional to catch.

The Statement of Applicability. Annex A’s 93 controls are not mandatory. As the guidance quoted earlier puts it, you carry out a risk assessment to decide which you need and “should also justify why you exclude other controls.” The Statement of Applicability is where those exclusions live, with reasons. It is the most information-dense document in the whole certification, and it is the one the auditor reads first and the customer never asks for.

So the correct question to a vendor waving a certificate is never “are you ISO 27001 certified?” It is “what is the scope statement, and may I see the Statement of Applicability?” If the answer to the second is no, you have learned something.

And there is an unexpected corroboration for this from the academic literature, which we will come to in Part IV: when researchers went looking for a performance effect from ISO 27001 certification and found none, one of the two explanations they offered for the null result was that most of their sample firms held only partial-coverage certifications rather than organisation-wide ones. The scope problem is large enough to show up in the statistics.

Law, federal edition: OPM, or a government failing its own framework

If HIPAA and Anthem show a regulator punishing a private company, FISMA and OPM show something rarer and more instructive: the government failing the framework it wrote, and then investigating itself.

The House Committee on Oversight and Government Reform published a staff report titled The OPM Data Breach: How the Government Jeopardized Our National Security for More than a Generation, chronicling what the committee describes as a year-long investigation into a 2015 compromise of highly sensitive personnel data. Its key findings, as the committee lists them:

The OPM data breach was preventable.
OPM leadership failed to heed repeated recommendations from its Inspector General, failed to sufficiently respond to growing threats of sophisticated cyber attacks, and failed to prioritize resources for cybersecurity.
Data breaches in 2014 were likely connected and possibly coordinated to the 2015 data breach.
OPM misled the public on the extent of the damage of the breach and made false statements to Congress

Read the second finding against the first correction in Part I. OPM was subject to FISMA. FISMA’s whole machinery is annual reporting, Inspector General evaluation, and authorisation of systems. The Inspector General had been making recommendations. The recommendations were not heeded. The framework generated the finding and the finding generated nothing.

That is the failure mode specific to the law category, and it is different from the failure mode of a certificate. A certificate can be suspended by a body that has commercial reasons to protect its own accreditation. A statutory reporting regime pointed at a government agency has, in practice, no comparable lever — the report’s own remedy is a set of recommendations to Congress. Reporting is not enforcement, and a framework whose only output is a report will eventually produce a shelf of reports.

A note on sourcing. I read the committee’s own summary of its findings and quote it verbatim above; the underlying report runs to hundreds of pages and I did not read it end to end, so nothing here goes beyond the four findings the committee itself lists.

Control catalogue: the case that cannot exist

There is no enforcement case for NIST SP 800-53, and looking for one is the fastest way to understand the category.

Nobody has ever been fined for violating SP 800-53. No organisation has ever lost a certificate for it, because none is issued. The catalogue has no jurisdiction, no registry, no assessor cadre and no penalty. What it has is other people’s regimes pointing at it: the Risk Management Framework selects baselines from it for federal systems, and FedRAMP’s baselines are drawn from it for cloud services.

So when you see “800-53 compliance” on a vendor’s website, the useful follow-up is: compliant according to whom, assessed by whom, against which baseline? Usually the honest answer is “we mapped our controls to the Moderate baseline internally,” which is a perfectly respectable thing to have done and a completely different claim from an authorisation.

Government authorisation programme: FedRAMP, and a NOT FOUND

I went looking for a named FedRAMP revocation — a specific cloud service, identifiable, whose authorisation was withdrawn for sustained non-compliance. I did not find one. That is a search result, not a proof of absence; it may exist and be unfindable, or it may be that the mechanism works by attrition rather than by dramatic removal.

What is documented is the mechanism, and the mechanism is the more interesting thing anyway, because FedRAMP is the one regime in Table 3-11 that can be taken away from you while you still hold all the paperwork.

Under FedRAMP’s consolidated rules for 2026, the continuous-monitoring obligations are enforced through an escalation ladder. Repeated failures — missing the monthly continuous-monitoring meeting with agency customers, or failing to share required information through the required process — move a cloud service offering into a public “Remediation” status on the FedRAMP Marketplace, then to a notice of pending revocation, then to revocation itself, at which point the offering “will be removed from the FedRAMP Marketplace for a period of at least 6 months, after which the cloud service offering may undergo a full new assessment for FedRAMP Certification.” I am deliberately describing the shape and not the calendar: this comes from a Request for Comment inside a ruleset that is new and still moving, and any specific number of failures or effective date printed here would be wrong within a year.

The shape is the lesson. The obligation is continuous, so the failure is procedural. You do not lose a FedRAMP authorisation by being breached. You lose it by not turning up to the meeting. That is a genuinely different theory of assurance from an annual audit, and it is a direct answer to the compliance-theatre objection we will get to shortly.

FedRAMP is also blunt about not being what the book’s heading implies. Its own guidance for providers says:

FedRAMP is a security framework for businesses to set security goals for themselves, continuously validate the effectiveness of the capabilities used to meet those goals, measure their performance against those goals, and ensure security and engineering teams have the resources necessary to meet those goals. It should not be treated like a traditional compliance framework.

The programme in Table 3-11 says, in its own words, do not treat me as a compliance framework.

Governance framework: COSO, and the framework that spread where an auditor was watching

COSO is in the book’s table as a “voluntary private sector initiative,” which is accurate as far as it goes. What the table does not convey is that COSO’s internal control framework became the de facto standard for the most consequential control assessment in American corporate life without ever being named in the rule that requires it.

SOX section 404 requires management to assess internal control over financial reporting against a suitable, recognised control framework. The SEC did not name COSO. COSO won anyway.

The revealing part is not that it won but where it won, and the number is worth carrying. Research on the adoption of the updated COSO framework found that roughly 82% of companies whose internal control over financial reporting carried an external auditor’s opinion adopted the updated framework in the first year — against roughly 37% of filers where management reported alone with no auditor attestation. Adoption then converged towards near-universal the following year.

The framework spread where an auditor was watching and stalled where one was not.

That single comparison is the most honest thing anyone can tell you about voluntary frameworks. Voluntary adoption is real but it is slow and partial; adoption becomes fast and near-total the moment somebody independent is going to look. If you are trying to get a governance framework adopted inside your own organisation, that is your lever, and it is not the quality of the framework.

Sourcing note: those adoption percentages come from an audit-data vendor’s published analysis and the accounting literature that used the same data, both consistent, neither read by me at the underlying dataset. Treat the two figures as approximately right and the contrast between them as the finding.

One correction while we are here. The book blurs COSO into a single thing. COSO publishes two distinct products that get confused constantly: the Internal Control—Integrated Framework — the one used for SOX 404 work, originally issued in 1992 and refreshed in 2013 — and Enterprise Risk Management—Integrating with Strategy and Performance, which is a different document for a different purpose. If someone says “we use COSO,” ask which.

The two remaining rows

ITIL is at ITIL 4, and the book’s description of it — the processes of a well-run IT department, service management aligned to business goals — is fair. The thing worth knowing that the book omits is custodial: ITIL is no longer a UK government publication, and the certification scheme is run by PeopleCert. That matters if you are budgeting for training or checking whether a supplier’s “ITIL certified” staff hold anything current.

COBIT is at COBIT 2019, is ISACA’s, and is genuinely the best fit in the table for audit and assurance work, which is what the book says. On the acronym expansion, see the exclusions block at the end of this article; there is a reason I have not printed one.

Part IV — The honest question: does any of this stop breaches?

Every article about control frameworks eventually has to answer the question the reader is actually holding, and most of them dodge it. So here it is, and here is the answer.

Does compliance with a security control framework correlate with not being breached? No credible public evidence establishes it, in either direction. That is the finding, and it is more interesting than either of the answers people usually give.

Both of the usual answers are unsupported. “Compliance doesn’t equal security” is a slogan that everyone repeats and nobody has demonstrated. “Certified organisations are more secure” is a marketing claim with no study behind it. What actually exists is a small, careful evidence base that mostly measures something else, plus one dataset that is genuinely illuminating and almost never quoted properly.

What the compliance data actually shows

Verizon has published a Payment Security Report for a decade, built on its own global PCI DSS assessment dataset. Its 2024 edition reviews the whole lifetime of PCI DSS version 3.x, and it defines its headline metric like this:

The share of organizations achieving 100% PCI DSS compliance at interim validation is considered full compliance. This is a reasonable indicator of how well organizations within the dataset managed to sustain compliance by rapidly detecting and correcting controls that fell out of place and then demonstrating 100% compliance when tested prior to their formal annual validation. Nearly all organizations studied had passed a previous validation assessment.

Read the last sentence twice. These are not organisations that failed an audit. These are organisations that had already passed one. The interim validation is a look inside the year, before the formal annual assessment they are preparing for. So the metric answers a question no annual audit ever asks: on a day that is not audit day, are the controls still in place?

Across the ten-year series, the answer trends downwards, and hard. Verizon’s own characterisation:

The percentage of organizations maintaining full compliance has steadily declined since 2020.

and

Significantly fewer organizations achieved 100% compliance in 2023 compared to previous years.

The series runs from a high of 55.4% to a low of 14.3%. Here is the whole thing:

Year	Full compliance
2015	48.4%
2016	55.4%
2017	52.2%
2018	36.7%
2019	27.9%
2020	43.4%
2021	38.9%
2022	32.4%
2023	14.3%

(These per-year values are the data labels on Verizon’s “Full compliance trends” chart, recovered from the report’s text layer and aligned to the axis labels; the alignment agrees with Verizon’s own prose about the decline since 2020 and about 2023. The range and the trend are what the argument rests on — do not build anything on a single year.)

Verizon is careful about causes and so should we be: it attributes part of the fall to a reduced assessment-report population in 2021 and 2022 during the pandemic, and part of the 2023 collapse to the workload of migrating from version 3.2.1 to version 4.0. Those are real confounders and they matter. What survives them is the structural finding, which Verizon states in a different section:

During the lifetime of PCI DSS v3.2.1, fewer than half of organizations demonstrated that they developed and maintained a robust, sustainable PCI security program that enabled them to rapidly detect and correct controls that are not in place.

And the diagnosis, in Verizon’s own phrase: many organisations took a “fire and forget” approach to control implementation.

This is the single best piece of evidence in the whole of section 3.3, and here is what it actually proves. It does not prove that compliance fails to prevent breaches; it says nothing about breaches at all. What it proves is that compliance is a photograph, not a state. The overwhelming majority of organisations that can pass a scheduled assessment cannot pass an unscheduled one. Whatever value the certificate has, it is not evidence about the condition of the estate on a randomly chosen Tuesday.

The finding almost nobody quotes

In the same report, in a small commentary box, Verizon says something that cuts directly against the compliance-theatre position — and then, in the next paragraph, cuts against itself:

The results of the comparison remain consistent year after year. To date, we are not aware of any disclosed public records of any organization experiencing a confirmed payment card data breach that validated its PCI DSS compliance and was found to be in full compliance with the requirements at the time of the breach.

That is a decade-long observation from the firm with the largest PCI assessment dataset in the world: no publicly documented case of an organisation that was actually in full compliance at the moment it was breached. Every breached organisation they can see had either never validated, or had validated and then let controls lapse. Target fits that pattern exactly — assessed in September, breached in November and December, and the assessment covered a scope the attack routed around.

And then Verizon disarms its own finding, in the very next paragraph, with the honesty that makes the whole box quotable:

That said, many organizations that did not suffer payment card data breaches usually also implemented security measures that go beyond the PCI DSS baseline set of requirements. They understand the limitations of the PCI DSS and the need to complement and supplement it by implementing and adhering to additional industry governance, risk management and other compliance standards and frameworks.

In other words: the organisations that sustain full compliance are also the organisations doing considerably more than the standard requires, so you cannot attribute their outcome to the standard. This is a confounder the size of a house, and Verizon prints it rather than hiding it. The correlation may be real; the causal arrow is unrecoverable from this data.

That is the honest state of the evidence, and it is worth more to a professional than either slogan.

What the academic literature measures, and why it does not answer the question

There is a research literature on security certification. It is smaller than you would expect and it mostly measures the wrong outcome.

The most-cited early study — Hsu, Wang and Lu, “The Impact of ISO 27001 Certification on Firm Performance,” presented at the 49th Hawaii International Conference on System Sciences — took certified firms in the United States and selected European countries and looked for a payoff. From the abstract:

Different from our expectation, we found no evidence that ISO 27001 certification brought benefits to the certified firm in terms of return-on-assets and stock market performance. We attributed the results to the nature of ISO 27001 that a good information security management would be seen as an obligation, instead of a competitive advantage.

Note the outcome variables: return on assets and stock market performance. Not breach rate. Not incident count. Not dwell time. The study is a good study and it does not address the question in this section’s title, because measuring breach outcomes across firms is extraordinarily hard — breaches are rare, disclosure is inconsistent, and the firms most likely to certify are systematically different from the firms least likely to.

Their conclusion also contains the sentence I flagged in Part III, and it deserves to be read twice by anyone who buys assurance from certificates:

In addition, the scope of the certification is also a concern, since most of our sample firms only have a partial coverage of certification, instead of having certified at the organizational level.

The researchers went looking for an effect, found none, and offered partial scope as one of two explanations. The scope problem is not a lawyer’s technicality. It is large enough to plausibly wash out a measurable effect across an entire sample of firms.

Later work in the same area finds performance effects that are contingent on sector and internationalisation — which is to say, the literature disagrees with itself about a question that is not the one we are asking. And survey work on why organisations certify puts the motives in a revealing order: compliance first, then business value, then competitive edge, with breach reduction ranked last. Firms are not certifying to reduce breaches. They are certifying because someone made them, and then hoping.

Sourcing note. I read the Hsu, Wang and Lu paper at source. The later performance literature and the motivation-ranking survey I did not open at source; they are consistent across multiple secondary summaries and none is contested, but treat them as directional rather than precise, and do not quote a number from them.

So what should you conclude?

Three things, and they fit together.

Nobody has shown that framework compliance reduces breach likelihood. Not for ISO 27001, not for PCI DSS, not for any framework in Table 3-11. If someone tells you otherwise, ask for the study.
Nobody has shown that it doesn’t, either. The compliance-theatre position is a rhetorical stance, not an empirical result. The one dataset that speaks to it — Verizon’s — points weakly the other way, and then honestly explains why you cannot lean on that.
What has been shown is that compliance decays, and that the decay is the thing to manage. Fewer than half of assessed organisations sustain their controls between audits. That is measured, repeatedly, over a decade, by the firm doing the assessments. It is the finding to act on, and it converts the whole framework question from “which one?” into “how do we know these are still in place today?”

Part V — “Merged, rationalized, and then tested once,” and when that is safe

We come back to the book’s most dangerous sentence.

It doesn’t make sense to test a very similar control multiple times. As such, controls are merged, rationalized, and then tested once. This is the approach most organizations take.

The first clause is right. The second is right in practice. The third is right as a description of the industry. And the whole passage is missing the qualifier that decides whether the practice is sound or reckless, which is: it depends entirely on the relationship between the two controls you merged, and there are five possible relationships, and only two of them make “test once” safe.

NIST’s own warning label

Start with the mildest possible authority. NIST publishes crosswalks from SP 800-53 to other frameworks — including one to ISO/IEC 27001:2022 — and puts this caution on the publication page, next to the download links:

Mappings and crosswalks provide a general indication of SP 800-53 control coverage with respect to other frameworks and standards. When leveraging these relationships, consider the scope and intended use of each publication. Do not assume equivalency based solely on relationship tables; mappings and crosswalks are not always one-to-one and relationship analysis can be subjective.

Do not assume equivalency based solely on relationship tables. That is the organisation that publishes the tables telling you not to do the thing the book describes as what most organisations do.

The five relationship types

NIST Internal Report 8477, Mapping Relationships Between Documentary Standards, Regulations, Frameworks, and Guidelines, is the methodology behind that caution. It is short, it is free, and it is the most useful document nobody in this field has read.

It defines several mapping styles. The one that matters for control rationalisation is set theory relationship mapping, which types every pair of concepts into exactly one of five relationships:

Subset of: Concept A is a subset of concept B. In other words, concept B contains everything that concept A does and more.

Intersects with: Concept A and concept B have some overlap, but each includes content that the other does not.

Equal: Concept A and concept B are the same, although not necessarily identical.

Superset of: Concept A is a superset of concept B. In other words, concept A contains everything that concept B does and more.

No relationship: Concept A and concept B are unrelated; their content does not overlap.

Now apply “merge, rationalize, test once” to each of them, from the position of the control you are about to stop testing.

Relationship	Can you test once?	What happens if you do
Equal	Yes.	The two controls are the same requirement stated twice. Testing once is simply not doing the work twice.
Superset of (your merged control contains the other)	Yes.	Your test covers everything the narrower requirement asks for, and more. Evidence satisfies both.
Subset of (your merged control is contained by the other)	No.	Your test covers part of the broader requirement. The remainder is untested and unevidenced, and you will discover this in front of an auditor.
Intersects with	No, and this is the dangerous one.	Each control contains something the other does not. Testing either one leaves a real gap, and the gap is invisible because the mapping table showed a match.
No relationship	Not applicable.	These should never have been merged.

Two of five. That is the honest expansion of the book’s sentence.

And “intersects with” is not a rare edge case. It is the normal outcome when two frameworks written by different bodies for different purposes describe similar-sounding controls. NIST says so implicitly in a passage about converting between mapping styles:

However, set theory intersects with relationships cannot be automatically converted because they only indicate overlap between the concepts, not the nature of that overlap.

Even NIST’s own tooling cannot mechanically do anything useful with an “intersects with,” because the relationship type records that the two overlap without recording how. If NIST cannot automate around it, neither can your GRC platform, and neither can a spreadsheet a consultant handed you.

The subtlety that will catch you out

IR 8477 has one more idea that changes how you should read every crosswalk you are ever given. The relationship type on its own is meaningless; it must be paired with the rationale on which the mapping was made, of which there are three — syntactic (word-for-word), semantic (meaning), and functional (what happens if you actually do it).

NIST’s worked example uses two near-identical control statements from the Cybersecurity Framework and the Privacy Framework, differing only in “users” versus “individuals” and the word order at the end:

With a rationale of syntactic, the relationship type would be intersects with because the two overlap, but each includes content that the other does not. However, with a rationale of semantic, the relationship type would be equal if “users” and “individuals” have the same meaning in their respective sources, subset if “users” was a subset of “individuals,” and so on.

The same pair of controls is “intersects with” or “equal” or “subset of” depending on which question the mapper was asking. So when someone hands you a crosswalk, the first question is not “does control X map to control Y.” It is “mapped on what rationale, and by whom?” A syntactic mapping is a word-matching exercise and will systematically under-claim equivalence. A functional mapping requires somebody to have thought about what happens when both controls are actually operated, which is expensive and rare, and is the only kind you should let anyone stop testing on.

NIST is also candid about the bottom of the range: a bare concept crosswalk — two columns of control IDs with no relationship types at all, which is what most vendor mapping spreadsheets are — is described as “the most basic relationship style because they provide the least information.” That is what you are usually being sold.

The artefacts, so this is not just a warning

The point of all this is not to talk you out of rationalising controls. Rationalising controls is correct and the book is right that everyone does it. The point is that free, maintained, methodologically-typed mappings now exist, and building your own crosswalk in Excel in 2026 is a choice.

NIST OLIR — the National Online Informative References Program. NIST’s catalogue of accepted mappings between other people’s documents and NIST publications, hosted with the Cybersecurity and Privacy Reference Tool. The distinction that matters is between a mapping NIST has accepted into OLIR and a mapping a vendor drew: the first has been through a process and carries the relationship types and rationales that IR 8477 specifies. It is also alive — the programme was posting new final mappings within days of this article being written, including an SP 800-53 to NERC CIP mapping.

The Secure Controls Framework. A free common controls framework — the site’s own summary is that it “maps 1,500+ controls across 200+ laws, regulations, and industry frameworks so you can implement once and comply everywhere,” across 34 domains, published under Creative Commons with no registration. It names NIST IR 8477’s methodology explicitly as the basis of its mapping relationships, which is exactly the property you want and exactly the property a vendor spreadsheet lacks. This is the concrete answer to the book’s hand-wave: somebody already did the merging, typed the relationships, and gave it away.

The direct crosswalks. For the specific pairs in Table 3-11, several exist for free from the source bodies themselves — NIST publishes the SP 800-53 to ISO/IEC 27001:2022 crosswalk from the publication’s own page, and the Center for Internet Security publishes mappings from the CIS Controls to several of the frameworks here. Where a crosswalk exists from one of the two bodies whose documents it maps, prefer it.

What “test once” should actually mean

Put the pieces together and the working rule falls out:

Type the relationship before you merge. Equal or superset: merge and test once. Subset: merge and test the remainder separately. Intersects with: do not merge; note the overlap so you can reuse evidence, and keep both tests.
Reuse evidence, not conclusions. A single access-review artefact can satisfy four frameworks. A single test result cannot satisfy four control objectives unless the relationships allow it. Evidence reuse is where nearly all of the real saving lives, and it carries none of the risk.
Record the rationale. When the auditor asks why you tested once, “they were equivalent” is not an answer. “Functional equivalence, mapped against OLIR reference X, reviewed on this date” is.

That is the sentence the book owed the reader, and it is the most useful thing in section 3.3.

The two objections, answered

An article like this earns nothing if a reader holding an informed objection finds it unaddressed. There are two, and they are both partly right.

“Frameworks are compliance theatre”

The strongest form of this argument is not a slogan, it is a stack of evidence, and this article has supplied most of it. Full compliance at unannounced validation bottoming out near one organisation in seven. Target assessed compliant weeks before losing forty million card numbers. OPM producing FISMA paperwork for years while its own Inspector General’s recommendations went unheeded. Verizon’s own diagnosis of “fire and forget” implementation. If you wanted to build the case that control frameworks are a ritual performed for auditors, you would build it out of exactly these materials.

Here is where it is weak, and the weakness is specific rather than general.

The charge lands on point-in-time attestation, not on control frameworks. Every piece of evidence above is evidence about a particular assurance model: assess annually, certify, go away, come back in a year. That model does produce theatre, and it produces it structurally, because the incentive is to be compliant on assessment day rather than on a random Tuesday, and “fire and forget” is a rational response to it.

But not everything in Table 3-11 works that way. FedRAMP’s obligation is continuous monitoring, and its enforcement ladder — remediation status, notice, revocation, removal from the Marketplace — is triggered by procedural failures month by month rather than by an annual verdict. An ISO 27001 certificate is maintained through a surveillance cycle rather than issued once. PCI DSS version 4 moved deliberately in the same direction; Verizon’s own framing is that it “advanced closer to post-implementation monitoring and evaluation” precisely because the previous version did not require organisations to evaluate whether their controls actually worked after installation.

So the honest version of the objection is: point-in-time compliance is theatre, and the industry knows it, and the regimes are visibly migrating away from it. That is a much more useful sentence than “frameworks are theatre,” because it tells you what to do — which is to buy assurance from continuous evidence and treat the annual certificate as the receipt rather than the assurance.

And there is a second weakness in the objection, which is that it proves too much. Anthem’s four cited failures were not theatre problems. No enterprise-wide risk analysis, no regular review of system activity, no incident identification and response, no minimum access controls — those are the absence of a programme, not the failure of one. A framework that had been performed as theatre would at least have produced the risk analysis document. The failure there was upstream of compliance entirely.

“The mapping overhead exceeds the benefit”

This one is real, and I want to be careful with it because the temptation is to answer it with a cost-benefit number.

There is no such number. I looked for a credible published figure for the cost of control rationalisation — consultancy days, platform licence, internal effort, anything — and found none that was not marketing. So nobody, including me, can tell you what the crossover point is.

What can be said is structural, and it is enough to work with.

First, the overhead is real and it is exactly why the free crosswalks exist. The Secure Controls Framework is not a charity project that happened; it is a response to thousands of organisations independently rebuilding the same mapping. When a piece of work is duplicated that widely, someone eventually publishes it. That work is now done and given away, which removes most of the mapping cost from the equation.

Second, removing the mapping cost does not remove the rationalisation cost, and people conflate them. Downloading a crosswalk is free. Deciding that your control 4.2.1 genuinely satisfies both requirements it maps to, evidencing that decision, and defending it to two different assessors is not free, and it does not crosswalk away. That is the residual cost, and it is where the money actually goes.

Third — and this is the reply that decides it — the alternative is not “no overhead.” The alternative is testing the same control four times. A hospital under HIPAA and PCI DSS, a SaaS vendor under SOC 2 and ISO 27001 and a FedRAMP baseline, a public company under SOX with a security programme underneath it: none of these organisations gets to opt out of the second framework. The choice is between paying the rationalisation cost once and paying the duplicate-testing cost every year. The book is right that most organisations choose the first. The correction this article adds is that you must type the relationships before you merge, or you will have paid the rationalisation cost and created gaps.

Where the objection is strongest is at small scale. If you are subject to exactly one regime, mapping to a second one you are not subject to is pure overhead and you should not do it. Frameworks are not free to hold; the correct number of frameworks is the number that somebody is going to make you demonstrate.

What to actually take from 3.3

Strip out every correction and this section still reduces to four ideas, none of which is a list of eleven names.

A framework is a source of candidate controls, not a control selection. The book says this and then the industry ignores it. Decomposition, valuation and risk analysis come first; the framework is consulted afterwards, to answer “what have people found useful for protecting a thing like this?” Anthem’s $16 million turned on the absence of the first step, not on a missing product. If you open a framework before you know what you are protecting and what it is worth, you are shopping.

Know which of the six things you are dealing with, every time. Law, contractual standard, certifiable standard, authorisation programme, control catalogue, governance framework. The category determines who obliges you, what evidence you must produce, what failure costs, and whether you can walk away. Six answers, and the book’s single heading gives you one.

Every regime except the statutes tests inside a boundary you drew. The cardholder data environment. The ISO 27001 scope statement and its Statement of Applicability. The FedRAMP authorization boundary. This is the fact that unites Target’s 10-K, the academic finding that most certified firms hold only partial coverage, and the guidance that you must “justify why you exclude other controls.” Whenever anyone shows you a certificate, the useful question is about the boundary, not the certificate. Statutes are the exception, and that is exactly why they are a different category: Congress draws the boundary, draws it around you, and does not consult you on the scope.

Compliance decays, and the decay is measurable. Fewer than half of assessed organisations sustain full compliance between audits, and in the worst measured year it was closer to one in seven — among organisations that had already passed a formal assessment. Nobody has demonstrated that compliance prevents breaches. What has been demonstrated, over a decade and by the people running the assessments, is that controls fall out of place between the photographs. Design your programme around that finding rather than around the certificate, and you will be doing something almost nobody does.

There is one more thing, and it is where this started. In the fall of 2013, an independent assessor looked at the portion of Target’s network that handled payment card information and found it compliant with the applicable standards. That statement was true when it was made, it was made by a competent party, and it was worth precisely what it said and nothing more.

The attackers did not need to break it. They needed only to find the part it was not about.

Key Takeaways

The ISC2 objective is nine words — “3.3 Select controls based upon systems security requirements” — with no examples and no sub-objectives. Everything in the CISSP book 3.3.1 is the book’s own pedagogy over that line. Domain 3 carries an average weight of 13%.
The book’s ISO 27001 Annex A list is the superseded structure. It prints fourteen domains — the 2013 layout, 114 controls — under the 2022 version number. Current Annex A is four themes, 93 controls: Organisational 37 (clause 5), People 8 (clause 6), Physical 14 (clause 7), Technological 34 (clause 8), including 11 new controls (threat intelligence; information security for use of cloud services; ICT readiness for business continuity; physical security monitoring; configuration management; information deletion; data masking; data leakage prevention; monitoring activities; web filtering; secure coding). ISO’s own text is paywalled and was not opened for this article; the structure is confirmed by convergence across six independent sources, and NIST’s own SP 800-53 Rev. 5 page carries a “Crosswalk: 800-53 Rev. 5 to ISO/IEC 27001:2022 (OLIR)”.
ISACA is an Association, not “Assurance” — and it retired the expansion. From its own history page: “Previously known as the Information Systems Audit and Control Association®, ISACA now goes only by its acronym to reflect the broad range of IT governance professionals we serve.” It incorporated in 1969 as the EDP Auditors Association. Current framework: COBIT 2019.
The operative FISMA is the Modernization Act of 2014, Public Law 113-283, which amended chapter 35 of title 44 “by striking subchapters II and III” and inserting a new subchapter at 44 U.S.C. §§ 3551–3558. Same acronym, different middle word.
FedRAMP does not reach “any cloud service holding federal data.” Its own words: FedRAMP covers “cloud computing products and services that process unclassified information used by agencies.” Single-agency systems not offered as a shared service, social media platforms, search engines, commercially-available information providers and negligible-risk ancillary services are named as out of scope. Scope attaches to the agency use case, not to the product, and FedRAMP “does not support or provide ‘equivalency.'”
Enron explains why SOX was drafted; WorldCom explains why it passed. The weaker House bill H.R. 3763 passed on 24 April 2002 (334–90). The SEC charged WorldCom “with a massive accounting fraud totaling more than $3.8 billion” on 26 June 2002. Nineteen days later the Senate passed S. 2673 by 97–0; the conference report was agreed 99–0 on 25 July 2002.
There is no such thing as being “compliant with SP 800-53.” Its own abstract calls it “a catalog of security and privacy controls”; it has twenty control families and no jurisdiction, no assessors and no penalties. FISMA reaches you through the Risk Management Framework and FedRAMP through its baselines — the thing that reaches you invokes the catalogue.
You cannot adopt a law. There is no HIPAA certificate, no SOX certificate, no FISMA certificate, and any vendor selling one invented it. Compliance with a statute is a legal state assessed after the fact by a regulator, usually because something already went wrong.
HIPAA’s Security Rule governs ePHI, not PHI. The book says PHI; OCR’s Anthem release says ePHI throughout. Privacy Rule: PHI in any form. Security Rule: electronic. A proposed rewrite exists at 90 FR 898 — proposed, not final, with no final rule found.
Anthem’s $16 million was for four process failures, not for the breach. OCR: Anthem “failed to conduct an enterprise-wide risk analysis, had insufficient procedures to regularly review information system activity, failed to identify and respond to suspected or known security incidents, and failed to implement adequate minimum access controls” — dating back “as early as February 18, 2014,” more than a year before the breach report. Entry was by spear phishing a subsidiary; almost 79 million people’s ePHI was taken.
OPM is the case of a government failing its own framework. House Oversight staff report findings, verbatim: “The OPM data breach was preventable”; leadership “failed to heed repeated recommendations from its Inspector General”; OPM “misled the public on the extent of the damage of the breach and made false statements to Congress.” A reporting regime whose findings nobody acts on produces a shelf of reports.
Target’s compliance statement is the best sentence in this section. Target’s 10-K, quoted in the Senate Commerce kill-chain report: “an independent third-party assessor found the portion of our network that handles payment card information to be compliant with applicable data security standards.” Initial access came through a contractor’s credentials against an external billing system that the report notes “is not technically related to Target’s POS system.” The assessment was accurate; the scope was the problem. Do not name the assessor — the role was publicly disputed.
Read the scope statement and ask for the Statement of Applicability. An ISO 27001 certificate attests to a management system inside a scope the organisation declared. The 93 Annex A controls are not mandatory: “You don’t have to implement all 93… You should also justify why you exclude other controls.” The exclusions and their reasons are the most information-dense document in the certification and the one nobody requests.
Compliance is a photograph, not a state. Verizon’s 2024 Payment Security Report: “The share of organizations achieving 100% PCI DSS compliance at interim validation is considered full compliance… Nearly all organizations studied had passed a previous validation assessment.” Full compliance ran from a high of 55.4% to a low of 14.3%, and “has steadily declined since 2020.” These are organisations that could pass a scheduled audit and could not pass an unscheduled one.
On whether compliance prevents breaches, print the gap. No credible public evidence establishes it in either direction. Verizon says it is “not aware of any disclosed public records of any organization experiencing a confirmed payment card data breach that validated its PCI DSS compliance and was found to be in full compliance with the requirements at the time of the breach” — and immediately notes that organisations avoiding breaches “usually also implemented security measures that go beyond the PCI DSS baseline.” Hsu, Wang and Lu found “no evidence that ISO 27001 certification brought benefits to the certified firm in terms of return-on-assets and stock market performance,” and cited partial certification scope as one explanation. The academic literature measures firm performance, not breach rates.
“Merge, rationalize, test once” is safe for two of five relationship types. NIST IR 8477 types every mapping as Subset of / Intersects with / Equal / Superset of / No relationship. Equal and Superset of permit a single test. Subset of leaves an untested remainder. Intersects with is the trap: each control contains something the other does not, and NIST notes such relationships “only indicate overlap between the concepts, not the nature of that overlap.” NIST’s own crosswalk page warns: “Do not assume equivalency based solely on relationship tables.”
The relationship type is meaningless without the rationale. Syntactic, semantic or functional. NIST’s own example shows one pair of controls typing as “intersects with,” “equal” or “subset” depending purely on which rationale the mapper used. A bare two-column crosswalk — what most vendor spreadsheets are — is, in NIST’s words, “the most basic relationship style because they provide the least information.”
Use the free artefacts. NIST OLIR for accepted, typed mappings to NIST publications; the Secure Controls Framework, free under Creative Commons, mapping “1,500+ controls across 200+ laws, regulations, and industry frameworks” across 34 domains and built on IR 8477’s methodology; NIST’s own SP 800-53 to ISO/IEC 27001:2022 crosswalk. Reuse evidence freely; reuse test conclusions only where the relationship type allows it.
The other rows, briefly. ITIL is at ITIL 4, with the certification scheme run by PeopleCert rather than the UK government. COSO publishes two different things — the Internal Control—Integrated Framework (1992, refreshed 2013), which is the SOX 404 one, and Enterprise Risk Management—Integrating with Strategy and Performance. ISO 27002 is implementation guidance for 27001’s controls and nobody certifies against it; the book is right about this. PCI DSS v4.0.1 is, per Verizon, “the only active version of the standard supported by the PCI SSC.”
And FedRAMP’s own guidance disowns the book’s heading: “It should not be treated like a traditional compliance framework.”

Sources & References

All URLs were retrieved on 10 September 2026. Every quotation above was matched against the source at the moment it was written; where a source could not be opened, that is said in the text and repeated here.

The CISSP material

The CISSP book, Certification, Domain 3, section 3.3, “Select controls based upon systems security requirements,” subsection 3.3.1, “Security Control Frameworks,” including Table 3-11 and the “Rationalizing Frameworks” passage. Every core concept, table entry and sentence attributed to “the book” is from this section.
ISC2, CISSP Certification Exam Outline, effective 15 April 2024. Objective 3.3 quoted in full — the outline gives it no examples and no sub-objectives. Domain 3 average weight 13%.

Standards, catalogues and their own words

NIST, SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations. Abstract quoted (“a catalog of security and privacy controls…”). The twenty control families are counted from the publication page’s own Control Families list. The mappings caution (“Do not assume equivalency based solely on relationship tables…”) and the supplemental item labelled “Crosswalk: 800-53 Rev. 5 to ISO/IEC 27001:2022 (OLIR)” are both on this page.
NIST, IR 8477, Mapping Relationships Between Documentary Standards, Regulations, Frameworks, and Guidelines: Developing Cybersecurity and Privacy Concept Mappings, February 2024; full PDF. Section 4 read in full. The five set-theory relationship types are quoted verbatim from the numbered list; note the type is “Equal,” not “Equal to,” and NIST defines it as “the same, although not necessarily identical.” The syntactic/semantic/functional rationales, the PR.AC-1 worked example, the “intersects with relationships cannot be automatically converted” passage and the description of concept crosswalks as “the most basic relationship style because they provide the least information” are all from the same document.
NIST, National Online Informative References (OLIR) Program. The programme description and the Latest Updates list, which was carrying new final mappings dated within days of this article.
Secure Controls Framework. The “1,500+ controls across 200+ laws, regulations, and industry frameworks” claim, the 34 domains, the free Creative Commons licensing and the NIST IR 8477 / STRM basis are the framework’s own published description of itself, and are not independently audited here.
GRC Solutions (formerly IT Governance), “Your Guide to ISO/IEC 27001:2022”. Source of the 93 controls, the four themes with per-theme counts and clause numbers, and the “You don’t have to implement all 93… justify why you exclude other controls” passage. ISO’s own text is paywalled and iso.org defeats automated retrieval; ISO/IEC 27001:2022 itself was not opened for this article. The structure is graded confirmed by convergence: this source plus five further independent publishers (Drata, Sprinto, Scrut, GAICC, Mindset Cyber) that agree on the counts, the clause numbering and the eleven new controls, with no dissenting source found.
ISACA, History — the EDP Auditors Association incorporation and the “now goes only by its acronym” passage, quoted verbatim. ISACA, COBIT — COBIT 2019 as the current framework.
COSO, Internal Control — the Internal Control—Integrated Framework “originally issued in 1992 and refreshed in 2013,” and its separation from the Enterprise Risk Management product.

Law and legislative record

Public Law 113-283, the Federal Information Security Modernization Act of 2014, govinfo. Section 2’s amendment of chapter 35 of title 44 “by striking subchapters II and III,” and the inserted subchapter II at 44 U.S.C. §§ 3551–3558.
US House of Representatives, Office of the Clerk, roll call vote 110 of 2002 — H.R. 3763, “Corporate and Auditing Accountability and Responsibility Act,” on passage, 24 April 2002, 334 ayes to 90 noes.
SEC, Litigation Release No. 17588, 27 June 2002 — the complaint filed the previous day charging WorldCom “with a massive accounting fraud totaling more than $3.8 billion.” (sec.gov rate-limits automated retrieval; this page was read through a fetching proxy rather than by direct download.)
US Senate, roll call vote 176 of the 107th Congress, 2nd session — S. 2673 on passage, 15 July 2002, 97–0; and roll call vote 192 — conference report on H.R. 3763 (Sarbanes-Oxley Act of 2002), 25 July 2002, 99–0.
HHS, “HIPAA Security Rule To Strengthen the Cybersecurity of Electronic Protected Health Information”, 90 FR 898, RIN 0945-AA22 — a Proposed Rule, 125 pages, comment period closed 7 March 2025. The two section headings quoted are from the document’s own table of contents. No final rule was found.

Enforcement findings and official investigations

HHS Office for Civil Rights, “Anthem Pays OCR $16 Million in Record HIPAA Settlement Following Largest U.S. Health Data Breach in History”, 15 October 2018. Read in full via the Internet Archive’s capture of the HHS page; hhs.gov itself defeats automated retrieval, and the archive rate-limits repeated automated requests, so a link-checker may report this URL as blocked when a browser opens it normally. Source of the $16 million figure, the “eclipses the previous high of $5.55 million paid to OCR in 2016” comparison, the spear-phishing entry, the almost 79 million individuals, and the four cited failures with their “beginning as early as February 18, 2014” clause.
US House Committee on Oversight and Government Reform, The OPM Data Breach: How the Government Jeopardized Our National Security for More than a Generation. The four Key Findings are quoted verbatim from the committee’s own report page. The underlying report was not read end to end and nothing here goes beyond those findings.
US Senate Committee on Commerce, Science, and Transportation, majority staff, A “Kill Chain” Analysis of the 2013 Target Data Breach, 26 March 2014. Source of the Target 10-K quotation about “the portion of our network that handles payment card information,” the CFO’s testimony about layers of protection and the September 2013 certification, and the note that the Ariba system “is not technically related to Target’s POS system.”
Congressional Research Service, N. Eric Weiss and Rena S. Miller, The Target Data Breach: Frequently Asked Questions, R43496, 22 April 2014. “Target has testified that its systems were reviewed in September 2013 and certified as compliant,” and the 40 million / 70 million disclosure dates.

FedRAMP

FedRAMP, Scope of FedRAMP, Consolidated Rules for 2026. The statutory-scope sentence, the six out-of-scope categories quoted in full, and the “Only a federal agency can determine if their use case…” passage. The out-of-scope list is FedRAMP’s quotation of OMB Memorandum M-24-15; the memorandum itself was not opened directly.
FedRAMP, Cloud Service Providers, Consolidated Rules for 2026. The “It should not be treated like a traditional compliance framework” passage and the statement that FedRAMP “does not support or provide ‘equivalency.'”
FedRAMP, RFC-0026, Clarifying CA-7 Continuous Monitoring Expectations for Rev5 Providers. Source of the escalation mechanism and of the “removed from the FedRAMP Marketplace for a period of at least 6 months” consequence. This is a Request for Comment inside a new and moving ruleset; the enforcement calendar and the specific failure counts are deliberately not printed above, and will age.

Compliance data and evidence

Verizon, 2024 Payment Security Report. PDF downloaded and read. Source of the full-compliance definition (p.44), the “Nearly all organizations studied had passed a previous validation assessment” sentence, the “steadily declined since 2020” and “Significantly fewer organizations achieved 100% compliance in 2023” characterisations, the “fewer than half of organizations” sustainability finding, the “fire and forget” phrase, the “only active version of the standard supported by the PCI SSC” statement about v4.0.1, and the “Data breach vs. compliance validation correlation” commentary box (p.34) with both of its paragraphs. The per-year percentages in the table above are the chart’s own data labels, recovered from the PDF’s text layer and aligned against the axis labels; the reconstruction agrees with Verizon’s prose in both directions it can be checked against. The report’s own summary sidebar words the definition slightly differently from the body (“during an interim validation assessment” rather than “at interim validation”); the body wording is the one quoted.
Carol Hsu, Tawei Wang and Ang Lu, “The Impact of ISO 27001 Certification on Firm Performance”, 2016 49th Hawaii International Conference on System Sciences. Abstract and conclusion read at source; the null result and the partial-coverage explanation are quoted verbatim.
The later ISO 27001 performance literature (sector- and internationalisation-contingent market effects) and the survey ranking of certification motives — compliance, business value, competitive edge, breach reduction last — were not read at source. They are consistent across multiple secondary summaries and none is contested, and no figure from either is quoted above.
The COSO adoption comparison (approximately 82% of filers with an external ICFR audit opinion against approximately 37% of management-only filers, converging the following year) comes from an audit-data vendor’s published analysis and the accounting literature built on the same dataset. Not read at the underlying data. The contrast is the finding; the two percentages are approximate.

Not used, and why

Restraint is part of the method. Nine things were available and are not in this article.

Any expansion of the COBIT acronym. ISACA does not use one — its history page says the organisation “now goes only by its acronym,” and the same logic governs the framework’s name. Worse for anyone hoping to settle it: ISACA’s own COBIT page carries two different expansions in the same document, one in the page’s metadata and a different one inside an article on the page, and the book supplies a third variant. With the publisher itself inconsistent, printing any one of them as correct would be inventing an authority that does not exist. The only safe sentence is “COBIT is ISACA’s.”
The role of Target’s security assessor. Whether the firm named in contemporaneous reporting was Target’s formal Qualified Security Assessor or a scanning and monitoring provider was publicly disputed at the time, and the litigation touching it was withdrawn almost immediately. The compliance-then-breach fact is solidly sourced to sworn testimony and to Target’s own 10-K; the assessor’s identity and role add nothing to the argument and cannot be stated with confidence. Not named.
The ISO 27001 certified-and-breached case. The circulating example rests on a single opinionated standards-industry blog with no independent corroboration. Cut entirely. The Statement of Applicability and scope point is stronger, is sourced, and needs no anecdote — and it gains a second, independent corroboration from the academic finding about partial certification coverage.
Any projected date for the final HIPAA Security Rule. The proposal exists at 90 FR 898 and the comment period has closed. Everything beyond “proposed, not final” is speculation about a rulemaking timetable, and a reader who plans against a guessed date will plan wrong.
FedRAMP’s enforcement calendar and failure counts. The escalation ladder is real and is described above as a mechanism. The specific number of failures that triggers each stage, the grace period and the enforcement start date sit inside a Request for Comment in a ruleset published this year. Printing them would date the article within months and, worse, would be quoted back by someone as current.
Any cost figure for control rationalisation. I looked for a credible published number — consultancy days, licence cost, internal effort — and found none that was not vendor marketing. The counter-argument about mapping overhead is answered structurally above rather than numerically, because a fabricated crossover point would be worse than no answer.
A named FedRAMP revocation. No documented, named case surfaced. That is a search result and not a proof of absence; it is stated as a search in the text. The removal mechanism carries the point instead, and carries it better.
Verizon’s per-year full-compliance figures, as an argument. They are printed, with the method of their recovery stated, because a reader is entitled to see the shape of the series. But nothing in the argument rests on a single year — the case is built on the range, the trend, and Verizon’s own definition of what the metric measures. Picking the year that flatters a thesis is precisely the behaviour this article convicts other people of.
Numbers from the multi-source-but-unopened rows. The FedRAMP statutory language beyond what FedRAMP’s own site quotes; the COSO adoption percentages; the later ISO 27001 performance literature and the survey of certification motives. Each is flagged in place and in the sources block, none carries a quoted figure it cannot support, and the OPM material is confined to the four findings the committee itself publishes.

One thing that is in the article and would normally be cut: the ISO 27001 Annex A structure, where the primary source is paywalled. It stays because it is the correction the reader most needs, because six independent sources agree without a dissenter, and because NIST’s own crosswalk confirms the edition. The provenance is printed in full so you can weigh it yourself. That is the deal.

Nothing Came to Us: The Security Models That Are Still Running Under Everything You Use

The Security Models That Are Still Running Under Everything You UseCISSP Domain 3.2 In 1973, at the MITRE Corporation in Bedford, Massachusetts, David Elliott Bell…

76.2% match September 9, 2026

Example Only: The Most-Cited Number in Secure Design Was Never a Finding

The 30x comes from a table titled Example Only. The 100x IBM study is course notes. Why designing security in early is still right, and…

73.9% match September 18, 2026

You Cannot Adopt a Law: CISSP 3.3, and the Eleven “Frameworks” That Are Six Different Kinds of Thing

What the exam actually asks, which is nine words

What the book says, fairly

Part I — The category error, and why it costs money

The sharpest one: SP 800-53 is a catalogue, not a regime

The second sharpest: you cannot adopt a law

Where that distinction is worth $16 million

Part II — Five corrections, and one is the headline

Correction 1: the ISO 27001 Annex A structure in the book is the previous one

Correction 2: ISACA is an Association, and it does not use the name any more

Correction 3: FISMA’s operative text is the 2014 Act

Correction 4: FedRAMP’s scope is much narrower than “any cloud service”

Correction 5: Enron explains why SOX was drafted; WorldCom explains why it passed

Part III — One real case per category

Contractual standard: Target, and the boundary you drew yourself

Certifiable standard: ISO 27001, and why I am not giving you an anecdote

Law, federal edition: OPM, or a government failing its own framework

Control catalogue: the case that cannot exist

Government authorisation programme: FedRAMP, and a NOT FOUND

Governance framework: COSO, and the framework that spread where an auditor was watching

The two remaining rows

Part IV — The honest question: does any of this stop breaches?

What the compliance data actually shows

The finding almost nobody quotes

What the academic literature measures, and why it does not answer the question

So what should you conclude?

Part V — “Merged, rationalized, and then tested once,” and when that is safe

NIST’s own warning label

The five relationship types

The subtlety that will catch you out

The artefacts, so this is not just a warning

What “test once” should actually mean

The two objections, answered

“Frameworks are compliance theatre”

“The mapping overhead exceeds the benefit”

What to actually take from 3.3

Key Takeaways

Sources & References

Not used, and why

Related Posts

Nothing Came to Us: The Security Models That Are Still Running Under Everything You Use

Example Only: The Most-Cited Number in Secure Design Was Never a Finding

Example Only: The Most-Cited Number in Secure Design Was Never a Finding

Read Next

California AB 1008: Implications for Data Privacy in the Age of AI

The Role of Artificial Intelligence in Cybersecurity (Adversarial Attacks and Regulatory Frameworks in Healthcare)

When Cyber Threats Hit All 50 States at Once, Who’s Really in Charge?

Subscribe to our Newsletter