Not understanding the risk is how you get a raccoon in your tent

At summer camp, we told our Scouts not to keep any food in their tents – a simple, firm, and clearly communicated rule. But we never explained why - that it would help to keep the wildlife at bay. So when one Scout decided to stash a bag of chips beside his sleeping bag, it wasn’t out of carelessness; it was out of convenience.

Around 2 a.m., the consequence arrived. The Scout woke to the sound of rustling and found a raccoon halfway inside his tent – nose-deep in that forbidden snack.

He didn’t ignore the rule to be careless; he ignored it because he didn’t understand why it mattered.

Most organizations do the same thing with risk. Teams follow frameworks and compliance checklists without grasping the real dangers those rules are meant to prevent. And eventually, something unwanted wanders in.

That pattern reveals a deeper issue. If teams don’t understand why the rules exist, their assessments become mechanical rather than meaningful. They end up measuring progress against checklists instead of exposure to risk. That’s why so many so-called “risk assessments” never actually tell you what your risks are. Too often, organizations are measuring compliance, not exposure–checking how closely they align with frameworks instead of asking what could actually go wrong.

A framework can tell you to keep food out of the tent. A risk assessment explains what happens when you don’t – and why the raccoon shows up in the first place.

Frameworks vs. Risk Assessments

When conducting assessments, many organizations rely on two main types of inputs: regulatory requirements and industry best practice frameworks – such as NIST CSF, ISO 27001, COBIT, and ITIL. Both are invaluable, but they serve distinct roles. Regulatory requirements are mandatory and set the minimum baseline for safe and sound operation – the rules everyone must follow. Frameworks, meanwhile, are generally voluntary and provide scalable guidance on how to design and implement processes or controls. They help organizations assess maturity and consistency but don’t prescribe the right level of implementation for every environment.

Assessing compliance with either frameworks or regulations is not, and will never be, a true risk assessment. Both can guide and inform risk thinking, but they don’t replace the process of identifying, analyzing, and evaluating risk itself.

• A framework or regulatory assessment evaluates alignment with standards or expectations. It asks, Are we doing what’s required or expected?

• A risk assessment, on the other hand, identifies potential events that could threaten your objectives. It asks, What could go wrong, and how much does it matter?

When organizations rely solely on framework or regulatory assessments as their proxy for risk, they end up with maturity scores instead of insight. They know how compliant they are – but not how exposed. Regulators reference frameworks because they establish a common baseline, but they still expect organizations to extend beyond them, assessing their unique risk context and addressing exposures that standardized requirements may not cover.

For example, the NIST CSF’s “Access Control” category highlights identity management, but only a risk assessment will tell you whether credential misuse is actually a top concern for your organization.

Why This Matters

Regulators are catching on. The New York Department of Financial Services (NYDFS) now explicitly requires risk-based assessments under its Part 500 cybersecurity regulation. That means understanding actual risk, not just framework alignment.

Frameworks are, by nature, reactionary. They codify lessons learned from past failures – someone else’s raccoon, so to speak. But they don’t tell you whether that same threat applies to your tent, your terrain, or your food storage habits – or whether the danger you face looks more like a curious raccoon or a determined bear.

Starting with a framework or regulation is fine – in fact, it’s smart. It helps identify where risk likely exists. But it’s only a starting point. Every organization must still ask: What are the risks that aren’t covered here? and How severe could they be in our context? Without connecting frameworks and regulations to their underlying risks, organizations risk missing the point entirely. The result isn’t just wasted effort – it’s a false sense of security. Teams may believe they’ve met expectations when in reality, they’ve only demonstrated process compliance. True assurance comes from understanding whether those controls actually and meaningfully mitigate risk.

The consequences of that misunderstanding are real. Compliance gaps can lead to penalties, but unmitigated risks can lead to breaches, outages, and reputational damage. Checking boxes may satisfy an auditor, but it won’t stop a determined adversary or prevent the next operational failure.

The “Why” Behind Every Control

Years ago, back when I was also helping to support Internal Audit work, I was auditing a client’s Sarbanes-Oxley compliance and they had a user termination control that routinely failed testing. I asked the client why they thought they were supposed to perform the failing control.

Their answer: Because you told us we had to.

That moment stuck with me. The problem wasn’t their process – it was the lack of understanding behind it. They didn’t recognize that the control existed to prevent lingering access risks that could lead to fraud or data exposure. They were following the rule, not managing the risk.

When teams understand the why, behavior changes. They adapt controls intelligently instead of performing them mechanically. That understanding also increases engagement: people take ownership of controls when they know how their actions protect the organization.

Building True Risk Awareness

To move from framework compliance to risk understanding:

1. Use the regulation or framework to find the risks that need to be assessed, then ask what could go wrong that the framework might not cover.

2. Translate control objectives into risk statements. Consider whether you can define what every control prevents, detects, or monitors.

3. Engage the people behind the process. Explain why controls exist, not just how to execute them. When teams understand the intent behind controls, they become your first line of defense.

4. Connect to tolerance. Define what “acceptable” risk looks like for your organization, and use that to shape investment and prioritization decisions. Tolerance (or appetite) sets the boundary between comfort and concern.

5. Review continuously. Risk evolves faster than regulations.

Regulations and frameworks will always matter. They outline the terrain and provide a shared map to guide how we navigate complex landscapes. But they can’t tell us which paths are safe, which are risky, or which are no longer relevant.

In the end, frameworks and regulations keep us compliant and organized – but understanding risk keeps us secure. Risk assessments fill that gap by revealing what’s actually at stake. They help organizations look past the checklist to understand the real threats to their mission, their customers, and their reputation.

And if your teams don’t understand why the rules exist, sooner or later the raccoon will show up to remind them.