Building an ISMS for an AI-enabled organisation

Learn in your browser · Chapter 01 of 09

Start here so the rest of the course has a shared vocabulary: what a management system actually is, and which questions belong to information security and which belong to AI governance.

This course is general education, not legal, security or certification advice. It draws on primary sources read on 29 September 2026, and finishing it, or any exercise in it, does not certify an organisation or prove compliance with any law or standard. Where a question needs a qualified professional, this course says so plainly rather than guessing.

A management system is not a filing cabinet of policies. It is an organisation's own working combination of policies, processes, defined roles, records and a habit of checking itself, all aimed at one stated purpose. An information security management system (ISMS) aims that combination at one purpose: keeping information confidential, correct and available, whoever or whatever is handling it, including an AI tool.

ISO/IEC 27001:2022, the third edition, published in October 2022, is the internationally recognised standard that sets out what a working ISMS needs to contain. Like several other ISO management-system standards, it follows ISO's shared harmonised structure, a common set of clause numbers running from context (clause 4) through improvement (clause 10). ISO/IEC 42001:2023, the first edition, published in December 2023, is the equivalent standard for an AI management system (AIMS), built on that same harmonised structure. That shared shape means an organisation that already runs an ISMS is well placed to add AI-specific management alongside it, rather than starting from nothing.

Scroll sideways to see every column.

1. Read a chapter's explanation and worked example before starting its exercise.
2. Do each exercise for real, on your own information or on Harrowgate's, not just in your head: a management system is built from written records, not intentions.
3. Use the checklist at the end of the course to see what you have actually produced.
4. Treat the final chapter's capstone as the point of the whole course: a scoped implementation plan and evidence checklist you could hand to a colleague.

Learn in your browser · Chapter 02 of 09

Nothing else in this course means anything until you can say, precisely, what your ISMS actually covers.

ISO/IEC 27001's clause 4 starts an ISMS with context: the internal issues (what the organisation actually does, its structure, its existing systems) and external issues (the law, the market, its regulators, its customers' expectations) that shape what the ISMS needs to handle. From context comes a list of interested parties: anyone with a stake in how the organisation handles information, and what each of them actually needs from it. Only then does a scope statement draw the boundary: which sites, which systems, which information, and, for this course, which AI tools sit inside the ISMS and which do not.

Scroll sideways to see every column.

1. List your internal issues: what the organisation does, its main systems, including every AI tool in real use, not just the officially approved ones.
2. List your external issues: relevant law, your sector's regulator if any, contractual promises to customers, and market expectations.
3. List your interested parties and, for each, one sentence on what they actually need from the ISMS.
4. Draft a boundary: named sites, named systems, named AI tools, in plain language.
5. Name at least one thing that is explicitly out of scope, and why, so the boundary is falsifiable rather than a marketing line.
6. Get the draft reviewed and signed off by whoever leads the organisation, since scope is a leadership decision, not a documentation exercise.

Learn in your browser · Chapter 03 of 09

You cannot protect, classify or check anything that is not written down. This chapter builds the inventory the rest of the course works from.

In an ISMS, an asset is broader than a laptop or a server. It is anything that carries or processes information of value: a customer database, a signed contract, a set of engineering drawings, a training dataset, a vector store of embedded documents, a prompt library, an API key, a log file, or a fine-tuned model's configuration. An AI-enabled organisation's inventory needs the same discipline extended to these newer, less obviously physical items.

• Name: what the asset actually is, in plain words a non-technical reviewer could understand.
• Owner: a named role, not a team, who is accountable for the asset day to day.
• Classification: how sensitive the information is, on a scale your organisation actually uses.
• Location: where it lives, including which supplier or AI vendor hosts or processes it.
• AI-specific flag: does this asset feed a third-party model, does it contain personal data, could an AI tool's output derived from it reach a customer directly.

Scroll sideways to see every column.

Save the CSV below as inventory.csv in a new folder, plain UTF-8 text: a sample of Harrowgate's inventory, with two mistakes planted on purpose. Use a text editor, not a spreadsheet, since a spreadsheet can silently alter values.

asset,owner,classification,ai_flag
Customer order database,Sales Manager,Confidential,Feeds the supplier-risk-scoring tool
AI drafting assistant document history,Operations Director,Confidential,Vendor retains files 30 days
Visual inspection model configuration,Quality Manager,Restricted,Controls which defects are flagged
Supplier-risk-scoring API key,IT Manager,Restricted,Credential not a document
Staff HR records,HR Manager,Confidential,No AI tool has access
Marketing image library,,Internal,AI photo tool used to tidy images
Quoting spreadsheet template,Sales Manager,Unclassified,No AI tool has access

The checker below uses only Python's standard library and changes nothing. Save it as check_inventory.py beside the CSV.

"""check_inventory.py: check the form of an asset and information inventory. It only reads."""
import csv
import sys

ALLOWED = {"Public", "Internal", "Confidential", "Restricted"}
COLUMNS = ["asset", "owner", "classification", "ai_flag"]


def check(rows):
    problems = []
    for row in rows:
        name = row.get("asset", "").strip() or "(unnamed row)"
        if None in row.values():
            problems.append((name, "wrong number of values"))
            continue
        if not row["owner"].strip():
            problems.append((name, "no owner"))
        if row["classification"].strip() not in ALLOWED:
            problems.append((name, "classification '%s' not in %s" % (row["classification"], sorted(ALLOWED))))
        if not row["ai_flag"].strip():
            problems.append((name, "ai_flag left blank: state 'none' if no AI tool touches this asset"))
    return problems


if __name__ == "__main__":
    with open(sys.argv[1], newline="", encoding="utf-8-sig") as f:
        reader = csv.DictReader(f)
        if reader.fieldnames != COLUMNS:
            sys.exit("First line must be: " + ",".join(COLUMNS))
        rows = list(reader)
    problems = check(rows)
    for name, message in problems:
        print("%s: %s" % (name, message))
    print("%d assets checked, %d problem(s)" % (len(rows), len(problems)))
    sys.exit(1 if problems else 0)

Run it from that folder (python3 on macOS and Linux).

python check_inventory.py inventory.csv
Marketing image library: no owner
Quoting spreadsheet template: classification 'Unclassified' not in ['Confidential', 'Internal', 'Public', 'Restricted']
7 assets checked, 2 problem(s)

Learn in your browser · Chapter 04 of 09

Once you know what you have, decide what could go wrong with it, how badly, and what you are going to do about it.

Risk assessment has three parts: identify what could happen to an asset, analyse how likely it is and how bad the consequences would be, and evaluate whether that level of risk is acceptable. Risk treatment then chooses a response: reduce it with a control, avoid it by not doing the risky thing at all, share or transfer it, such as through insurance or a supplier contract, or accept it deliberately, with a named person taking that decision.

For an AI-enabled organisation, keep two lenses separate. Information-security risk asks whether an asset's confidentiality, integrity or availability could be harmed. AI-specific risk asks a wider question again. NIST's AI Risk Management Framework structures this around four functions: GOVERN, covering culture, policy and accountability; MAP, understanding context and identifying risks; MEASURE, analysing and tracking them; and MANAGE, treating them. NIST's AI RMF is voluntary guidance, not a legal requirement, and on 29 September 2026 NIST's own page still described AI RMF 1.0 as being revised as part of the White House AI Action Plan, so treat its exact wording as a living document, not a fixed text.

Scroll sideways to see every column.

Inherent risk is the score before any control. Residual risk is what remains once controls are actually working, and should never exceed the inherent score. This scale, and the appetite below, are invented for this course; use your own organisation's, if it has one. Harrowgate's own invented risk appetite: a residual score above 8 needs sign-off from the Operations Director, not the asset owner alone.

Learn in your browser · Chapter 05 of 09

A Statement of Applicability turns a risk treatment plan into an honest, checkable record of every control you considered.

A Statement of Applicability (SoA) lists every control an organisation considered, whether each one is applied, and why. ISO/IEC 27001:2022's Annex A groups its controls into four themes: organisational, people, physical and technological. ISO/IEC 42001:2023 has its own annex of AI-specific controls, covering areas such as AI policy, AI system impact assessment, the AI system lifecycle, data for AI systems, and third-party and customer relationships. Where an organisation runs both, the two annexes complement each other rather than duplicating: 27001's controls largely protect the information an AI system touches, and 42001's controls largely govern the AI system's own behaviour and lifecycle.

1. List every control theme relevant to your scope, using your risk treatment plan from Chapter 3 as the starting point rather than working through an annex line by line in a vacuum.
2. For each control, mark applicable or not applicable, with one sentence of justification either way.
3. For every applicable control, name where the evidence it is working actually lives: a dated test, a sample, a log, a signed contract clause.
4. Name an owner for each applicable control.
5. Review the SoA whenever scope, risk assessment or a major AI tool changes, not only once a year.

Scroll sideways to see every column.

Learn in your browser · Chapter 06 of 09

A management system runs on people who know what is expected of them, not on a policy document nobody has read since it was signed.

An information security policy states, briefly, what the organisation is committed to and why, and it needs to be genuinely understood by the people it covers, not just filed. For an AI-enabled organisation, keep a short, separate piece of internal guidance on approved AI tools, what data may and may not go into them, and who to ask before adopting a new one, that explicitly references the wider information security policy rather than repeating or contradicting it. Keeping them as two connected documents, rather than one, mirrors the earlier point that information security and AI governance are related systems, not one system.

Objectives turn policy into something you can check. A useful security objective names what will change, by when, measured how, and who owns it, in the same way any other business objective would.

Scroll sideways to see every column.

Roles matter more than a policy's wording. Somebody needs to be the asset owner day to day, somebody needs to hold the risk owner's authority to accept or escalate a risk, somebody at the top needs to be accountable for the ISMS overall, and everybody working with an in-scope asset or AI tool needs enough competence to do their part correctly. Competence is not the same as a job title: it means the person has genuinely been shown what to do and why, and there is a record that this happened.

Learn in your browser · Chapter 07 of 09

Most of an AI-enabled organisation's real risk sits outside its own walls, in its suppliers and in who can reach what.

Supplier management in an ISMS runs through a lifecycle: due diligence before signing, contract clauses that actually say what you need them to say, ongoing monitoring rather than a one-off check, and a plan for what happens when the relationship ends. An AI vendor adds specific questions on top of the usual security due diligence: does the vendor train or fine-tune its own models on your data, how long does it retain your prompts and files, what happens to your data if you cancel, and will it tell you before a material change to how the AI system behaves or what it does with your data.

Access control follows the standard principle of least privilege, giving people and systems only the access they need, reviewed regularly and removed promptly when someone changes role or leaves. Treat an AI system's own credentials, such as an API key, the same way as a person's account: it needs an owner, a defined scope of access, and a review, not a value quietly copied into a script years ago and forgotten.

1. Before signing with a new AI vendor, ask the data-retention, training-use and change-notice questions above, and get the answers in writing.
2. Put the answers that matter into the contract itself, not just an email thread.
3. Set a review date to re-check the vendor's current terms, since AI vendors' terms change more often than most traditional software contracts.
4. Review every AI system's access credentials on the same schedule as staff accounts, with a named owner for each.
5. Write down what happens to your data, and to the vendor's access, if the relationship ends.

Scroll sideways to see every column.

Learn in your browser · Chapter 08 of 09

Plan for the day something genuinely goes wrong, including the specifically AI-shaped ways it can go wrong.

An incident response plan follows a standard shape: detect, contain, eradicate, recover, and learn. An AI-enabled organisation needs that shape to cover two overlapping categories of incident: classic information-security incidents, such as a lost device, a phishing compromise or a data breach, and AI-specific incidents, such as an AI tool exposing one customer's information to another, or an AI system's output quietly degrading until it stops being reliable, sometimes called model drift.

On prompt injection specifically, the UK's National Cyber Security Centre wrote in a blog post dated 8 December 2025 that current large language models do not enforce a security boundary between instructions and data, so prompt injection may well never be totally mitigated, and that design should focus on deterministic, non-model safeguards that constrain what a system can do, rather than assuming the model itself will always behave. Build your incident response plan on that assumption rather than against it.

Continuity and recovery ask a different question: not what went wrong, but what happens while it is being fixed. If an AI supplier has an outage, or Harrowgate loses confidence in the inspection model's output, is there a tested manual fallback, who has the authority to invoke it, and how long can the organisation actually run that way before it becomes its own problem.

Scroll sideways to see every column.

Learn in your browser · Chapter 09 of 09

Close the loop: check the system actually works, let leadership decide what changes, and put everything from this course into one working plan.

Internal audit is an organisation checking its own ISMS against what it says it does, done by someone independent enough to be honest about what they find, ideally not the person who owns the area being checked. It is not the same as an external certification audit, and this course does not prepare anyone to conduct either as a qualified auditor. Management review is where leadership uses the internal audit's findings, incident records, risk trends, supplier changes and objective progress to decide what the ISMS needs next: more resource, a changed priority, or a genuine acceptance that something stays as it is for now.

Corrective action fixes the actual cause of a nonconformity, not just its most visible symptom, and continual improvement is the habit of doing this consistently rather than only when an audit forces it. Together with the risk treatment and objectives from earlier chapters, this is the check-and-act half of the plan, do, check, act cycle that runs underneath ISO's management-system standards.

1. Plan the audit: which part of the scope, against which controls and records, and by whom.
2. Sample real evidence: do not just ask whether a control happened, go and look at the record.
3. Write findings as specific gaps, tied to a control or record, not general impressions.
4. Agree a corrective action for each finding that addresses the actual cause, with an owner and a date.
5. Follow up: check the corrective action actually happened and actually closed the gap, not just that the ticket was marked closed.

Scroll sideways to see every column.

Completing this exercise, this chapter, or this whole course does not certify Harrowgate, your own organisation, or you personally, as compliant with ISO/IEC 27001, ISO/IEC 42001, the EU AI Act, UK data protection law, or any other law or standard. It produces a working first draft of a genuine management system. A qualified internal auditor, external assessor or legal adviser still needs to test it against your organisation's real facts before anyone relies on it.

You can now set a defensible scope, build and check an asset inventory, assess and treat risk, keep a Statement of Applicability with real evidence, set policy, objectives, roles and competence, manage suppliers and access including AI vendors, plan for AI-specific incidents, and run the audit and review cycle that keeps all of it honest over time.

This is free educational content published by Mickai LTD, not professional, legal, financial or compliance advice, and Mickai accepts no liability for how you use it.

https://trust-agent.ai/exam/building-an-isms-for-an-ai-enabled-organisation

If you are reading this because your organisation needs its ISMS and its AI governance actually built, evidenced and kept current, rather than assembled once for an audit and left to drift, Mickai builds bespoke AI workflows and code enhancements for businesses, running on Mickai's own sovereign operating system with zero data egress: your scope statements, risk registers and evidence never leave your own environment. See what that looks like at mickai.co.uk/bespoke.