ISO 42001 vs. ISO 27001: Do You Need Both If Your SaaS Product Uses AI?

This post is for security, compliance, and product leaders at B2B SaaS companies that already have ISO 27001 or SOC 2 in place and are deciding what to change as AI enters the product.

A company spends a year getting ISO 27001 right. Access control, secure development, vulnerability management, cloud infrastructure, incident response, supplier management, ongoing risk assessment - all of it documented, tested, and certified. Then the product adds an AI assistant. Maybe it's RAG over customer data, maybe it's an agent that can take actions in other systems, maybe it's just a chatbot bolted onto the dashboard.

Within a quarter, enterprise prospects start asking how the AI is governed. Now the internal team is wondering whether adding AI means ISO 27001 is no longer enough, and is wondering whether you actually need both certifications.

It’s not so black and white. ISO 27001 and ISO 42001 address different but increasingly overlapping problems. ISO 27001 manages information security risk. ISO 42001 establishes an AI management system (AIMS) specifically for the responsible development, provision, and use of AI. Using AI does not automatically mean a SaaS company needs ISO 42001 certification, but ISO 27001 alone does not cover the AI-specific governance, risk, impact, lifecycle, and responsible-use questions that ISO 42001 was built to address. 

This post explains what ISO 42001 adds to ISO 27001, when SaaS companies should consider pursuing it, and how adding AI affects security and penetration testing.

Key takeaways

• ISO 27001 and ISO 42001 aren't interchangeable. They manage different kinds of risk.
• Using AI doesn't automatically require ISO 42001 certification.
• ISO 42001 becomes worth considering once AI is material to the product and customers start asking how it's governed.
• When both apply, you can integrate the two management systems rather than running two disconnected programs.
• If AI introduces RAG, agents, model integrations, or new data flows, your existing ISO 27001 pentest scope may need to expand to cover the new attack surface.

ISO 42001 vs. ISO 27001: Key Differences

At the highest level, the two standards manage different kinds of risk:

ISO 42001 and ISO 27001 are built on the same ISO management system structure, but they're aimed at different problems. A company can be fully ISO 27001 compliant and still have no structured way to answer questions such as "What happens if this model behaves unpredictably?" or "Did we assess the impact of this AI feature on the people it affects?" ISO 42001 exists to close that gap. For SaaS companies, that distinction matters because some of the controls, evidence, and security testing already used for ISO 27001 can carry over, while AI-specific risks may require new governance and additional technical validation. 

Do SaaS Companies Using AI Need ISO 42001?

No, using AI doesn't automatically require ISO 42001 certification

Using AI, implementing an AIMS, conforming to ISO 42001, and obtaining third-party ISO 42001 certification are four different things, and they don't happen automatically in sequence. A SaaS company can use AI features without ever building a formal AIMS. It can build an AIMS and manage AI risk in a structured way without pursuing certification. Certification is a business decision layered on top of all of it, driven by customer requirements, competitive positioning, or regulatory exposure, not a legal requirement triggered by shipping an AI feature.

When ISO 42001 starts becoming worth considering

ISO 42001 becomes a business consideration when these signals start showing up:

• AI is a meaningful part of the product, not an incidental internal tool.
• Enterprise customers increasingly ask how AI is governed during security reviews.
• The AI processes sensitive or customer information.
• AI outputs influence decisions that affect customers or users.
• RAG connects models to proprietary or customer data.
• Agents can take actions in other systems.
• The company depends on multiple third-party models or AI providers.
• Leadership wants a repeatable, organization-wide AI governance program instead of ad hoc policies.
• Independent AI management assurance has become commercially valuable, much like ISO 27001 or SOC 2 did for information security.

None of these individually means you need ISO 42001 certification. But as more of them become true, the business case gets stronger: AI is no longer simply a feature your engineering team needs to secure. It has become something the organization needs to govern, assess, document, monitor, and potentially provide assurance around to customers. 

What Does ISO 42001 Add to ISO 27001?

The fastest way to understand ISO 42001 is to start from ISO 27001 concepts a security team already knows and see what changes. That doesn't mean replacing the controls you already have. It means extending them where AI creates risks that an information security management system wasn't designed to address on its own.

1. AI risk and impact assessment

Already familiar: information security risk assessment, identifying threats and vulnerabilities to systems and data.

What AI adds: a broader consideration of AI risks and impacts, including intended and unintended consequences affecting individuals, organizations, and other interested parties, not just the organization running the AI.

Not every AI risk is a cybersecurity vulnerability. A model that produces biased outputs, or an AI feature that makes an incorrect decision affecting a customer, isn't necessarily an exploitable technical flaw, but it's exactly the kind of risk ISO 42001's impact assessment is built to catch. This is one of the core reasons the two standards aren't interchangeable.

2. AI system lifecycle management

Already familiar: secure development processes, from requirements through deployment.

What AI adds: governance across the full AI lifecycle, including requirements, design and development, verification and validation, deployment, operation, monitoring, and retirement.

AI governance extends well beyond whether the code itself is secure. A model can be deployed on perfectly secure infrastructure and still lack any process for validating that it does what it's supposed to do, monitoring its behavior in production, or deciding when it should be retired or replaced.

3. AI data governance

Already familiar: protecting the confidentiality, integrity, and availability of data.

What AI adds: questions about the role and management of data used specifically by AI systems, including acquisition, quality, provenance, and preparation.

This connects directly to how most SaaS products actually build AI features. A RAG pipeline pulling from customer documents, a fine-tuning dataset assembled from support tickets, an external data source feeding an agent- all of these raise data governance questions that traditional ISO 27001 data protection controls weren't written to answer on their own.

4. AI transparency and responsible use

Already familiar: policies, documentation, and communication as part of an ISMS.

What AI adds: documenting the intended use of AI systems, communicating relevant information about how they work to interested parties, and establishing processes around responsible use.

5. Third-party AI and supplier management

Already familiar: third-party and supplier security requirements.

What AI adds: AI-specific dependencies that don't map cleanly onto a traditional vendor security questionnaire, foundation model providers, training and reference datasets, hosted inference APIs, AI platforms, and other components spread across the AI lifecycle.

How Does ISO 42001 Change Penetration Testing?

A company already running an annual penetration test as part of its ISO 27001 program shouldn't assume that the existing pentest scope automatically covers newly introduced AI functionality. It usually doesn't.

What traditional penetration testing covers

A conventional application penetration test typically examines web application security, APIs, authentication, authorization, cloud configuration, and business logic flaws in the parts of the product that existed before AI was added. This is the scope most ISO 27001 pentest evidence is built around, and it's still necessary. It just isn't sufficient once an AI-mediated path into the same data exists.

When AI requires additional pentest scope

New AI functionality tends to introduce attack surface that a conventional web and API pentest wasn't scoped to find:

Access control and identity management

Existing authentication, RBAC, and tenant isolation requirements still apply. But access now often happens through a longer, less familiar path:

User → LLM → RAG → API → customer data

Instead of the conventional:

User → application → API → customer data

The underlying security principle hasn't changed, but the attack surface has. An authorization model built for the second path doesn't automatically hold up against the first.

API security and authorization

An AI agent deciding to invoke an API doesn't make that API request any more trustworthy than one triggered by a user click. Authorization still needs to be enforced independently, at the API layer, regardless of what decided to call it.

• RAG and retrieval systems, where authorization enforced on the source data doesn't always survive ingestion into a vector database.
• AI agents and tool calls, where an agent can be manipulated into invoking actions outside the calling user's actual permissions.
• Model-provider integrations, including how credentials and data are handled when talking to a third-party model API.
• New AI-specific data flows, from ingestion through retrieval through output.
• AI-mediated authorization, where access decisions get made or influenced by the model rather than enforced independently at the data layer.
• Prompt injection with meaningful security impact, as distinct from prompt manipulation that has no real consequence.

AI security testing should complement conventional application security testing, not replace it. A traditional pentest with no AI-specific methodology can pass an application cleanly while missing every one of the risks above. For a closer look at what that actually looks like in practice, Software Secured's breakdown of why AI pentesting is not just jailbreaking the model goes into the distinction in more depth. There is also an ISO 27001 penetration testing guide that specifically maps manual pentesting to ISO 27001 evidence requirements.

How ISO 42001 and ISO 27001 Work Together

If you pursue both standards, you don't need to build two completely separate management systems. Because ISO 27001 and ISO 42001 use the same ISO management-system structure, many existing processes can be reused or extended, including:

• Risk-management processes
• Internal audits
• Management reviews
• Documentation
• Supplier management
• Incident processes
• Secure development
• Monitoring
• Technical security evidence

Reuse the underlying processes where they genuinely overlap, and add AI-specific governance only where ISO 42001 requires a different lens: 

• AI risk and impact assessment
• AI lifecycle management
• AI data governance
• Responsible-use documentation 

Running two fully disconnected management systems for one product is more work than either standard actually requires.

Frequently Asked Questions

Does ISO 42001 replace ISO 27001? No. ISO 27001 addresses information security risk, while ISO 42001 adds governance for AI-specific risks, impacts, and lifecycle management. Companies using AI may use both.

Is ISO 42001 mandatory if my SaaS product uses AI? No. Using AI does not automatically require ISO 42001 certification. Certification becomes worth considering based on customer requirements, regulatory exposure, AI risk, and the role AI plays in your product.

Can one penetration test provide evidence relevant to both ISO 42001 and ISO 27001? Yes, if it's scoped appropriately. A pentest covering conventional application and API security alongside relevant AI attack surfaces can produce technical evidence that supports controls under both management systems. The exact evidence required will depend on your implementation, scope, and auditor.

What's the difference between using AI and needing an AI management system? Using AI simply means your organization or product uses AI. An AI management system (AIMS) provides a formal structure for governing its risks, lifecycle, responsibilities, and impacts.

Do ISO 42001 auditors expect penetration testing to be used as evidence? ISO 42001 doesn't explicitly require penetration testing, but auditors generally expect technical evidence that AI safeguards actually work, not just that they're documented. Penetration testing is one of the strongest ways to produce that evidence, particularly for verification and validation, monitoring, and event-logging controls.

AI Doesn't Replace Your Security Program. It Expands What You Need to Govern.

For companies already following ISO 27001, the most useful question isn't "Do we need ISO 42001?" 

It's: which risks are we already managing, and what has AI introduced that our existing management system doesn't address?

The same question should be applied to penetration testing: what does your existing test already cover, and what new attack surface has AI introduced?