Build a compliance operating system with NIST CSF 2.0

A hospital network wants to store its imaging archive on Pied Piper. Before anyone signs, the hospital’s security team sends Richard Hendricks a questionnaire: how do you secure the software we’re about to depend on?

Richard needs an answer. His engineers need something more useful than “go implement a compliance framework.” They need to know what applies, what work is necessary, who owns it, and how to keep it working as the company changes.

That is the job of a compliance operating system: the people, practices and evidence that make your commitments part of everyday work.

On the Autom8 YouTube channel, we introduced a four-stage approach to building one: understand, establish, adapt and rethink. Here we put those stages to work against a real framework, the US National Institute of Standards and Technology’s Cybersecurity Framework, version 2.0.¹ That’s a mouthful, so from here on we’ll call it NIST CSF, or just CSF. By the end, you’ll have a workbook tailored to your organization that holds the whole thing together.

Why NIST CSF?

NIST publishes CSF 2.0 for free, and it describes cybersecurity outcomes without prescribing a technology or a vendor. That makes it a good translator between what your customers expect and the work your engineers actually do.

You can read the whole framework as a PDF from NIST, or browse it with the tools on NIST’s Cybersecurity Framework site. We link back to the source every time we lean on it.

Meet Pied Piper

Our example company is borrowed, affectionately, from HBO’s Silicon Valley. In this story Pied Piper is a small B2B platform: customers upload files through an API, and Pied Piper compresses and stores them in a public cloud. Two engineering teams ship changes through a deployment pipeline. Everything about its security setup is invented for this article.

We’ll follow one slice of their work: software delivery and vulnerability management. That isn’t a complete security baseline. Identity, data protection, suppliers, detection, incident response and recovery all need their own look. A focused start makes the rest of the work visible.

Before anyone picks a tool or adds a ticket to the roadmap, Richard pulls Jared, Dinesh and Gilfoyle into a room. They work through three questions:

1. 01What assurance are customers actually asking for?The hospital wants its questionnaire answered now, and may ask for a SOC 2 report next year.
2. 02What applies through law or regulation?Health data could bring privacy and sector rules into play. Jared books time with counsel.
3. 03What has Pied Piper already promised in contracts?Jared pulls every signed agreement with a security clause in it.

The framework has an outcome for exactly this work. GV.OC-03 asks you to understand and manage the legal, regulatory and contractual requirements that apply to you. Notice what it leaves out: picking a framework doesn’t answer Richard’s three questions. Jared still has to find the commitments, and the people qualified to interpret them.

Learn how the framework thinks

It’s tempting to treat CSF as a checklist: find the rows, tick the boxes, move on. Resist that. The framework carries a way of thinking about security, and once your team shares it, every interpretation you make later gets easier to explain and defend. Three ideas do most of the work:

• It describes results, not implementations. CSF says what should be true and leaves the how to you. That’s why Pied Piper can meet it with the tools it already has.
• Its six Functions run at the same time. They aren’t phases you finish one after another. Govern sets direction for the other five, continuously.
• Its outcomes nest. Each Function holds Categories, and each Category holds the specific outcomes you’ll work with. The outcome codes tell you exactly where each one sits.

Those six Functions belong to NIST. Our four stages sit alongside them, not inside them: the Functions describe what good security covers, and the stages describe how you work with a framework over time. Pied Piper’s slice lives mostly in Govern, Identify and Protect.

Draw the boundary

Next, the team decides what exactly they’re assessing. They start with the thing the hospital is buying and work outward. Scroll to follow along.

While they draw, Richard asks a second question: when we launch the next product, how much of this will we have to do again? The team keeps this boundary tight, but notes the pieces, like the pipeline and single sign-on, that could serve more than one product later.

Translate one outcome

With the boundary drawn, Dinesh picks one outcome and turns it into something his team can act on: PR.PS-06, the framework’s outcome for secure software development. You can look up any outcome in NIST’s free CSF 2.0 Reference Tool² or in Appendix A of the CSF 2.0 PDF.¹ Step through Dinesh’s record with him.

Find the simplest faithful reading

That blank target state is the most important field on the record, and the step teams skip most often. Dinesh and Gilfoyle each draft what PR.PS-06 should mean in practice. Richard asks Monica to pressure-test both. She runs every draft through the same three tests.

Dinesh’s draft is too vague to test. Gilfoyle’s is faithful but so heavy that two small teams would start routing around it within a month. Monica’s version is mostly what they already do, applied to every path and checked regularly.

She adds a caveat: compare context before you copy anyone’s answer, hers included. Customer data, architecture, contracts and risk vary between companies. Where the team still disagrees, they take the question to someone qualified to settle it: security, legal, privacy or an assurance specialist.

From Current Profile to Target Profile

Monica’s version gives Dinesh what his record was missing: a target he can describe in practices, not adjectives. NIST has names for both ends. Your Current Profile describes where you stand today against the outcomes you’ve chosen. Your Target Profile describes where you intend to be. The work you and your team do to set up your compliance operating system is the bridge from one to the other. For PR.PS-06, Pied Piper’s bridge looks like this:

Dinesh copies the right-hand column into his record’s target state, and each row becomes work with an owner. If you want NIST’s own format, it publishes guidance and a template for Organizational Profiles.³ The workbook at the end of this article adds the working records around it: controls, evidence, actions and decisions.

Pied Piper now knows what needs to be true. Stage two is about making it true, every week, without anyone having to remember. That’s the job of a control: a safeguard or repeatable activity that gets you to an outcome. Dinesh writes the first one in his own words.

C-01 · CONTROLLED SOFTWARE DELIVERYPIED PIPERChanges affecting the production service are assessed for risk, reviewed, tested, and deployed through an authorized path. Emergency changes use a defined exception route and subsequent review.

Those words are Pied Piper’s design choice, not a quote from NIST. Next Dinesh has to show which outcomes C-01 helps with, and be honest about how much. Linking the two is called control mapping. Pick an outcome below to see where C-01’s help runs out.

Every link is partial, and that’s fine. One control can support several outcomes, and one outcome may need several controls. Writing down the limits is what makes the map useful: when a new framework arrives, these shared practices give you something to map against, but a similar-sounding label still isn’t proof of the same coverage.

Adobe shows how far this idea scales. To build its Common Controls Framework, it analysed the certifications its cloud business needed and rationalized more than 4,300 requirements, across more than 20 standards, into a few hundred controls of its own.⁵ It has since mapped those controls to NIST CSF too.⁶

Pied Piper won’t need hundreds of controls. The principle is the same at any size: write each control once, map it honestly, and reuse it.

Make the control operate

A control statement on its own does nothing. Four pieces make C-01 run. Follow one of Dinesh’s changes, a faster upload endpoint, as you scroll.

The four pieces relate more than they stack. One policy can govern several controls, and one evidence source can serve several checks.

Add a second control

Gilfoyle takes the vulnerabilities. His control reads:

C-02 · VULNERABILITY IDENTIFICATION AND RESPONSEPIED PIPERVulnerabilities in the service’s inventoried software and dependencies are identified, validated, and prioritized by risk. Remediation or a time-limited authorized exception is tracked to an owner, and the resulting change is verified.

C-02 supports three of the framework’s outcomes, each in part:

• ID.RA-01finding, confirming and recording vulnerabilities
• PR.PS-02keeping software maintained
• ID.RA-07tracking exceptions when a fix has to wait

CSF won’t hand Gilfoyle a remediation deadline, so he has to propose response targets and who can approve an exception. A scanner alone won’t catch vulnerability reports from outside, either; that intake needs its own process. And a single fix now ties both controls together: C-02 finds and tracks the problem, and C-01 governs the change that solves it.

Collect evidence as the work happens

A month in, Richard wants to know whether C-01 is actually working. Gilfoyle goes looking.

The lesson isn’t about how many records to check. Before you check any, make sure you know the full population: every relevant change in scope for the period. A sample only tells you something once the population is complete. However tidy, 48 records can’t prove that an unknown path is covered.

So Pied Piper changes its routine:

• Every month, reconcile pipeline records against the cloud activity log.
• Investigate every difference, and keep what you find.
• Automate collection where you can, then check that the automation still runs. A broken integration can quietly stop producing evidence you thought you had.

If an external audit comes later, the auditor decides what evidence and sampling that engagement needs. A clean routine makes that conversation much shorter.

Make gaps useful

The build server’s two hotfixes are a gap, and Richard is glad to know about them. A dashboard should help you act, so Pied Piper keeps four states apart:

A green cell isn’t proof, and a discovered gap is useful information. Aaron Verones has led engineering at several startups through their compliance work. When I interviewed him for our YouTube channel,⁸ he described finding missing historical communications at one of them. His team fixed the process and explained the gap. They couldn’t recreate work that had never happened.

At Pied Piper’s size, named people and a reliable manual routine are a sensible start. As you grow, GRC (governance, risk and compliance) software can connect mappings, owners, evidence and follow-ups for you. Someone still needs to understand how the pieces relate.

Gilfoyle moves the compression worker into containers. Pied Piper’s vulnerability procedure still describes patching virtual machines. Copy it across and you miss part of the job: building a patched image isn’t the same as replacing the vulnerable one in production.

The expectation in C-02 stays exactly the same. The procedure beneath it changes. Switch between workload types to compare:

“Managed” isn’t a complete answer to who does what, either. Gilfoyle writes down who handles each layer:

• application dependencies and container images
• worker-node updates and cluster versions
• components the cloud provider operates

Before claiming the new worker is covered, he records its inventory, owner, procedure and evidence source. Generic control wording makes reuse possible, but it doesn’t prove a new service is covered, and it doesn’t stretch a SOC 2 report or a certification to include it.

The same reuse helps when the business takes on a new standard rather than a new architecture. Adobe maps each new standard to the controls it already runs and builds only what’s missing.⁶ When the hospital asks for a SOC 2 report next year, Pied Piper will start by mapping it to C-01 and C-02.

Separate the release condition from the roadmap

On an enterprise modernization project I describe on our YouTube channel, we faced eight months of estimated compliance work with three months to reach a releasable state. Some of it addressed real gaps. Some came from controls built around the architecture we were leaving behind. We grouped the work, brought in outside help, and reached a releasable state with real tradeoffs on the longer-term roadmap.

The lesson: separate meeting an obligation from meeting it at maximum maturity. Here’s how that plays out for the new worker:

Engineering and InfoSec need both: a straightforward path for new technology, and a credible place for security improvements on the roadmap. Without the second, engineering promises improvements that never get prioritized, and InfoSec has every reason to demand everything at the production gate. That burden discourages exactly the modernization the business needs. Give improvements owners, capacity and dates, then follow through.

Choose assurance partners who understand the systems they evaluate. Aaron’s advice from the same interview is to interview potential auditors for technical and business understanding. Their judgment stays independent, and the conversation gets better.

Pied Piper starts using AI to write code. Dinesh’s pull requests now arrive faster than anyone can review them, and he suggests replacing the reviewer with another agent. Before agreeing, Richard asks what the approval was supposed to establish in the first place.

Compliance people talk about the letter and the spirit of a requirement. The letter is the exact wording, such as “every change is reviewed by someone other than its author.” The spirit is the reason behind it: someone independent confirmed the change was correct, safe and intended. When an old method stops scaling, the spirit tells you what a replacement has to achieve.

So Richard breaks the reviewer’s job into its parts. A new tool may help with some without covering all of them. Try assigning each one:

The spirit helps you choose a workable method. It never cancels the letter: if a contract says a human reviews every change, a human still does, and the AI helps them do it well.

Evaluate before you change the gate

Instead of declaring the new process compliant, Richard asks Dinesh to write it up as a proposal:

ASSUMPTION

Human review supplies the scrutiny and authorization production changes need.

PROPOSAL

AI assists with analysis and testing. A named human keeps production authorization.

EVALUATION

Run the new checks alongside existing review for a bounded set of changes, including security-sensitive ones like customer-data access. Look for missed issues, disagreements, overrides and false confidence.

DECISION

Set acceptance criteria before judging results. Record what the checks establish, what they don’t, who is accountable, and what triggers a rollback.

Gilfoyle adds a question of his own: what can the agents reach? Customer data, credentials, review settings and deployment permissions all need checking. An agent that can change the checks used to approve its own work needs particular scrutiny. NIST’s Secure Software Development Framework⁴ offers more practices for secure development, but neither it nor CSF shows that a particular AI reviewer is effective. Where assurance is involved, bring the proposal and its evidence to your auditors early.

Use AI to do more of the security work

Rethinking should open doors too. Here’s Gilfoyle using an AI assistant on a real piece of compliance work: the container version of C-02’s procedure from the Adapt stage.

The same pattern works elsewhere. AI can prepare dependency updates, suggest interpretations with links to the source, or build evidence collection. In every case people still verify the sources, tests, coverage and behaviour. Faster delivery helps when the company can still explain why a change is safe enough, and stand behind it.