Controls in engineering terms

Where you are

Lesson 2 showed that frameworks mostly ask for the same things in different words. This lesson is those things. There are hundreds of controls across the frameworks, but most of the ones that land on an engineer's desk fall into six groups. Learn the six, with their everyday engineering, and you can talk about almost any framework.

Each section below covers one group: what it's for, in plain words, what it looks like in a real system, the NIST 800-53 control IDs it maps to, and what evidence usually proves it. The IDs are worth learning. In federal work, people say "AC-6" the way other people say "least privilege", and using them naturally in an interview is a quiet signal that you've done this before.

Your home, as a set of controls

You already run controls at home without calling them that:

• Only people who live there get a key, and you take a key back when a roommate moves out. That's access control.
• Valuables go in a safe, and letters go in sealed envelopes. That's encryption.
• A doorbell camera records who came and went. That's logging and monitoring.
• You don't knock a wall down without plans someone has checked. That's change management.
• Copies of your passport and deeds are in a fire-proof box, and you know where. That's backup and recovery.
• The car goes in for its recalls and servicing. That's patching.

Six habits that keep a home safe. A cloud system needs the same six, and the rest of this lesson takes each in turn.

1. Access: who can get in, and to what

What it's for: only the right people and programs can reach anything, and only as much as they need.

This is the biggest family in most frameworks, because most breaches involve someone getting access they shouldn't have. In engineering terms:

• Accounts exist only while they're needed. A leaver's accounts are removed on their last day, and access is reviewed regularly. That's AC-2, account management.
• Everyone gets the least access their job needs. A deploy pipeline can change one namespace, not the whole cluster; a developer can read production logs but not delete the database. That's AC-6, least privilege, and it's the one you'll hear named most.
• People prove who they are, strongly. Sign-ins use multi-factor authentication (MFA), not just a password. That's IA-2, identification and authentication.
• Secrets are looked after. Passwords and API keys are stored safely, never in Git, and changed when someone leaves or a key leaks. That's IA-5, authenticator management.

In Kubernetes, least privilege is RBAC (role-based access control), from the Kubernetes track's namespaces and access lesson.

Typical evidence: a list of who has admin access, and who approved it; a screenshot showing MFA is required; the RBAC files in Git; a record of the last access review.

2. Encryption: in transit and at rest

What it's for: data can't be read by anyone who intercepts it, or gets hold of the disk it's stored on.

Encryption comes in two halves, and frameworks ask for both:

• In transit, while data travels across a network: TLS, from Networking Lesson 9. That's SC-8, which you met in Lesson 1.
• At rest, while data sits on a disk, in a database or in a backup: disk and database encryption, usually a setting your cloud provider offers. That's SC-28, protection of information at rest.
• The keys themselves are created, stored and rotated carefully, often with a cloud key management service. That's SC-12, cryptographic key establishment and management.

One trap catches people often enough to name here: Kubernetes Secrets are encoded, not encrypted. The base64 you see in a Secret can be decoded by anyone who can read it, as the Kubernetes track's configuration and secrets lesson shows. Encryption at rest for Secrets is a separate setting on the cluster, and access control does the real protecting.

Typical evidence: the encryption setting on each database and disk, ideally in Terraform; a TLS test like the one you saved in Lesson 1; the key management configuration.

3. Logging and monitoring: noticing

What it's for: if something goes wrong, someone finds out quickly, and there's a record of what happened.

These are the detective controls from Lesson 1:

• The right events are recorded. Sign-ins, permission changes, failed access attempts, admin actions. That's AU-2, event logging.
• Someone actually looks. Logs are reviewed, or better, alerts fire automatically on suspicious events. That's AU-6, audit record review.
• The system is watched as a whole. Monitoring and alerting on health and security. That's SI-4, system monitoring.

Two things auditors often check that engineers forget: logs are kept long enough (PCI DSS, for example, asks for a year of audit logs), and logs are protected, so someone who breaks in can't quietly delete the record of it.

Typical evidence: the logging configuration; a sample of real log entries; the alert rules; an example of an alert that fired and what was done about it.

4. Change management: no surprises

What it's for: every change to production is proposed, reviewed, approved and recorded, so nothing changes by accident or in secret.

• There's a known, agreed starting point. The approved configuration of each system is written down, ideally as code. That's CM-2, baseline configuration.
• Changes go through a process. Proposed, reviewed by someone else, approved, tested, and recorded. That's CM-3, configuration change control.

This is where modern engineering shines. A pull request is a change proposal with a built-in review, approval and permanent record. Terraform is a baseline configuration you can read. GitOps tools like Argo CD make sure what runs in production matches what's in Git, and put it back if someone changes it by hand. Lesson 4 is entirely about this.

Typical evidence: the Git history; pull requests with their approvals; the branch protection setting that stops anyone merging without review.

5. Backup and recovery: putting it back

What it's for: when data is lost or a system is destroyed, you can get it back, within a time you've agreed.

• Data is backed up regularly, and the backups are protected. That's CP-9, system backup.
• You can actually recover. There's a tested way to rebuild the system and restore the data. That's CP-10, system recovery and reconstitution.

The second one is where most teams fall short. A backup you've never restored is a hope, not a control. Two numbers come up in every conversation about this: RPO (recovery point objective), how much data you can afford to lose, like "one hour", and RTO (recovery time objective), how long you can afford to be down, like "four hours".

Typical evidence: the backup schedule and retention settings; the record of the last test restore, with how long it took.

6. Patching: fixing known holes

What it's for: known security bugs in your software get found and fixed before someone uses them against you.

• You look for weaknesses. Scanning servers, container images and dependencies for known vulnerabilities. That's RA-5, vulnerability monitoring and scanning.
• You fix them, on a schedule. Updates applied within a set time, faster for serious ones. That's SI-2, flaw remediation.

Frameworks usually expect deadlines by severity: something like critical fixes within days and lower ones within weeks or months, with the exact numbers set by the framework or the organisation. Tools do most of the finding: image scanners, dependency bots that open pull requests for updates, and the cloud provider's own upgrade options for things like Kubernetes nodes.

Typical evidence: scan reports; the list of open vulnerabilities and how old each one is; records of upgrades applied.

The six, side by side

Audit your own laptop

Your laptop is a small system, and you can check three of the six on it right now, saving the results as evidence like you did in Lesson 1. On a Mac:

{
  echo "System: my laptop"
  echo "Checked: $(date -u)"
  echo "SC-28, encryption at rest:"
  fdesetup status
  echo "SI-2, flaw remediation:"
  softwareupdate --list 2>&1 | tail -2
} > evidence-laptop.txt
cat evidence-laptop.txt

fdesetup status reports whether FileVault, the Mac's full-disk encryption, is on. softwareupdate --list checks for updates you haven't installed; 2>&1 | tail -2 keeps just its last lines, where the answer is. Checking for updates can take a minute. You'll see something like this; yours will differ:

System: my laptop
Checked: Sun Oct 25 05:02:41 UTC 2026
SC-28, encryption at rest:
FileVault is On.
SI-2, flaw remediation:
Finding available software
No new software available.

If FileVault is off, or updates are waiting, that's a real finding, on a real system, and you know how to fix it: turn FileVault on in System Settings, under Privacy and Security, and install the updates. For change management, any Git repository you work in is evidence already: git log --oneline -5 shows who changed what, and when. On Windows, BitLocker is the full-disk encryption, and Windows Update the patching; on Linux it depends on how the disk was set up.

Spot the problem

Three situations from real teams. Work out which control is weak before you read the explanation.

"Our secrets are safe, they're Kubernetes Secrets." An engineer tells an auditor the database password is protected because it's stored as a Kubernetes Secret. The auditor asks who can read Secrets in that namespace, and the answer is "everyone on the team, and the CI pipeline". What's weak? Two things. A Secret is base64, not encryption, so anyone who can read it has the password. And "everyone can read it" fails least privilege, AC-6. The fix is access control on who can read Secrets, plus encryption at rest for them, SC-28, rather than trusting the word "Secret".

Backups every night, for two years. A team proudly shows nightly database backups going back two years. Then a disk fails, and the first restore attempt takes nine hours and fails twice, because the restore steps were never written down. Which control was weak? CP-9, backups, was fine. CP-10, recovery, was never tested. A backup you've never restored is a hope. The fix is a scheduled test restore, timed, with the steps written down, and its record kept as evidence.

Admin for everyone, just in case. A small company gives every engineer full admin on the cloud account, "so nobody's ever blocked". An engineer leaves, and their account stays active for three months. Which controls are weak? AC-6, least privilege: most of them never needed admin. And AC-2, account management: accounts should end when the job does. Together, that's one forgotten account away from a breach. The fix is roles sized to the job, and a leaver's checklist that removes access on the last day.

Where you are now

You know the six families of control that make up most of an engineer's compliance work, what each one asks for in plain engineering terms, the NIST IDs that go with them, and what evidence usually proves them. You've audited your own laptop. Lesson 4 takes the family where engineers have the biggest advantage, change management, and shows how Git, pull requests, Terraform and GitOps produce evidence almost for free.

Check yourself

Key terms

• Least privilege (AC-6): only the access a person or program needs for its job.
• Account management (AC-2): accounts exist only while needed, and are reviewed.
• MFA (multi-factor authentication): proving who you are with more than a password, part of IA-2.
• Encryption in transit and at rest (SC-8, SC-28): protecting data while it travels, and while it's stored.
• Event logging (AU-2) and monitoring (SI-4): recording what happens, and watching for trouble.
• Baseline and change control (CM-2, CM-3): a known starting point, and a reviewed process for every change.
• Backup and recovery (CP-9, CP-10): keeping copies, and proving you can restore them.
• RPO and RTO: how much data you can afford to lose, and how long you can afford to be down.
• Vulnerability scanning and flaw remediation (RA-5, SI-2): finding known weaknesses, and fixing them on time.

Go deeper

• NIST's SP 800-53 Revision 5 (opens in a new tab), where every control ID in this lesson is spelled out in full.
• The CIS Critical Security Controls (opens in a new tab), 18 practical safeguards in priority order, a good companion to the six families here.