It starts with Risk - Leveling up with NIST

Why Risk Must Come First

This is the first entry in a multi-part series on building a risk-driven security program using NIST standards.

Most security programs don’t fail because teams aren’t working hard. They fail because the work isn’t anchored to risk.

WAFs get deployed. Alerts get tuned. Controls get implemented.

But without a structured understanding of what risk you’re actually trying to reduce, security becomes a collection of tasks instead of a program. A security program without risk anchoring is just activity. At its core, security exists to reduce uncertainty around bad outcomes and not to “do security things.”

Security, Explained Simply

In simple terms, security is about understanding how things fail. Think about managing water leaks in a building. You:

• Look for weak spots
• Prepare for failures you know will happen eventually
• Fix leaks when you find them
• Keep monitoring, because conditions change and even good repairs fail over time

You don't assume the problem is solved forever. This is also why outside expertise matters. Just as you'd bring in a plumber or structural expert to find hidden weaknesses or stress-test assumptions, security experts help identify where systems could break and how serious the damage might be if they do.

At its core, security is risk management:

Knowing what can go wrong, under what conditions, and how quickly you need to respond when it does.

Security is not about eliminating risk. It's about understanding and managing risk well enough to make confident decisions and enable the business.

Why NIST (and standards friends)

There are many risk management frameworks across industries and disciplines. In security, some of the most commonly referenced include: NIST, ISO, COBIT, FAIR, ISACA (links below). In this series, we'll focus primarily on NIST, with light references to ISO where it's helpful to our cause. Two ISO standards worth calling out specifically are ISO 31000 and ISO 27005. Both, but especially NIST gives us something especially valuable: a connected set of standards that span assessment, execution, and governance.

NIST Risk Standards and How They Fit Together

We'll rely on three core NIST standards to bring our story together about risk:

NIST SP 800-39 - Enterprise Risk Management - A blueprint for running risk management across the organization. It connects strategic objectives, risk tolerance, and governance to systems and operations.Practically speaking, 800-39 tells you how to run risk management across the entire organization or enterprise.

NIST SP 800-30 - Risk Assessment - A repeatable method for identifying threats, vulnerabilities, likelihood, and impact; producing risk determinations that inform decisions. Practically speaking, 800-30 tells you how to perform risk assessments that feed decisions.

NIST SP 800-37 - Risk Management Framework (RMF) - A lifecycle-based approach for managing security and privacy risk through structured steps: Prepare → Categorize → Select → Implement → Assess → Authorize → Monitor. Practically speaking, 800-37 tells you how to translate those decisions into system-level control execution and authorization.

The Correct vs Realistic Ordering

While there isn't a right or wrong way; in theory, NIST’s logical dependency order looks like this:

800-39 → 800-30 → 800-37

You define strategy and risk tolerance, assess risk, and implement controls. For a large enterprise, this is absolutely probably what is in effect. In practice, especially for startups and small to mid-sized companies, this often doesn’t work. When you’re early or rebuilding, acting quickly to gain market share, you usually don’t have enough signal to:

• Write meaningful strategy
• Define accurate KPIs
• Set realistic governance

So for this series, we’re going to intentionally flip the stack and our practical implementation order (which we'll focus on SaaS-type business) like this:

800-30 → 800-37 → 800-39

Why? Because, you can't govern risks you haven't seen, prioritize controls without understanding impact, or write strategy in a vacuum. As such, this is one of the most effective ways to bootstrap a security program without creating security theater. That said, flipping the order is a tradeoff. And ironically, tradeoffs are...well, a risk. We'll talk explicitly about how to backfill governance as scale becomes a concern.

How This Series Will Approach NIST

Here's how we'll apply the standards across the series:

Phase 1 — Risk Discovery (NIST SP 800-30)

Together, we'll start small and practical:

• Identify a top 10 risk scenarios list
• Define crown jewels and trust boundaries
• Create a few targeted threat models (e.g. identity, data flows)
• Practice writing risk statements that don't make you dread the process

In return, we'll output a small set of high-impact, high-confidence risks you can stand behind and drive an early-stage security program.

Phase 2 — Controls & Guardrails (NIST SP 800-37 + 800-53r5)

We'll use the risks identified from Phase 1 to select controls – not the other way around – an important distinction from what I feel a lot of individuals gravitate towards. We'll leverage NIST SP 800-53 Rev5 as the control catalog and map those controls into:

• Identity and access patterns
• Logging and detection baselines
• Secrets and dependency hygiene
• Backup and disaster recovery (often under-invested, especially when third-party dependencies enter the picture)
• Scanning and monitoring guardrails

In return, we'll output a realistic baseline control profile and a simple way to maintain evidence that controls function for their intended purpose.

Phase 3 — Strategy, Policy, and KPIs (NIST SP 800-39)

In Phase 3, now that we've seen real risk and potential gaps in controls we'll:

• Write strategy grounded in reality
• Define priorities based on prior risks and controls
• Create or update policies that reflect actual behavior(s)
• Establish KPIs and metrics that measure what matters right now

In return, we'll recognize that security work is interrupt-driven and flexibility matters. In Phase 3, we'll also formally define and document:

• Unacceptable outcomes (breach, fraud, outage)
• Risk tolerance (risk-averse vs. risk-accepting)
• What matters most (customer data, payment flows, production access)

This ensures formal risk assessments don't exist in a vacuum and that impact is meaningful to drive decisions and confidence.

Risk, Made Concrete

As a quick aside in our first post: a solid risk statement improves awareness, decision-making, and confidence for both security team members and business stakeholders. Having this clarity, and finding what works for you and the team, is the foundation for everything that follows.

An example risk we'll leverage throughout the series, but a teaser here:

Example: Unauthorized access to customer data due to compromised employee credentials.

Risk statement:

There is a risk that customer data could be accessed without authorization due to employee credentials being compromised, resulting in potential data exposure, loss of customer trust, regulatory consequences, and business impact.

A simple template to guide your thinking is:

There is a risk that [what could go wrong] due to [how it could happen], resulting in [why it matters to the business].

And for you long-time security folks:

There is a risk that [undesired event] could occur due to [threat exploiting vulnerability], resulting in [business impact].

Why Risk Brings the "Why"

Most leaders, especially security leaders, already know their biggest risks intuitively:

• "A breach would destroy customer trust."
• "Downtime during peak sales would hurt revenue."
• "Regulatory violations would stall long-term growth."

The problem is that intuition doesn't scale. Without formal risk framing:

• Everything is urgent (literally everything, depending on your leadership)
• Teams chase the loudest alert (let me tell you about team burnout)
• Security struggles to explain why something matters to the business (stakeholders should know why something matters)

A risk-driven program changes that. It creates a shared language between security, builders, and business leadership and ties work directly to outcomes the business cares about and will invest additional resources into.

Security teams rarely own the risk. Rather, we assess it, recommend treatments, and monitor outcomes. Risk brings the why.

What's Next

In the next article, we'll focus on finding and understanding the risks you have today grounding our process in NIST SP 800-30. And we’ll walk through the example above, plus a handful of other scenarios, step by step. Perhaps importantly, you'll notice we didn't start with controls or strategy. That was intentional.