Slide 39 of 44Sand & SignalOpen full tutorial

Five functions, and which framework to start with

Introduces the NIST Cybersecurity Framework's five functions as an organizing model referenced inside SOC 2 and ISO 27001, then gives a concrete decision framework for which compliance standard an organization should actually pursue first.

Raw HTML

Speaker notes

  • Frame NIST CSF correctly from the start: it is not a certification you pass or fail, unlike SOC 2 or ISO 27001 — it's an organizing model, a way of categorizing security work into five functions so a team of any maturity level can describe where its effort is actually going. This matters because SOC 2 auditors and ISO 27001 assessors both implicitly reference this same five-function shape.
  • Walk the five functions as a narrative connecting back to the whole course, not just a list: Identify is knowing your real assets and risk (barely covered in this course, genuinely a separate discipline); Protect is essentially everything in Modules 1 through 5 — every scanner, every hardening step, every access control; Detect is Falco and audit logging from Module 3; Respond is the leak-response runbook from Module 4; Recover is the blameless postmortem material referenced throughout. Making the audience see their own course material mapped onto this wheel is the actual teaching goal of this slide.
  • The decision-framework callout is the second half of this slide's job, and it should be delivered as genuinely practical advice, not trivia: in most real organizations, which framework to pursue first isn't a free technical choice — it's dictated by who's asking. A contract with an enterprise customer usually names SOC 2 explicitly. Touching cardholder data makes PCI-DSS non-negotiable, not a maturity choice. Health data triggers HIPAA. Selling into the EU, or wanting one broad international standard covering everything, points toward ISO 27001.
  • Close on the two-layer point: NIST CSF organizes the internal work; SOC 2/ISO/PCI-DSS are the external proof someone actually demands. A team that only knows the acronyms without understanding this distinction will struggle to explain, in an interview or to a stakeholder, why an organization has more than one of these running at once.

Deck map

01
Make security everyone's job
02
Six modules, one continuous defense
03
Security stops being a gate at the end
04
Shift-left: catch it while it's still cheap
05
Think like an attacker, on purpose
06
The cloud secures the cloud, you secure what's inside it
07
Turn the policy PDF into an enforced rule
08
Tooling alone doesn't make you DevSecOps
09
SAST, DAST, SCA: three different questions
10
SAST reads your code without ever running it
11
DAST attacks the running app like a real attacker would
12
The vulnerability three packages deep
13
CVSS tells you how bad, not whether it can reach you
14
No single tool covers the whole OWASP Top 10
15
A container image is more than your app
16
One image scan doesn't see your whole cluster
17
Five changes separate a throwaway image from a liability
18
A container is not a lightweight VM
19
What's inside the image isn't how it's run
20
Kubernetes adds a new set of who-can-do-what questions
21
Kubernetes trusts every pod by default
22
Enforce it automatically, then watch for what slips through
23
Two more names worth knowing: Kyverno and kube-bench
24
One leaked secret bypasses every other control
25
Catch it before the commit, know what to do if it leaks anyway
26
Why environment variables aren't a secrets manager
27
Every app instance gets its own credential, and it expires on its own
28
Not every secret needs a Vault server
29
Long-lived keys are a secret you have to store somewhere
30
Something has to be the first credential
31
Why attack a thousand customers when you can attack one build system
32
A misconfigured trigger can hand your secrets to a stranger's fork
33
A mutable version tag is a promise the maintainer can break
34
Scan the infrastructure definition before it's ever provisioned
35
Know exactly what's inside, prove exactly where it came from
36
One diagram, every module, in the order it runs
37
Passing an audit is not the same as being secure
38
Turn the compliance checklist into a real, running scan
39
Five functions, and which framework to start with
40
ISO 27001 asks for a system, PCI-DSS asks for specific controls
41
Compliance is largely DevSecOps, formalized
42
Every tool from this course, in one place
43
Sixty seconds before the interview
44
What you should be able to explain now