ASD's Appendix A, annotated

In May 2026 ASD's ACSC, with its Canadian, NZ and UK counterparts, publishedOpportunities for AI in cyber defence. Its Appendix A is a question list for AI vendors, and it is quietly the most useful part of the paper: a government-issued procurement script your next AI vendor will be marked against. I wrote about the paper itself inthe essays; this page is the practical companion. Print the appendix, take it to the meeting, and read below for what each block is actually testing.

The honest disclosure first: I work on products at Senetas in exactly this territory, so I sit on the vendor side of this table too (the opinions here are mine, not the company's). That is also why I know which questions bite.

Measurable outcomes

What it tests: whether the vendor can say what the product does in numbers a buyer can verify later. A good answer names the metric, the baseline and how you would measure it yourself. A bad answer is adjectives. If the outcome cannot be measured, you are buying a mood.

Scope and limits

What it tests: whether the vendor knows where their product stops. Every real system has failure modes and unsupported cases; a vendor who cannot name theirs either does not know them (worse) or will not say (bad enough). The crisp version to ask: what would you NOT use this for?

Human oversight

What it tests: who is accountable when the AI acts. A good answer describes which actions need human approval, how the approval works at volume, and what happens when the human is removed. Watch for answers that only work at demo scale (a human approving everything is a demo, not an operating model).

Transparency and auditability

What it tests: whether you can prove, afterwards, what the system did. The good answer is a trail that captures the action, the data touched, and the principal behind it, exportable to your own tooling. My rule from the glossary: a governance system you cannot audit is a governance claim, not a governance system.

Security of the AI system itself

What it tests: whether the vendor treats their own AI stack as an attack surface. Prompt injection, model supply chain, the plumbing between components. A vendor who says their system cannot be manipulated has just failed the question. The good answer assumes compromise and describes the blast radius.

Data protection and sovereignty

The block with teeth, and the one I would start with. The paper's own questions include, verbatim: "How is sensitive data handled, stored and protected during AI processing?", "What data is retained, reused, or used to retrain models?" and "Which jurisdictions process or store customer data, including through third-party AI services?" Ask that last one for every hop, because most AI products route through a frontier-model API, which routes through whatever sits behind it. If the jurisdiction answer takes more than a paragraph, that is the answer.

Integration

What it tests: how the product touches your existing environment, and with whose credentials. The question I would add to the government's list: does the AI act with its own identity and scoped access, or does it inherit whatever the connected systems will give it? The second answer sets your blast radius for you, and generously.

Resilience and lock-in

What it tests: what leaving looks like. Data formats, export paths, what stops working when the contract ends, what they keep. Ask on the way in; the answer only gets worse on the way out.

Net: Appendix A works because it is not really about AI. It is a data-governance questionnaire wearing an AI title, and the vendors who can answer it cleanly are the ones who governed their data before the AI arrived. Use it, and read the library for the sources behind this page.