AI governance for state, local & SMB. A practical crosswalk.
The frameworks for governing AI exist. They were written for organizations with general counsel, dedicated compliance teams, and budget. This page translates them — NIST AI RMF, ISO/IEC 42001, and Virginia Executive Order 30 — into one-page artifacts a county IT department or a 40-person SMB can actually run.
The problem we're actually solving.
A school district uses a large language model to triage parent emails. A county HR office runs an AI screening tool on resumes. A 40-person manufacturer pilots generative AI for proposal writing. None of these organizations are subject to federal AI mandates. None of them have a Chief AI Officer. None of them have a budget line item for "AI governance." But all of them are being asked — by procurement officers, board members, parents, and customers — to explain what controls they have in place.
The result is predictable. Most adopt AI tools without governance, get burned, and either freeze adoption or carry hidden liability. The third path — deliberate adoption with lightweight governance — exists, but it requires translating frameworks built for very different organizations into something a four-person IT shop can actually run on a Tuesday morning.
That's what this page does. It maps the NIST AI Risk Management Framework — the U.S.-domiciled, voluntary, sector-agnostic standard everyone should already know about — to ISO/IEC 42001:2023, the international management-system standard we use as our implementation framework. It strips the consulting-speak. It gives concrete examples of what each piece looks like in a state agency or an SMB. And it does not pretend that any of this requires a $50,000 audit to be useful.
The three reference points.
NIST AI RMF 1.0 — the framework you should be using
The National Institute of Standards and Technology's AI Risk Management Framework, version 1.0, is the closest thing the United States has to a national AI governance standard. It is voluntary, vendor-neutral, sector-agnostic, and built around four functions: GOVERN, MAP, MEASURE, MANAGE. It's the framework every state procurement officer, every responsible-AI policy team, and every audit firm references first.
For state and local government: it's the default reference if your state IT policy doesn't already point somewhere specific. For SMBs: it's what your enterprise customers and partner contracts are starting to ask about — sometimes by name, sometimes phrased as "your AI risk management program."
Virginia Executive Order 30 — the operative state instrument
On January 18, 2024, Governor Glenn Youngkin signed Executive Order 30, "Establishing Additional Safeguards for the Use of Artificial Intelligence in the Commonwealth." EO 30 created a Virginia-specific AI compliance regime that today applies to every executive branch agency in the Commonwealth and every vendor that sells AI into one. It is commonly mis-cited as "Executive Directive 1" — the operative instrument is EO 30.
EO 30 contains five directives. As of mid-2026, three are fully operational, one is in successor work under the Spanberger administration, and one is established and active:
2. AI Information Technology Standard (via VITA) — EA-225 Enterprise Solutions Architecture for AI, v1.2, published November 16, 2023. Conformance with Commonwealth security standards, decision-path logging, performance and accuracy monitoring thresholds. Applies to standalone, embedded, generative, internally developed, third-party, and procured AI.
3. AI Education Guidelines — Guidelines for AI Integration Throughout Education in Virginia, 2024. Applies to K–12, the Virginia Community College System, and SCHEV-covered institutions.
4. AI Standards for executive-branch law enforcement — successor work advanced by Governor Spanberger's February 4, 2026 Executive Order and Directive after the original October 2024 deadline lapsed.
5. AI Task Force — established October 2024.
The procurement angle is the part most vendors miss: the VITA Policy Standard explicitly extends to procurement of AI applications. A vendor selling AI into Commonwealth agencies inherits EO 30 obligations through solicitation language, evaluation criteria, and contract terms. If you are responding to an eVA solicitation or a cooperative master agreement (such as the Henrico / GovMVMT cooperative), this is your applicable regime.
VA Executive Order 51 — agentic-AI awareness
In 2025, Governor Youngkin signed Executive Order 51, establishing an agentic-AI regulatory review pilot for the Commonwealth. EO 51 does not currently create vendor compliance obligations the way EO 30 does — but if your organization is deploying or piloting agentic AI (multi-step autonomous systems, not just single-call generative tools), it belongs on your awareness radar. We track it as a watch item in every Virginia engagement.
Beyond Virginia
Our methodology and extraction tooling support multi-state AI executive-order scope where engagements require it — currently Virginia, Maryland, North Carolina, and Tennessee. Each state's regime is mapped against the same NIST AI RMF backbone, with state-specific overlays loaded only when the client's jurisdictions require them. Virginia is our anchor. The rest are supported on demand.
ISO/IEC 42001:2023 — our implementation framework
ISO/IEC 42001:2023 is the international management-system standard for AI. Where NIST AI RMF tells you what to think about, ISO 42001 tells you how to build the organization that handles it — policy, leadership, roles, risk treatment, internal audit, continual improvement. It uses the same Plan-Do-Check-Act backbone as the ISO 9001 quality standard most operations teams have seen before.
The crosswalk.
Each row pairs a NIST AI RMF subcategory with the ISO 42001 clause that operationalizes it, then translates both into a concrete artifact or practice a state, local, or SMB organization can actually adopt. We've stripped the federal-mandate language and replaced it with what the work looks like on a Tuesday morning in a real organization.
GOVERN — establishing the culture and structure
The GOVERN function underpins everything else. It is about who decides, who owns the risk, and what gets written down. ISO 42001's leadership and support clauses (5 through 7) provide the formal structure.
| NIST AI RMF | ISO 42001 Clause | What this looks like in practice |
|---|---|---|
| GOVERN 1.1 Policies, processes, and procedures for AI risk are established and managed |
Clauses 5, 6, 7 Leadership · Planning · Support |
A two-to-three-page AI Acceptable Use Policy that says what your team can and can't do with ChatGPT, Claude, Copilot, and similar tools — and who decides when a new use case shows up. For a 30-person nonprofit: two meetings and a Google Doc. For a county IT department: a board-adopted policy procurement can hand to vendors. |
| GOVERN 1.2 Accountability and responsibility are established |
Clause 5.3 Roles & authorities |
Name one person who is responsible for AI decisions. Not a committee. One human, with their name in the policy, who signs off on new use cases. This is the single highest-leverage governance move and it costs nothing. |
| GOVERN 1.3 Workforce is trained in AI risk management |
Clauses 7.2, 7.3 Competence · Awareness |
A 45-minute internal session twice a year on what's allowed, what's not, and what to do when something looks off. Recorded, captioned, available on the intranet. For SMBs: include it in onboarding. |
| GOVERN 1.4 A culture of AI risk management is promoted |
Clauses 5.1, 10 Leadership commitment · Improvement |
The agency director or company head says the words "AI governance" in public, in writing, twice a year. Cultures do not form from policies; they form from repeated leadership statements. This is the cheapest part of the work and the part most often skipped. |
MAP — understanding the systems you actually have
Most organizations cannot list every place AI is being used inside their walls. The MAP function fixes that. ISO 42001's context and risk-assessment clauses (4 and 8.2) give the formal structure.
| NIST AI RMF | ISO 42001 Clause | What this looks like in practice |
|---|---|---|
| MAP 1.1 Context is established and understood |
Clauses 4.1, 4.2 Organizational context · Interested parties |
A one-page use-case inventory: who uses AI in your organization, what for, with what data, who depends on the outputs, and who could be harmed if it goes wrong. Updated once a quarter. Lives in the same drive folder as the AUP. |
| MAP 1.2 Categorization of the AI system is performed |
Annex A.2.2 AI system impact assessment |
A simple tier list. Tier 1: drafting and internal-only use. Tier 2: customer- or constituent-facing, or influences a human decision. Tier 3: automated decisions affecting people's rights, money, or access. Most state and local entities will have only Tier 1 and 2. Most SMBs will have only Tier 1. |
| MAP 1.3 Capabilities, applications, intended and unintended uses are understood |
Clause 8.2 AI risk assessment |
For each Tier 2 or Tier 3 system, write down three things: (a) what it's supposed to do, (b) what it might accidentally do, and (c) what would have to be true for that accident to actually matter. That is the entire AI risk-assessment process for the vast majority of state, local, and SMB organizations. |
MEASURE — knowing whether it's working
Measurement is where most AI governance programs collapse — not because measurement is hard, but because nobody decided in advance what "good enough" looks like. ISO 42001 Clause 9 and Annex A.5 provide the structure.
| NIST AI RMF | ISO 42001 Clause | What this looks like in practice |
|---|---|---|
| MEASURE 1.1 Appropriate methods and metrics are applied |
Clause 9.1 Annex A.5 — Testing, validation, verification |
For each Tier 2+ system, pick two metrics. Accuracy is one. The second is whichever trustworthiness characteristic matters most for the use case — fairness for HR tools, reliability for citizen-facing chatbots, explainability for decision-support. |
| MEASURE 1.2 Performance is tracked over time |
Annex A.4.2.4 Monitoring |
Once a quarter, somebody runs the same ten test prompts through your AI system and compares results to last quarter. Drift shows up in the first comparison. This single practice would have caught half of the public AI-failure stories of the past three years. |
| MEASURE 1.3 Rigorous testing practices are used |
Annex A.5 | Before any Tier 2+ rollout: a one-page written test plan that defines what "good enough" looks like. If you cannot define it in a paragraph, you are not ready to roll the system out. |
| MEASURE 1.4 Mechanisms for tracking identified AI risks are used |
Clauses 8.2, 8.3 Risk assessment & treatment |
A shared spreadsheet titled AI Risk Register. Five columns: Risk, Likelihood, Impact, What we're doing about it, Owner. The format matters less than the existence of the file and the cadence of updating it. |
MANAGE — acting on what you measured
Measurement without action is theater. The MANAGE function ties everything together: prioritization, treatment, incident response, and the steady rhythm of improvement. ISO 42001 Clauses 8.3, 9, and 10 carry the load.
| NIST AI RMF | ISO 42001 Clause | What this looks like in practice |
|---|---|---|
| MANAGE 1.1 Risks are prioritized by likelihood and impact |
Clause 8.3 AI risk treatment |
Rank everything in the AI Risk Register. The top three get a written treatment plan this quarter. The rest get reviewed next quarter. Repeat. |
| MANAGE 1.2 Risk treatment plans are implemented |
Clause 8.3 · Annex A controls | Pick one Annex A control area to operationalize this quarter — usually data quality (A.3) or transparency (A.6) is the highest-leverage starting point for state, local, and SMB organizations. |
| MANAGE 1.3 A process for responding to and recovering from AI incidents is in place |
Annex A.9.5 Incident management |
A one-paragraph procedure: if an AI system produces an output that causes harm or appears to violate policy, here's the phone tree, here's how we pause the system, here's who decides when to restart it. Walked through once a year. Most organizations have a security incident plan and assume it covers AI; it usually doesn't. |
| MANAGE 1.4 AI systems are regularly monitored and improved |
Clauses 9, 10 Performance evaluation · Improvement |
A standing 30-minute meeting once a quarter. Same agenda every time: What's new on the use-case inventory? What did the Risk Register surface? Any incidents? What's the priority for next quarter? Half an hour, four times a year, is enough to run a credible AI governance program at this scale. |
How we implement this.
Every 12th House AI Readiness Engagement is organized around three phases, anchored in the ISO 42001 clause structure. The artifacts above — the AUP, the named owner, the use-case inventory, the risk register, the test plans, the incident procedure, the quarterly review — are the deliverables. The phases are how we get there without bringing your operations to a halt.
Governance Foundation
Establish the AI governance baseline before configuring a single AI tool.
- Written AI Acceptable Use Policy ready for leadership adoption
- Named AI risk owner with documented authority
- 3–5 person AI steering group (not 12)
- Initial risk-tier categorization for every AI use case currently in flight
Risk Mapping & Measurement
Document every AI use case, generate the artifacts you'll need when procurement asks, and stand up lightweight monitoring.
- Use-case inventory with intended use, data flows, and owners
- AI risk register with top 3 risks under written treatment
- Quarterly performance-monitoring template for Tier 2+ systems
- Draft incident response procedure
Continual Improvement
Turn the artifacts into a working program your team can run without us.
- Quarterly AI Business Review structure (30 minutes, 4 questions)
- Internal-audit cadence calibrated to your size and risk profile
- Risk-register and use-case-inventory hygiene practices
- Handoff documentation
Most state and local clients complete Phases 1 and 2 within six weeks. Most SMB clients complete them in three to four. Phase 3 is optional and designed to be self-sufficient — we structure the program so your team can run it without retaining us indefinitely. That's a deliberate choice. We would rather you run a credible governance program for ten years than depend on us for one.
About 12th House AI
12th House AI, LLC is a veteran-owned Virginia firm specializing in AI readiness and governance for state and local government, nonprofits, and SMBs. We use the NIST AI Risk Management Framework as our reference standard and ISO/IEC 42001:2023 as our implementation framework.
Our founder, Brannon J. Solomon, holds an Active DoD Secret clearance and brings eight-plus years of enterprise systems experience — depth we use to translate complex compliance frameworks into one-page artifacts your team can actually run. We are based in Hampton Roads and serve Virginia first, with engagements available nationwide.
We are not ISO 42001 certified and we are not pursuing certification. The framework is what's valuable to our clients; the audit is what's expensive. Most organizations don't need the audit. They need the structure.
Our extraction tooling is vendor-neutral by design. We do not recommend specific AI products or platforms unless you have already named them in your environment. The output you receive is anchored in your own language and the published frameworks — not in any vendor's marketing.
Want to see what this would look like for your organization?
The intake takes about three minutes. We send back a tailored readiness brief within 24–48 hours — no pitch deck, no commitment, no consulting-speak.
Begin the assessment →