ISO 27001:2022 AI security controls — multimodal prompt injection evidence

The ISO 27001:2022 controls most relevant to AI inputs

ISO 27001:2022 reorganised Annex A into four themes: Organizational controls (A.5), People controls (A.6), Physical controls (A.7), and Technological controls (A.8). The controls most directly applicable to AI input security sit in the Technological theme. Four controls form the operative compliance anchor for multimodal AI input validation.

A.8.28 — Secure Coding is new in the 2022 edition. The control states: "Secure coding principles shall be applied to software development." The accompanying implementation guidance covers a set of specific requirements including: inputs shall be validated before use; protection shall be implemented against injection attacks; external data sources shall be treated as untrusted until validated. For an AI application, the "software" under development and deployment includes the inference pipeline — the code that receives a multimodal request, prepares inputs for the model, and dispatches the model call. The "external data" the inference pipeline handles includes image bytes and audio waveforms submitted by users. A.8.28 requires that those bytes are validated — checked against a known-malicious corpus or scored for adversarial-instruction content — before being forwarded to the model. A text-only validator on the text field does not constitute validation of the image field under A.8.28's requirement that all external data sources are treated as untrusted until validated.

A.8.7 — Protection against malware is carried forward from the 2013 edition (where it appeared as A.12.2). The 2022 implementation guidance explicitly notes that "malicious code" includes adversarial content designed to manipulate system behaviour — not just binary executables or phishing scripts. For AI systems, a FigStep-class prompt injection payload (an adversarial instruction rendered as typography in a pixel layer) or a WhisperInject-class payload (an adversarial instruction embedded in an audio waveform) is adversarial content designed to manipulate system behaviour. A.8.7's detection requirement applies to this content class. A text-only scanner does not detect these payloads because it never processes the channels that carry them.

A.8.16 — Monitoring Activities is another new control in 2022. It requires: "Networks, systems and applications shall be monitored for anomalous behaviour and appropriate actions taken to evaluate potential information security incidents." For AI applications, "anomalous application behaviour" during inference includes the receipt of inputs that score highly on adversarial-instruction detection. A per-request risk score from an inference-boundary scanner is the concrete implementation of A.8.16 monitoring for AI features: each request generates a score, scores above threshold trigger an alert, the alert feeds the incident evaluation workflow described in A.8.16. Without a multimodal scan, image and audio inputs produce no anomaly score, and the A.8.16 monitoring coverage is limited to the text channel.

A.5.7 — Threat Intelligence is also new in 2022. It requires organisations to collect and analyse information about security threats to produce actionable intelligence. For AI security, the active multimodal PI threat landscape — FigStep, AgentTypo, WhisperInject, indirect image injection — is exactly the threat class A.5.7 requires organisations to track and act on. A runtime scanner whose payload corpus is continuously updated with new attack families is the operational implementation of A.5.7 threat intelligence for AI input channels: intelligence about new attack vectors is translated into detection signatures that protect the inference boundary.

What the Statement of Applicability requires for AI input channels

The Statement of Applicability (SoA) is the central required document in any ISO 27001 ISMS certification. It lists every Annex A control, states whether each is applicable or excluded (with justification for exclusions), and documents the implementation status of each applicable control. External certification auditors and customer security assessors reviewing the ISMS will read the SoA to understand what controls are in place and whether the documented implementation matches the actual system.

For an AI SaaS product that accepts image uploads or voice input, A.8.28 must be listed as applicable in the SoA — there is no credible exclusion argument for input validation controls in a product that processes external user input. The implementation entry for A.8.28 must describe what input validation mechanism the inference pipeline uses. If the documented implementation is "Lakera Guard text-side prompt-injection scanning," the SoA entry covers the text channel. An auditor reviewing the SoA alongside the system architecture description — which should enumerate image and audio as input channels — will ask: what A.8.28 implementation covers the image input path? What covers the audio input path?

The same question applies to A.8.7 and A.8.16. For A.8.7, the implementation entry for malware/adversarial-content protection must cover every input channel from which malicious content could arrive. For A.8.16, the monitoring implementation entry must describe anomaly detection for every inference-relevant channel. A SoA where A.8.7 and A.8.16 are implemented only for the text channel is internally inconsistent with a system description that lists image and audio as active input modalities.

Internal audits — which ISO 27001 requires annually as part of clause 9.2 — will surface this inconsistency during control evidence review. The internal auditor will sample a population of inference requests and match each to its control evidence. A request that included an image upload will have a text-side scan log entry and no image-side scan log entry. The internal audit finding will note: A.8.28 implementation does not cover the image input channel documented in the system architecture. The gap is then remediated before the external certification audit, or it surfaces as a non-conformity in the external audit if the internal audit cycle has not addressed it.

Customer security questionnaires — increasingly common for B2B SaaS companies with ISO 27001 certification as a procurement requirement — ask the same questions in informal language: "Does your product's input validation cover image uploads?" and "What security controls are active on voice input?" These are A.8.28 questions in questionnaire form. A vendor whose SoA documents a text-only implementation cannot answer yes to either without qualification.

A.8.28 secure coding — input validation at the AI inference boundary

For traditional web applications, A.8.28 input validation covers the parameters and payloads that web endpoints process: query strings, form fields, JSON bodies, file upload contents. The validation pattern is mature: validate type, length, and format before use; scan uploaded files for malware; reject inputs that violate expected schema. ISO 27001-certified web application teams have established A.8.28 implementations that cover these input surfaces with established tooling.

AI inference pipelines extend the A.8.28 input surface in a way that most existing control inventories have not yet addressed. When an inference request includes an image file alongside a text prompt, the "input" to the inference pipeline is not just the text field — it is the image bytes that the vision encoder will consume as part of its multimodal context. The inference boundary — the code path that prepares the multimodal payload for the model call — is where the A.8.28 validation requirement applies. Validating the text field and forwarding the image bytes without inspection is structurally equivalent to validating query parameters but forwarding JSON body content without validation: the implementation covers some inputs and ignores others.

The operative question for A.8.28 compliance is whether the organisation treats external data sources as untrusted until validated. A user-submitted image file is an external data source. The validation mechanism for a text document is a text PI scanner. The validation mechanism for an image file is a multimodal scanner that inspects the pixel layer for adversarial-instruction content. Without a multimodal scan, the image bytes are forwarded to the vision encoder in an untrusted state — the state A.8.28 explicitly requires the organisation to remediate through validation before use.

The A.8.28 requirement applies to AI features at inference time, not just at development time. A.8.28's scope is software development and deployment: the control applies to the operational inference pipeline running in production, not only to the development practices that produced it. An inference pipeline that was developed securely but that forwards unvalidated image bytes to a vision encoder in production is non-compliant with A.8.28's runtime deployment requirement. The validation must be active on the inference boundary, not merely documented as a design principle.

The evidence gap: what text-only scanners cannot document for image and audio inputs

The ISO 27001 certification evidence question is not whether a known FigStep payload would succeed against the deployed system. It is whether the control log shows that validation was performed at the inference boundary for every input the model consumed. Internal and external auditors reviewing A.8.28 compliance will request evidence records: show me that input validation ran for this inference request. The evidence record must cover the complete input set the model received, not only the text portion.

For a text-only scanner applied to an AI application that accepts image uploads, the evidence structure per request looks like this. A user submits a request with a text prompt and an attached image. The text scanner receives the text field, runs the detection pipeline, and writes a log entry: request_id=R1, modality=text, score=12, action=allowed. The image field bypasses the scanner and is forwarded directly to the vision encoder. The model receives both the text and the image as part of its multimodal context. The control log for request R1 contains one entry covering the text field. The vision encoder received the image bytes without any A.8.28 validation being performed on them.

When an internal auditor samples request R1 and asks "show me the A.8.28 input validation evidence for this request," the evidence package covers the text channel. The auditor then asks: this request included an image — where is the input validation record for the image? The team can explain that the scanner only processes text inputs. The auditor records: A.8.28 — image inputs not validated before processing during the review period. This is a non-conformity finding, not a risk-severity question. The control requirement is to validate before use; the evidence shows validation did not occur for the image input channel.

The same pattern applies to audio inputs in voice-enabled AI features. A WhisperInject-class payload embedded in an audio waveform is an adversarial instruction in an external data source. A.8.28 requires that external data sources are treated as untrusted until validated. A speech-to-text transcript does not constitute validation of the audio waveform — it is a derived representation of the waveform, not an inspection of the waveform for adversarial content. The A.8.28 evidence record for an audio inference request must show that the waveform bytes were inspected, not that a downstream text representation was inspected. For RAG pipelines that retrieve image-bearing PDFs, the PDF images are external data from a retrieval source and are subject to the same A.8.28 treatment as user-submitted images. Each multimodal input channel the inference pipeline processes is a separate A.8.28 evidence line item.

Why OCR-before-text-scan does not satisfy A.8.28 for image inputs

The most common response to the image input validation gap is to insert an OCR step before the text scanner: convert the image to a text representation, pass the text to the existing PI scanner, and treat the scan record as covering the image. This approach does not satisfy A.8.28's input validation requirement for two structural reasons that parallel the SOC 2 CC6.6 argument.

The first is architectural. The FigStep family of attacks — including the AgentTypo adversarial-glyph variant — is explicitly designed to defeat OCR-before-text-scanner pipelines. FigStep renders an adversarial instruction as typography using anti-OCR fonts or adversarial rendering techniques that exploit the gap between the character set a neural vision encoder reads and the glyph alphabet an OCR system extracts. The OCR transcript is clean; the text scanner scores it low; the image is forwarded to the vision encoder with a passing validation record. The scan record is evidence that the OCR output was inspected — it is not evidence that the image bytes were inspected. A.8.28's requirement is to validate the input. The input to the vision encoder is the image bytes. The OCR output is a derived artifact, not the input. See FigStep detection and AgentTypo detector for the detailed attack model.

The second is evidentiary. ISO 27001 certification auditors reviewing A.8.28 compliance will ask: what was validated? The answer "the OCR-derived text representation of the image" is not the same as "the image bytes the model consumed." For a principle-based reading of A.8.28 — "inputs shall be validated before use" — the "input" to the vision encoder is the image bytes, and the "use" is the model call. Validation of a derived representation is not validation of the input. This distinction is the same one that applies to the SOC 2 CC6.6 evidence question and to the EU AI Act Article 15(5) adversarial-robustness evidence question. The vocabulary differs across frameworks; the architectural gap is the same.

For audio inputs, the parallel is even clearer. A speech-to-text adapter transcribes the audio stream. A text PI scanner inspects the transcript. A WhisperInject payload embeds an instruction in the waveform that the audio model decodes while the transcript representation omits it or misrepresents it — because the payload exploits the gap between the representation produced by the STT system and the representation the audio model's encoder produces directly from waveform bytes (see WhisperInject detection). The transcript scan log shows a clean result; the waveform is forwarded to the audio model. The A.8.28 evidence record for that request shows validation of the derived transcript — not of the waveform bytes that the model actually consumed. The gap is structurally identical to the image case.

Coverage matrix against A.8.28, A.8.7, and A.8.16 evidence requirements

Mapping the self-serve prompt injection scanner landscape to ISO 27001:2022 Annex A evidence requirements produces a picture that sorts cleanly along the modality boundary.

Four clarifications apply to this matrix. First, Promptfoo is a pre-deployment evaluation harness — it generates adversarial probes and verifies model behaviour at CI time. ISO 27001 A.8.28 operational compliance requires runtime input validation during production inference, not only pre-deployment test coverage. Promptfoo's eval records are development evidence; they are not per-production-request A.8.28 validation records. Second, Azure Prompt Shields' image-input capability covers content moderation categories — violence, CSAM, hate speech — not prompt-injection payload detection. A content moderation "no harmful content" score for an image is not A.8.28 input validation evidence for adversarial-instruction payloads. Content moderation and PI detection are separate functions with separate threat models; the Azure Prompt Shields vs Glyphward comparison covers this distinction in detail. Third, Lakera Guard was acquired by Check Point in 2025 and is moving upmarket; the self-serve evidence log format and SoA documentation support may change — the Lakera alternative page tracks the practical implications. Fourth, the LLM Guard OSS implementation covers text-side PI and is commonly used as the text-path complement in a run-both architecture; the LLM Guard alternative page covers the integration pattern for adding multimodal coverage without replacing the text path.

Five-step ISO 27001-aligned architecture for multimodal AI input controls

Implementing ISO 27001:2022 A.8.28-compliant input validation for a multimodal AI product requires five steps that map directly onto the relevant Annex A control language.

1. Enumerate every input modality in the ISMS asset inventory and system architecture documentation. ISO 27001 clause 8.1 requires that the organisation implements controls for its identified information security risks. The risk assessment (clause 6.1.2) must identify all information assets the system processes, including each input modality an AI feature accepts. An asset inventory that lists "user text prompts" but omits "user-uploaded images," "audio inputs," and "image-bearing PDFs from retrieval sources" creates a risk assessment gap — the identified assets do not match the actual asset surface. Update the asset inventory and system architecture document to enumerate each multimodal input channel: direct image upload, direct audio input, images retrieved from external URLs by tool-calling agents, image-bearing PDFs in RAG corpora, content blocks from MCP servers. Per-product inventory examples are available for chatbots with image upload, RAG pipelines, MCP servers, voice agents, and screenshot-reading agents.
2. Place the A.8.28 input validation control at the inference boundary — after input receipt and before the model call. A.8.28 requires validation "before use." For the vision encoder, "use" is the model call. The validation scan must be positioned in the inference pipeline between input receipt and model call: image bytes or URL posted to the scan endpoint, audio bytes posted to the audio scan endpoint, scan response received and scored before the multimodal payload is assembled for the model call. Early placement at upload time (which may precede the inference request by minutes or hours) does not satisfy the "before use" requirement at the inference boundary — the validated state cannot be assumed to hold for the duration between upload and inference. Each inference request triggers a fresh scan of the input bytes it will forward to the model.
3. Write per-request scan records as the A.8.28 and A.8.16 operational evidence. Each scan response from the inference-boundary scan generates the evidence record that satisfies A.8.28 (validation was performed before use) and A.8.16 (anomalous inputs are monitored and scored). The record should include: application request_id, Glyphward scan_id, input modality, risk_score, threshold applied, and action (allowed or blocked). The request_id links the scan record to the application access log; the scan_id links it to the immutable server-side scan record at Glyphward, which can be produced as corroborating evidence if the application log is questioned during an audit. Records should be append-only and immutable for the duration of the ISO 27001 evidence retention period (typically aligned with the ISMS review cycle, commonly one to three years). The SoA entry for A.8.28 can now accurately describe: "inference-boundary multimodal scan produces a per-request validation record for all image and audio inputs; scan_id is logged alongside application request_id in the immutable access log."
4. Route high-risk scan events into the A.8.16 monitoring and A.8.7 incident detection pipeline. A.8.16 requires active monitoring of applications for anomalous behaviour and evaluation of potential incidents. A scan result with a risk score above the blocking threshold is the anomaly signal A.8.16 expects. Glyphward's Pro plan returns synchronous scan results; webhook delivery of high-risk alerts enables async pipeline architectures. Route webhook payloads to your SIEM ingestion endpoint — Splunk, Datadog, Elastic Security, Azure Sentinel — to generate structured A.8.16 alert records. The downstream A.8.7 incident detection flow (evaluate whether the anomaly constitutes a malware / adversarial content incident) follows the same runbook your security operations team uses for other alert classes, with scan_id and risk_score as the triage artefacts. For ISO 27001 programmes that also run under OWASP LLM01:2025, NIST AI RMF, CISA AI guidance, or SOC 2 CC7.2, the same SIEM alert stream satisfies the monitoring evidence requirement across all four frameworks simultaneously.
5. Update the SoA and conduct the A.8.28 / A.8.7 / A.8.16 scope review in each annual ISMS review cycle. ISO 27001 clause 9.3 requires management review of the ISMS at planned intervals. The management review should include: which input modalities the system currently accepts (updated as features ship), whether the inference-boundary scan covers all active modalities, and whether the payload corpus the scanner checks against has been updated for new attack families published since the last review. A.8.28's scope evolves with the product — a new audio upload feature added in Q3 must be added to the A.8.28 implementation record before the next audit cycle. The annual SoA review is the checkpoint that keeps the documented controls aligned with the actual inference pipeline.

ISO/IEC 42001:2023 — the AI management system standard and its A.8.28 complement

ISO/IEC 42001:2023 — published December 2023 — is the first dedicated international standard for AI management systems. It follows the same high-level structure (Annex SL) as ISO 27001, enabling organisations to build an AI management system (AIMS) as an extension to their existing ISMS. For AI products pursuing both ISO 27001:2022 certification and ISO/IEC 42001:2023 compliance, the two standards are designed to be implemented together, with shared risk assessment and internal audit processes.

Within ISO/IEC 42001, the most directly relevant controls for AI input security sit in Annex A. Control A.6.2.4 addresses AI system robustness and requires that AI systems are tested for robustness against adversarial inputs — FigStep, AgentTypo, and WhisperInject are exactly the adversarial input classes this control covers. Control A.8.2 addresses data quality for AI, including validation of training data and inference-time input data for malicious or corrupted content. Annex B.8.1 provides implementation guidance for AI system robustness that aligns with the inference-boundary scan architecture described above.

For an organisation pursuing ISO/IEC 42001 alongside ISO 27001, the same inference-boundary multimodal scan satisfies both: the ISO 27001 A.8.28 input validation requirement and the ISO/IEC 42001 A.6.2.4 adversarial-input robustness requirement are addressed by the same per-request scan and the same evidence record. The SoA under ISO 27001 and the AIMS scope document under ISO/IEC 42001 can reference the same implementation. ISO/IEC 42001 certification is also increasingly cited in procurement questionnaires from European enterprise buyers alongside ISO 27001, particularly following the EU AI Act's August 2026 effective date for high-risk AI systems — the EU AI Act Article 15 compliance page covers the adversarial-robustness evidence requirements that overlap with ISO/IEC 42001 A.6.2.4.

The strategic case for pursuing ISO/IEC 42001 alongside ISO 27001 is strong for AI-native SaaS companies entering enterprise procurement cycles in 2026. ISO 27001 alone answers the information security question; ISO/IEC 42001 answers the AI-specific governance question that security assessors are now asking separately. The compliance investment in inference-boundary multimodal scanning — the A.8.28 implementation — addresses controls in both standards and satisfies the same procurement questionnaire questions regardless of which certification is being evaluated.

How Glyphward fits

Glyphward is the inference-time multimodal scanner — bytes in, 0–100 risk score and flagged regions out — positioned at the inference boundary that ISO 27001:2022 A.8.28 identifies as the input validation point. The HTTP contract is a single POST per input: image bytes or URL forwarded to the image scan endpoint, or audio bytes forwarded to the audio scan endpoint. The response includes a risk score, a flagged region (bounding box for image inputs, time window for audio inputs), a modality-tagged reason string, and a stable scan_id that persists on the Glyphward server as an immutable record. The scanning pipeline runs CLIP embedding plus a typographic-PI detection head plus Tesseract OCR cross-referenced against a curated payload corpus on the image side, and a waveform anomaly classifier plus Whisper-small transcript filter on the audio side.

For ISO 27001:2022 evidence packaging, Glyphward produces a per-request validation record on the image and audio side that parallels what your existing text scanner produces on the text side. The scan_id is the stable external reference that allows the SoA implementation description to point to an immutable corroborating record. The risk_score and flagged_region are the A.8.28 technical validation detail. The action field (allowed or blocked) is the validated-before-use outcome required by the control. Logging these four fields against your application request_id populates the A.8.28 evidence log and the A.8.16 anomaly monitoring record simultaneously, across all input modalities, for the duration of the ISO 27001 certification period. Glyphward does not replace your existing text scanner — the two run in parallel, each covering their respective channels. Pricing is flat-rate self-serve — see the full pricing breakdown — starting at $29/mo for Pro with a free no-card tier for prototyping and SoA gap assessment.

Get early access · See the API surface

Related questions

Further reading

• SOC 2 AI security controls — multimodal prompt injection evidence — the SOC 2 Trust Services Criteria companion; CC6.6 and CC7.2 are the US-facing counterparts to ISO 27001 A.8.28 and A.8.16; the same per-request scan log satisfies both.
• EU AI Act Article 15 — multimodal prompt injection compliance — for organisations pursuing ISO 27001 and EU AI Act simultaneously; Article 15(5) adversarial-robustness evidence requirements are addressed by the same inference-boundary scan that satisfies A.8.28.
• OWASP LLM01:2025 prompt injection — multimodal sub-category — the practitioner threat catalogue that explicitly names the multimodal attack classes; covers the three delivery channels (direct image, direct audio, indirect tool-delivered) that A.8.28 validation must span.
• OWASP LLM02:2025 Insecure Output Handling — multimodal origin — the downstream execution risk when a multimodal injection produces output flowing to a code interpreter; the A.8.16 incident-evaluation implication of an unblocked high-risk image.
• NIST AI RMF GenAI Profile (NIST AI 600-1) — the US-side risk management framework; its Measure and Manage evidence requirements align directly with ISO 27001 A.8.16 monitoring and A.8.28 operational evidence.
• CISA deploying AI systems securely — prompt injection and the multimodal gap — US government operational guidance; inference-boundary hardening language is the closest regulatory analogue to ISO 27001 A.8.28's input validation requirement.
• MITRE ATLAS — multimodal prompt injection (AML.T0051) and LLM jailbreak (AML.T0054) — for ISO 27001 programmes that run annual red-team exercises; ATLAS technique IDs provide structured references linking test findings to the A.8.28 / A.8.7 controls being tested.
• NIST AI 100-2e2025 (AML Taxonomy) — canonical terminology for prompt injection (direct, indirect) and jailbreak; the reference vocabulary for A.8.28 SoA implementation descriptions and ISO/IEC 42001 AIMS documentation.
• FigStep detection · AgentTypo detector · WhisperInject detection · Audio prompt-injection detection — the specific attack families the A.8.28 / A.8.7 controls must cover; each page includes the structural reason why OCR-before-text-scan does not constitute validation of the input.
• For chatbots with image upload · For RAG pipelines · For MCP servers · For voice agents · For screenshot agents — per-product A.8.28 validation mount points; each covers the specific pipeline architecture where "before use" validation must occur.
• Multimodal LLM security API — the API surface the A.8.28 input validation control calls into, with latency budget and throughput characteristics relevant to the ISMS system architecture documentation.
• vs Lakera Guard · vs Azure Prompt Shields · vs LLM Guard — head-to-head analysis of which ISO 27001:2022 Annex A evidence each tool produces per modality and where the run-both pattern applies.