AI governance becomes more challenging when security and compliance activities sit outside the engineering process.
A development team might follow established security procedures, review access permissions, and document infrastructure changes. At the same time, its AI systems may introduce additional questions about intended use, model behaviour, risk ownership, and ongoing oversight.
Managing these responsibilities separately can create gaps between technical implementation and organizational governance.
ISO/IEC 27001 and ISO/IEC 42001 provide management-system frameworks that can help organizations address these challenges. The practical task is to connect governance requirements with the way software teams actually build, deploy, and maintain AI systems.
Why AI Teams Need More Than Security Controls
Information security is an important part of AI governance, but it does not cover every consideration associated with an AI system.
Consider an application that uses a third-party language model to summarize customer support conversations.
The engineering team might already have processes for protecting API credentials, controlling database access, and responding to security incidents. These practices help protect the application and its data.
However, the team may also need to consider whether model inputs expose sensitive information, whether outputs require human review, how changes to the model are evaluated, and who monitors the system after deployment.
These are different questions that require coordinated technical and organizational decisions.
ISO 27001 establishes a framework for information security management. ISO 42001 establishes a framework for managing AI-related risks and opportunities. Organizations can coordinate relevant processes while retaining the distinct requirements of each standard.
## Where the Two Standards Fit Into the Development Lifecycle
A useful approach is to connect management-system activities with existing engineering workflows rather than creating a separate process for every compliance task.
1. AI system planning
Before development begins, teams should understand the intended purpose of an AI feature and the responsibilities associated with it.
Useful questions include:
- What business problem will the system address?
- Will the system process personal, confidential, or otherwise sensitive information?
- Which external models, APIs, or datasets will it depend on?
- Who owns the system and approves important changes?
- What risks need to be assessed before deployment?
Information security requirements can help establish safeguards for data and infrastructure. AI governance processes can help teams evaluate the wider implications of the proposed system.
Recording these decisions early gives engineers and governance teams a shared starting point.
2. Development and testing
Security reviews and AI evaluations should reflect the characteristics of the system being developed.
For example, an engineering team might test authentication, authorization, dependency vulnerabilities, and secrets management. It may also need to evaluate AI-specific concerns such as inappropriate outputs, performance limitations, or the effectiveness of human oversight.
The required evaluations depend on the system's purpose, risks, and applicable requirements.
Teams should document what was tested, what the results showed, and which issues remain unresolved. Where approval is required, the process should identify the responsible reviewer.
3. Deployment and change management
An AI system can change when its model, prompts, datasets, dependencies, or surrounding application is modified.
A conventional software release process can provide useful controls for reviewing and approving these changes. However, organizations should determine whether their existing process adequately captures AI-related risks.
A change that appears minor from an engineering perspective might affect output quality or the system's intended use.
Teams can establish proportionate review criteria to determine when additional testing, risk assessment, or approval is needed before a change reaches production.
4. Production monitoring
Deployment does not eliminate the need for oversight.
Engineering teams typically monitor availability, latency, errors, and infrastructure performance. Depending on the application, they may also need to evaluate output quality, recurring failure patterns, user feedback, and other AI-specific indicators.
Monitoring responsibilities should be clear. Teams need to know who reviews findings, how issues are escalated, and when corrective action is required.
The monitoring process should also reflect the organization's documented risk assessments and relevant management-system requirements.
Build a Shared Evidence Process
One of the practical challenges in implementing multiple management systems is keeping records consistent.
Security teams may maintain risk registers, engineering teams may store test results in development tools, and compliance teams may manage approvals in separate documents.
When these records are disconnected, it becomes harder to understand which decisions have been made and whether the required actions are complete.
- A shared evidence process can improve traceability.
- For each AI system, an organization might maintain links to:
- The system's owner and intended purpose.
- Relevant information security and AI risk assessments.
- Testing results and review records.
- Approved changes and deployment decisions.
- Monitoring findings and corrective actions.
This does not mean every record must be stored in one application. The important point is that the organization can locate the evidence, identify its owner, and understand which requirements it supports.
Shared evidence should not be mistaken for identical requirements. A security test may support an information security control without demonstrating that an AI-specific assessment has been completed.
Make Responsibilities Clear Across Teams
Effective governance depends on cooperation between people who have different responsibilities.
Developers understand the implementation. Security professionals focus on protecting systems and information. Product owners understand intended use and business priorities. Compliance personnel help interpret applicable requirements and coordinate evidence.
These responsibilities can overlap, but they should not remain ambiguous.
A practical responsibility model should clarify who:
- Identifies and documents AI systems.
- Conducts or coordinates risk assessments.
- Implements technical and organizational controls.
- Reviews and approves relevant decisions.
- Monitors the system and manages corrective actions.
The model should reflect the organization's size and operating structure. Smaller teams may assign several responsibilities to one person, while larger organizations may require more formal review and escalation processes.
What matters is that decisions have clear ownership and that the people responsible have the necessary competence and authority.
How Does This Relate to the EU AI Act?
Organizations operating in Europe may also need to consider obligations under the EU AI Act.
The Act's requirements depend on factors including the organization's role, the AI system's intended purpose, and its classification under the legislation.
ISO 27001 and ISO 42001 can support relevant governance activities, but neither standard automatically establishes compliance with every applicable EU AI Act requirement.
Organizations should assess their legal obligations separately and determine how existing management-system processes can support the required controls, documentation, and oversight.
This distinction is particularly important when teams use certification as evidence of a broader governance programme. A management-system certificate and a legal conformity assessment serve different purposes.
For a closer look at how the two standards complement one another, see this guide to integrating ISO 27001 and ISO 42001.
A Practical Starting Point for Engineering Teams
Organizations do not need to redesign every engineering workflow at once.
A sensible starting point is to select one AI system and map its lifecycle, existing security controls, governance responsibilities, and available evidence.
Next, identify where the current workflow does not address the relevant AI management requirements. Prioritize the gaps according to their significance, assign owners, and document the changes needed.
Once the process has been reviewed, the organization can apply the lessons to other AI systems where appropriate.
This approach helps teams build on existing capabilities without assuming that a single workflow will suit every AI application.
Conclusion
ISO 27001 and ISO 42001 can support a more coordinated approach to information security and AI governance.
Their value becomes clearer when management-system requirements connect with practical activities such as development reviews, change management, risk assessment, evidence collection, and production monitoring.
The objective is not to add unnecessary approval steps to software development. It is to make responsibilities visible, address relevant risks, and maintain records that support informed decisions.
By bringing engineering, security, and governance teams into the same process, organizations can make AI oversight a more consistent part of how their systems are developed and maintained.
Top comments (0)