RMFInsider

AI security skills for GRC and ISSO roles in 2026 are no longer a specialty niche you can defer to the “AI team.” AI systems are showing up inside RMF packages right now — a gen-AI assistant bolted onto an existing boundary, a fine-tuned predictive model feeding a mission dashboard — and someone on the ISSO or GRC side has to be able to assess it. This post lays out the concrete skills worth building this year, tied directly to the frameworks that are already shaping how these systems get authorized.

Why This Isn’t Optional Anymore

Two things are happening at the same time. First, mission and program teams are adopting AI faster than the control frameworks can formally catch up — NIST’s control overlays for AI systems are still in draft, and DoD’s dedicated AI authorization path is still maturing. Second, ISSOs and GRC analysts are the ones getting asked to assess these systems anyway, because the AO still needs a body of evidence before signing anything. Waiting for a finished framework before building AI competency means showing up unprepared to the assessments happening today.

The Six AI Security Skills for GRC and ISSO Roles

Before going deep on each one, here is the short list. These are not abstract “AI literacy” skills — each one maps to a real gap ISSOs and GRC analysts are running into on live packages right now.

Skill	Why it matters now
Categorizing AI systems correctly	Determines which risk questions and eventual overlay apply
Working the Assess Only / infrastructure ATO split	Keeps model risk and infrastructure risk from getting tangled in one package
Model and training data provenance documentation	Assessors ask for this regardless of whether a formal control number exists yet
CSRMC continuous monitoring fluency	Frequently-updating models cannot be reassessed manually every cycle
Vendor and third-party AI risk assessment	Most gen-AI tools are commercial models wrapped in an agency interface
Writing tailoring rationale that survives an overlay update	Saves a redesign when the finished COSAiS overlay publishes

Skill 1: Categorizing AI Systems Correctly

NIST’s Control Overlays for Securing AI Systems (COSAiS) project breaks AI systems into five use cases: generative AI assistants, fine-tuning predictive AI, single-agent systems, multi-agent systems, and developing AI systems from scratch. Each one carries a different risk profile and, eventually, a different control overlay. Full details on where each overlay stands in the publication process are in NIST COSAiS Explained: The AI Control Overlays Coming to 800-53.

The practical skill here is not memorizing the five categories — it is being able to look at a system a mission team wants to field and correctly identify which category it falls into, because that determines what questions you need to be asking. A team fine-tuning a predictive model on operational data has completely different data-provenance and drift risks than a team standing up a gen-AI assistant on top of a commercial foundation model they never touched.

Skill 2: Working the Assess Only / Infrastructure ATO Split

DoD’s current approach to AI system authorization splits the work into two parallel tracks: the AI model itself goes through the “Assess Only” construct under the DoD AI Cybersecurity Risk Management Tailoring Guide, while the hosting infrastructure gets authorized separately through traditional RMF or cATO. The full mechanics are covered in how to get an ATO for an AI system in DoD. An ISSO who does not understand this split will either try to cram model-specific risk questions into an infrastructure ATO package where they do not belong, or miss model risk entirely because it “isn’t part of the ATO.”

The skill to build: knowing how to scope a package so model performance evidence and infrastructure control evidence stay organized separately, and knowing which questions belong to which track when an AO asks for status.

Skill 3: Model and Training Data Provenance Documentation

This is the skill that translates most directly from traditional GRC work but with a new subject. Where you used to document software supply chain and configuration baselines, you now need to document where training data came from, whether it was validated for integrity and bias, and how a model gets updated over time. If a fine-tuned model gets pushed as an update, that update needs the same root-cause-analysis and integrity discipline that any software deployment does — this is exactly the kind of accountability the newer 800-53 control additions around secure software updates are pushing toward. Build the habit now of asking mission teams for a data lineage record before you ever see a control assessment request.

Skill 4: Understanding CSRMC’s Automation and Continuous Monitoring Model

The Cybersecurity Risk Management Construct (CSRMC), announced by DoD in September 2025, is the framework eventually replacing legacy RMF, built around five phases — Design, Build, Test, Onboard, Operations — and ten tenets including automation, continuous monitoring paired with ATO, and DevSecOps. Full breakdown in DoD CSRMC Explained: What’s Replacing RMF and What It Means for ISSOs. AI systems, especially ones that retrain or update frequently, are a natural fit for CSRMC’s emphasis on continuous, automated assessment rather than a point-in-time authorization that goes stale the moment a model gets retrained.

The skill worth building: getting comfortable with continuous monitoring tooling and automated evidence collection, because a model that updates monthly cannot realistically be reassessed manually every time under a legacy RMF mindset. ISSOs who understand how to build monitoring pipelines that flag model changes for review — rather than relying on someone remembering to submit a modification request — will be the ones DoD programs want running AI system security going forward.

Skill 5: Vendor and Third-Party AI Risk Assessment

Most gen-AI assistant deployments are not built in-house — they are a commercial foundation model wrapped in an agency-specific interface. That means your risk assessment skill set needs to extend past your own system boundary into questions about the model vendor: what data was the foundation model trained on, what are the vendor’s update and patching practices, and what contractual or technical controls exist if the vendor pushes a model change that affects your system’s behavior. This is GRC work you already know how to do for software supply chain risk — the skill gap is applying the same rigor to a vendor relationship where the “product” is a model instead of a codebase.

Skill 6: Writing Control Tailoring Rationale That Survives an Overlay Update

Because COSAiS overlays are still publishing in pieces, every AI system authorized today is being assessed against tailored 800-53 controls rather than a finished AI-specific catalog. That means your tailoring decisions and the reasoning behind them need to be documented well enough that when the relevant overlay does publish, remapping your package is a documentation exercise rather than a redesign. This is less a technical skill than a writing and record-keeping discipline, but it is the one that saves the most rework down the line.

A useful habit: every time you tailor a control for an AI system, write one sentence explaining why that control applies the way it does to this specific use case, and file it alongside the control response itself. When an assessor — or a future you, six months later — asks why a control was scoped a certain way, you want an answer that took thirty seconds to find, not an afternoon of reconstructing your own reasoning.

Where GRC Skills Overlap With ISSO Skills on AI Systems

ISSOs and GRC analysts sitting on the same AI system often bring different starting strengths, and the best packages come from leaning into that split rather than duplicating effort. A GRC analyst typically has the stronger risk-framing and policy-mapping instincts — good at asking “does this align with agency AI governance guidance” and tracking the paper trail across a portfolio. An ISSO typically has the deeper hands-on control implementation and technical assessment experience — good at asking “does this configuration actually enforce what the SSP claims it does.”

On an AI system, both skill sets need to stretch into new territory at the same time. The GRC analyst needs enough technical fluency to understand what a model fine-tuning pipeline actually does before mapping it to a risk category. The ISSO needs enough governance fluency to understand why a data provenance gap is a policy problem, not just a technical footnote. Teams that pair these roles deliberately on AI systems — rather than assuming one person can cover both — tend to produce stronger packages than either role working in isolation.

How to Start Building These Skills This Year

• Read the COSAiS discussion drafts as they publish, even in rough form — you want to be forming opinions alongside NIST, not catching up after the fact.
• Ask to sit in on (or lead) the next AI system risk assessment in your program, even if it is not formally your system.
• Build a simple data provenance and model-update questionnaire you can hand to a mission team the moment they mention “we’re adding AI to this.”
• Get familiar with your program’s continuous monitoring tooling now, before an AI system’s update cadence forces the issue.
• Practice writing tailoring rationale for hypothetical AI use cases so the habit is already built before a real package lands on your desk.

None of this requires waiting for a finished framework. The ISSOs and GRC analysts who build these habits now will be the ones AOs trust to handle AI systems as they keep showing up faster than the guidance can formally catch up.

Bottom Line on AI Security Skills for GRC ISSO 2026 Planning

AI security skills for GRC ISSO 2026 planning boil down to one theme: the frameworks are catching up to a reality that has already arrived on your desk. COSAiS overlays, the Assess Only construct, and CSRMC are all still maturing, but the AI systems needing risk assessment are not waiting for any of them to finish. The practitioners who invest in categorization, provenance documentation, continuous monitoring fluency, vendor risk assessment, and disciplined tailoring rationale now will be the ones running these assessments confidently once the guidance fully catches up — instead of scrambling to retrofit a package after the fact.

If you want help mapping these skills against your own program’s AI adoption timeline, or want to work through a specific AI system’s risk assessment with someone who does this daily, coaching sessions are open and built around exactly this kind of practical, package-level work.