ASD ISM 2084 Document AI model and system characteristics
What it says
AI-specific documentation, including AI model cards and AI system cards (or equivalent artefacts), is used to document AI model characteristics, system architectures, use cases and security risks.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishCreate detailed documents about AI models and systems, including their architecture and security risks.
This control is about writing down important details about our AI systems, like how they work and the risks they might have. It's important because without this documentation, we could make expensive mistakes or face security issues with our AI models.
Free. Save your status, tasks and notes.
Why it matters
Without documenting AI model details and risks, businesses may experience security breaches, financial loss, or reputational damage.
How to implement
System owners should create and maintain AI model cards.
To do this, describe the AI model's purpose, how it operates, what data it uses, and potential risks, making sure everything is clear and easy to understand.
The IT team should document the system architecture.
Write down details about how the AI system is set up, including hardware, software, and network components, so everyone knows how the system functions.
Managers need to review AI system cards with their teams.
Schedule regular meetings to discuss these documents, ensuring all team members understand potential security and privacy risks associated with the AI models.
HR should organise training for staff on AI security risks.
Set up workshops to educate employees on recognising and handling any security threats or ethical issues related to AI.
Procurement should ensure AI systems selected align with documented use cases and security needs.
Collaborate with the IT team to evaluate vendors' AI systems against the documented requirements and risks.
Keep it running
Regularly update AI documentation to reflect system changes and new risks. Ensure all team members can access and understand these documents.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Ask for the AI model cards (or equivalent artefacts) for each AI model in use.
Look at
Look at how well each card explains the model's purpose, how it operates, the data it uses and its known security risks.
Good evidence
Good model cards are detailed, easy to read and updated regularly so they reflect the model as currently deployed.
- Check 2 of 5What an auditor asks for
Ask for
Request the AI system cards or system architecture documentation for each AI system.
Look at
Check that the documentation covers all relevant hardware, software and network components, along with the system's intended use cases.
Good evidence
A complete document accurately reflects the current system setup rather than an outdated or planned design.
- Check 3 of 5What an auditor asks for
Ask for
Ask for records of team review meetings where AI system cards were discussed.
Look at
Look for meeting notes or minutes that show the cards were reviewed and their content understood by the relevant people.
Good evidence
Good notes capture the key points discussed and highlight any action items raised, such as updates needed to the documentation.
- Check 4 of 5What an auditor asks for
Ask for
Request training attendance records and training materials covering AI risks.
Look at
Check that the staff responsible for AI models and systems have been trained on AI security risks and that the materials cover the risks recorded in the model and system cards.
Good evidence
Quality training uses practical examples and scenarios, and attendance records show the relevant staff completed it.
- Check 5 of 5What an auditor asks for
Ask for
Ask for the procurement criteria and evaluation reports used when selecting or assessing AI systems.
Look at
Examine whether the criteria and reports align with the use cases and security risks documented in the model and system cards.
Good evidence
Good practice shows a thorough evaluation process that was documented and followed, with findings consistent with the AI documentation.
Mappings
Closest match in ISO/IEC 27001: A.5.8, Information security in project management, which this control partially meets.
ISO/IEC 27001: 2 mappings
This control partially meets A.5.8.
Annex A 5.8 requires information security to be integrated into project management so project delivery considers security risks and controls. ISM-2084 relates by requiring AI model/system documentation (e.g. model/system cards) to capture characteristics, architectures, use cases and security risks, which is a project artefact that supports secure AI delivery. Annex A 5.8 is broader because it applies to all projects, whereas ISM-2084 is specific to AI systems and documentation of AI-specific risks.
This control partially overlaps A.8.27.
ISM-2084 requires AI-specific documentation (e.g. model/system cards) to record model characteristics, architectures, use cases and security risks. Annex A 8.27 requires secure system architecture and engineering principles to be established and documented, then applied during system development. They overlap where AI system cards capture architecture decisions and security considerations that support secure engineering, but ISM-2084 is specifically about AI model artefacts and risk documentation rather than general engineering principles.
ISO/IEC 42001: 3 mappings
This control partially overlaps A.6.2.7.
Annex A 6.2.7 requires the organisation to determine what AI system technical documentation is needed for each category of interested party (e.g. users, partners, regulators) and provide it in an appropriate form. ISM-2084 specifically requires creating AI model/system documentation artefacts (e.g. model cards/system cards) covering characteristics, architecture, use cases and security risks, which are a common core input to the technical documentation Annex A 6.2.7 expects to be disseminated. ISM-2084 focuses on producing particular AI documentation content, while Annex A 6.2.7 focuses on tailoring and distributing documentation to different audiences (including potentially non-technical forms).
This control partially overlaps A.8.2.
ISO/IEC 42001 Annex A 8.2 requires the organisation to determine and provide the information that users of an AI system need. ISM-2084 requires AI model cards and system cards (or equivalent artefacts) to document model characteristics, architecture, use cases and security risks, and these artefacts are a common source of the information given to users. Annex A 8.2 is user-facing and broader than security, while ISM-2084 is a documentation requirement centred on characteristics and security risks that is not necessarily shared with users.
This control supports A.9.4.
Annex A 9.4 requires the organisation to ensure an AI system is used only for its documented intended uses and within documented limits. ISM-2084 mandates creating and maintaining AI model/system documentation (e.g., model cards/system cards) that defines use cases, characteristics and risks, which is a prerequisite for communicating and enforcing “intended use”. Annex A 9.4 focuses on controlling use in operation, while ISM-2084 focuses on producing the artefacts that make intended-use boundaries explicit and auditable.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.