By the end you'll know
- The difference between a law, a standard, a report, a certificate and an authorization
- What SOC 2, ISO 27001, PCI DSS and HIPAA are, and who asks for each
- How NIST 800-53, FedRAMP, FISMA and CMMC fit together in US government work
- What CIS Benchmarks and DISA STIGs are, and why engineers use them directly
- Why one good control often satisfies several frameworks at once
Where you are
Lesson 1 gave you the vocabulary: a framework is the rulebook, a control is one rule, and evidence is the proof. This lesson opens the rulebooks themselves, the ones whose names fill cloud job descriptions.
You won't need to memorise any of them. The aim is that when you read "SOC 2 Type II", "FedRAMP Moderate" or "CIS hardened images" in a job description, you know what world that company lives in and roughly what it'll ask of you.
Licences for what you carry
Anyone can learn to drive. But to drive a truck you need an extra licence, to drive a taxi another, and to carry dangerous goods yet another. The road skills are the same; the extra rules depend on what you carry, and for whom.
Frameworks work the same way. Good security is the same everywhere, but which rulebooks apply depends on what a company carries, card payments or health records, and who it carries them for: other businesses, hospitals or the government. That's why one company deals with three frameworks and another with none.
Not all frameworks are the same kind of thing
People call all of these "frameworks", but they're different kinds of thing, and the difference matters when someone says "we're compliant":
| Kind | Examples | What you end up with |
|---|---|---|
| A law | HIPAA, GDPR, FISMA | A legal duty. There's no official certificate; you just have to comply. |
| An industry standard | PCI DSS | An assessment, required by the card companies and banks you work with. |
| An audit report | SOC 2 | A report from an independent auditor, which you share with customers. |
| A certification | ISO 27001, CMMC | A certificate saying you meet the standard, for a set period. |
| A government program | FedRAMP | An authorization to provide a service to government agencies. |
| A control catalogue | NIST SP 800-53, NIST SP 800-171 | Nothing on its own: other frameworks build on it. |
| A hardening guide | CIS Benchmarks, DISA STIGs | Configuration settings engineers apply directly to systems. |
That table explains a classic mistake you'll meet in the first case below: there's no such thing as being "HIPAA certified", because HIPAA is a law, not a certification.
Which ones come with the job?
Tick what's true about a company you work for, or one you'd like to, and see which frameworks usually come with it:
Try a few combinations. A startup selling a tool to other businesses gets one or two. A company selling a cloud service to the US government, with card payments, ends up with five or six. Then read on for what each one actually is.
Selling to other businesses: SOC 2 and ISO 27001
SOC 2 is the one you'll see most in US job descriptions. When a company sells software to other businesses, those customers want proof that their data will be safe, so they ask for a SOC 2 report. It's defined by the AICPA (the American Institute of Certified Public Accountants), and carried out by an independent CPA firm, as in Lesson 1.
SOC 2 is built around five Trust Services Criteria: security, availability, processing integrity, confidentiality and privacy. Security is always included; the others are added when they matter to the customers. And there are two types of report, which job descriptions often name:
- Type I checks that the controls are designed properly, at one point in time.
- Type II checks that they actually worked, over a period, often three to twelve months. It's the kitchen's three months of temperature logs from Lesson 1, and it's the one customers really want.
A SOC 2 report is not a certificate. It's a detailed document, usually shared with customers under a non-disclosure agreement.
ISO/IEC 27001 is the international equivalent, more common in Europe and with global customers. It's a standard for running an ISMS (information security management system): a whole, ongoing programme for managing security risk, not just a list of settings. It comes with a list of 93 controls in its Annex A, grouped into organisational, people, physical and technological themes. Unlike SOC 2, it ends in a real certificate, from an accredited certification body, usually valid for three years with a check-up audit every year.
Handling sensitive data: PCI DSS, HIPAA and GDPR
PCI DSS (Payment Card Industry Data Security Standard) applies to anyone who stores, processes or transmits card data. It's written by the PCI Security Standards Council, which the major card brands set up, and the current version is 4.0.1. It's organised into 12 main requirements, from firewalls to logging to testing.
The most useful thing an engineer can know about PCI DSS is scope: it applies to the systems that touch card data, and to those connected to them. That's why so many companies use a payment provider whose own page takes the card number. If the card number never reaches your servers, most of PCI DSS stops applying to them. Keeping sensitive data out of systems that don't need it is a strategy you'll see in every framework.
HIPAA (Health Insurance Portability and Accountability Act) is a US law. Its Security Rule requires health organisations to protect electronic health information, and the same duty extends to any company handling that information for them, called a business associate, under a signed BAA (business associate agreement). If you build software for hospitals or insurers, HIPAA comes with the job.
GDPR (General Data Protection Regulation) is the European Union's law on personal data. It applies to companies anywhere in the world when they handle data about people in the EU. It's more about privacy rights, like deleting someone's data when they ask, than about technical settings, but engineers build the parts that make those rights possible.
US government: NIST 800-53, FedRAMP, FISMA and CMMC
US government work has its own family of frameworks, and they all trace back to one place.
NIST SP 800-53, which you met in Lesson 1, is the catalogue of controls: 20 families, from access control to supply chain. A companion document, NIST SP 800-53B, groups them into baselines, Low, Moderate and High, according to how much harm a breach could do. A system holding public information might need the Low baseline; one holding sensitive personal data needs Moderate or High.
FISMA (Federal Information Security Modernization Act) is the law that requires federal agencies to secure their systems, using NIST's standards. For each system, an agency official formally accepts the remaining risk and grants an ATO (authority to operate). Lesson 6 walks through that process.
FedRAMP (Federal Risk and Authorization Management Program) is for cloud companies that want to sell to federal agencies. Instead of every agency checking every cloud service separately, FedRAMP checks it once, against the NIST 800-53 baselines, and agencies can reuse that authorization. You'll see "FedRAMP Moderate" or "FedRAMP High" in job descriptions: that's the baseline the service was authorized at. FedRAMP is also in the middle of a big change: since March 2025, a new approach called FedRAMP 20x has been moving it towards automated, continuous checking instead of mostly paper-based reviews.
CMMC (Cybersecurity Maturity Model Certification) is the Department of Defense's program for its contractors. Its middle level builds on NIST SP 800-171, a smaller set of requirements, 110 in the version CMMC uses, for protecting sensitive government information held by companies. A final rule made CMMC requirements start appearing in defense contracts from November 10, 2025, phased in over several years. If you work near defense contractors, you'll hear about it constantly.
Hardening guides: CIS Benchmarks and DISA STIGs
These two are different from the rest, and the most hands-on: they're lists of exact settings, which engineers apply to systems directly.
CIS Benchmarks, from the non-profit Center for Internet Security, are free configuration guides for operating systems, cloud accounts, databases and Kubernetes, agreed by a community of experts. A rule might be "make sure SSH root login is disabled". Many frameworks accept "we follow the CIS Benchmark" as a way to meet their hardening controls, and Lesson 5 runs a real CIS check on a Kubernetes cluster.
DISA STIGs (Security Technical Implementation Guides) are the Defense Department's equivalent: detailed, strict hardening rules for specific products. If a job description mentions STIGs, it's almost certainly defense work, and you'll be applying and checking those settings.
One control, many rulebooks
Here's the good news that makes all this manageable. Frameworks are written by different groups, but they're all trying to keep data safe, so they ask for many of the same things in different words. Take encryption in transit, SC-8 from Lesson 1:
Five frameworks, one piece of engineering. A table that lines up equivalent controls across frameworks like this is called a crosswalk, or a control mapping, and compliance teams live in them. For engineers, the lesson is simpler: build a control well once, keep good evidence, and it counts many times over. Lesson 3 goes through the most common controls this way.
Reading job descriptions
Put it together, and job description phrases start to translate themselves:
| The job description says | What it usually means |
|---|---|
| "Support our SOC 2 Type II audit" | A business software company. You'll provide evidence that controls worked over the audit period. |
| "Experience in a FedRAMP Moderate environment" | A cloud company selling to federal agencies, with NIST 800-53 Moderate controls on everything. |
| "Knowledge of NIST 800-53 and the RMF" | Federal agency or contractor work, including ATO paperwork. Lesson 6. |
| "Build CIS-hardened images" or "STIG compliance" | Applying hardening settings to servers and containers, and proving it with scans. Lesson 5. |
| "Familiarity with PCI DSS" | Card payments somewhere in the system. Expect strict network separation and logging. |
| "HIPAA-compliant infrastructure" | Health data. Expect encryption everywhere, access logging, and BAAs with every vendor. |
In my real setup
CivicGrid is an API that sells public civic data to other businesses, so if a customer ever asked for proof of security, SOC 2 is the framework they'd ask for. It doesn't hold health records or card numbers, so HIPAA and PCI DSS don't come into it. It's the "what you carry, and for whom" idea from the driving-licence picture: the same engineering, but only one rulebook really applies, and Lesson 7 maps CivicGrid against NIST 800-53 controls because their IDs are the clearest way to practise.
Spot the problem
Three claims you'll hear in real life. Work out what's wrong before you read the explanation.
"We're HIPAA certified." A vendor's sales page says it. What's wrong? HIPAA is a law, not a certification, and there's no official HIPAA certificate from the government. A company can comply with HIPAA, sign a BAA, and have an auditor assess its controls against the Security Rule, which is useful. But "certified" is a marketing word here. The right follow-up is: "Will you sign a BAA, and can we see an independent assessment?"
"We have SOC 2." A customer asks for your SOC 2 report, and your team sends a Type I report from last year. The customer's security team isn't happy. Why? A Type I only shows the controls were designed properly on one day. Most customers want a Type II, which shows the controls actually worked over months. And last year's report doesn't cover this year. When someone asks for SOC 2, they almost always mean a current Type II.
"We run on AWS, which is FedRAMP authorized, so we are too." A startup building a tool for federal agencies says this. What's wrong? AWS's authorization covers AWS's part: its data centres, its hardware and the cloud services as AWS runs them. Everything the startup builds on top, its own servers, code, access control and logging, is its own responsibility, and needs its own authorization. It's the shared responsibility idea from the cloud: the landlord's fire inspection doesn't cover your extension cords. Building on an authorized cloud makes FedRAMP easier, because you inherit many controls, but it never makes it automatic.
Where you are now
You can tell a law from a standard, a report, a certificate and an authorization, and you know what each of the frameworks in job descriptions is for, and who asks for it. You know the US government ones all build on NIST, and that hardening guides are the most hands-on. Above all, you know that one control done well counts across many frameworks. Lesson 3 takes the controls that appear in nearly every framework, access, encryption, logging, change management, backups and patching, and turns each into the engineering you already do.
Check yourself
A customer asks for SOC 2. Which report do they almost always mean?
Why is the claim HIPAA certified misleading?
How does PCI DSS scope affect engineers?
What do FedRAMP, FISMA and CMMC have in common?
What makes CIS Benchmarks different from SOC 2?
A startup builds on AWS, which is FedRAMP authorized. Is the startup authorized too?
Key terms
- SOC 2: an independent auditor's report on a company's controls, built on the Trust Services Criteria. Type I is design on one day; Type II is operation over a period.
- ISO/IEC 27001: the international standard for an information security management system, ending in a certificate.
- PCI DSS (Payment Card Industry Data Security Standard): the card industry's rules for systems that touch card data.
- HIPAA (Health Insurance Portability and Accountability Act): the US law protecting health information.
- NIST SP 800-53: the US government's catalogue of security controls, grouped into Low, Moderate and High baselines.
- FedRAMP (Federal Risk and Authorization Management Program): authorization for cloud services used by federal agencies.
- CMMC (Cybersecurity Maturity Model Certification): the Defense Department's program for contractors, built on NIST SP 800-171.
- CIS Benchmarks and DISA STIGs: hardening guides of exact settings for specific systems.
- Crosswalk (control mapping): a table lining up equivalent controls across frameworks.
Go deeper
- FedRAMP 20x (opens in a new tab), FedRAMP's own page on the new approach and its timeline.
- The PCI Security Standards Council's announcement of PCI DSS v4.0.1 (opens in a new tab).
- The US Department of Health and Human Services' HIPAA Security Rule (opens in a new tab) pages.
- The AICPA's overview of SOC 2 and the Trust Services Criteria (opens in a new tab).