Table of Contents

Reach SOC 2 Compliance in 6 Weeks or Less.

  /

  / NIST AI RMF 1.0 Explained: The AI Governance Benchmark

NIST AI RMF 1.0 Explained: The AI Governance Benchmark

The NIST AI Risk Management Framework (AI RMF 1.0) is the most widely referenced standard for managing AI risk in the United States, and it is not a law, a regulation, or a certifiable standard. It is voluntary guidance. That combination explains both its rapid adoption and the confusion around it: regulators cite it, enterprise buyers ask about it in security questionnaires, and AI governance programs are built on it, yet no auditor will ever hand you an AI RMF certificate. This article explains what the framework actually contains, how its four core functions work, and where it fits alongside ISO/IEC 42001 and the EU AI Act.

NIST AI RMF 1.0

What Is the NIST AI RMF 1.0?

Background and Purpose of the Framework

The AI RMF is a structured approach for identifying, assessing, and managing the risks that AI systems create across their entire lifecycle, from design and data collection through deployment, monitoring, and decommissioning. Its stated goal is to help organizations build and use AI systems that are trustworthy: valid, reliable, safe, secure, accountable, transparent, explainable, privacy-enhanced, and fair. The framework treats AI as a socio-technical system, meaning risk does not come from models and data alone. It also comes from how people build, deploy, oversee, and interact with those systems. That framing is the single most important idea in the document, because it pushes risk management beyond model accuracy metrics and into governance, human oversight, and organizational culture.

Who Published It and When

The framework was published by the National Institute of Standards and Technology (NIST), an agency of the U.S. Department of Commerce, on January 26, 2023. The official document is NIST AI 100-1, developed over 18 months of public workshops, requests for information, and two public draft rounds. Congress directed NIST to create it through the National Artificial Intelligence Initiative Act of 2020, so the framework carries legislative backing even though compliance with it does not.

Voluntary Nature of the Framework

NIST describes the AI RMF as voluntary, rights-preserving, non-sector-specific, and use-case agnostic. There is no enforcement mechanism, no audit regime, and no certification. In practice, the word voluntary undersells its weight. U.S. regulators, including the FTC and sector agencies, reference NIST principles when assessing whether an organization exercised reasonable care; federal contractors face growing expectations to demonstrate NIST-aligned AI governance, and enterprise procurement teams increasingly ask vendors how they apply it. Voluntary frameworks have a habit of becoming de facto requirements, and the AI RMF is following that exact path.

Insider Note: In vendor risk assessments, “do you align with the NIST AI RMF” is becoming the AI equivalent of “do you have a SOC 2 report.” There is no certificate to show, so what buyers actually want is documented evidence: an AI inventory, a risk assessment methodology, and named accountability for AI decisions. Organizations that can produce those three artifacts pass most questionnaires.

Reach SOC 2 Compliance in 6 Weeks or Less

Schedule Your Free SOC 2 Assessment Today

Why the NIST AI RMF 1.0 Was Developed

Addressing Unique AI Risks

Traditional software risk frameworks assume deterministic systems: the same input produces the same output, and failures are traceable to specific defects. AI systems break those assumptions. Models drift as real-world data shifts; training data can embed historical bias at scale; outputs can be opaque even to their developers; and the same model can behave differently across deployment contexts. The AI RMF was built specifically for these properties. It treats risk as continuous rather than one-shot, requiring ongoing measurement and monitoring instead of a single pre-deployment review.

Building Trustworthy AI Systems

The second driver was the trust gap. By 2022, organizations were deploying AI faster than they could explain or govern it, and high-profile failures in hiring, lending, and facial recognition had made AI bias a mainstream concern. NIST’s answer was to define trustworthiness in operational terms rather than aspirational ones, breaking it into seven measurable characteristics that risk, security, and product teams could actually work against.

Key Drivers Behind Its Creation

Three forces converged. First, the congressional mandate in the National AI Initiative Act of 2020. Second, international momentum: the framework explicitly aligns with the OECD AI Principles, positioning U.S. guidance within a global consensus on responsible AI. Third, industry demand for a shared vocabulary. Before the AI RMF, every organization defined AI risk differently, which made procurement, audits, and cross-industry collaboration unnecessarily painful. The framework gave executives, engineers, auditors, and regulators a common language.

Core Concepts Behind the NIST AI RMF 1.0

Defining AI Risk

The framework defines risk as the composite measure of an event’s probability of occurring and the magnitude of its consequences. Two things distinguish the AI RMF’s treatment of risk from older frameworks. It explicitly considers positive impacts as well as harms, framing risk management as a way to maximize benefits, not just avoid downsides. And it acknowledges that AI risk is genuinely hard to measure: third-party models, emergent behavior, and a lack of agreed metrics mean organizations must often manage risks they cannot precisely quantify.

Characteristics of Trustworthy AI Systems

The AI RMF defines seven characteristics of trustworthy AI: valid and reliable; safe; secure and resilient; accountable and transparent; explainable and interpretable; privacy-enhanced; and fair with harmful bias managed. Validity and reliability is described as a necessary precondition for all the others, since an inaccurate system cannot be meaningfully safe or fair. The framework is candid that these characteristics involve trade-offs. Improving explainability can reduce accuracy, and strengthening privacy can limit the data available for bias testing. Managing those tensions is a governance decision, not a technical one.

Framing Risks: Harms to People, Organizations, and Ecosystems

The framework organizes potential harm into three groups. Harm to people covers individual civil liberties, physical and psychological safety, and economic opportunity, as well as harm to communities and society at large. Harm to organizations covers business disruption, security breaches, financial loss, and reputational damage. Harm to ecosystems covers damage to interconnected systems, including the global financial system, supply chains, and natural resources. This breadth is deliberate. It forces impact assessments to look beyond the deploying organization’s own balance sheet.

Structure of the NIST AI RMF 1.0

Part 1: Foundational Information

Part 1 sets the conceptual ground. It explains how AI risks differ from traditional software risks, defines the audience of AI actors — everyone who plays a role across the AI lifecycle, from data scientists to procurement teams to end users — describes the harm taxonomy above, and details the seven trustworthiness characteristics. It also addresses the practical challenges of risk measurement, risk tolerance, and prioritization, acknowledging that organizations cannot eliminate AI risk and should not try to treat every system as equally critical.

Part 2: Core and Profiles

Part 2 is the operational half. It presents the AI RMF Core: four functions broken into categories and subcategories that describe specific outcomes, plus the concept of Profiles for tailoring the framework to specific use cases and sectors. If Part 1 explains why AI risk management matters, Part 2 is the part teams actually implement.

The Four Core Functions of the NIST AI RMF 1.0 Explained

The Core organizes everything into four functions: Govern, Map, Measure, and Manage. They are not sequential steps. Govern is cross-cutting and continuous, while Map, Measure, and Manage are applied to specific AI systems and contexts, often iteratively.

Govern

Govern establishes the organizational foundation: policies, accountability structures, risk tolerance, and culture. It covers legal and regulatory compliance, workforce diversity and competence, third-party risk, and processes for engaging affected communities. NIST positions Govern as the function everything else depends on. Without named accountability and a defined risk appetite, mapping and measuring risks produces documentation that nobody acts on.

Map

Map establishes context. For each AI system, the organization documents its intended purpose, deployment setting, the people it affects, its capabilities and limitations, and the risks and benefits of each component, including third-party models and data. Mapping is where most organizations discover their first uncomfortable truth: they do not actually know how many AI systems they are running, especially once embedded AI features in SaaS tools are counted.

Measure

Measure analyzes and tracks the risks identified during mapping, using quantitative and qualitative methods. This includes testing systems against each trustworthiness characteristic, monitoring for drift in production, and evaluating the effectiveness of the measurement program itself. The framework leans heavily on test, evaluation, verification, and validation (TEVV) processes performed throughout the lifecycle rather than once before launch.

Manage

Manage allocates resources to treat the risks that mapping and measuring surfaced, based on the priorities Govern established. It covers risk response (mitigate, transfer, avoid, or accept), documentation of residual risk, incident response, and decommissioning. Manage closes the loop: it is where risk assessments turn into decisions, including the decision not to deploy a system at all.

Pro Tip: Do not start with Map

Do not start with Map, even though it looks like the natural first step. Start with two Govern outcomes: name a single accountable owner for AI risk and write a one-page AI use policy. Then build the system inventory. Teams that inventory first, without an owner, produce a spreadsheet that goes stale within a quarter.

AI RMF Profiles Explained

Profiles are implementations of the framework’s functions, categories, and subcategories tailored to a specific setting. The framework describes three kinds.

Use-Case Profiles

A use-case profile applies the framework to a particular application or sector, such as hiring, lending, or fraud detection. The most significant published example is the Generative AI Profile (NIST AI 600-1), released in July 2024, which identifies twelve risks unique to or amplified by generative AI — including confabulation, data privacy leakage, and harmful content generation — and maps suggested actions to the Core’s subcategories. In April 2026, NIST also released a concept note for a profile on trustworthy AI in critical infrastructure.

Cross-Sectoral Profiles

Cross-sectoral profiles address risks from activities or technologies that cut across industries, such as large language models or cloud-based AI services, rather than a single vertical application. They help organizations govern shared infrastructure consistently across many use cases.

Temporal Profiles

Temporal profiles describe state over time. A current profile documents how an organization manages AI risk today; a target profile describes the desired end state. The gap between the two becomes the AI governance roadmap — the same gap-analysis pattern familiar from the NIST Cybersecurity Framework and ISO 27001 implementations.

 

AI RMF Categories and Subcategories Overview

Beneath the four functions sit 19 categories and 72 subcategories. Govern is the largest function with six categories spanning policy, accountability, culture, and third-party oversight. Map contains five categories covering context, system categorization, capabilities, component risks, and impact characterization. Measure has four categories on metrics, trustworthiness evaluation, risk tracking, and feedback on measurement effectiveness. Manage has four categories on risk prioritization, treatment strategy, third-party risk management, and response and recovery. Each subcategory is an outcome statement, not a control. The framework tells you what good looks like and leaves the how to you, which is precisely where the Playbook comes in.

 

The AI RMF Playbook: Companion Resource Explained

The AI RMF Playbook is the framework’s practical companion, hosted in NIST’s Trustworthy and Responsible AI Resource Center. For every subcategory, it provides suggested actions, documentation guidance, and references. NIST is explicit that the Playbook is neither a checklist nor an ordered list of steps; organizations borrow what applies to their context. It is also updated more frequently than the framework itself, making it the best place to track NIST’s evolving thinking between formal revisions. For teams staring at 72 outcome statements and wondering where to begin, the Playbook is the difference between a framework and an implementation plan.

Key Benefits of the NIST AI RMF 1.0

The framework’s flexibility is its biggest practical advantage. Because it is technology-neutral and scales to organization size, a 50-person SaaS company and a global bank can both use it without absurd overhead on one end or insufficient rigor on the other. Its structure also plugs neatly into existing governance: the function-category-subcategory model mirrors the NIST Cybersecurity Framework, so security and compliance teams can extend processes they already run rather than building a parallel program. It improves stakeholder communication by giving boards, engineers, and auditors a shared vocabulary. And alignment with it strengthens regulatory positioning: demonstrating AI RMF-based governance is increasingly treated as evidence of reasonable care, and it provides a head start on overlapping requirements in ISO/IEC 42001 and the EU AI Act.

 

Limitations of the NIST AI RMF 1.0

The flexibility cuts both ways. The framework specifies outcomes, not controls, so two organizations can both claim alignment while doing very different amounts of actual risk management. There is no certification, which means no independent verification and no simple artifact to hand a customer. It offers limited prescriptive guidance on emerging issues like agentic AI, and its risk measurement guidance acknowledges — honestly but unhelpfully — that reliable metrics for many AI risks do not yet exist. Finally, it is a living document: the AI RMF 1.0 is currently under revision, per NIST and the 2025 U.S. AI Action Plan, so organizations building programs on it today should design for change rather than treating the 2023 text as final.

Worth Knowing: NIST uses a Two-number Versioning System

NIST uses a two-number versioning system: major revisions increment the generation (1.0 to 2.0) and minor updates add a decimal (1.1). The pending revision will be the first test of how disruptive a framework update is in practice. Organizations that mapped their controls to subcategory IDs, rather than copying text into policies, will absorb the change with far less rework.

How the NIST AI RMF 1.0 Compares to Other Frameworks

NIST AI RMF vs. ISO/IEC 42001

ISO/IEC 42001, published in December 2023, is the international standard for AI management systems (AIMS), and the comparison with the AI RMF comes down to one word: certification. ISO/IEC 42001 is auditable and certifiable; the AI RMF is not. The two are complementary rather than competing. Many organizations use the AI RMF to structure their risk thinking and ISO/IEC 42001 to formalize and certify the resulting management system, much as the NIST Cybersecurity Framework and ISO 27001 coexist in security programs.

NIST AI RMF vs. EU AI Act

The EU AI Act is the comparison that matters most for any organization selling into Europe, and it is a category difference: the EU AI Act is binding law with penalties, while the AI RMF is guidance. The Act entered into force in August 2024 and applies in phases; prohibited practices took effect in February 2025 and obligations for general-purpose AI models in August 2025. In May 2026, EU lawmakers reached provisional agreement under the Digital Omnibus to defer the main high-risk system obligations to December 2027, a 16-month delay reflecting how unprepared the supporting standards ecosystem was. The frameworks are philosophically aligned on risk-based thinking, and AI RMF implementation builds much of the documentation, risk assessment, and human oversight machinery the Act requires. But alignment with the AI RMF does not constitute EU AI Act compliance, and treating it as such is a genuine legal exposure.

Important: A common and costly misconception: “we follow NIST, so we are covered for the EU AI Act.” The AI RMF has no concept of prohibited practices, conformity assessment, or CE marking. If you deploy high-risk systems in the EU, the AI RMF is a strong foundation, not a substitute. Run a separate gap analysis against the Act’s specific articles.

Reach SOC 2 Compliance in 6 Weeks or Less

Schedule Your Free SOC 2 Assessment Today

Conclusion

The NIST AI RMF 1.0 earned its position the hard way: by being useful. It gave organizations a shared definition of AI risk, a workable structure in Govern, Map, Measure, and Manage, and the flexibility to scale from a single chatbot deployment to an enterprise AI portfolio — all without licensing fees or audit gatekeeping. Its voluntary status is a feature and a limitation at once, which is why mature AI governance programs rarely use it alone, pairing it instead with ISO/IEC 42001 for assurance and EU AI Act mapping for legal compliance. For organizations starting their AI governance journey, it remains the most sensible first framework to adopt, with the official NIST AI RMF resources as the starting point.

Frequently Asked Questions

Is the NIST AI RMF 1.0 mandatory?

No. It is voluntary guidance with no certification or enforcement mechanism. In practice, U.S. regulators reference it as a benchmark for reasonable care, federal procurement increasingly expects alignment, and enterprise customers ask about it in vendor assessments — so for many organizations it is voluntary in name only.

Any organization that designs, develops, deploys, procures, or uses AI systems. The framework deliberately addresses all AI actors across the lifecycle, from data engineers to risk and compliance teams to executives. It scales to organization size, so it is as relevant to a startup embedding an LLM in its product as it is to a regulated enterprise.

NIST uses a two-number versioning system: major revisions change the generation number and minor updates are tracked as point releases. Version 1.0 was published in January 2023 and is currently being revised under the U.S. AI Action Plan. The companion AI RMF Playbook is updated more frequently than the framework itself.

Yes, through the Generative AI Profile (NIST AI 600-1), released in July 2024. It identifies twelve risks unique to or amplified by generative AI — including confabulation, information security weaknesses, and harmful content — and maps several hundred suggested actions back to the framework’s core subcategories.

There is no certification deadline, so adoption is a maturity curve rather than a project with an end date. Most organizations can stand up the essentials — a named owner, an AI use policy, a system inventory, and an initial risk assessment — within one to three months. Building out measurement, monitoring, and third-party risk processes across all four functions typically takes six to twelve months, and the framework itself frames risk management as a continuous activity thereafter.

Axipro Author

Picture of Pedro Dias

Pedro Dias

Pedro has been writing online for over 10 years. With experience in all things programming, cyber security, and compliance, he is our editor-in-chief at Axipro.

Blog Highlights

Explore More Articles

CMMC certification costs between $4,000 and $30,000 at Level 1, $30,000 to $300,000 or more at Level 2, and $100,000 to well over $1 million at Level 3. Most contractors expect the audit fee to be the big number. It isn’t. The formal assessment typically accounts for only 25% to 40% of total spend, with preparation, remediation, and technology upgrades consuming the rest. The stakes changed in late 2025. The final 48 CFR acquisition rule took effect on November 10, 2025, which means CMMC requirements now appear directly in Department of Defense (DoD) solicitations and contracts. Starting in November 2026, Phase 2 of the rollout gives contracting officers the authority to require third-party certification for Level 2 work. If you handle Controlled Unclassified Information (CUI), certification is no longer optional, and the cost question becomes a budgeting exercise rather than a hypothetical. This guide breaks down every major cost category, what moves your number up or down, and how to keep the total under control. What Is CMMC Certification and Why Does Cost Vary? The Cybersecurity Maturity Model Certification (CMMC) is the DoD’s framework for verifying that companies in the Defense Industrial Base (DIB) actually protect the sensitive information they handle. The program, codified in 32 CFR Part 170, builds on the security requirements of NIST SP 800-171 and, at the top tier, selected controls from NIST SP 800-172. Costs vary so widely because you can’t buy CMMC off a shelf. Your environment has to reach a certain state and then stay there. A 15-person machine shop with one well-scoped CUI enclave faces a fundamentally different project than a 500-person prime contractor with CUI flowing through a dozen systems. Your starting security posture, the scope of your assessment boundary, and whether you build internally or hire help all move the total by six figures in either direction. Average CMMC Certification Cost at a Glance The DoD’s own published estimates are instructive. A triennial Level 2 certification assessment, including affirmations, is projected at roughly $105,000 for small entities and $118,000 for larger ones. Those figures cover only assessment and affirmation activities, though. The DoD excludes implementation costs from its estimates on the grounds that NIST SP 800-171 compliance has been contractually required under DFARS 252.204-7012 since 2017. Your real budget has to cover both. CMMC Certification Cost by Level CMMC Level 1 (Foundational) Cost: $5,000 – $30,000 Level 1 covers Federal Contract Information (FCI) and requires 15 basic safeguarding practices drawn from FAR 52.204-21. Because Level 1 permits an annual self-assessment with no third-party auditor, the costs are internal labor, basic tooling, and documentation. Small contractors with reasonable IT hygiene often land near the bottom of the range. The DoD estimates annual Level 1 assessment and affirmation activity at around $6,000 for a small entity, with the remainder of the range driven by any remediation needed to attest honestly. CMMC Level 2 (Advanced) Cost: $50,000 – $300,000+ Level 2 is where most of the DIB lands and where budgets get serious. It requires full implementation of all 110 security requirements in NIST SP 800-171, assessed across 320 individual objectives. For most contracts, a C3PAO (Certified Third-Party Assessor Organization) accredited by the Cyber AB has to conduct the assessment every three years. Market data puts C3PAO assessment fees at $30,000 to $100,000 depending on scope, site count, and complexity. Preparation dwarfs that figure for most organizations. Companies starting from a low maturity baseline routinely spend three to four times the assessment fee on readiness work before an auditor ever shows up. CMMC Level 3 (Expert) Cost: $300,000 – $1,000,000+ Level 3 adds 24 enhanced requirements from NIST SP 800-172 on top of a completed Level 2 certification, and the assessment is conducted by the government’s DIBCAC rather than a commercial C3PAO. DIBCAC charges no assessment fee, but don’t mistake free for cheap. The DoD estimated roughly $41,000 in additional implementation cost for the 800-172 controls alone, and total triennial assessment-related costs in the $146,000 to $159,000 range. Real-world totals run far higher once you account for the advanced tooling, threat hunting capability, and organizational changes Level 3 demands. Only contractors supporting the most sensitive programs need this tier. Worth Knowing: You can’t skip to Level 3. You can’t skip to Level 3. A final Level 2 certification with all POA&M items closed is a prerequisite for the same assessment scope, so Level 3 budgets always include a full Level 2 project first. CMMC Certification Cost Breakdown by Expense Category Gap Assessment and Readiness Planning Costs A gap assessment maps your current environment against NIST SP 800-171 and typically costs $1,500 to $20,000 depending on depth and scope. This is the most valuable dollar you’ll spend in the entire project, because everything downstream is priced off what it finds. Documentation and System Security Plan (SSP) Costs The System Security Plan (SSP) is the cornerstone document of any assessment, mapping every control to your specific implementation. Professionally developed SSPs and supporting policies run $12,000 to $60,000. A weak SSP is one of the most common reasons assessments stall or fail, so this is a poor place to economize. Remediation and Security Control Implementation Costs Closing the gaps is usually the largest line item: $20,000 to $150,000 or more. Multi-factor authentication, logging and SIEM deployment, encryption, access control restructuring, and incident response capability all live here. Organizations with mature security postures spend far less than those starting from scratch. Technology and Infrastructure Upgrade Costs Many contractors move CUI into a dedicated enclave rather than securing their entire network. Enclave platforms typically cost $300 to $400 per user per month. Others upgrade endpoint protection, replace unsupported systems, or migrate to government-grade cloud environments, each with its own licensing and migration costs. C3PAO Assessment and Audit Fees The formal Level 2 assessment runs $30,000 to $100,000, driven by assessor-days, number of sites, and evidence quality. Well-organized evidence directly reduces assessor time and therefore your invoice. Consulting and Advisory Fees Specialist consultants, including Registered Practitioners (RPs) and

SOC 2 and ISO 27001 Engagement

After a SOC 2 and ISO 27001 engagement, there are two documents out of the whole pile that actually close deals: the SOC 2 attestation report and the ISO 27001 certificate. Everything else your engagement produces exists to create those two, support them, or keep them alive for another year. Companies routinely ask their auditor for a SOC 2 certificate, which doesn’t exist. They send a prospect their full ISMS documentation when a one-page certificate would have done. They pay for six months of readiness work and then can’t say what they’re holding at the end of it. So here’s the full list. What a SOC 2 engagement produces, what an ISO 27001 engagement produces, what a combined program produces, and who gets to see each one. Understanding SOC 2 and ISO 27001 Engagement Outputs The Core Difference: Report vs. Certificate SOC 2 is an attestation. A licensed CPA firm examines your controls against the Trust Services Criteria under standards set by the AICPA, then writes up what it found and signs an opinion. No certificate. No logo from the AICPA. No pass or fail stamp. What you get is the report, and it usually runs 60 to 120 pages. ISO 27001 is a certification. An accredited certification body audits your Information Security Management System (ISMS) against ISO/IEC 27001:2022, and if you conform, it issues a certificate of registration. The certificate itself is a page or two. All the detail lives behind it, in your ISMS documentation and the audit reports the certification body writes as it goes. SOC 2 Engagement Deliverables The SOC 2 Attestation Report The report is the engagement. The AICPA’s illustrative SOC 2 report lays out the standard structure: auditor’s report, management’s assertion, system description, the Trust Services Criteria in scope, and the controls tested with their results. A Type I covers control design at one point in time. A Type II covers whether those controls actually operated over a period, usually three to twelve months, and most enterprise buyers now won’t accept anything else. Independent Auditor’s Opinion Letter First section of the report, and the first thing anyone experienced turns to. It gives the scope, the examination period, and the auditor’s conclusion. An unqualified opinion means the description held up and the controls worked. A qualified opinion means the auditor found something material, and every serious reviewer will want to talk about it. Management Assertion Your leadership signs a written statement stating that the system description is accurate and that the controls were properly designed and are operating. It reads like a formality, and it isn’t. The auditor’s entire examination runs against what management asserts here, so overstating anything creates real exposure. System Description Usually the longest part of the report, and you write it, not the auditor. It covers the services in scope, your infrastructure, software, people, processes, how data moves, which subservice organizations you depend on, and the complementary user entity controls your customers have to run on their side for your controls to hold up. Trust Services Criteria Applied Security (the Common Criteria) is in every SOC 2. Availability, Processing Integrity, Confidentiality, and Privacy are optional, and the report names exactly which ones you picked. Whatever you decide during scoping ends up printed in a document your customers read for the next several years. Description of Tests of Controls and Results (Type II) The matrix: every control, what the auditor did to test it, and what came back, including exceptions. Reviewers spend most of their time here, because the exceptions tell them things the opinion letter won’t. Bridge Letter / Gap Letter Your report covers a fixed window, so one ending December 31 leaves a hole for a customer doing diligence in June. A bridge letter from your management, not the auditor, confirms that nothing material changed in the control environment between the report’s end date and today. You’ll write these often enough to keep a template. Management Letter and Observations Plenty of auditors also send an internal-only letter covering observations, minor exceptions, and suggestions that never reached the threshold of a qualified opinion. It’s the closest thing to free consulting you’ll get before next year’s audit starts. Insider Note: Ask early whether your auditor issues a management letter, and whether exceptions land in the report body or only in that letter. Firms handle this differently, and the answer decides what your customers see versus what stays behind your firewall. It rarely comes up in the proposal, but it changes how the finished report reads to a buyer. ISO 27001 Engagement Deliverables ISO 27001 Certificate of Registration The document everyone asks for. It names the certified legal entity, states the ISMS scope, identifies the certification body, carries an accreditation mark from a body recognized under the International Accreditation Forum such as UKAS or ANAB, and shows the validity dates. It’s good for three years as long as you pass annual surveillance audits. Read the scope statement carefully, on your own certificate as much as anyone else’s. A certificate covering one office or one product line says nothing about the rest of the business. Statement of Applicability (SoA) After the certificate, this is the document buyers request most. The Statement of Applicability runs through all 93 Annex A controls in ISO/IEC 27001:2022, says which apply to you, justifies the ones you excluded, and records where each stands. Auditors use it as the map of your control environment, and larger customers increasingly want to see it or a summary of it during diligence. Risk Assessment and Risk Treatment Plan Your methodology, the register it produced, and the Risk Treatment Plan showing what you decided to do about each significant risk: mitigate it with a control, transfer it, avoid it, or accept it. ISO 27001 is built around risk, so these documents are what justify every control decision recorded in the SoA. Information Security Management System (ISMS) Documentation The policy and procedure set, plus the operational records that prove any of it happens. Information

The EU AI Act’s transparency requirements take effect on 2 August 2026, and most of the companies they cover still think the rules are not their problem. Article 50 applies to any business that publishes AI-generated content or runs an AI system that talks to people in the EU. That includes the marketing team generating campaign images and the support team running a chatbot. It also covers the AI agents you’ve wired into customer email. Penalties reach €15 million or 3% of total worldwide annual turnover, whichever is higher, and you don’t need an office in Europe to be in scope. If your content or your chatbot reaches EU users, the obligations reach you. In a nutshell: if you publish AI-generated images or video, deploy chatbots or AI agents that interact with EU users, or publish AI-written text on matters of public interest, then yes, the EU AI Act applies, starting 2 August 2026. A quick word on the “AI Act delay” headlines. The Digital Omnibus package did push the high-risk system deadlines back, in some cases by more than a year, but it did not move the deployer obligations in Article 50. Companies that read those headlines and stood down their AI Act work made an expensive mistake, because the rules most likely to touch an ordinary business are the ones that stayed on the calendar. What Article 50 Actually Requires Article 50 of the AI Act sets out transparency obligations in four situations. In plain English: Tell people when they’re talking to AI. Systems designed to interact directly with people — chatbots, voice assistants, and AI agents — must make clear that the user is dealing with AI, unless that’s already obvious. Mark AI-generated content so machines can detect it. Providers of generative AI systems must mark outputs in a machine-readable format, typically through metadata and watermarking, so the content is detectable as artificially generated. Label deepfakes. Anyone deploying AI to generate or manipulate image, audio, or video content that resembles real people, places, objects, or events, and could falsely appear authentic, must disclose that the content is artificial. Label AI-generated text on matters of public interest. Text published to inform the public must carry a label if AI-generated or manipulated, unless a human reviewed it and a person or organization holds editorial responsibility for it. Article 50 also covers emotion recognition and biometric categorization systems, which carry their own disclosure duties. Far fewer businesses run into those, so this article sticks to the four above. The distinction running through all of this is provider vs deployer. The provider builds or supplies the AI system. The deployer uses it professionally. Most companies reading this are deployers. If You Use AI-Generated Images Realistic AI images sit closer to the deepfake rules than most marketing teams assume. The Act’s definition covers content depicting people, objects, places, and events that could falsely appear authentic to a viewer, which describes a large share of what image generators produce for campaigns, social posts, and landing pages. So what does “clearly and distinguishably labeled” mean? The threshold is best described by its failures: a tiny disclosure hidden in the website footer doesn’t qualify. Neither does a faint label on an image, a label that flashes for an instant in a video, or a disclosure buried in your terms and conditions. The label has to be visible right where someone sees the content, and it has to meet accessibility standards so people with disabilities can perceive it too. The Code of Practice proposes a standardized “AI” visual label, localized per language (“KI” in German, “IA” in French). It also draws a useful line between fully AI-generated content and AI-assisted content, with lighter requirements for the latter. A designer who used AI to extend a background is in a different position from a team publishing a fully synthetic image of a person who doesn’t exist. Important: The deepfake duty doesn’t care about intent. A flattering, harmless AI image of your CEO at an event that never happened is still a deepfake under the Act. Marketing teams generate this kind of content casually. From August, every one of those images needs a label. If You Deploy AI Agents or Chatbots The rule itself is simple: people must know they’re dealing with AI. The provider carries the design obligation, but as the deployer you’re the one putting the system in front of your customers, and you’re the one an EU regulator will contact if your branded assistant pretends to be human. The Act contains an exception for cases where it’s “obvious” the user is talking to AI, judged from the perspective of a reasonably well-informed and observant person. Don’t lean on it. What’s obvious to your product team isn’t obvious to every customer, and the human-sounding voice agents and email-writing AI agents rolling out right now are designed specifically to not feel like software. If an AI agent negotiates a renewal over email or handles a support ticket end to end, disclose it. Pro Tip: Put the Disclosure at the Start of the Interaction Put the disclosure at the start of the interaction, in the interface itself: “You’re chatting with an AI assistant.” A line in your privacy policy doesn’t meet the standard, and a disclosure that appears after the conversation ends is worthless. For voice agents, say it up front in the greeting. What Your AI Vendors Owe You The machine-readable marking obligation in Article 50(2) sits with providers — the companies supplying your generative AI tools. The final Code of Practice expects providers to apply at least two layers of marking where necessary, such as embedded metadata combined with watermarking, and to offer detection mechanisms so deployers, authorities, and researchers can verify whether a piece of content came from AI. One timing caveat: the Digital Omnibus gives generative AI systems already on the market before 2 August 2026 until 2 December 2026 to comply with the marking requirement. Every other Article 50 obligation stays on