Interlock Ransomware and the 2026 Playbook: Mapping CISA Controls to NIST AI RMF Profile Evidence

Why Interlock exposes weak controls

On a single incident day, “ransomware” is rarely the starting gun. It’s what you see after earlier compromise paths, weak identity protections, and monitoring gaps have already bought attackers time. That’s the reason CISA issued a joint advisory focused on protecting against Interlock ransomware, with prevention steps and a clear operational sequence for what to do when activity is suspected. (CISA joint advisory)

Interlock matters because it reveals the seams in your defense-in-depth. If only a few people can interpret alerts, if your incident playbooks don’t connect with identity and log sources, or if your “governance” is a spreadsheet that can’t keep up with tooling changes, you’ll bleed time right where ransomware crews count on you to be slow. CISA’s stop-ransomware guidance is blunt: prevention and response capability are not separate disciplines. They must connect through procedures, visibility, and recovery preparation. (CISA ransomware guide)

Now add AI operations. Many critical-infrastructure teams are experimenting with AI for alert triage, asset classification, or anomaly detection. It can help. It can also add new failure modes: model drift, vendor changes, and the nagging question of “who approved what,” when audit trails aren’t designed into the system. The editorial goal is simple: stop treating AI governance as paperwork, and treat it as a control stack that produces auditability by design. NIST’s AI RMF Profile concept note for critical infrastructure frames that direction under a “Trustworthy Use of AI” approach. (NIST AI RMF Profile concept note)

So what for operators

Treat Interlock-like ransomware as a control integration problem, not a single-product problem. Your AI governance evidence needs to prove--during a real incident--that identity, monitoring, data integrity, and incident response controls were working, and that changes made when models evolved were done safely.

NIST AI RMF Profile as an operations stack

NIST’s Cybersecurity Framework profiles help organizations tailor CSF outcomes and categories to their context, and NIST provides profiles to organize cybersecurity programs around consistent expectations. (NIST CSF profiles) The practical move is to use the AI RMF Profile the same way: as a control stack you can implement, test, and evidence alongside what your security operations already do.

Think in terms of control mapping, not policy mapping. Control mapping asks a hard operational question: when an incident happens, can you show which controls were in place, which signals were monitored, what actions were taken, and which approval gates applied to AI components that influenced those actions? In Interlock events, timing and decision quality are everything. Your AI layer might be involved in detection, prioritization, or investigation support. If you can’t reconstruct the AI layer’s data lineage, configuration, and change history, you can’t defend operational stability or explain why decisions were reasonable.

That’s where auditability by design becomes operational. AI systems evolve: models get retrained, prompts get updated, third-party components get replaced, and vendors ship patches. Governance evidence has to survive those changes. The NIST AI RMF Profile concept note for critical infrastructure explicitly points toward trustworthy use meant to support critical-infrastructure constraints and expectations. (NIST AI RMF Profile concept note)

A baseline comes from NIST’s CSF 2.0 quick-start structure ideas, focused on templates and implementation options. Templates matter because they turn governance into something engineers execute, not something auditors chase after the fact. (NIST CSF 2.0 quick-start template options) You want your AI governance evidence artifacts generated automatically by pipelines you already use for logging, configuration management, and change control.

So what for operators

Stop asking whether you “have AI governance.” Start asking whether you can produce AI governance evidence within the same time window you produce incident evidence. That means wiring AI change history, model/data lineage, and approval records into the same operational workflows your SOC and incident response already rely on.

Security controls mapping from ransomware guidance

CISA’s stop-ransomware materials emphasize prevention and response practices, including guidance to reduce ransomware risk and improve incident handling. (CISA stopransomware page) Your mapping should be concrete. Every ransomware control should map to the AI controls that influence detection, investigation, containment decisions, or data handling.

• Identity and access management. Ransomware often succeeds when attackers exploit identity weaknesses and move laterally. Your identity posture includes multi-factor authentication and least privilege. If AI recommends access changes or flags account anomalies, you need evidence that AI recommendations were based on accurate identity data and that access changes were authorized through your normal workflow.
• Data integrity and logging. If logs are altered or incomplete, your “ground truth” disappears. AI that performs log triage must be proven to consume logs with integrity guarantees and to preserve a record of which log events it used in outputs.
• Monitoring and detection. AI used to augment monitoring needs measurable performance thresholds, plus drift detection that can trigger rollback or human review.
• Incident response. When CISA lays out incident-handling expectations, the operational test is whether your response playbooks stay coherent when AI behavior changes due to model updates or configuration changes.

CISA’s Interlock advisory and its companion stopransomware PDF ground what defenders should do for this specific threat. Use those steps to define your “control runtime,” then attach AI governance evidence exactly where the AI system touches that runtime. (CISA joint advisory; CISA Interlock PDF)

So what for operators

Create a one-to-one security controls mapping document for your AI-supported workflows: for every AI function that touches security decisions, name the governing security practice from your ransomware guidance and define the AI-specific evidence artifact you will store.

AI governance evidence that survives drift

Model drift is easy to describe and hard to operationalize. It means an AI system’s behavior changes over time because inputs or internal parameters change, sometimes subtly. In production, drift can be caused by new data distributions, vendor updates, or retraining. In a ransomware context, drift can show up as lower detection quality, higher false positives that exhaust analysts, or missed signals that delay containment.

NIST’s critical infrastructure AI RMF profile direction matters because critical infrastructure depends on operational stability, where governance can’t assume systems stay static. (NIST AI RMF Profile concept note) The mapping you need is to connect drift management to incident response and change control, not to treat “model risk reviews” as the whole story.

Auditability by design means evidence is created at the time of change, not assembled after the incident. Concretely:

• Configuration snapshots: record model version, prompt templates, feature flags, and dependency versions at deploy time. Also record the effective configuration for a given request (a pointer to the snapshot ID), so you can re-run an incident query against the exact state that produced the AI output.
• Data lineage: record which datasets or log sources were used to generate outputs, especially for decisions that flow into incident tickets. Lineage fields should include a time window (e.g., “logs covering 10:14:03–10:18:22 UTC”) and the identifier for the ingestion pipeline that produced the records.
• Decision logging: record the AI’s output plus the inputs that influenced it, along with whether the decision was accepted by a human. Store outcome fields such as “human approved / human rejected,” “analyst follow-up created ticket? (Y/N),” and “time-to-next-action” to quantify whether AI assisted or slowed response.
• Rollback capability: ensure you can revert to a previously known-good configuration if drift thresholds are exceeded. Operationalize this with an “AI safe mode” switch that disables automated containment recommendations while leaving alert enrichment available.

For drift thresholds, avoid hand-waving. Select at least one performance proxy and one input-quality proxy per AI function. Examples:

• For triage/ranking models: track “top-N precision at analyst resolution” (how often items AI ranks highest become true incidents once analysts act) and “score distribution shift” relative to the previous approved baseline.
• For anomaly/embedding models: track “representation drift” (embedding centroid shift or cosine similarity changes) and “feature availability rate” (percentage of required fields present/valid).

When either proxy breaches its threshold, force human-gated mode and capture an incident evidence bundle linking the breach event to the configuration snapshot.

CISA’s ransomware guidance is built for operational reality: preparedness, not retroactive blame. (CISA ransomware guide) That mindset should carry through your AI governance evidence. If you can’t explain why a specific AI-supported action was taken during an incident, you can’t reliably tune controls or defend operational stability afterward.

NIST’s CSF community profiles and archived examples show that profiles are intended to guide organizations in structuring control expectations. Use that principle to structure your AI evidence set in alignment with your program logic. (NIST CSF 1.1 community profiles archive)

So what for operators

Treat drift like a production outage risk. Require that every AI update used in security operations produces evidence artifacts your incident response team can query instantly: model version, input lineage, and human decision record.

Operational workflow: alert to ticket with evidence

The biggest failure in many environments isn’t the lack of tools. It’s the workflow discontinuity between detection, investigation, and response. When AI is inserted midstream, you risk creating a black-box handoff where the SOC receives outputs without the evidence chain needed for governance or post-incident learning.

A robust workflow looks like this:

1. Detection ingestion. Alerts originate from SIEM (Security Information and Event Management) systems and EDR (Endpoint Detection and Response) sensors. SIEM aggregates and correlates logs; EDR provides endpoint-level monitoring.
2. AI triage. AI ranks alerts and suggests next investigative steps.
3. Evidence capture. For every AI-ranked alert, store: the model version, the alert features used, the AI output, and the confidence rationale in a form your engineers can audit.
4. Human gate. Analysts decide whether to open an incident ticket or take automated containment actions.
5. Incident response. Playbooks execute containment, eradication, and recovery steps.
6. After-action review. Use the stored evidence chain to determine whether AI behavior changed the outcome and whether the relevant controls performed as designed.

CISA’s Interlock materials stress practical defensive posture. Even if your environment uses different technical implementations, the operational sequence matters: prevention measures, preparedness, and response procedures that teams can execute under stress. (CISA joint advisory; CISA Interlock PDF)

Make your AI governance evidence a first-class input to your incident record. It reduces operational stability risk because audits and incident retrospectives become cheaper and faster--and vendor handoffs become manageable. When a model provider changes the service or you switch vendors, you can compare what changed using evidence artifacts instead of guessing.

So what for operators

Make the AI output an auditable field in your incident ticketing system. Your SOC shouldn’t just record “AI recommended X,” but also the evidence bundle proving why, using model version and input lineage captured at triage time.

Case reality: ransomware guidance meets infrastructure limits

Case 1: CISA Interlock joint advisory

CISA published a joint advisory to protect against Interlock ransomware, pairing it with stopransomware resources for operational use. (CISA joint advisory) The outcome isn’t a single victim story; it’s an expected defensive action set. The timeline is the publication date in July 2025, and the practical outcome for operators is an updated set of recommended protections to reduce exposure and improve response readiness. (CISA joint advisory)

That’s the lesson for AI governance. If you can’t map those recommended defensive steps to the operational workflow where your AI participates, you’ll end up with AI governance that can’t help during the incident it was meant to support.

Case 2: CISA stopransomware guide as control logic

CISA’s stopransomware ransomware guide is a practical reference intended for defenders building prevention and response capability. (CISA ransomware guide) Its timeline is ongoing operational use, and the outcome is organizational improvement in how teams prepare and execute ransomware response. While the guide isn’t a single incident resolution report, it functions as a control specification you can treat like the source of truth for your ransomware playbooks. (CISA ransomware guide)

Where AI governance often fails is when teams update tooling. After an AI model update, you must ensure the ransomware control logic still holds: identity rules remain enforced, logging stays trustworthy, monitoring thresholds remain valid, and incident response steps still trigger. The guide’s emphasis on practical response capability supports that operational perspective. (CISA ransomware guide)

So what for operators

Use CISA’s ransomware guidance as the backbone for your security controls mapping. Then attach NIST AI RMF evidence artifacts to the specific workflow touchpoints where AI influences decisions, so governance is operationally provable.

Quantitative signals you can track

Quantitative security metrics help you avoid feel-based governance. Track numbers that show whether your AI evidence chain works under stress, not just whether the model performs well in a lab.

Start with three evidence-quality indicators and one workflow-timing indicator:

1. Evidence completeness rate (ECR).
   Percentage of AI-assisted incident tickets (or ticket candidates) that contain all required evidence fields captured at triage time. Define a minimum set per workflow stage--for example: model_snapshot_id, prompt_template_id, feature_set_version, input_lineage_ids, AI_output, and human_decision (accepted/rejected).
   Track this weekly and break it down by AI function (triage vs enrichment vs containment recommendation).

2. Evidence-to-action coverage (EAC).
   Percentage of AI outputs that resulted in an analyst action with an evidence bundle linked to that action. This catches a common failure mode where the SOC records “AI said X” but loses the linkage to the exact inputs/config that produced X.

3. Decision log integrity success rate (DLISR).
   Percentage of AI requests where the system successfully wrote an immutable (append-only) record of inputs used, configuration snapshot pointer, output, and human acceptance. DLISR is your operational guarantee that post-incident reconstruction is feasible.

4. Workflow timing delta (ΔTTA).
   Change in time-to-next-meaningful-action relative to non-AI baselines (or relative to earlier model versions), such as:

   • time from alert creation to analyst first judgment, and
   • time from analyst judgment to ticket creation or containment start.
     Look for consistent improvement--or at least no regression--when a model changes.

Then connect internal metrics to anchors and external context you already have:

• CISA Interlock advisory published date (22 July 2025) is a defensible anchor for your internal change-control timeline when you adjust evidence bundles and workflows to reflect the guidance. (CISA joint advisory)
• ENISA Threat Landscape 2025 helps sanity-check whether your alert volumes and triage loads are changing in ways consistent with broader threat reporting. Use it for planning capacity, not for proving model correctness. (ENISA threat landscape 2025 booklet)

These aren’t KPIs by themselves, but they are governance-critical anchors. Evidence systems need timestamps, and practitioners need defensible timelines when explaining what changed before the incident and why.

For your operational stability dashboards, turn these anchors into metrics you can own: time-to-triage, time-to-containment, percentage of alerts with complete evidence bundles (model version plus input lineage), and drift-triggered rollbacks per quarter.

So what for operators

You don’t need perfect AI metrics to start. Begin with evidence completeness and workflow timing. Build dashboards that answer: Which alerts had auditable AI context, and did that change response speed or containment quality?

Defense-in-depth for AI monitoring

Critical infrastructure defenders should assume attackers adapt to detection. That means bypass attempts, poisoned inputs, and strategies that burn analyst time on noise. Your goal is operational stability: the security program keeps functioning as models, vendors, and data sources evolve.

ENISA’s threat landscape reporting for 2025 can support the context side of that program, offering an external reference point for how threat actors and tactics are described in that year’s reporting. (ENISA threat landscape 2025; ENISA threat landscape 2025 booklet) The internal translation is to ensure your AI monitoring layer doesn’t become a single point of failure. AI should augment, not replace, authority.

Practically, implement AI circuit breakers:

• If evidence completeness drops (missing lineage or version fields), force human-only mode.
• If drift triggers are hit, require analyst confirmation before AI-suggested actions influence containment steps.
• If identity context is incomplete (for example, user and asset mapping is stale), block automated recommendations and route to an investigation queue.

Your AI governance evidence then becomes an operational safety feature. It stops being a compliance artifact and turns into a runtime guard that keeps your incident workflow from collapsing when systems change.

So what for operators

Treat AI-supported monitoring like a critical control path. Enforce evidence completeness and human-gated decision points so model updates can’t silently weaken your ransomware defenses.

Forward plan for auditability in change windows

Tie your timeline to engineering cadence. Start building auditability by design now, without waiting for abstract policy promises.

Next 30 to 60 days

Identify AI touchpoints in security operations: which alerts are triaged by AI, which tickets are enriched, and which containment actions are recommended or automated. Define the minimal evidence bundle for each touchpoint (model version, input lineage, output, and human acceptance record). Then update incident ticket schemas so evidence is captured at triage time.

By the next quarterly release

Implement drift detection and circuit breakers that activate when evidence completeness or model behavior deviates from approved baselines. Run tabletop exercises using Interlock-style ransomware response scenarios, focusing on whether your evidence chain can be produced and queried rapidly during the exercise.

Within 6 to 12 months

Align your AI evidence bundle with the NIST AI RMF Profile intent for critical infrastructure trustworthy use, using it as a control mapping standard for governance evidence. The NIST critical infrastructure AI RMF Profile concept note provides the development direction you can map your internal implementation to. (NIST AI RMF Profile concept note)

Keep CISA’s ransomware materials as the backbone of the underlying security controls in your mapping, because they reflect operational defensive logic. (CISA ransomware guide; CISA joint advisory)

So what for operators

Assign ownership now, and require every AI change touching security operations to ship with audit-ready evidence artifacts. Then prove it in the next incident exercise by reconstructing the decision chain from alert to ticket to response.