ISO 42001 RACI: Who Owns What in the AIMS
An ISO 42001 program stalls most often not because nobody understands the standard, but because nobody can say, without checking, who owns the AI risk register, who signs the Statement of Applicability, or who is accountable when an Annex A control lapses. ISO/IEC 42001:2023 requires an organization to assign roles and responsibilities for its AI management system directly, under Clause 5.3, but the standard does not hand over an org chart. Building that operating model is the organization’s job, and getting it wrong is one of the most common reasons an AIMS looks complete on paper and falls apart the first time an auditor asks who actually does the work. This article builds a practical RACI structure for an AIMS, clarifies what ISO 42001 itself requires versus what is common implementation practice, and walks through where ownership typically breaks down when this is left informal. What ISO 42001 Actually Requires on Roles ISO/IEC 42001 follows the same Harmonised Structure used across ISO management system standards, with Clauses 4 through 10 forming the mandatory requirements and Annex A providing a reference set of controls organizations select based on applicability. Clause 5.3, Roles and Responsibilities, sits inside the Leadership section of that structure, and it requires top management to assign and communicate responsibilities and authorities for roles relevant to the AI management system. That is the extent of what the standard mandates directly: assign the roles, communicate them, and make sure they are understood. It does not name specific titles, and any org chart implementing this clause is the organization’s own design choice, not a template copied from the standard’s text. A Requirement Unique to ISO 42001 One clause-level requirement is worth calling out specifically because it does not have a direct equivalent in ISO 27001 or most other management system standards. As part of establishing the AIMS scope, an organization must formally determine its own role with respect to the AI systems inside that scope, distinguishing whether it is developing, providing, or using AI, since the obligations attached to each of those roles differ. This organizational role determination is a separate question from the individual roles and responsibilities Clause 5.3 requires internally, and conflating the two is a common early mistake. Get the organizational role wrong at the scoping stage, and the internal RACI built on top of it inherits the error. Where This Article’s RACI Terminology Comes From The role titles used through the rest of this article, AI Governance Body, AI Risk Owner, AIMS Program Owner, and Control Owner, are common implementation practice, not verbatim language pulled from the standard’s text. ISO 42001 requires that these functions exist and are assigned; it does not require these specific names. An organization already using different titles for equivalent functions does not need to rename anything to satisfy Clause 5.3, provided the underlying accountability is clear and documented. Building the AIMS RACI: Roles Defined A workable AIMS RACI needs a small number of clearly bounded roles rather than a long list that dilutes accountability. Five roles cover most of what a mid-sized organization’s AIMS actually requires. Top Management Top management holds ultimate accountability for the AIMS under Clause 5.1, including approving the AI policy, committing resources, and demonstrating leadership commitment during management review. This role cannot be delegated away entirely, even in organizations that appoint a dedicated AI governance lead, because certain accountabilities, particularly policy approval and resource commitment, are explicitly leadership functions under the standard’s structure. Demonstrating that commitment in practice means more than a signature on the policy document. It shows up in management review meetings where leadership actually engages with risk treatment status and audit findings rather than rubber-stamping a summary slide, and in resourcing decisions that follow through when the AI Governance Body identifies a genuine gap requiring budget or headcount to close. AI Governance Body Most organizations implementing ISO 42001 establish a cross-functional body, sometimes a committee, sometimes a smaller working group depending on organizational size, that holds day-to-day oversight of the AIMS on top management’s behalf. This body typically owns the AI policy’s ongoing currency, coordinates the risk assessment and treatment process, and serves as the escalation point when a control owner identifies a gap that needs a decision above their own authority. In smaller organizations, this function sometimes collapses into a single AIMS Program Owner rather than a formal committee, which is acceptable as long as the accountability is documented rather than assumed. AI Risk Owner The AI Risk Owner, which may be an individual or a role held collectively by the governance body depending on organizational scale, is accountable for the AI risk assessment and treatment plan Clause 6.1 requires, including ensuring identified risks are tracked to resolution rather than logged and forgotten. This role is distinct from a control owner, because a risk can span multiple controls and multiple systems, and someone needs to own the risk itself rather than only the individual mitigations underneath it. AIMS Program Owner The AIMS Program Owner runs the operational machinery of the management system: maintaining the Statement of Applicability, scheduling and tracking internal audits, preparing management review inputs, and keeping the documented information the standard requires current and accessible. This role is often the actual day-to-day driver of certification readiness, even though it typically does not hold the same authority as top management or the governance body to make policy-level decisions. Control Owners Each applicable Annex A control needs a named owner accountable for that control’s operation and evidence, not a general statement that “the team” is responsible. Control ownership is where AIMS programs most often go vague, because a control like lifecycle management or data governance can plausibly involve several functions, and without a single named owner, evidence collection becomes nobody’s specific job when an audit approaches. The RACI Matrix Across Key AIMS Activities The table below maps the five roles against the recurring activities an AIMS generates, using standard RACI notation: Responsible for doing the work, Accountable for the outcome, Consulted before a
FedRAMP Consulting: What the CR26 Advisor Role Changes
FedRAMP consulting used to operate in a gray zone. Advisory firms helped cloud service providers navigate authorization, but the program itself had no formal category for what they did, no listing process, and no accountability structure distinguishing a firm that genuinely knew the framework from one that had simply decided to sell FedRAMP services. The Consolidated Rules for 2026 closed that gap. CR26 now defines Advisor as one of five formal stakeholder categories in the program, alongside FedRAMP itself, agencies, cloud service providers, and independent assessors, with its own published rules covering who can claim the role and what they owe the program in return. This article explains what that change actually means, what CR26 now requires of a FedRAMP advisor, how it should reshape the build-versus-buy decision a provider faces, and what a buyer should verify before hiring one. Why FedRAMP Consulting Just Became a Formally Defined Role For most of FedRAMP’s history, advisory work sat outside the program’s formal structure entirely. A provider could hire any firm claiming FedRAMP expertise, with no external mechanism to verify that claim beyond reputation and references. CR26 changes that by giving advisors a defined place in the program’s rules, not a special status, but a defined one with real obligations attached. The Five CR26 Stakeholder Categories CR26 organizes the entire FedRAMP program around five stakeholder groups, each with its own section of published rules: FedRAMP itself, which sets and administers the rules; agencies, which consume authorized cloud services; cloud service providers, which build and operate the systems being certified; independent assessors, which perform the assessments that support certification; and advisors, which help providers navigate the process without performing the assessment themselves. Structuring the rules this way means every stakeholder category, including advisors, now has a defined scope of responsibility rather than an implicit one inferred from industry practice. What “Advisor” Means Under CR26, Specifically Under CR26, an advisor is explicitly not an independent assessor. Advisory services help a provider understand the rules, map its current state against the framework, plan a certification path and class, and prepare for assessment, but they do not perform the assessment itself and cannot grant any official status. A company may offer both advisory and assessment services, but CR26 requires it to clearly specify which capacity it is acting under at any given point in the certification process. This distinction is not a formality. Assessment independence is a core integrity mechanism in the program, and blurring the line between advising a provider and assessing it undermines the credibility the whole certification depends on. How Advisors Fit Between the Other Stakeholder Roles An advisor’s position in the CR26 structure sits deliberately outside the direct line between provider and assessor. The cloud service provider owns the certification and bears responsibility for its accuracy. The independent assessor evaluates the provider’s evidence and forms an independent judgment the agency relies on. The advisor sits alongside that relationship, helping the provider prepare, without inserting itself into the evaluation itself. This positioning is what makes the advisory-versus-assessment separation so consequential: an advisor that starts acting like a shadow assessor, effectively pre-grading the provider’s readiness in a way the provider then presents to the real assessor as settled fact, quietly compromises the independence the entire structure exists to protect, even if no rule is technically broken in the process. Why This Matters More Than Terminology A skeptic might read this as a rename with no practical consequence. That reading misses what actually changed. Before CR26, a buyer evaluating FedRAMP consulting firms had no external reference point to check a claim of expertise against. Now, the program itself publishes rules that a legitimate advisor operates under, which means a buyer has something concrete to verify rather than a sales pitch to take on faith. The formalization did not create new competence requirements for advisors. It created a public standard a buyer can check a firm against, and that shifts real leverage toward the buyer. What the Pre-CR26 Market Actually Looked Like Before this ruleset, the FedRAMP consulting market ran almost entirely on reputation, referrals, and self-description. A firm could describe itself as a FedRAMP expert on its own website with no external body confirming or disputing that claim, and a buyer’s only real recourse was calling references and hoping those references were representative rather than cherry-picked. This produced a market where the loudest marketing often outcompeted the deepest expertise, because nothing structurally rewarded the difference. The FedRAMP PMO changes that came with 20x already signaled the program moving toward more structured, verifiable participation across every stakeholder group, and the formal Advisor category is that same shift applied specifically to the consulting layer that sits outside the certification boundary itself but heavily influences how providers reach it. What CR26 Actually Requires of a FedRAMP Advisor The rules governing advisors are specific enough to function as a genuine due-diligence checklist, not just a description of the category. Three sets of requirements matter most to a provider evaluating consulting support. Website and Disclosure Requirements Under rule MKT-CAS-WEB, an advisor seeking a Marketplace listing must maintain a public website that supplies, in both human-readable and machine-readable format, a general description of the consulting or advisory service, contact information, the specific types of consulting or advisory services offered, and optionally, positive attestations from customers or customer references. This is a low bar in isolation, but it is a bar every legitimate, currently listed advisor has already cleared. A firm that cannot point to a website meeting this standard is either not listed or has let its listing lapse, both of which are worth asking about directly before signing anything. The Marketplace Listing Process Rule MKT-CAS-LRQ requires an advisor to complete a formal Advisor Listing Request Form to be listed in the FedRAMP Marketplace. FedRAMP does not review or endorse the substance of an advisor’s work, but it does maintain a centralized set of listings tracking which firms have gone through this process and meet the baseline information-sharing requirements. A
Continuous Monitoring for Audit-Ready Evidence
Continuous compliance monitoring exists to close one specific gap: the distance between what a policy says and what the system is actually doing right now. Most compliance programs do not fail on the control. They fail on the evidence, because a control that was true in January and never checked again is not the same thing as a control that is true today, and an assessor cannot grade intent. Continuous monitoring is what keeps documentation and operational reality pointing at the same thing, all year, instead of only in the week before an audit. This article covers what continuous monitoring actually means for audit readiness, why point-in-time evidence fails under real assessor scrutiny, what a defensible monitoring program has to include, and how it changes the audit itself when it is built correctly. The Gap Continuous Monitoring Closes Every compliance program has a policy layer and an operational layer, and the two drift apart by default, not by negligence. A policy says access is reviewed quarterly. The operational reality is whichever person last remembered to run the review, whenever that happened to be. A policy says vulnerabilities are patched within a defined window. The operational reality is whatever the patch queue actually looked like on any given day. Continuous monitoring is the discipline that keeps those two layers honest with each other, by checking the operational reality against the documented control on an ongoing basis rather than reconstructing it once a year under audit pressure. Point-in-Time Evidence Does Not Hold Up A screenshot taken the week before an audit proves one thing: that the control was true in that specific week. It says nothing about the other fifty-one weeks of the year, and a competent assessor knows this. The reason continuous monitoring has become a baseline expectation across frameworks, not an optional maturity upgrade, is that point-in-time evidence answers a narrower question than the one the audit is actually asking. The audit is asking whether the control operates. A single screenshot can only answer whether the control existed once. What Continuous Monitoring Actually Requires A working continuous monitoring program has three components that have to function together. The first is a defined cadence for each control category, since not every control needs the same check frequency; access reviews, vulnerability scans, and configuration checks each have their own reasonable interval. The second is an automated or semi-automated way to pull evidence on that cadence without relying on someone remembering to do it manually. The third is a record of the evidence itself, timestamped and attributable, so that when an assessor asks for six months of history, the answer is a query, not a scramble. Matching Cadence to Control Category Not every control drifts at the same speed, and treating them all identically wastes effort on some categories while under-checking others. Access rights change whenever someone joins, leaves, or changes role, so access-related controls warrant a tighter check interval than something that changes rarely. Vulnerability exposure changes as new flaws are disclosed and new assets are deployed, which argues for near-continuous scanning rather than a periodic check. Configuration drift tends to happen gradually, often through unreviewed changes, and benefits from a cadence tied to the deployment pipeline rather than a fixed calendar date. Physical or vendor-relationship controls typically change slowly enough that a longer interval is genuinely defensible, provided the interval is documented and followed consistently rather than treated as a suggestion. The specific interval a given framework requires for a given control category should come from that framework’s own published rules, not from a generic industry rule of thumb, since mandated cadences vary and change over time. What stays constant across frameworks is the underlying design principle: match the check frequency to how quickly the underlying risk actually changes, and document the reasoning so an assessor can see the cadence was chosen deliberately rather than defaulted to whatever was easiest to automate first. Why Compliance Teams Get This Wrong The most common failure is not the absence of a monitoring program. It is a program that exists on paper and produces evidence only when someone is specifically looking for it, which functions identically to no program at all from an audit perspective. The Screenshot Trap A team that manually captures evidence once a quarter is not running continuous monitoring, even if the resulting folder of screenshots looks organized. The tell is what happens between captures. If a control could fail silently for two months before the next scheduled screenshot catches it, the monitoring is not continuous, it is periodic, and periodic monitoring reconstructs the same point-in-time problem on a slightly longer cycle. Mapping evidence for audit readiness at scale is the discipline that prevents this trap, and it depends on evidence capture being built into the system doing the work, not bolted on afterward by whoever remembers to check. Ownership Ambiguity Kills Cadence A monitoring cadence only holds if someone is accountable for it running, and that accountability breaks down quietly when no single person owns a given control. A RACI structure for control ownership that names who is responsible for each control’s evidence, not just who is broadly aware of it, is what keeps a monitoring cadence from silently lapsing when priorities shift. Continuous monitoring tooling can automate the check itself, but it cannot substitute for a named owner who is accountable when the check fails. What a Defensible Monitoring Program Looks Like An assessor evaluating a continuous monitoring program is not grading the tooling. They are grading whether the evidence the tooling produces is trustworthy, complete, and traceable back to a named control. Requirement, What an Assessor Checks, What Teams Commonly Produce Instead For a control like access review, the requirement is a periodic, documented review of who has access to in-scope systems. What an assessor looks for is dated review records, a named reviewer, and evidence that changes identified during the review were actually actioned, not just noted. What teams commonly produce instead is a current access
Audit Readiness Solutions for Lean Teams
Audit readiness solutions exist because most compliance teams are not sized for the work an audit actually demands. A five-person security function can build a genuinely strong control environment and still watch an audit stall, not because the controls are weak, but because nobody has the hours to assemble evidence, manage assessor questions, and keep the business running at the same time. The organizations that get through audits calmly are rarely the ones with the largest teams. They are the ones that matched the right kind of outside support to the actual gap. This article covers what audit readiness solutions actually include, how to vet a partner before signing anything, what changes when a lean team runs more than one framework at once, and how to compare the service models available so the decision is based on your team’s real constraints, not a vendor’s pitch deck. What Audit Readiness Solutions Actually Cover The phrase gets used loosely, so it helps to define it precisely. Audit readiness solutions are the combination of services that gets an organization from its current control state to a defensible, evidence-backed position an external assessor or auditor can certify. That combination typically spans four functions: gap assessment against the target framework, remediation support to close what the assessment finds, evidence collection and organization so findings can be produced on request, and audit-day support to manage the assessor relationship while the business keeps operating. A lean team rarely needs all four functions delivered by one vendor at full intensity. What it needs is a partner that can flex across those four functions as gaps appear, rather than a fixed engagement that assumes a large internal team is doing most of the work in parallel. That distinction, flexible capacity versus a fixed scope of work, is the single most useful filter when comparing options. Why Lean Teams Hit This Wall Specifically A well-resourced compliance function can absorb an audit cycle by reassigning people temporarily. A lean team does not have that slack. Every person already owns a full workload, and pulling someone onto evidence-gathering for six weeks means something else stops. This is not a maturity problem. It is a capacity problem, and it shows up even in organizations with genuinely strong security programs. The honest question is not whether your controls are good enough. It is whether your team has the hours to prove they are good enough, on the assessor’s timeline, without the rest of the business noticing. Audit readiness matters long before the audit starts, and the capacity gap that outside support solves is usually visible months before a formal engagement begins, not the week the assessment gets scheduled. Building the Foundation Before Bringing In Help Bringing in outside support works best when it builds on a real internal foundation, not a blank slate. A team that has already worked through what audit readiness actually means for a B2B compliance program and has attempted a monthly audit readiness checklist internally arrives at a partner conversation with a much clearer picture of where the actual gap sits. That clarity changes the vetting conversation from a general capability pitch into a specific discussion of the exact function the team needs covered, which is a better use of everyone’s time than starting from zero. How to Vet an Audit Readiness Partner Once the decision to bring in outside support is made, the harder decision is who to trust with it. Vendors in this space describe themselves almost identically, so the differentiation has to come from specific questions, not from the pitch. What the Engagement Actually Requires The requirement is straightforward to state and hard to verify from a sales conversation: a partner that can assess your current control state accurately, prioritize remediation by real risk rather than by what is easiest to bill, and produce evidence in the format your specific auditor or assessor expects. That last point matters more than most buyers assume. Evidence that satisfies a SOC 2 auditor is not automatically formatted the way a CMMC assessor or an ISO certification body expects it. What a Strong Partner Demonstrates A partner worth hiring can walk you through a real example of a gap they found, how they prioritized it against other findings, and what evidence they produced to close it, without switching to generic language halfway through. They name the framework-specific pitfalls your organization is likely to hit, not a universal list that applies to any compliance program. They can also describe what happens when their initial assessment turns out to be wrong, because a partner who has never revised a finding has probably never been tested by a real assessor. What Weak Partners Substitute Instead The common substitute for genuine expertise is a templated gap-assessment report and a generic project plan, delivered fast and priced attractively, that reads well in a proposal but does not reflect your actual architecture or your actual assessor’s expectations. Another common substitute is staffing the engagement with junior consultants working from a checklist, with a senior name attached to the proposal but absent from the actual work. Watch for vague answers to specific questions about your framework and your industry. A partner that cannot get specific about your situation in the sales conversation will not get specific about it during the engagement either. A Short List of Questions Worth Asking Directly Before signing, ask a prospective partner to name the last engagement where their initial finding changed after deeper review, to describe how they staff a project by seniority across its lifecycle, and to show a redacted example of the evidence format they produce for your specific target framework. Vague or evasive answers to any of these three are a stronger signal than anything in the proposal itself. Evidence Volume Is Where Weak Partners Get Exposed The vetting conversation often looks strongest on paper and weakest in practice once the evidence-collection phase actually starts. A partner’s real capability shows up in how they handle volume: dozens of controls,
FAR Part 40: The Class Deviation Making CMMC Suspension Official
FAR Part 40 is where the CMMC Phase 2 suspension stopped being a policy statement and became a binding term in actual defense contracts. On September 3, 2026, the Office of the Assistant Secretary of War issued DARS Tracking Number 2026-O0025, Revision 3, a class deviation implementing the Revolutionary FAR Overhaul’s Part 40, Information Security and Supply Chain Security, along with the corresponding DFARS Part 240. Buried inside this deviation, alongside several unrelated supply chain security provisions, is the specific instruction that turns the Department of War CIO’s July suspension memo into something contracting officers are now required to act on in your actual solicitations and contracts. This article explains what this class deviation actually requires contracting officers to do, what it confirms remains unchanged, and what a defense contractor should expect to see happen to its own contracts as a direct result. What DARS 2026-O0025, Revision 3 Actually Is A class deviation is not a policy announcement. It is a formal instruction that authorizes and directs contracting officers to depart from the codified FAR or DFARS text and use different, specified language instead, effective immediately upon issuance. This particular deviation revises and supersedes its own prior version, Revision 2, which had been issued on July 16, 2026, meaning this is already the third iteration of this specific instrument in under two months. The Regulatory Chain From CIO Memo to Binding Deviation The Department of War Chief Information Officer’s memorandum suspending the advancement to CMMC Phase 2, dated July 13, 2026, announced the policy: program managers could require only CMMC Level 1 (Self) or Level 2 (Self) assessments, the Phase 2 third-party assessment transition was suspended, and baseline compliance with NIST SP 800-171 Revision 2 remained required. That memo, on its own, directed program managers and requiring activities. This class deviation is the document that formally authorizes contracting officers to depart from the codified regulatory text to actually implement that direction inside solicitations and contracts. The original suspension explained covers what the policy itself changed; this deviation is the mechanism that makes it enforceable contract language rather than internal guidance. Why This Is Already on Its Third Revision A class deviation reaching its third revision in under two months signals that the underlying policy area is still actively being refined, not that anything about the suspension itself is in doubt. This revision specifically implements several statutory requirements and corrects definitions, including fixes to the definitions of covered lobbyist and Chinese military company used elsewhere in the same Part 40 text. Contractors should treat a class deviation with an active revision history as a live document to monitor, not a one-time notice to file away, since a fourth revision addressing further corrections or statutory updates is a reasonable expectation given this pace. Reading a Class Deviation Correctly A class deviation is directive to contracting officers, not directly to contractors, which is a distinction worth understanding before drawing conclusions from one. It tells a contracting officer to use specific revised text in place of the codified FAR or DFARS provisions; it does not itself amend a contractor’s existing contract. The actual change to a contractor’s situation happens when a contracting officer acts on the deviation, through a solicitation amendment or a contract modification, which is why the timing questions addressed below matter as much as the deviation’s existence itself. Reading a class deviation and assuming it immediately and automatically changes every affected contract’s terms is a common and understandable misreading of how this instrument actually works. What Contracting Officers Are Now Required to Do The operational core of this deviation, for CMMC purposes, is a specific set of instructions directing contracting officers to take concrete action on solicitations and contracts already in progress. Amending Active Solicitations Contracting officers must collaborate with requiring activities to remove or revise CMMC requirements in new and existing solicitations in accordance with the CIO’s suspension memo. Program managers and requiring activities are required to initiate the amendments, provide them to the cognizant contracting officer, and contracting officers must then issue the corresponding solicitation amendments as soon as practicable. A contractor with a proposal currently in evaluation against a solicitation that still references Phase 2 CMMC requirements should expect an amendment removing or revising that language, rather than assuming the original solicitation text controls simply because it predates this deviation. Modifying Existing Contracts For contracts already awarded that contain Phase 2 CMMC requirements, this deviation requires contracting officers to remove them through a modification, either prior to the exercise of the next option period or through the next scheduled administrative modification, whichever comes first in the contract’s normal cycle. This means a contractor should not expect an immediate, out-of-cycle modification to every affected contract. The removal is tied to the contract’s existing administrative rhythm, which means the timing varies considerably depending on where a given contract sits in its option period or modification schedule. Contract situation What triggers the modification Realistic timing Contract nearing an option period exercise The option period exercise itself Weeks to a few months Contract with a scheduled administrative modification already planned That scheduled modification Depends on the existing schedule Contract with neither event imminent Whichever event happens first Potentially well over a year New solicitation not yet awarded Direct amendment, not a modification As soon as practicable per the deviation The pattern in this table matters for planning: a contractor should not expect uniform timing across a portfolio of contracts, and a contract with no option period or administrative modification on the near-term horizon may carry Phase 2 language in its official file for a considerable period even though the requirement is not being enforced. This administrative lag is normal under the deviation’s own terms and is not evidence that the suspension is not actually in effect. The Baseline That Does Not Move Consistent with the underlying CIO memo, this deviation reaffirms that baseline compliance with NIST SP 800-171 Revision 2 remains required through the clause at DFARS 252.204-7012, and that CMMC
EU AI Act Article 50: What It Actually Requires Now
EU AI Act Article 50 is already in force. It took effect on August 2, 2026, and the widely reported delay to the Act’s high-risk obligations did not touch it. Many organizations read the headlines about the EU’s Digital Omnibus pushing back the Act’s most demanding requirements, filed the entire regulation under next year’s problem, and moved on. That assumption is now a compliance gap, not a scheduling one, because Article 50’s transparency obligations apply today, regardless of whether an organization’s AI systems are classified as high-risk under the Act’s separate Annex III framework. This article explains what changed, what Article 50 actually requires, why it reaches organizations that do not think of themselves as AI companies, and how to fold compliance into governance infrastructure many regulated organizations are already building. Article 50 Is Already in Force, and the Omnibus Did Not Change That The confusion here is understandable, because the EU AI Act’s implementation timeline genuinely did change in 2026, just not in the way most coverage suggested. What the Digital Omnibus Actually Delayed The EU’s Digital Omnibus on AI, formally Regulation (EU) 2026/1744, entered into force on July 27, 2026, after final adoption on June 29, 2026. It pushed the compliance deadline for high-risk AI systems under Annex III from August 2, 2026 to December 2, 2027, and delayed the Annex I product-safety obligations to August 2, 2028. Those are real, substantial delays, and they are the reason so much of the public discussion around the EU AI Act in mid-2026 described the regulation as having been pushed back by more than a year. What that coverage largely missed is that the Omnibus explicitly left Article 50 untouched. The transparency obligations in Article 50 became generally applicable and enforceable by national authorities across the EU on August 2, 2026, on schedule, and they apply regardless of whether the underlying AI system is classified as high-risk. An organization that correctly tracked the Annex III delay and incorrectly assumed the same delay covered Article 50 is not behind schedule. It is currently out of compliance with a regulation that has already taken legal effect. The One Narrow Exception The Omnibus did make one specific, limited change relevant to Article 50. Providers of AI systems that generate synthetic audio, image, video, or text content, and that placed those systems on the market before August 2, 2026, received a four-month grace period on the machine-readable marking requirement under Article 50(2), extending that specific deadline to December 2, 2026. This exception is narrow in three ways: it applies only to the marking obligation, only to systems already on the market before the original deadline, and not at all to the other three transparency obligations Article 50 establishes, all of which remain in force from August 2, 2026 with no grace period. What Non-Compliance Actually Costs Article 99 of the EU AI Act sets the enforcement framework, and it assigns Article 50 breaches to the middle of the Act’s three penalty tiers. Non-compliance with Article 50’s transparency obligations can result in administrative fines of up to fifteen million euros or three percent of an organization’s total worldwide annual turnover for the preceding financial year, whichever figure is higher. This sits below the top tier reserved for the Act’s prohibited practices under Article 5, which reaches thirty-five million euros or seven percent of turnover, but it is a real, material exposure rather than a symbolic one. The Regulation caps the fine at the lower of the two figures for small and medium enterprises, and enforcement sits with each member state’s national market surveillance authority, which took on that enforcement power on the same August 2, 2026 date the obligations themselves became applicable. Reviewing the full EU AI Act compliance timeline puts this specific enforcement date in context alongside the other deadlines the Digital Omnibus did and did not move. The Four Transparency Obligations Under Article 50 Article 50 covers four distinct situations, each triggering a specific disclosure duty. Understanding which apply to a given organization requires looking at actual AI use cases, not at industry classification. AI Systems That Interact Directly With People Providers of AI systems intended to interact directly with natural persons must ensure those individuals are informed they are interacting with an AI system, unless it is obvious from the circumstances to a reasonably well-informed person. This obligation covers chatbots, virtual assistants, and any conversational AI interface a person might otherwise reasonably mistake for a human. The disclosure requirement is not satisfied by a policy buried in terms of service. It requires the interaction itself to make the AI nature of the system reasonably clear to the person engaging with it. Marking AI-Generated Content Providers of AI systems that generate synthetic audio, image, video, or text content must mark that output in a machine-readable format detectable as artificially generated or manipulated. This obligation is covered in depth in Elevate’s guide to labeling AI-generated content under the EU AI Act, including the specific format requirements and the narrow grace period for legacy systems described above. Emotion Recognition and Biometric Categorization Disclosure Deployers of an emotion recognition system or a biometric categorization system must inform the individuals exposed to that system of its operation, and must process any personal data involved in line with EU data protection law. An exception applies to systems used to detect, prevent, or investigate criminal offenses, subject to safeguards under other applicable law. This obligation attaches to the deployer, the organization using the system, not only to the technology’s original provider, which means an organization that purchases and operates a third-party emotion-recognition or biometric-categorization tool carries this disclosure duty directly. Deepfake Disclosure Deployers of AI systems that generate or manipulate image, audio, or video content constituting a deepfake must disclose that the content has been artificially generated or manipulated. This obligation sits alongside the provider-side marking requirement under Article 50(2) but applies specifically to the deployer’s disclosure to the audience encountering the content, which is a distinct duty
FedRAMP Vulnerability Management: The 2026 VDR Deadline
FedRAMP vulnerability management is being rebuilt, and the deadline is closer than most providers realize. On December 7, 2026, two new rulesets, Vulnerability Detection and Response (VDR) and Vulnerability Evaluation and Reporting (VER), become mandatory for every cloud service offering that holds or seeks FedRAMP Certification. A grace period runs to March 7, 2027, after which certification is revoked for any offering not following the rules. This is not a FedRAMP 20x-only change. It reaches every Rev5 provider in the Marketplace, and it lands before the mandatory 20x adoption date. This article explains where the rule came from, what VDR and VER require, how the new risk-based prioritization model works, why multi-tenant architecture changes the math, what an agency reviews, and the concrete steps a provider needs to take before the December deadline. Why FedRAMP Vulnerability Management Changed in 2026 For years, FedRAMP vulnerability management ran on a fixed clock. Scan on a set cadence, score each finding by severity, and remediate inside flat windows tied to that severity. The model was simple to audit and poor at distinguishing a critical flaw on an internet-facing authentication service from an identical score on an isolated internal tool. In 2026 the program replaced that clock with a risk-based model, and it did so on a compressed timeline. The Directive Behind the Rule The change traces to CISA Binding Operational Directive 26-04, Prioritizing Security Updates Based on Risk, issued on June 10, 2026. The directive pushes federal cybersecurity away from remediating raw scanner counts and toward prioritizing vulnerabilities that are internet-reachable, exploitable, and known to be exploited. A binding operational directive, on its own, binds federal civilian executive branch agencies. It does not reach a private company directly, which is the detail that makes the next step matter. How the Directive Became a CSP Requirement FedRAMP closed that gap with Public Notice NTC-0014 on June 16, 2026, which folds the directive’s risk model into the Consolidated Rules for 2026 through the VDR and VER rulesets. This is the mechanism that makes the model bind a cloud service provider: not the directive itself, but FedRAMP adopting it as a condition of certification. Any provider that follows the VDR and VER rules meets the timelines, prioritization requirements, and approach set out in the directive. A provider that does not follow them puts its certification at risk regardless of how the underlying directive is worded. The Deadline That Arrives First The single most useful thing to take from this change is the calendar, because the compliance dates do not land together. The table below sequences the dates that matter for an existing provider. Date Event What it means for a certified provider June 10, 2026 CISA BOD 26-04 issued The risk-based model is set for federal agencies June 16, 2026 FedRAMP NTC-0014 published The model becomes a condition of FedRAMP Certification December 7, 2026 VDR and VER mandatory Non-compliance begins for any offering still on the legacy process March 7, 2027 Grace period ends Certification revoked for offerings not following the rules January 1, 2027 Broader Consolidated Rules mandatory for Rev5 A separate, later obligation than the vulnerability deadline The order in that table is the point. VDR and VER become mandatory on December 7, 2026, which is earlier than the January 1, 2027 mandatory adoption of the broader Consolidated Rules for existing Rev5 providers. A provider tracking only the 20x transition calendar can miss the vulnerability deadline entirely, because it arrives first and is driven by an external directive rather than by the 20x rollout. The original plan was gentler, with mandatory adoption set for June 1, 2027 and a grace period into 2028. That timeline was pulled forward, which is the reason this now demands attention in the current quarter rather than next year. What the VDR and VER Rules Require The two rulesets work together. VDR defines how a provider detects, prioritizes, and responds to vulnerabilities under a risk model. VER contains the evaluation and reporting rules drawn from the VDR, separated into their own ruleset for convenience. Together they replace the legacy scan-and-remediate cadence that has defined FedRAMP continuous monitoring since the program began. The table below contrasts the legacy model with the model that becomes mandatory in December. Dimension Legacy scan model VDR and VER model Prioritization basis CVSS severity tier in isolation Impact, exploitability, and reachability in context Remediation clock Flat windows by severity Timeframe driven by contextual risk rating Reporting Monthly scan output Structured, machine-readable evaluation and response records Focus Clear the scanner queue Address internet-reachable, exploitable, known-exploited findings first The shift in that table is not cosmetic. Under the legacy model, a provider could spend engineering capacity remediating a high-severity finding on an asset that holds no federal data and has no path from the internet, while a genuinely dangerous finding waited in the same queue. The new model forces each finding to be evaluated against what the affected asset actually does, whether it is exposed, and whether it is being exploited in the wild. That is a more defensible use of finite engineering time, and it is now a certification requirement rather than an option. The End of the Flat Scan Clock The legacy cadence assigned fixed remediation windows by severity, commonly 30 days for critical and high findings, 90 for moderate, and 180 for low. The VDR model retires that flat clock. Remediation timeframes now derive from a contextual rating, which means two findings with identical scanner scores can carry very different deadlines depending on the asset they sit on and their real exposure. Providers that have built their entire vulnerability workflow around the flat clock will find that the workflow itself, not just the paperwork, has to change. The New Prioritization Model: Impact, Exploitability, and Reachability At the center of the VDR model is a structured way to rate how much a given vulnerability actually threatens a federal agency. This replaces severity-in-a-vacuum with a rating that reflects context, and it is the part of
CUI Compliance: The 2026 Rules Every Federal Contractor Faces
CUI compliance used to be a defense-contractor problem. In 2026 it stopped being one. A federal contract cybersecurity case closed in June 2026 with a $507,144 False Claims Act settlement tied to unmet safeguarding requirements, and two parallel regulatory moves now push controlled unclassified information obligations toward nearly every federal contractor and subcontractor. If your organization touches federal data of any kind, the question is no longer whether CUI compliance applies to you, but how soon you have to prove it. This article explains what changed in 2026, what agencies are now required to pass down to you in contracts, and the concrete steps that separate a defensible CUI program from a paper one. Why CUI Compliance Changed in 2026 For most of the last decade, controlled unclassified information lived in a strange gap. The government created the category in 2010, wrote the rules for agencies, and told defense contractors to protect it through a single Defense Federal Acquisition Regulation Supplement clause. Civilian-agency contractors had no equivalent obligation. That gap is closing on two fronts at once. The Agency Side: ISOO Notice 2026-07 On September 2, 2026, the Information Security Oversight Office issued ISOO Notice 2026-07, refreshing how every federal agency must run its CUI program. The notice consolidates and updates the required elements agencies must implement, from designation and marking through decontrol, misuse reporting, and annual self-inspection. It rescinds older guidance, including the 2020 notice that governed program implementation deadlines. The part that matters to you sits in the notice’s contract requirements. Agencies entering any contract that requires access to controlled unclassified information must, at a minimum, give the prime contractor specific guidance on a defined list of items. That list is effectively a preview of what will land in your contracts, and it is worth reading as a checklist rather than as background. The Contractor Side: The FAR CUI Rule The second front is the Federal Acquisition Regulation itself. The FAR CUI rule, formally FAR Case 2017-016, was first proposed in January 2025 and re-proposed on June 23, 2026 as part of the Revolutionary FAR Overhaul. The comment period closed on July 23, 2026 with 96 comments, and the rule now awaits finalization. Industry observers expect it to begin appearing in contracts before the end of 2026, though as a proposed rule its terms can still change. The rule would extend CUI safeguarding and incident reporting to nearly every federal contractor and subcontractor, not just defense suppliers. It relocates these obligations into the expanded FAR Part 40 and introduces a standard form the agency completes to identify the CUI in a given contract. The Cost of Getting It Wrong Enforcement is not theoretical. In June 2026, a contractor resolved False Claims Act allegations involving Navy contract cybersecurity requirements for $507,144, in a matter that reportedly involved a Defense Contract Management Agency assessment score of negative 170 after alleged noncompliance with required controls. The False Claims Act exposure attaches to the representations a contractor makes about its security posture, which means a weak or inaccurate CUI program is not only an operational risk but a financial and legal one. What the FAR CUI Rule Requires The proposed rule builds a single, uniform mechanism for communicating and enforcing CUI obligations across federal contracts. The table below summarizes the core requirements as proposed in the June 2026 version. Requirement What it means for you Source mechanism NIST SP 800-171 Rev 3 Meet the current revision of the security requirements for CUI in nonfederal systems FAR 52.240-7 clause 72-hour incident reporting Report a suspected or confirmed CUI incident within 72 hours of discovery FAR 52.240-7 clause Subcontractor flowdown Pass safeguarding and reporting requirements to subs that will receive CUI FAR 52.240-7 clause CUI identification Receive an agency-completed Standard Form identifying the CUI in the contract SF XXX, CUI Requirements Records preservation Preserve information related to a CUI incident for a defined retention period FAR 52.240-7 clause The single most consequential line in that table is the move to NIST SP 800-171 Revision 3. Defense contractors have operated under Revision 2 through the existing DFARS clause, so the shift to Revision 3 is a real delta in control expectations, not a rename. For civilian-agency contractors who have never lived under a cybersecurity clause at all, the entire framework is new. Either way, the practical work is the same: your information systems that store, process, or transmit CUI have to meet a named control set, and you have to be able to show it. The 72-Hour Clock The June 2026 version proposes a 72-hour window to report a suspected or confirmed CUI incident, a change from the 8-hour requirement in the January 2025 version. Seventy-two hours sounds generous until you consider what has to happen inside it: detection, triage, a preliminary determination that CUI was involved, and a report that contains the required data elements. Organizations that have never run this drill discover during a real incident that the clock starts at discovery, not at the moment they finish investigating. Flowdown Is Now Your Responsibility The rule requires prime contractors to flow safeguarding and incident-notification requirements down to subcontractors that will receive CUI. This is where many programs break. A prime can hold an excellent internal posture and still carry unmanaged risk through a sub that never received, acknowledged, or implemented the requirements. The obligations that primes and subs must meet to secure CUI are not a clause you paste once; they are a supplier-management process you have to be able to evidence. What Agencies Must Pass Down in Contracts ISOO Notice 2026-07 lists the specific guidance an agency must provide to a prime contractor for any contract requiring CUI access. Read this as the map of what your next CUI-bearing contract will ask of you. Contract element What you will need to operate Identification and marking A way to recognize government-furnished CUI and mark contractor-developed CUI correctly Safeguarding and access Controls limiting CUI to authorized holders, at rest and in transit Training
EU AI Act Compliance Checklist: Obligations by Risk Category
An EU AI Act compliance checklist only works if it is organized the way the law itself is organized: by risk tier. The Act does not impose one uniform set of rules on every AI system; it sorts systems into risk categories and assigns obligations to each, so the first question is never what must be done but rather which tier a system falls into. This guide lays out the obligations for the prohibited, high-risk, and limited-risk tiers, explains how classification drives everything, and points to where the current application dates are maintained, since those have been revised. The reason the tier comes first is that it determines the entire obligation set. A system in the minimal-risk tier carries no mandatory obligations, while one in the high-risk tier carries an extensive program of them, and misclassifying a system is therefore the most consequential mistake an organization can make. Working through this checklist means classifying each AI system first, then applying only the obligations that its tier actually triggers. How the EU AI Act Classifies Risk The Act’s risk-based structure is the foundation of every obligation, and the table sets out the four tiers and what each demands. The classification comes directly from the Regulation. Risk tier What it covers What the Act requires Prohibited AI practices deemed an unacceptable risk under Article 5, such as certain manipulative techniques and social scoring The practice is banned outright High-risk AI that is a product safety component or falls within the Act’s listed use cases under Article 6 An extensive set of obligations before and throughout use Limited risk AI that interacts directly with people or generates content, under Article 50 Transparency obligations Minimal risk All other AI systems No mandatory obligations under the Act The practical consequence of this structure is that classification is not a formality but the step that decides how much work an organization faces. Most business AI falls into either the high-risk or limited-risk tiers, and the gap between the two is large, so an honest classification, rather than an optimistic one, is where compliance genuinely begins. The tiers are mutually exclusive for a given use, which is why the checklist is built to be read one tier at a time. Prohibited Practices: What You Must Not Do The prohibited tier is the shortest part of any such checklist because it is a list of things to stop, not build. Article 5 bans a defined set of practices outright, including AI that uses subliminal or purposefully manipulative techniques to materially distort behavior, AI that exploits the vulnerabilities of specific groups, social scoring of individuals by public or private actors, and certain uses of biometric categorization and remote identification. An organization’s obligation here is simply to confirm that none of its systems, current or planned, fall into these categories. The reason this tier sits first on the checklist is that a prohibited practice cannot be remediated into compliance; it must be abandoned. Unlike a high-risk system, which becomes compliant through controls and documentation, a system whose purpose is a prohibited practice has no compliant version. Screening the AI portfolio against Article 5 early therefore prevents an organization from investing in a system it can never lawfully deploy. High-Risk Systems: The Core Obligations The high-risk tier carries the heaviest obligations, and it is where most of the checklist lives. A system is high-risk under Article 6 either when it is a safety component of a regulated product or when it falls within the Act’s listed high-risk use cases, which cover sensitive domains such as employment, access to essential services, and critical infrastructure. Once a system is classified high-risk, a defined program of requirements applies to it before it reaches the market and throughout its operation. The core requirements the Regulation sets for high-risk systems are a connected set, and a checklist should treat them as items to evidence rather than boxes to tick. They include a risk management system that runs across the lifecycle under Article 9, data and data governance practices under Article 10, technical documentation under Article 11, automatic record-keeping and logging under Article 12, transparency and information provided to deployers under Article 13, human oversight designed into the system under Article 14, and appropriate accuracy, robustness, and cybersecurity under Article 15. Surrounding these, providers must operate a quality management system, complete a conformity assessment before placing the system on the market, register it as required, and monitor it after deployment. The through-line across these obligations is evidence: each requirement is satisfied not by intent but by documentation that a regulator or a deployer can inspect, which is why a high-risk program looks in practice like a managed system rather than a one-time project. This is also where a structured AI risk assessment does much of the work, because the risk management requirement sits at the center of the high-risk obligations and feeds several of the others. Limited-Risk Systems: Transparency Obligations The limited-risk tier is defined by transparency rather than by the extensive controls of the high-risk tier. Under Article 50, systems that interact directly with people must make clear that a person is dealing with an AI system unless that is already obvious, and systems that generate or manipulate content must ensure that synthetic content, including deepfakes, is disclosed and detectable. Similar disclosure obligations apply to systems that perform emotion recognition or biometric categorization, which must inform the people exposed to them. The obligation for this tier is narrower but still real, and organizations often overlook it precisely because it feels light. A chatbot, a synthetic-media tool, or a recommendation interface may carry no high-risk obligations yet still owe clear disclosure to the people who encounter it. The checklist item for this tier is therefore to identify every system that interacts with people or produces content and confirm that its disclosures meet the transparency standard. Who the Obligations Fall On A checklist organized by risk tier answers what the obligations are, but a second question decides
AI Risk Assessment Template: The Fields Auditors Look For
An AI risk assessment template is only as useful as the fields it captures, and the fields that matter are the ones an auditor or regulator expects to see: not just the technical risk, but its impact on the people the AI system affects. A template that treats an AI risk like any other IT risk misses the element that AI governance frameworks specifically require, which is the assessment of impact on individuals and society. This guide sets out the fields an AI risk assessment template should contain, a scoring approach that prioritizes correctly, and a structure aligned to ISO 42001 and the NIST AI Risk Management Framework. The reason to build the assessment around the right fields, rather than reach for a generic risk register, is that AI risk has a dimension ordinary risk assessments do not capture. An AI system can create risks to fairness, safety, and the rights of the people it affects, and the frameworks that govern AI expect those to be assessed explicitly. A template that prompts for them turns an AI risk assessment from a repurposed security exercise into one that actually satisfies what AI governance requires. What an AI Risk Assessment Template Should Capture A strong template captures each risk in enough structured detail to assess, prioritize, and act on it, without becoming so heavy that no one completes it. At minimum it should identify the AI system or use case being assessed, describe the context and purpose, state the specific risk, and capture the AI-specific dimension of how that risk could affect individuals. It then records the likelihood and severity that produce a rating, the controls already in place, the resulting risk level, and the treatment plan with an owner. Each field does a distinct job, and the assessment is only as good as its weakest field. The field that distinguishes an AI risk assessment from a generic one is the impact on individuals and society. Ordinary risk assessments focus on impact to the organization, but AI governance frameworks require an organization to consider how an AI system affects the people subject to it, which is the substance of an AI impact assessment. Building that field into the template rather than bolting it on afterward is what makes the assessment defensible under AI governance scrutiny. The Fields That Matter The table sets out the fields a defensible template should contain, what each captures, and why it matters. It is a structure to adapt to the organization’s AI systems, not a fixed form. Field What it captures Why it matters AI system or use case The specific system or application being assessed Scopes the assessment to one clear subject Context and purpose What the system does, for whom, and in what setting Frames how the risk should be judged Risk description The specific risk, from security to fairness to safety The core of the entry Impact on individuals How the risk could affect the people the system touches The AI-specific element frameworks require Likelihood How likely the risk is to occur One half of the risk score Severity How damaging the risk would be if it occurred The other half of the risk score Existing controls What already mitigates the risk Determines the residual risk Risk rating The resulting priority level Drives the order of treatment Treatment and owner The plan to address the risk and who owns it Turns assessment into accountable action The pattern across the fields is that the first four define and contextualize the risk, the middle three score it, and the last two convert it into action. A template missing the impact-on-individuals field fails the AI-specific requirement, one missing existing controls overstates risk by ignoring mitigation already in place, and one missing an owner produces analysis no one acts on. The fields that organizations most often omit, impact on individuals and a named owner, are precisely the ones that make the difference between an assessment that satisfies a framework and one that sits unused. The Scoring Approach The scoring approach in the template combines likelihood and severity into a risk rating, which is the mechanism that turns a list of risks into a priority order. Most templates use a simple matrix in which likelihood and severity are each rated on a scale, and their combination places each risk into a level such as low, medium, high, or critical. What matters is less the exact scale than that it is applied consistently, so that risks can be compared and the highest-rated ones addressed first. The AI-specific refinement is that severity should account for impact on individuals, not only impact on the organization. A risk with modest operational cost but serious potential to harm or unfairly affect people should score as significant, because the frameworks weigh that impact heavily. Building this into the severity judgment, rather than scoring purely on business impact, is what aligns the template’s prioritization with how AI governance expects risks to be ranked. The output is a rated, ordered set of risks that tells the organization where to act first. How the Template Aligns to ISO 42001 For organizations working to ISO 42001, an AI risk assessment is not optional but required: the standard’s planning clause requires both an AI risk assessment and an AI impact assessment, and a template that captures both satisfies that requirement directly. The risk fields support the risk assessment, the impact-on-individuals field supports the impact assessment, and the treatment and control fields feed the risk treatment and the Statement of Applicability that ISO 42001 expects. A template built around these fields therefore produces exactly the documented information an ISO 42001 audit looks for. The connection to the wider standard is covered in the guide to ISO 42001 requirements, which shows how the risk and impact assessments sit within the management system, and the specific design of the impact assessment is covered in the guide to designing the AI impact assessment for ISO 42001. The AIMS Manual provides the broader documented-information