What compliance is: frameworks, controls and evidence

Where you are

Read a few cloud job descriptions and the same words keep turning up: "experience with SOC 2", "familiarity with NIST 800-53", "supported FedRAMP authorization", "audit evidence". They sound like paperwork, and some of it is. But underneath, nearly every one is about engineering you already do: who can log in, whether traffic is encrypted, whether changes are reviewed, whether anyone notices when something breaks.

This track is about that overlap. It isn't legal advice, and it won't make you an auditor. The goal is to know enough to read those job descriptions, hold your own when an auditor asks a question, and point at the evidence in a system you run. This first lesson is the vocabulary everything else is built on.

A kitchen inspection

Every restaurant kitchen has to follow a food safety code. The code is a long list of rules, written by someone else, that apply to every kitchen. One rule might be: "Keep cold food at 41°F or below." The code doesn't say which fridge to buy. It says what has to be true.

The kitchen decides how to meet each rule: a fridge with a thermometer, set to 38°F. And because nobody takes the kitchen's word for it, staff write the temperature in a log twice a day. When the inspector visits, they don't just look in the fridge today; they read the log for the last three months, to see that the rule was kept all along.

That's compliance, all of it. Swap the names:

• The food code is a framework: a published set of rules for keeping something safe.
• "Cold food at 41°F or below" is a control: one rule in the framework.
• The fridge set to 38°F is the implementation: how you, specifically, meet that control.
• The temperature log is evidence: proof the control was met, and over time.
• The inspection is an audit: an independent check of the evidence against the framework.

The rest of this lesson takes each one in turn.

Framework: the rulebook

A framework is a structured set of security or privacy requirements that an organisation agrees to follow. Some are laws, some are industry standards, some are contracts. Lesson 2 goes through the ones you'll see in job descriptions, but here's a taste of why there are so many:

• A company that sells software to other businesses gets asked by its customers for a SOC 2 report.
• A company that takes card payments must follow PCI DSS (Payment Card Industry Data Security Standard).
• A US federal agency, or a company selling cloud services to one, works with NIST 800-53 and FedRAMP.

Different rulebooks, written by different groups, for different situations. The good news is that they ask for many of the same things, because there are only so many ways to keep systems safe. Learn the ideas once, and they carry across frameworks.

Control: one rule

A control is one requirement in a framework: a specific thing that must be true. Here's a real one, from NIST SP 800-53, the US government's big catalogue of security controls. It's control SC-8, in the System and Communications Protection family:

SC-8  Transmission Confidentiality and Integrity

Protect the [Selection (one or more): confidentiality; integrity]
of transmitted information.

That's the whole control statement. In plain words: data travelling across a network must be protected from being read, changed, or both. The part in brackets is a choice each organisation makes when it adopts the control. If you did the Networking track, you already know the usual way to meet this one: TLS, from Networking Lesson 9.

Controls in NIST 800-53 have IDs made of a family code and a number. The family tells you the area: AC is access control, AU is audit and accountability (logging), CM is configuration management, SC is system and communications protection, and there are 20 families in all. You'll see these IDs everywhere in federal work, so it's worth getting used to them early: "we meet AC-6 through role-based access in Kubernetes" is the kind of sentence that comes up in interviews.

Notice what SC-8 doesn't say: it doesn't say "use TLS 1.3" or "use Cloudflare". Controls say what must be true, and leave how to you. That's on purpose: frameworks would go out of date in a year if they named products.

Implementation: how you meet it

The implementation is your specific answer to a control: the actual settings, tools and processes. Two companies can meet SC-8 in completely different ways, and both be fine:

• One terminates TLS at a cloud load balancer, and encrypts again from there to the servers.
• Another runs everything behind Cloudflare, with a tunnel into the cluster and plain HTTP refused at the edge.

When an auditor asks "how do you meet SC-8?", they're asking for your implementation, in words someone else could check. Being able to describe it clearly, without hand-waving, is half of what compliance asks of engineers.

Evidence: the proof

Evidence is anything that proves a control was met: a configuration file, a screenshot of a setting, a log, a report from a scanning tool, a record of who approved a change. Like the kitchen's temperature log, good evidence answers three questions:

• What does it show? It points at a specific control.
• When was it true? It has a date, or covers a period.
• Can someone else check it? It's not just your word.

Evidence is where engineers spend most of their compliance time, and it's where good habits pay off: Lesson 4 is all about getting evidence almost for free from tools you already use, like Git and Terraform.

Audit: the independent check

An audit, or assessment, is when someone independent checks your evidence against the framework. Who does it depends on the framework: for SOC 2 it's an independent CPA (certified public accountant) firm, and for FedRAMP it's an approved third-party assessment organisation. Either way, the key word is independent: you don't get to mark your own homework.

Auditors rarely check everything. They sample: "show me the access list for these five servers", "show me the approval for these ten changes from March". That's why one bad example matters: if the sample happens to land on the change nobody reviewed, the auditor writes it up as a finding, a control that wasn't met, whatever the other nine looked like.

Many audits also cover a period, not just a moment. A kitchen that was spotless only on inspection day isn't safe, and a control that only worked on audit day isn't met. Lesson 2 covers the difference this makes for SOC 2.

Three kinds of control

Controls come in three broad kinds, by what they do. It's a useful way to sort them, and auditors and job descriptions use these words:

Good systems have all three for anything that matters, because no preventive control is perfect. If you did the Networking track, its firewalls were preventive, the troubleshooting checklist was detective, and blocking plain HTTP then checking which API keys might need replacing was corrective.

Who does what

In most companies, compliance is shared between a few groups:

• The compliance team, often called GRC (governance, risk and compliance), chooses the frameworks, writes the policies, and runs the audits.
• The auditors are independent and check the evidence.
• Engineers build and run the controls, and produce most of the evidence.

That last line is why the job descriptions mention it. In practice, engineers get asked things like:

• "Can you send a screenshot of the encryption setting for the production database?"
• "Who has admin access to the cloud account, and who approved it?"
• "Show me the change record and the approval for this deployment on March 12th."
• "How do you know if someone logs in who shouldn't?"

An engineer who can answer those quickly, with evidence that holds up, is worth a lot to a team in the middle of an audit. That's the skill this track builds.

Collect your first evidence

Time to make some evidence for SC-8, against a real API. This checks that plain HTTP is refused and HTTPS works, and saves the result in a file with the date and the control it's for:

{
  echo "Control: SC-8, transmission confidentiality and integrity"
  echo "System: api.civicgrid.org"
  echo "Checked: $(date -u)"
  echo "Plain HTTP status:"
  curl -s -o /dev/null -w '%{http_code}\n' http://api.civicgrid.org/
  echo "HTTPS status:"
  curl -s -o /dev/null -w '%{http_code}\n' https://api.civicgrid.org/
} > evidence-sc8.txt
cat evidence-sc8.txt

The { ... } groups the commands so all their output goes into one file with a single >. $(date -u) puts in the current date and time in UTC, so the evidence says when it was true. You'll see something like this; your date will differ:

Control: SC-8, transmission confidentiality and integrity
System: api.civicgrid.org
Checked: Sun Oct 25 04:40:12 UTC 2026
Plain HTTP status:
403
HTTPS status:
200

That's a real, if small, piece of evidence. It names the control, the system and the date, and anyone can rerun it to check. Real teams collect evidence like this automatically, every day, instead of scrambling before an audit, which is where Lesson 4 picks up.

Compliant isn't the same as secure

One honest warning before going further. Compliance is a floor, not a ceiling. A framework lists the controls most organisations need, and an audit checks a sample of them at a point or over a period. Passing means you met those rules, as sampled. It doesn't mean nothing can go wrong.

Plenty of companies with clean audit reports have still been breached, through a control that was met on paper but not in practice, a gap the framework didn't cover, or a mistake made the day after the audit ended. The reverse is true too: a small team can run a very safe system without any certification at all, because nobody's asked for one.

The healthiest way to think about it: build the system to be secure, and let compliance be the proof that you did. If you find yourself doing something only because the audit checks it, and it doesn't make anything safer, that's worth questioning, politely.

Spot the problem

Three cases, the kind auditors find every day. Work out the problem before you read the explanation.

The screenshot from last year. An auditor asks for evidence that the production database is encrypted. An engineer sends a screenshot of the encryption setting, taken for last year's audit. Nothing's changed since, they say. Why might the auditor reject it? It doesn't show when the setting was true for this audit's period. Settings do change, and nobody can tell from an old picture. Evidence needs to be current, and dated. A screenshot taken today, or better, the setting in a Terraform file with its Git history, would answer it.

The policy says one thing. The company's written policy says every admin account must use multi-factor authentication (MFA). The auditor samples five admin accounts. Four use MFA; one, an old account a contractor set up two years ago, doesn't. Is the control met? No. A policy is a promise, not a control; the control is the MFA actually being on. The auditor writes a finding, and "we have a policy" doesn't help. This is why sampling works: the forgotten corner is exactly where controls slip.

Clean report, still breached. A company passes its audit with no findings. Two months later, an attacker gets in using a database password that a developer had committed to a public Git repository. How can both be true? The audit sampled controls, over a period, against a framework, and passed. But the password in Git wasn't something the sample happened to check, or the leak happened after the audit window. Compliant, and still breached. That's the floor-not-ceiling point: compliance proves the controls you were checked on, and nothing more.

Where you are now

You have the vocabulary: a framework is the rulebook, a control is one rule, the implementation is how you meet it, evidence is the proof, and an audit is someone independent checking. You know the three kinds of control, who does what, and that compliance is the floor, not the ceiling. You've even made your first piece of evidence. Lesson 2 opens the rulebooks themselves: the frameworks in job descriptions, what each is for, and who asks for which.

Check yourself

Key terms

• Framework: a published set of security or privacy rules an organisation follows, like SOC 2 or NIST 800-53.
• Control: one rule in a framework, like SC-8 or AC-6.
• Implementation: your specific way of meeting a control.
• Evidence: proof a control was met, that says what and when, and can be checked.
• Audit (assessment): an independent check of evidence against a framework.
• Finding: a control the auditor found wasn't met.
• Preventive, detective, corrective: controls that stop, notice, or fix a problem.
• GRC (governance, risk and compliance): the team that runs compliance in most companies.

Go deeper

• NIST's page for SP 800-53 Revision 5 (opens in a new tab), the full catalogue of controls, including SC-8. It's long; skim the family list rather than reading it front to back.
• The AICPA's overview of SOC 2 and the Trust Services Criteria (opens in a new tab), which Lesson 2 covers.