Using AI to Implement ISO 27001 Annex A Controls Safely

Artificial intelligence can reduce the effort involved in researching, drafting and reviewing ISO 27001 control arrangements. It can also create confident errors, expose sensitive information and produce generic documents that do not match the organisation.

The useful question is not whether AI can implement Annex A. It cannot own a risk, approve a control decision or prove that a process operated. The better question is: which implementation tasks can AI support, and what human controls are needed around that support?

This guide presents a controlled approach. It treats AI as an assistant for analysis and drafting while leaving accountability, risk acceptance, technical validation and approval with competent people.

Start with risk treatment, not an AI-generated control list

Annex A contains a reference set of information security controls. Selection must remain connected to the organisation’s risks, obligations and risk-treatment decisions. An AI system should not be asked to select every control in isolation and declare the resulting list compliant.

Begin with the established risk assessment and treatment process. Identify the risk, the intended treatment outcome, relevant obligations and the operational environment. Then use the Annex A Control Lookup to understand potential controls and the control-selection guide to maintain traceability.

For each selected control, define four things before using AI:

1. Control objective: what risk or requirement the arrangement must address.
2. Operating context: systems, people, suppliers, locations and constraints.
3. Required decision: research, drafting, configuration advice, evidence review or another bounded task.
4. Approval authority: who is competent and authorised to accept the output.

Without this context, an AI response may be polished yet irrelevant.

Good and poor uses of AI in control implementation

AI is strongest when the task can be bounded, checked and repeated. It is weakest when a response would be accepted as an authoritative decision without reliable source material.

Use case	Appropriate role for AI	Human responsibility
Control research	Summarise approved internal and public reference material	Confirm sources, applicability and currentness
Drafting	Propose a first draft using supplied facts and house style	Validate accuracy, ownership, feasibility and approval
Gap review	Compare defined criteria with provided evidence	Decide conformity, significance and action
Evidence organisation	Extract dates, owners and references from records	Verify extraction and assess what the evidence proves
Technical guidance	Suggest configuration considerations	Test safely and approve through change management
Statement of Applicability support	Explain inconsistencies and missing rationales	Approve applicability, justification and implementation status

A poor use would be asking a public AI service to produce an access-control policy without providing the organisation’s identity architecture, roles, approval model, legal obligations or actual practices. Another poor use would be accepting an AI-generated finding as an internal audit conclusion without examining the evidence.

Establish an approved AI working environment

Before users submit ISMS information, define which AI services are approved and what information they may process. The decision should consider contractual terms, retention, model training, access control, data location, logging, deletion, intellectual property and incident handling.

Create clear data-handling levels. Public information may be suitable for a broadly available service, while confidential risk details, personal data, credentials, vulnerability information and client evidence may require an enterprise environment with stronger contractual and technical controls—or may be prohibited entirely.

At minimum, establish:

• approved tools and accounts;
• permitted and prohibited data types;
• authentication and access requirements;
• logging and monitoring expectations;
• output-review responsibilities;
• escalation for suspected disclosure or unsafe output; and
• retention rules for prompts, responses and derived documents.

The NIST AI Risk Management Framework offers a useful voluntary structure for governing, mapping, measuring and managing AI risks. It does not replace ISO 27001 decisions, but it can help frame controls around AI use.

Ground the AI in controlled information

General-purpose models do not automatically know the organisation’s approved processes or the exact text of licensed standards. Give the system a bounded source set that the user is authorised to use.

Useful inputs may include:

• the approved control objective and risk-treatment decision;
• relevant internal policies and process descriptions;
• system architecture and responsibility boundaries;
• approved control guidance;
• contractual or regulatory requirements; and
• examples of the organisation’s document style.

Remove unnecessary sensitive information. Use identifiers or synthetic examples where possible. Tell the model to identify uncertainty, cite the supplied source used for each material assertion and avoid inventing missing details.

A grounded response is easier to review because the reviewer can trace where the proposed content came from. Grounding does not guarantee correctness; it makes validation more practical.

Use structured prompts that expose assumptions

A useful prompt should define the role, task, scope, inputs, exclusions and required output. Ask the system to separate facts supplied by the organisation from suggestions that require a decision.

For example, instead of “write an access-control procedure,” request a draft that:

• covers a named scope and identity platform;
• uses the organisation’s stated approval roles;
• distinguishes joiner, mover, leaver and privileged access activities;
• identifies every missing decision as an open item;
• maps proposed records to the relevant activity; and
• does not invent frequencies, job titles or system capabilities.

Require a final assumptions section for the reviewer, even if that section will be removed before approval. Hidden assumptions are a common cause of attractive but unusable outputs.

Apply a three-stage review

Every material AI-assisted output should pass three different tests.

1. Requirement and risk review

Confirm that the output supports the intended risk-treatment outcome and does not misstate ISO requirements. Check consistency with the SoA, risk register and applicable obligations.

2. Operational review

The process owner confirms that roles, systems, steps, timing and records match real operations. If the proposed process cannot be performed, it should not be approved merely because it reads well.

3. Assurance review

An independent reviewer asks whether the resulting arrangement can be tested. Are responsibilities clear? Is evidence generated? Can exceptions be identified and followed up? Does the output conflict with another controlled document?

Record who performed each review, the issues identified and the final approval. For higher-risk decisions, use a second qualified reviewer.

Validate technical recommendations before deployment

AI-generated technical guidance must be treated as untrusted until tested. Commands may be obsolete, insecure or unsuitable for the environment. Never paste generated code or configuration directly into production.

Use the normal secure change process:

1. Confirm the intended security outcome.
2. Review the recommendation against authoritative product documentation.
3. Test in an isolated environment.
4. Assess security, privacy, availability and rollback implications.
5. Obtain required approval.
6. Deploy through controlled change.
7. Verify the configuration and retain the result.

The evidence should show the actual approved configuration and test result, not only the AI conversation that proposed it.

Use AI to strengthen evidence preparation

AI can help classify and index evidence, identify missing periods, compare a record with defined criteria and draft interview questions. These uses can save time when the underlying evidence is already controlled.

However, the model should not make the final conformity decision. A policy can be correctly classified while still failing to prove operation. A log extract can contain the expected event while covering the wrong system or period.

Use the principles in the ISO 27001 evidence register guide to retain owner, period, version, classification and review status. For AI-assisted extraction, keep a reference to the original evidence and record material corrections made during human validation.

Maintain the Statement of Applicability

AI can review SoA entries for incomplete rationales, inconsistent status language and missing links to risks or evidence. It can also suggest questions for the control owner.

It must not decide applicability on its own. Applicability is a management decision grounded in risk treatment, obligations and context. The control owner and risk authority should approve the outcome.

The Statement of Applicability Builder provides a structured environment for recording applicability, justification, implementation status and evidence across all 93 controls.

Evidence that demonstrates controlled AI use

An auditor may expect to see more than a policy saying AI outputs are reviewed. Useful evidence can include:

• the approved AI-use rules and service assessment;
• user access and role records;
• data-classification restrictions;
• prompt and source references for important outputs;
• reviewer comments and approvals;
• technical test results and change records;
• sampled errors and corrections;
• monitoring results and incidents; and
• periodic review of approved models and use cases.

The strength of evidence depends on risk. A low-risk brainstorming task may need little retained detail. An AI-assisted security configuration or audit analysis needs much stronger traceability.

Pass, partial and fail examples

Result	Example
Pass	The team uses an approved enterprise service, restricts input data, grounds outputs in controlled sources, records reviews and tests technical changes before deployment.
Partial	Users review drafts, but prompt sources and corrections are not retained, making important claims difficult to trace.
Fail	Staff submit confidential security evidence to unapproved public services and accept generated controls without validation or accountable approval.

Common implementation failures

Treating fluent language as evidence

A well-written procedure proves only that text exists. Operating records must still demonstrate that the described activities occurred.

Allowing AI to invent organisational facts

Generated roles, frequencies and system names create contradictions. Missing facts should remain explicit decisions for process owners.

Ignoring model and service changes

AI services change. Reassess material use cases when models, terms, integrations, data handling or capabilities change.

Losing source traceability

Without source references, reviewers cannot distinguish an approved requirement from a model suggestion. Preserve traceability for important outputs.

Using AI to avoid competent review

AI may accelerate work; it does not remove the need for subject-matter competence, independence or authorised risk decisions.

Final takeaway

AI can make Annex A implementation faster when it supports bounded tasks inside an approved governance process. It becomes dangerous when speed replaces context, source control, testing or accountability.

Keep the sequence clear: assess risk, select the control, define the task, protect the input, ground the response, validate it, approve the decision and retain evidence. That approach uses AI productively without allowing the tool to become the control owner or the auditor.