Frameworks demystified

CIS, SOC 2, PCI, NIST, ISO as checkable controls.

An auditor sits down across the table and asks one short question: "Show me control IA-2, prove it operates, and tell me which of your four frameworks it satisfies." If your answer is a 300-page PDF and a shrug, you are in for a long month. If your answer is a versioned check that runs on every deploy, plus a table saying which framework identifiers that check covers, the meeting is over in ten minutes. Compliance as code starts by taking the mystery out of the word "framework". A framework is a filing system for requirements, nothing more exotic than that. This lesson walks the five frameworks you will actually meet, then pulls a real control out of a machine-readable source file so the rest of the course has something concrete to turn into running policy.

Every framework is really three nouns

A building code works the same way. One rule says every bedroom needs a smoke alarm. The code book holds thousands of rules like it. The inspector only holds you to the ones that apply to a two-storey timber house. Security frameworks have those same three layers under different names. A control is one requirement that lowers risk, like "enforce MFA (multi-factor authentication, a second proof of identity on top of the password) for admin access" or "encrypt data at rest". A catalog is the framework's full list of controls, each carrying a stable identifier that does not change between revisions: NIST (the US National Institute of Standards and Technology) files the identity requirement under IA-2, and SOC 2 (System and Organization Controls, the trust report software buyers ask for) calls the same idea CC6.1. A baseline, which some tools call a profile, is the slice of the catalog that actually applies to you, chosen by risk level or by the kind of data you hold. Frameworks disagree about who they protect and who demands them. Underneath, they are all lists of controls you can write as executable checks, and a control you can check is a control you can automate and evidence.

SOC 2: Type I is a photo, Type II is a film

SOC 2 comes from the AICPA (the American Institute of Certified Public Accountants) and it is the default trust report a software vendor hands an enterprise buyer. It is built on the Trust Services Criteria. Security is mandatory and arrives as the Common Criteria, CC1–CC9. On top of that you add Availability, Processing Integrity, Confidentiality, and Privacy, depending on what you promised customers in writing. The part that trips teams up is Type I versus Type II. A Type I report says your controls were suitably designed on one particular day. That is a photograph. A Type II report says those same controls operated effectively across a period, typically 3 to 12 months, with the auditor pulling evidence samples from all over that window. That is a film. Enterprises almost always insist on Type II, because a control that was designed beautifully and then quietly broke in month four is worth nothing to them. This is the reason continuous, automated evidence exists. A Type II audit asks for a year of proof that a check kept running, and you cannot assemble that the week before the auditor arrives.

PCI-DSS: merchant levels and the cardholder data environment

A hospital quarantine ward is a useful comparison. Everything inside gets the full protocol, so the hospital keeps the ward as small as it possibly can. PCI-DSS (Payment Card Industry Data Security Standard) works on the same instinct. It applies wherever cardholder data is stored, processed, or transmitted, and its scope is the CDE (cardholder data environment), meaning the systems that touch card data plus anything connected to them. The current standard is v4.0.1, and the full v4.0 requirements have been mandatory since 31 March 2025. How much you have to prove depends on your merchant level, which is set by how many card transactions you handle in a year. Level 1, roughly over 6 million transactions a year, means an on-site Report on Compliance signed by a QSA (Qualified Security Assessor, an auditor accredited by the card brands) plus quarterly ASV (Approved Scanning Vendor) scans. Levels 2 through 4, down to under 20,000 e-commerce transactions, can usually self-attest with a Self-Assessment Questionnaire. The engineering lever here is scoping. Segment the CDE hard so fewer systems fall inside the boundary, because every system inside it has to meet all 12 requirement groups.

ISO 27001 and NIST 800-53: the two big catalogs

ISO/IEC 27001:2022 (a joint standard from the International Organization for Standardization and the International Electrotechnical Commission) certifies a management system rather than a product. The certificate says you run security the way a good factory runs quality control: written process, records, reviews, corrective action. Clauses 4 to 10 are that management system, called an ISMS (information security management system). Annex A sits alongside it and supplies the reference controls. The 2022 revision reshaped Annex A into 93 controls across four themes: Organizational (37), People (8), Physical (14), and Technological (34), replacing the older layout of 114 controls in 14 domains. You are not required to implement all 93. You write a Statement of Applicability declaring which controls apply, which do not, and why, and that reasoning has to come out of a risk assessment. That is the ISO bargain. Justify your control set against real risk, then prove the management system keeps it alive year after year.

NIST SP 800-53 Rev 5 (Special Publication 800-53, revision 5) is the deepest catalog of the five: 20 control families (AC, AU, IA, SC, SI, SR and the rest) holding 1,196 controls and enhancements between them. It is also the spine that other frameworks bolt onto, including FedRAMP (the Federal Risk and Authorization Management Program), which tailors 800-53 into Low, Moderate, and High baselines for cloud services sold to the US federal government. Because it is that complete and that precisely structured, it is the obvious target for tooling that reads controls mechanically, which is what you are about to run. CIS sits at the opposite, most concrete end of the scale. CIS Benchmarks, from the Center for Internet Security, are hardening baselines written per target (Linux, AWS, Kubernetes), and their items already read like checks you could run this afternoon. They get their own lesson later in this course.

OSCAL: controls a machine can read

Everything above starts life as prose in a PDF, and prose is where automation goes to die. OSCAL is the fix. OSCAL (Open Security Controls Assessment Language) is NIST's standard for expressing catalogs, baselines, and evidence as JSON, XML, or YAML (plain-text data formats a program can parse) instead of paragraphs. Once a framework exists in OSCAL you can diff two revisions of it, query it with ordinary command-line tools, and generate documents from it. compliance-trestle (the trestle CLI, a command-line tool from the open-source OSCAL Compass project) is the Python toolkit for that work. Install it, pull down the real NIST 800-53 catalog, and look at how a single control is actually shaped. That shape is the raw material for every mapping and every policy later in this course.

python -m pip install compliance-trestle
trestle version

Successfully installed compliance-trestle-4.2.0 ruamel.yaml-0.19.1 orjson-3.11.8
Trestle version v4.2.0 based on OSCAL version 1.2.1

trestle wants its own workspace, the way git wants its own repository. Create one, download the official Rev 5 catalog straight from NIST's oscal-content repository, then import it so trestle can query and render it. One catch will bite you the first time you try this: trestle refuses to import a file that is already sitting inside its own project directory, so save the download somewhere outside the workspace. After the import, jq (a small command-line tool for slicing JSON) can ask the catalog what it contains.

trestle init
# download OUTSIDE the trestle project dir — import rejects files inside it
curl -sL -o /tmp/nist-cat.json \
  https://raw.githubusercontent.com/usnistgov/oscal-content/main/nist.gov/SP800-53/rev5/json/NIST_SP-800-53_rev5_catalog.json
trestle import -f /tmp/nist-cat.json -o nist80053
 
# 20 control families:
jq -r '.catalog.groups[] | "\(.id|ascii_upcase)  \(.title)"' catalogs/nist80053/catalog.json
# total controls + enhancements:
jq '[.. | objects | select(.class=="SP800-53" or .class=="SP800-53-enhancement") | .id] | length' catalogs/nist80053/catalog.json

AC  Access Control
AT  Awareness and Training
AU  Audit and Accountability
CA  Assessment, Authorization, and Monitoring
CM  Configuration Management
CP  Contingency Planning
IA  Identification and Authentication
IR  Incident Response
MA  Maintenance
MP  Media Protection
PE  Physical and Environmental Protection
PL  Planning
PM  Program Management
PS  Personnel Security
PT  Personally Identifiable Information Processing and Transparency
RA  Risk Assessment
SA  System and Services Acquisition
SC  System and Communications Protection
SI  System and Information Integrity
SR  Supply Chain Risk Management
1196

The numbers come back exactly as advertised: 20 families, 1,196 controls and enhancements, every one of them carrying a stable identifier. Those identifiers are the reason 800-53 became the common currency other frameworks translate into. Now render one control into Markdown so you can read, in English, what the requirement actually demands.

trestle author catalog-generate --name nist80053 --output md_nist
sed -n '1,16p' md_nist/ia/ia-2.md

---
x-trestle-global:
  sort-id: ia-02
---
 
# ia-2 - \[Identification and Authentication\] Identification and Authentication (Organizational Users)
 
## Control Statement
 
Uniquely identify and authenticate organizational users and associate that unique identification with processes acting on behalf of those users.
 
## Control Assessment Objective
 
- \[IA-02[01]\] organizational users are uniquely identified and authenticated;
 
- \[IA-02[02]\] the unique identification of authenticated organizational users is associated with processes acting on behalf of those users.

That file is one control, IA-2, Identification and Authentication, lifted out of a machine-readable catalog into Markdown you can read over coffee, control statement and assessment objective included. Look at what the assessment objective does. It splits the requirement into two separately testable statements, IA-02[01] and IA-02[02]. Those are the seams an automated check plugs into. And IA-2 is the same requirement SOC 2 files under CC6.1, PCI under Requirement 8, and ISO under Annex A 8.5. One control, four framework identifiers. Build it once, evidence it once, map it everywhere, which is exactly where the next lesson, Controls & mapping, picks up.

Try this

Work through “OSCAL: controls a machine can read” yourself on a sandbox you can throw away, following the commands above in order. Then break one step deliberately and re-run, so you have seen the failure before it finds you.

Takeaway

The trap worth remembering here: the full catalog is not your baseline. Check that on your own systems before you need to, because it is cheaper to find on a quiet afternoon than during an incident.

Related