The NIST Risk Management Framework, Explained for CEOs

The NIST Risk Management Framework, Explained for CEOs

You've probably already got AI running somewhere in your business — a chatbot answering customers, an automation sorting leads, ChatGPT drafting emails. Most business owners I talk to didn't sit down and "approve" any of this. It just started happening. That's normal. What's not fine is not knowing what's actually at risk, or who's supposed to be watching it.

What the NIST Risk Management Framework Actually Is

The Risk Management Framework, or RMF, comes from NIST — the U.S. National Institute of Standards and Technology. It was built for federal agencies, and no law says a private company has to use it. But it became something bigger than a rule: it's the standard that serious companies, auditors, and international clients use to check if a business really manages risk, or just says it does.

The framework has seven steps: Prepare, Categorize, Select, Implement, Assess, Authorize, and Monitor. In simple words: you get organized and decide who's in charge, you figure out what's really at stake in each tool you use, you decide what protection that risk needs, you put it in place, you check that it actually works, you make a real decision about the risk you're accepting, and you keep watching — not just once, but as an ongoing habit.

Why I'm not giving you a checklist

I could hand you a simple checklist with these seven steps and call it a day. I won't, and here's why: a checklist you run on your own, without someone who knows your contracts and your actual operation, gives you the feeling of being covered — not the real thing. That's worse than knowing you have a gap, because it stops you from looking for it. The distance between "we checked the boxes" and "I can actually explain this decision if someone asks me" — that's where the real work happens.

Why This Matters Even More If You're Bilingual, Running a Bilingual Business

Here's something most consultants writing about this framework never mention: if you run a business between two languages and two ways of doing things — which is exactly how business works in Miami — the risk isn't just technical. It's also about who understood what, and in which language. A vendor contract written only in English, reviewed only by someone who thinks only in English, can miss exactly the kind of thing that matters to how you actually run your company. I work in English and Spanish, so nothing gets lost in translation between what your accountant tells you, what your team understands, and what actually ends up in a contract.

Where the Federal Version Breaks for a Company Your Size

NIST built this framework assuming a company with a security team, a compliance officer, and enough people to run all seven steps as separate jobs. You don't have that, and you don't need to build it to get real value from the thinking behind it. What you need is someone who can take that enterprise-level logic and turn it into decisions your actual team can own — without pretending you have resources you don't have. That translation is the real work. It's also where generic templates fail: they're written for a company three times your size.

The Risk Most Business Owners Adopting AI Are Missing

Almost every conversation about AI starts as a tech question — which tool, which vendor, how fast can we roll it out. It should start as a governance question. What data does this tool touch? Who said yes to using it? What does your contract with that vendor actually say if something goes wrong? If a client asked you tomorrow to show them how you manage that risk, could you show them anything real?

That last question is where operations and legal stop being two separate conversations. Figuring out what's at risk — step two in the framework — isn't just a tech exercise. It's a legal one too. What you're exposed to depends on your contracts and how you handle data, not just which tool you picked.

What This Looks Like Built for Your Business, Not a Federal Agency

This is the part that doesn't fit in a blog post, because it's not meant to be generic. I take the logic behind frameworks like this one and rebuild it at the size of a real business — combining the operational side (who's responsible for what, what gets checked, how often) with the legal side (what your contracts actually protect you from, and what they don't). What you end up with isn't a binder nobody reads. It's a handful of clear decisions you could actually explain if someone asked.

Before You Build Anything

A few questions worth sitting with before you hire anyone — me included — to help with this:

• Can you name, right now, every AI tool touching your customers' or employees' information?

• Is there one person responsible for approving a new AI vendor, or does it just happen?

• If a client asked you to show them how you manage that risk, would you have anything real to show them?

If any of those made you pause, that's your real starting point — not a framework, not a template. A decision about who's going to own this before it ends up owning you.

Schedule a session →

María Alejandra Tuozzo

Attorney | Operational Structure Consultant