ISO 27001 and AI-Assisted Development: Staying Certifiable

By the UXreviewer.io team4 min read

You can use AI coding agents and remain ISO 27001 certifiable, but the tools must be brought inside your information security management system. That means treating AI vendors as suppliers, restricting what agents can access, keeping human review and testing in the secure development life cycle, and documenting decisions so auditors can see the controls working.

This article maps typical AI-assisted development practices to the ISO 27001:2022 controls they touch. It reflects our experience as an ISO 27001 certified team that builds with agentic coding tools daily. It is guidance, not a certification guarantee; your auditor and your risk assessment decide what applies.

Which ISO 27001 controls do coding agents affect?

Annex A of ISO 27001:2022 groups its controls into organisational, people, physical and technological themes. AI-assisted development touches several directly:

• Supplier relationships and cloud services: AI tool vendors process your source code and sometimes secrets.
• Access control and privileged access: agents run commands, read repositories and may hold credentials.
• Secure development life cycle and secure coding: generated code must meet the same standards as human code.
• Security testing and change management: larger, faster changes need reliable gates.
• Access to source code: agents and cloud sandboxes become new access paths.
• Data leakage prevention and information classification: prompts can carry confidential data out of your environment.

How do you treat AI tool vendors as suppliers?

Evaluate AI coding tools like any service that processes confidential information. Check data handling terms, including whether inputs are used for training, retention periods, data location, sub-processors, security certifications and enterprise controls such as single sign-on and admin policies.

Record approved tools and plans in your supplier register, and say clearly in policy which tools are not approved. Shadow use of personal accounts is the most common gap; a sanctioned option with good ergonomics prevents it better than a ban. Tool capabilities and terms change quickly, so as of late 2026 a quarterly review of vendor terms is a sensible rule of thumb.

Do not forget AI features inside tools you already use, such as code hosting platforms, ticket systems or documentation tools. Enabling an AI add-on can change data flows without anyone filing a new supplier request. Assign an owner who checks such changes and updates the register, so the supplier inventory stays truthful.

How should agent access be restricted?

A coding agent with your developer's full permissions is a privileged account that follows instructions from text it reads, including potentially malicious text in issues, dependencies or web pages. Our article on prompt injection explains why this matters.

Practical measures: run agents in sandboxes or containers, allowlist commands and network destinations, never give agents production credentials, use short-lived and narrowly scoped tokens, and keep secrets out of repositories and prompts. Require human approval for pushes to protected branches and for anything that touches infrastructure.

Log what agents do in the same way you log privileged administrators: commands executed, files changed, network calls made. These logs support incident investigations and give auditors evidence that access restrictions are enforced, not just written down.

What changes in the secure development life cycle?

Generated code must pass the same gates as human code, and some gates matter more. Agents can produce large changes quickly, so review capacity becomes the bottleneck. Teams that stay certifiable usually adjust the life cycle rather than add bureaucracy:

1. Keep mandatory human review for every merge, with the reviewer accountable for the change.
2. Limit change size so reviews stay meaningful; split large agent output into reviewable pieces.
3. Run static analysis, dependency and secret scanning on every pull request.
4. Check new dependencies explicitly, since agents may suggest outdated or non-existent packages.
5. Require tests for generated code and review the tests too.
6. Record in the pull request which parts were AI-assisted, where your policy requires it.

What evidence will an auditor ask for?

Auditors look for consistency between policy and practice. Prepare an AI tool policy, the supplier assessment, access configuration screenshots or exports, branch protection settings, sample pull requests with reviews and scan results, training records and any incidents with their follow-up.

Include AI tools in your risk assessment and statement of applicability rather than treating them as an exception. If you also run AI features in your product, consider extending your management system with ISO/IEC 42001, which shares the same structure.

A short internal audit focused on AI-assisted development, run a few weeks before the certification or surveillance audit, usually uncovers the gaps early enough to fix them.

How do people and training fit in?

Awareness training should cover what may and may not go into prompts, how to recognise unsafe agent suggestions, and how to review generated code critically. Developers who understand the failure modes of agents review better and trust less blindly.

Structured training also creates evidence for people controls. Our team runs agentic coding workshops that cover secure workflows alongside productivity; see our overview of AI coding agent security for the technical risks.

Frequently asked questions