What does ISO/IEC 27090:2026 require?

ISO/IEC 27090:2026 provides AI security guidance, not a substitute for an organization’s management system or a universal implementation checklist. Published on October 14, 2026, it addresses threats and compromises affecting AI systems, including the protection of data and models. Teams investigating “ISO 27090 2026 requirements” should therefore distinguish the standard’s guidance from the specific obligations their organization adopts through policies, contracts, and applicable frameworks. (iso.org)

That distinction is critical when evaluating technology. Buying a platform does not establish that your chosen controls cover every relevant threat, operate effectively, or have accountable owners. Treat platform selection as one part of an evidence-led implementation programme rather than its completion.

For practical purposes, organize your assessment around three questions:

1. What needs protection?
2. Which attacks could compromise it?
3. What evidence demonstrates that safeguards work?

Build a compliance framework around existing governance

ISO/IEC 27090 is designed to complement established frameworks. BSI explains that its AI-specific risks and safeguards can feed into information security management under ISO/IEC 27001 and ISO/IEC 27002, and AI governance under ISO/IEC 42001, rather than creating a separate management system. (bsigroup.com)

A practical approach is to extend your existing compliance framework with an AI security workstream. Give each assessed system a business owner, technical owner, security reviewer, and documented approval route. Decide who can accept residual risk and who can suspend operation when safeguards fail.

Use a working register with these fields:

• System and purpose: Identify the business process, intended users, and permitted activities.
• Assets and dependencies: Record models, datasets, tools, integrations, and external providers.
• Threat scenario: Describe the attacker’s opportunity and the potential business consequence.
• Control and owner: Specify the safeguard, its operating boundary, and who maintains it.
• Evidence and review: Link test results, configuration records, exceptions, and reassessment triggers.

For example, avoid recording only “unauthorized disclosure.” Specify that a service agent could retrieve restricted documents and transmit them through an external tool. That wording gives reviewers a concrete path to investigate and a control boundary to test.

Establish an inventory that supports security decisions

Outerlimit Discover continuously identifies agents, tools, integrations, and Model Context Protocol (MCP) servers, including unsanctioned deployments. In addition, it applies risk scoring based on factors such as permissions, data access, identity, and behaviour. These functions provide a comprehensive agent inventory and risk-prioritization starting point for an agent inventory and risk-prioritized investigation. (outerlimit.com/platform/discover)

During evaluation, compare discovered records with engineering inventories, procurement records, and business-team declarations. Ask which environments and deployment types are covered, how frequently records refresh, and how unsupported assets are represented. Treat coverage as something to verify, not an assumption based on a dashboard total.

Enrich the technical inventory with business context. Record whether an agent only retrieves information or can also change records, send messages, approve transactions, or invoke other agents. Assign an owner to unexplained discoveries and document whether each deployment is approved, restricted, or awaiting review.

Prioritize assessment by potential consequence. A useful pilot candidate is a bounded workflow with meaningful permissions and an available business owner, not simply whichever agent is easiest to connect.

Translate AI threats into testable security requirements

AI threat assessment should account for attack methods, attacker capabilities, and the stage at which compromise could occur. NIST’s adversarial machine learning taxonomy provides a supporting vocabulary for organizing those considerations; it is a separate resource, not an ISO/IEC 27090 control mapping. (nist.gov)

For each relevant scenario, write a requirement that describes an observable outcome. State what must be prevented or detected, where the safeguard operates, and what constitutes a failed test. Avoid broad requirements such as “the AI must be secure,” which provide no useful acceptance criteria.

Protect data, models, and development changes

Data poisoning, model theft, prompt injection, and leakage of training data or model inputs are among the threats described in BSI’s explanation of the standard. These examples make clear why an assessment cannot stop at agent permissions. (bsigroup.com)

Consider requirements such as approved data-source registration, controlled changes to training pipelines, restricted access to model artifacts, and security review before production promotion. Tailor them to your architecture and responsibilities. A business consuming a hosted model should investigate provider assurances and integration controls rather than claim responsibility for training processes it cannot inspect.

NIST SP 800-218A provides complementary secure-development guidance for generative AI and dual-use foundation models. Use it alongside your development practices where applicable, without presenting it as evidence of ISO alignment by itself. (csrc.nist.gov)

Set boundaries for agent actions

For an agent enabled workflow, define permitted tools, target resources, initiating identities, and prohibited operations. Include both allowed and denied cases in acceptance testing. A restriction is useful only if legitimate work remains possible and prohibited work fails at the intended boundary.

For example, propose a policy that allows a support agent to read assigned cases but not export the entire customer database. Test the ordinary retrieval path, an explicit export request, and an attempt to invoke the same capability through a different tool. Record the expected outcome before running each test.

How can Outerlimit support the implementation programme?

Outerlimit can support the agentic AI portion of the programme through discovery, observability, and enforcement. Its documented approach applies authorization at tool execution layer rather than relying solely on upstream prompts or agent reasoning. The alignment below is an implementation interpretation of published capabilities, not an official ISO mapping or a guarantee of compliance. (outerlimit.com/platform)

‍

‍

This mapping follows Outerlimit’s Discover, Observe, and Enforce Platform. It should be validated against the integrations and deployment configuration you use. (outerlimit.com/platform)

Outerlimit Observe records governed tool calls with associated agent, user, policy, and reason information, and supports reconstruction of execution flows. It is important to verify retention, exports, access restrictions, and investigation procedures before treating telemetry as assessment evidence.

Keep lifecycle safeguards outside the platform in scope

ISO’s description explicitly includes security across development, operation, and model updates. It also notes that corrupted operational data can introduce vulnerabilities when reused for updating or retraining models. An agent runtime deployment should therefore sit within a broader lifecycle assessment. (iso.org)

For your gap review, assign responsibility for data sourcing, model acquisition, development access, release approval, supplier review, and retirement. Identify which controls are internal, which depend on providers, and which remain unresolved.

Define incident procedures before rollout. Specify who can disable a tool connection, restrict an agent, preserve records, and authorize restoration. Exercise those decisions using a realistic scenario so ownership is settled before an actual investigation.

What evidence demonstrates meaningful alignment?

A useful evidence package connects each assessed threat to a chosen safeguard, an accountable owner, and a repeatable effectiveness test. Use that as your internal acceptance model, then check it against the published standard and your wider assurance obligations. A feature list alone should not be your acceptance criterion.

For each priority workflow, assemble:

1. Scope and architecture: The system boundary, data flows, dependencies, and excluded components.
2. Risk assessment: Relevant attack scenarios, potential consequences, and treatment decisions.
3. Control configuration: Approved policies, access restrictions, versions, and change records.
4. Test evidence: Preconditions, expected outcomes, actual results, and unresolved findings.
5. Operational records: Representative activity, investigations, exceptions, and reviewer decisions.
6. Residual-risk approval: Named acceptance authority, rationale, conditions, and review date.

Use NIST’s attack taxonomy to help diversify test scenarios beyond a single prompt-injection example. Its coverage distinguishes attack types and discusses mitigation limitations, providing useful input for test planning. (nist.gov)

Include negative findings in the package. If an execution path is not covered, state that clearly and document the compensating action or deployment restriction. An honest boundary gives decision-makers something actionable; an unqualified “protected” label does not.

Roll out controls through a bounded pilot

Start with one workflow and explicit success criteria. Establish its inventory, document intended behaviour, review observed activity and agree the first enforcement policies with the business owner. Expand only after you have tested both security outcomes and operational usability.

A practical rollout sequence is:

• Scope: Select the workflow, responsible team, integrations, and assessment boundary.
• Baseline: Observe legitimate activity and investigate unexplained access or tool use.
• Test: Run approved adversarial and ordinary scenarios with expected outcomes recorded.
• Enforce: Activate agreed restrictions and confirm recovery procedures.
• Review: Resolve findings, approve remaining risk, and decide whether broader deployment is justified.

Schedule reassessment when a workflow gains a new tool, broader permissions, another model, or a changed data source. Use these changes as prompts to revisit assumptions rather than merely update an inventory field. Keep policy changes reviewable, with a clear rollback route and a named approver.

Turn alignment into an operating practice

Understanding the requirements to meet the new ISO 27090:2026 standard, aligned to Outerlimit’s AI security and governance platform, starts with separating guidance, organizational obligations, and product capabilities. Use the standard to inform the threat assessment, then establish your own documented controls and acceptance evidence.

The next step is a scoped workshop involving security, AI engineering, governance, and the workflow owner. Bring an architecture diagram, consequential agent workflows, and several concrete attack scenarios. Using Outerlimit, demonstrate the relevant discovery, evidence, and enforcement paths, then document both the supported controls and the remaining gaps before expanding deployment.

‍