1. SOC 2, ISO 27001 & the NIST Cybersecurity Framework, at a Glance
These three come up constantly in industry conversation and are frequently confused with each other — each verifies something genuinely different.
SOC 2 An AUDIT report, common for SaaS/vendor trust. An independent
auditor verifies your controls actually operate as described,
against 5 "Trust Service Criteria" (security, availability,
processing integrity, confidentiality, privacy). Produces a
report you show customers/prospects as proof.
ISO 27001 A CERTIFICATION for an Information Security Management
System (ISMS) -- a formal, ongoing process of identifying
risks, implementing controls, and continuously improving.
Broader and more process-focused than SOC 2's specific
control-testing.
NIST CSF A FRAMEWORK, not a certification -- a structured way to think
about and organize security work, built around five functions:
Identify, Protect, Detect, Respond, Recover. Many organizations
use it internally to structure their program without ever
being "certified" against it -- it's a mental model, not an audit.
Notice NIST CSF's five functions map almost directly onto this course's own structure: Identify is Week 1's threat modeling and Week 11's vulnerability management; Protect is most of Weeks 2-10; Detect is Week 12; Respond and Recover are Week 13. Frameworks aren't a separate, unfamiliar body of knowledge — they're a way of organizing and communicating the same work you've already been learning.
SOC 2 (and ISO 27001) verify that specific, defined controls exist and function as described over an audit period — they're evidence of a mature security process, not a guarantee against every possible incident. A well-run company with a clean SOC 2 report can still have a real incident; the report speaks to process rigor, not to zero risk ever existing.
2. GDPR & Data-Privacy Basics Every Engineer Should Know
GDPR (the EU's General Data Protection Regulation) is the most influential data-privacy law globally — many other jurisdictions' privacy laws follow a similar shape. A handful of its requirements have direct, everyday engineering implications.
Data minimization: collect only what you actually need. A signup form
asking for a birthdate "just in case it's useful later"
is exactly the anti-pattern this principle targets.
Right to erasure: a user can request their data be deleted. This means
a real "delete my account" flow must actually delete
(or properly anonymize) data across every system that
holds it -- not just the primary database, but backups,
logs, analytics platforms, and any third-party processor.
Right to access: a user can request a copy of everything held about
them -- your system needs to be able to actually
produce this, which is much harder if data is scattered
across undocumented systems with no clear ownership.
Breach notification: a confirmed personal-data breach must be reported
to the relevant authority within 72 hours of becoming
aware of it -- which only works if Week 13's incident
response process can determine scope and impact FAST.
Notice the direct dependency on earlier weeks: "right to erasure" is only tractable if you know exactly where personal data lives (Week 10's dependency/data-mapping discipline, applied to data itself rather than code). The 72-hour breach notification window is only achievable if Week 13's incident response can actually move that fast — which depends on having the logging and detection from Week 12 already in place.
Deciding to collect a piece of personal data at all, how long to retain it, and whether it's even necessary for the feature at hand are engineering design decisions with direct privacy-compliance consequences. Building "do we actually need this field?" into design reviews, before code is written, is far cheaper than retrofitting deletion/access support onto a system that already scattered personal data everywhere without a plan.
3. Other Frameworks You'll Encounter
Depending on the industry, other frameworks and regulations apply — worth recognizing even without deep expertise in each.
PCI DSS Payment Card Industry Data Security Standard -- required for
anyone storing, processing, or transmitting credit card data.
Heavy on network segmentation (Week 2) and encryption (Week 4)
requirements specifically around cardholder data.
HIPAA US healthcare data privacy/security law -- similar shape to
GDPR's principles, applied specifically to protected health
information, with its own specific technical safeguard
requirements (access controls, audit logs -- Weeks 3, 5, 12).
CIS Benchmarks Referenced back in Week 3 -- detailed, specific
hardening configurations per operating system/platform,
often used as the concrete "how" underneath a broader
framework's "what" (e.g. NIST CSF's Protect function).
The pattern across all of these: each names specific requirements, but the underlying controls are almost always the same handful of things this course has already covered — access control, encryption, logging, incident response, segmentation — organized and worded differently per framework's specific audience and legal context.
What matters practically is recognizing that "we need to be SOC 2 compliant" or "this handles cardholder data, so PCI applies" translates into a fairly predictable, overlapping set of real technical controls — most of which you've already learned how to build. Compliance work is largely about documenting and evidencing controls you should be implementing anyway, not inventing an entirely separate body of security practice.
4. Turning Frameworks into Actual Controls
A framework requirement reads as abstract policy language until it's mapped to a specific, concrete, already-implemented technical control — this mapping exercise is exactly what a real compliance audit walks through.
SOC 2 Criterion: "Logical access to system resources is restricted to
authorized users."
Maps to, from this course:
- Week 3: Users/groups, least privilege, sudo scoping on every server
- Week 5: MFA, RBAC/ABAC design, server-side authorization on every request
- Week 8: IAM least-privilege policies in the cloud
- Week 9: Kubernetes RBAC
SOC 2 Criterion: "The entity monitors system components for anomalies
that are indicative of malicious acts, natural disasters, and errors."
Maps to:
- Week 12: centralized logging, detection rules, SIEM
- Week 13: the incident-response process those alerts feed into
This is why compliance readiness is dramatically easier for a team that's already built these controls for genuine security reasons, versus one starting from nothing specifically to pass an audit — the mapping exercise above only works if the controls actually exist to be mapped.
An auditor doesn't just take your word that MFA is enforced — they need evidence: a screenshot of the enforced setting, a log showing it rejected a non-MFA login attempt, a policy document describing the requirement. Building the habit of documenting controls as you implement them (not scrambling to produce evidence right before an audit) is what actually makes compliance season manageable.
5. Writing a Security Policy an Engineering Team Will Actually Follow
A security policy that's long, vague, and written in legal-sounding language gets read once, if ever, and then ignored. A policy engineers actually follow is short, specific, and explains the reasoning — the same "why, not just what" approach this entire course has tried to model.
# Unfollowable: vague, no specifics, no reasoning
"Employees must exercise due diligence regarding data security and
adhere to industry best practices for access management."
# Followable: specific, actionable, explains why
"Every production database credential must be stored in [Vault], never
in a config file or environment variable checked into git (Week 10) --
because a leaked credential in git history is retrievable forever, even
after the line is deleted, and this is the single most common way
credentials actually leak in practice."
A good policy is also realistic about enforcement — a rule nobody can practically follow (or that blocks legitimate work with no exception path) gets quietly worked around, which is worse than no policy at all, because it also teaches people that policies in general are ignorable.
1. Scope: what systems/data this policy covers
2. The specific rule: concrete, checkable, not aspirational language
3. Why: the actual risk this addresses (builds buy-in far better than
an unexplained rule ever does)
4. How to comply: the actual tool/process to follow -- link it directly
5. Exceptions: how to request one, and who approves it (a policy with
zero exception path invites people to just quietly ignore it instead)
If following a policy is genuinely harder than the insecure alternative it's trying to prevent, most people will take the easier path most of the time, policy or not. The most effective security policies make the secure path the easiest path — a pre-configured secrets vault that's simpler to use than manually managing credentials, a linter that catches a hardcoded secret before commit (Week 10) rather than relying purely on a written rule someone has to remember.
6. Hands-on Exercise
Map your own controls to a framework, then write a real policy from scratch
Take stock of everything you've actually built across this course, and turn it into the two real deliverables a security-minded engineering org needs.
Part 1 — Map controls to a framework:
- Pick either NIST CSF's five functions or three SOC 2 Trust Service Criteria (Security, Availability, Confidentiality) as your target framework.
- For each function/criterion, list at least two specific, concrete controls from this course's earlier weeks that satisfy it — referencing the actual week and control (following Section 4's mapping format).
- Identify at least one gap: a requirement the framework implies that this course's earlier exercises didn't fully build out for a real system (be specific — don't just say "more security needed").
Part 2 — Apply GDPR's "right to erasure" to a real design:
- Take one of the applications you built in an earlier week's exercise (the todo app, the signup form, any app with user accounts) and list every place personal data actually lives — the primary database, any logs that might contain it (check Week 5's/6's exercises honestly), backups, any third-party service it was sent to.
- Design a "delete my account" flow that actually addresses every location on that list, not just the primary database record — write it as a concrete sequence of steps.
- Identify the hardest item on your list to actually delete (backups and third-party services are common answers) and write one paragraph on a realistic approach — full deletion vs. properly anonymizing vs. a documented retention exception.
Logs are the most commonly forgotten location for personal data during this exercise — if any earlier exercise logged a full request body, a username, or an email address as part of debugging output, that log entry is itself personal data subject to the same deletion requirement, even though it doesn't feel like "the database."
Part 3 — Write a real security policy:
- Pick one specific rule from this course you'd actually want enforced on a real team (e.g. "no secrets in source control," "MFA required for all admin access," "all production servers must have auditd configured").
- Write it as a full policy clause following Section 5's structure: scope, the rule, why, how to comply, and an exception path.
- Review your own draft against Section 5's "unfollowable vs. followable" example — rewrite anything that reads as vague or unenforceable.
Test your finished policy against the same standard as Week 13's action items: could someone with no context read just this clause and know exactly what to do, why, and what tool to use? If any part requires "common sense" to fill in a gap, it's not specific enough yet.
7. Knowledge Check
Four quick questions. Expand each to check your answer.
Q1
What's the fundamental difference between SOC 2 and the NIST Cybersecurity Framework?
What's the fundamental difference between SOC 2 and the NIST Cybersecurity Framework?
SOC 2 is an independently audited report verifying that specific controls actually operate as described — a formal attestation you can show customers. NIST CSF is a structural framework (Identify, Protect, Detect, Respond, Recover) for organizing security work — not a certification or audit, but a mental model many organizations use internally without ever being formally "certified" against it.
Q2
Why is GDPR's "right to erasure" much harder to satisfy for a system where personal data is scattered undocumented across many services, versus one with a clear data inventory?
Why is GDPR's "right to erasure" much harder to satisfy for a system where personal data is scattered undocumented across many services, versus one with a clear data inventory?
Honoring a deletion request requires actually finding and removing every copy of that user's personal data — the primary database, logs, backups, and any third-party processor it was sent to. Without a clear, documented inventory of where personal data lives, a team can't be confident they've actually found every location, meaning some copies could persist indefinitely without anyone realizing it.
Q3
Why does an auditor need actual evidence (screenshots, logs, documents) rather than just a verbal confirmation that a control exists?
Why does an auditor need actual evidence (screenshots, logs, documents) rather than just a verbal confirmation that a control exists?
Compliance frameworks exist to give a third party (a customer, a regulator) independent confidence that controls genuinely operate, not just that someone claims they do. Evidence is what makes an audit's conclusion verifiable and trustworthy — without it, "we have MFA enforced" is an unverified claim rather than a demonstrated fact.
Q4
Why does a security policy with no exception path tend to be less effective than one that includes a clear way to request an exception?
Why does a security policy with no exception path tend to be less effective than one that includes a clear way to request an exception?
When a rigid rule genuinely blocks legitimate work with no sanctioned way around it, people tend to quietly work around it anyway — undermining both that specific rule and the perceived legitimacy of policy in general. A defined exception path (with approval) keeps genuine edge cases handled transparently and on the record, rather than through silent, undocumented workarounds.