Lesson 1.1

1.1: The Six Pillars

8 minutes

The Six Pillars

A security program is a kitchen. There are separate rooms for separate messes — the pantry holds different problems than the dishwasher, and both are different from the fridge. You don’t walk in and “secure the kitchen.” You walk in and ask which room stinks.

Most frameworks ask you to learn their floor plan before you can cook. NIST CSF has six functions. ISO 27001 has fourteen control domains. CIS has eighteen critical controls. They’re all correct, they all overlap, and none of them match the way you actually encounter problems on a Tuesday afternoon when a contractor’s laptop went missing.

Here’s a map that does match. Six pillars, organized around what you touch when something goes wrong:

  1. People — who works for you, what they can access, how you onboard and offboard them
  2. Devices — laptops, phones, servers, the BYOD MacBook your CFO insists on using
  3. Data — what you hold, where it lives, who can see it, how long you keep it
  4. Systems — the software the org runs, how it’s configured, how it authenticates, how it logs
  5. Vendors — the third parties you depend on, from Okta to your payroll provider to a random NPM package
  6. Incidents — what happens when something breaks, who decides, who calls the lawyer

That’s it. Every real-world security question you’ll face maps to one or two of these. “We’re rolling out Zoom” is a Systems question with a Vendors flavor. “An engineer left and still has GitHub access” is a People problem with a Systems control. “Our backups haven’t been tested in 18 months” is Data, full stop.

Why this grouping, not someone else’s

You didn’t ask for this job. You asked to run engineering, or build a product, or manage a team. Security landed on your desk because nobody else had a plausible claim to it. You don’t have time to internalize a framework. You need a map you can draw on a whiteboard in two minutes and use to route incoming chaos.

Frameworks like NIST are built for auditors and consultants: people whose job is to compare one program against another. This map is built for you: someone whose job is to look at a problem, decide where it lives, and either handle it or delegate it. Both are valid. They serve different purposes. We’ll cross-walk to NIST in lesson 1.8 so you can speak their language when you need to — but this is the map you’ll actually use.

What each pillar lesson will cover

The next six lessons follow the same three-question shape for each pillar:

  1. What lives here? The actual things — people, MDM enrollments, S3 buckets — that belong to this pillar.
  2. What typically goes wrong? The failure modes you’ll recognize once you’ve seen them once. Many you’ve already seen; you just didn’t have a name for them.
  3. What do mature orgs do differently? Not perfect, not everything — just the moves that separate a program that works from one that performs.

By the end of lesson 1.7 you’ll have the full map. Lesson 1.8 gives you the NIST crosswalk in a single table so you can translate on demand.

What’s not a pillar

Compliance. Compliance — SOC 2, HIPAA, PCI-DSS, GDPR — is not a pillar. It’s a lens you apply across all six. SOC 2 asks you to prove you handle People, Devices, Data, Systems, Vendors, and Incidents in specific ways. It doesn’t add a new thing; it inspects the existing six from a particular angle. Keep compliance in its place: it’s a report card, not the curriculum.