Free AI, Cybersecurity & Audit Resources
Use these practical resources to organize your questions, inventory AI use and prepare evidence for an assessment. Start with the free AI Governance QuickScan or choose a checklist, template or guide for the task in front of you.
Interactive self-check
AI Governance QuickScan
For AI owners and teams starting a governance conversation. Use self-reported questions about your practices to identify what is known, unknown and worth examining next.
- Self-report questions with unknown and not-applicable choices
- Preliminary observations and three practical next actions
- A fictional example and a related evidence checklist
Preliminary guidance, not an assessment conclusion. It does not test controls or provide an audit, security scan, certification or compliance/legal conclusion.
AIGC Technical AI Controls Checklist
Twenty questions that follow an AI-enabled change from an authorised task through peer review, testing, release and runtime monitoring, with the evidence that would move each answer beyond self-report.
Audience: Engineering leads, technology-risk teams and internal auditors preparing a technical review of AI-generated or AI-assisted code and model changes.
Preview
| ID | Area | Question | Evidence | Suggested control stage | Suggested verification | Actual result | Evidence reference / notes |
|---|---|---|---|---|---|---|---|
| AIGC-01 | Authorisation | Was the AI-assisted change traceable to an approved ticket or backlog item with a named requester? | Ticket link in the commit or pull request; approval field populated before work started. | Design | Inspected | ||
| AIGC-02 | Authorisation | Is use of code or content assistants permitted for this repository, and is the permitted tool list written down? | Engineering policy or repository README naming approved assistants and prohibited data. | Design | Inspected | ||
| AIGC-03 | Peer review | Did a person other than the author (and other than the assistant) review and approve the change? | Branch protection rules; reviewer identity on a sample of merged pull requests. | Operation | Tested | ||
| AIGC-04 | Peer review | Does the review record state whether AI-generated code was disclosed and how it was checked? | Pull request template field or label; sample of reviews with the field completed. | Implementation | Inspected | ||
| AIGC-05 | Testing | Did automated tests run and pass on the final commit before merge? | CI run attached to the merge commit; failing runs cannot be bypassed without a logged override. | Operation | Tested | ||
| AIGC-06 | Testing | For model or prompt changes, was an evaluation set run and were results compared with a baseline? | Evaluation report with dataset version, metrics and acceptance threshold. | Implementation | Inspected | ||
| AIGC-07 | Testing | Were secrets, personal data and licensed code checked for before merge? | Secret-scanning and licence-scanning job output on the sampled change. | Operation | Tested | ||
| AIGC-08 | Release | Was deployment to production performed by a pipeline identity rather than an individual, with the approval recorded? | Deployment log showing actor, approver and artefact digest. | Operation | Tested |
Showing 8 of 20 items — the full list is in the download
Suggested stages and verification are planning prompts, not completed results. Record actual procedures, findings and evidence references after performing the work; blank result fields mean no result is recorded.
How to use
- Pick one AI-enabled system and one recent change to it. Answer every question for that change only; do not answer for the programme in general.
- Suggested control stage and Suggested verification are planning prompts, not completed findings. Leave Actual result and Evidence reference / notes blank until procedures have been performed; then record what was done, the evidence reference, result and limitations.
- Treat any answer that stays Self-reported as an open item, not a pass.
- Use Suggested control stage to plan which aspect to examine: design, implementation or operation. Select actual procedures appropriate to the scope; a suggested Tested entry is not evidence that testing occurred.
Fictional example — Northwind Claims Ltd (not a real client)
Change reviewed: pull request #418 adding an LLM-drafted claims summary to the adjuster console.
AIGC-03 (peer review): Self-reported 'always reviewed'. Inspection of the pull request showed it was approved by the same engineer who used the assistant to write it. Basis recorded as Inspected; finding raised: independent review not operating.
AIGC-11 (prompt and model version pinned): Tested — the deployment manifest pinned the model version and a replay of three prompts matched the recorded outputs.
Sources referenced
- NIST AI Risk Management Framework (AI RMF 1.0), NIST AI 100-1
- ISO/IEC 42001:2023 — Artificial intelligence management system
- ISO/IEC 27001:2022 — Information security management systems
- ISO/IEC 27002:2022 — Information security controls
- IIA Global Internal Audit Standards (2024)
- AICPA Trust Services Criteria
- NIST Secure Software Development Framework (SSDF), SP 800-218
- OWASP Top 10 for Large Language Model Applications
Formats: PDF
Related service: AI & Agentic AI AssuranceRelated article: AI Technical Controls Assessment: From Work Ticket to Production
Educational resource — not legal, audit or certification advice. Suggested control stages and verification procedures are planning prompts, not completed results. Record actual procedures, evidence, results and limitations separately. Conclusions depend on agreed criteria, procedures and evidence; completing a template does not establish compliance or control effectiveness.
AI Agent Risk & Controls Checklist
Eighteen questions for any software agent that plans and acts on behalf of the organisation: task boundaries, human authorisation, identity and permissions, integrations, stop and recovery mechanisms, and the records that show the controls operate.
Audience: Agent owners, platform engineers, risk reviewers and internal auditors.
Preview
| ID | Area | Question | Evidence | Suggested control stage | Suggested verification | Actual result | Evidence reference / notes |
|---|---|---|---|---|---|---|---|
| AGT-01 | Task boundaries | Is the agent's purpose, permitted actions and prohibited actions written down and approved by the business owner? | Agent charter or design document with owner sign-off and date. | Design | Inspected | ||
| AGT-02 | Task boundaries | Is the set of tools or functions the agent can call enumerated, and is anything outside the list refused? | Tool registry or configuration; test invoking an unregistered tool is refused and logged. | Implementation | Tested | ||
| AGT-03 | Task boundaries | Are limits set on volume, value and rate (e.g. maximum actions per hour, maximum spend per task)? | Limit configuration; log of a limit being reached and enforced. | Operation | Tested | ||
| AGT-04 | Human authorisation | Which actions require a human approval before execution, and does the approval actually interrupt the action? | Approval matrix; walkthrough of an approval-required action showing it waits for a named approver. | Operation | Tested | ||
| AGT-05 | Human authorisation | Can approvers see what the agent intends to do (inputs, target, amount) before approving, in plain language? | Screenshot or record of an approval request presented to the approver. | Implementation | Inspected | ||
| AGT-06 | Identity | Does the agent run under its own identity (not a person's credentials) with an accountable owner? | Service account record; owner field; authentication log showing the agent identity. | Implementation | Inspected | ||
| AGT-07 | Permissions | Are the agent's permissions the minimum for its charter, and were they reviewed in the last cycle? | Permission export compared with the charter; review sign-off. | Operation | Tested | ||
| AGT-08 | Permissions | Are credentials the agent uses stored in a secrets manager, scoped per integration and rotated? | Secrets inventory; rotation dates; no credentials in prompts or code. | Implementation | Inspected |
Showing 8 of 18 items — the full list is in the download
Suggested stages and verification are planning prompts, not completed results. Record actual procedures, findings and evidence references after performing the work; blank result fields mean no result is recorded.
How to use
- Complete one copy per agent (or per distinct agent role). Name the agent, its owner and the systems it can touch at the top.
- Suggested control stage and Suggested verification describe proposed work, not completed results. After performing procedures, record the Actual result and Evidence reference / notes, including the actual verification, scope and limitations. Broad permissions supported only by self-report warrant follow-up.
- Where the agent can spend money, change records or message people, insist on Tested evidence for the authorisation and stop controls before relying on it.
Fictional example — Contoso Logistics 'DispatchBot' (not a real deployment)
Scope: an agent that re-books delayed shipments and e-mails customers.
AGT-04 (human approval above a threshold): Design said re-bookings over 5,000 EUR need approval. Testing with a 6,000 EUR scenario showed the approval step was skipped when the original booking had already been cancelled. Finding: control implemented but not operating for that path.
AGT-12 (kill switch): Tested — the owner disabled the agent's service account during the review and queued actions stopped within one minute.
Sources referenced
- NIST AI Risk Management Framework (AI RMF 1.0), NIST AI 100-1
- ISO/IEC 42001:2023 — Artificial intelligence management system
- ISO/IEC 27001:2022 — Information security management systems
- ISO/IEC 27002:2022 — Information security controls
- IIA Global Internal Audit Standards (2024)
- AICPA Trust Services Criteria
- NIST AI 600-1 — Generative Artificial Intelligence Profile
- OWASP Top 10 for Large Language Model Applications (excessive agency)
Formats: PDF
Related service: AI & Agentic AI AssuranceRelated article: How to Test Human Oversight Controls for AI Agents
Educational resource — not legal, audit or certification advice. Suggested control stages and verification procedures are planning prompts, not completed results. Record actual procedures, evidence, results and limitations separately. Conclusions depend on agreed criteria, procedures and evidence; completing a template does not establish compliance or control effectiveness.
AI Audit Evidence Request Checklist
A request list of twenty evidence items for an AI governance or controls review, with suggested control stages and verification procedures. These are planning prompts, not completed results; the tracker provides blank fields for actual results and evidence references.
Audience: Teams preparing for an AI review, and reviewers assembling an initial request list. Ships as PDF and an editable XLSX tracker.
Preview
| ID | Area | Question | Evidence | Purpose | Suggested control stage | Suggested verification | Actual result | Evidence reference / notes |
|---|---|---|---|---|---|---|---|---|
| EVD-01 | Governance | Approved AI policy or AI use standard, with version history and approval record. | Policy document; approval minutes or workflow record. | Establishes the intended rules the other evidence is judged against. | Design | Inspected | ||
| EVD-02 | Governance | Roles and responsibilities for AI systems (owner, risk approver, technical lead) and the forum that oversees them. | RACI or charter; last two meeting records. | Shows accountability exists and the oversight forum actually meets. | Design | Inspected | ||
| EVD-03 | Inventory | Current AI system inventory including third-party and embedded AI features. | Inventory export with date; reconciliation to procurement or cloud billing for completeness. | Defines the population in scope; completeness testing depends on it. | Implementation | Tested | ||
| EVD-04 | Risk | Risk or impact assessment for each in-scope system, with the method used and the sign-off. | Completed assessments; template; approver identity and date. | Shows risk was considered before deployment and who accepted it. | Design | Inspected | ||
| EVD-05 | Data | Data sources, lineage and classification for training, fine-tuning, retrieval and prompts. | Data-flow diagram; classification labels; data agreements for external data. | Needed to assess data-quality, privacy and IP exposure of the model. | Implementation | Inspected | ||
| EVD-06 | Data | Privacy and legal review for personal data used by the system (e.g. DPIA where applicable). | Completed assessment and legal sign-off. | Confirms legal review happened before personal data was processed. | Design | Inspected | ||
| EVD-07 | Access | Access lists for model configuration, keys, training data and production endpoints, plus the most recent access review. | System export (not a summary); reviewer sign-off; removal tickets. | Supports a conclusion that least-privilege operated during the period. | Operation | Tested | ||
| EVD-08 | Change | Change records for model, prompt, tool and threshold changes in the period. | Ticket export; sample tickets with approval, test results and deployment link. | Supports a conclusion that changes were authorised and tested in the period. | Operation | Tested |
Showing 8 of 20 items — the full list is in the download
Suggested stages and verification are planning prompts, not completed results. Record actual procedures, findings and evidence references after performing the work; blank result fields mean no result is recorded.
The editable XLSX adds a tracking column per item: Owner (role) · Period covered (from – to) · Source system / location · Sensitivity · Limitation (what this evidence cannot show) · Due (date) · Status · Actual result · Evidence reference / notes.
How to use
- Send the XLSX to the system owner with the Owner and Due columns completed. Ask for the artefact itself, not a description of it.
- For every item record the Period covered (operation evidence must span the review period, not just the day of the request), the Source system it was exported from, and its Sensitivity so the handling and storage of the file can be agreed before it is sent.
- Use the Status column (Requested, Received, Insufficient, Accepted, Not applicable) and record why an item was Insufficient so the follow-up is specific.
- Use the Limitation column to note what the item cannot prove — a screenshot shows one day, a policy shows intent — so nobody over-reads it later. The Purpose column explains why the item is asked for; keep it when you add rows of your own.
- An item marked Self-reported (e.g. a questionnaire answer) can start the conversation but should be replaced by an Inspected or Tested item before the review concludes.
- Suggested control stage and Suggested verification are proposals, not completed results. Record actual procedures and findings in Actual result and supporting references in Evidence reference / notes. Request design, implementation or operation evidence according to the agreed scope; a single artefact rarely establishes effectiveness by itself.
Fictional example — Fabrikam Health (not a real engagement)
EVD-07 (access review): received a slide saying 'quarterly reviews completed'. Marked Insufficient — requested the Q2 export (period 1 April – 30 June), source: identity provider admin console, sensitivity: Internal, limitation: shows entitlements on export day only. Reviewer sign-off and the removal tickets received four days later; accepted after two removals were traced.
EVD-15 (incident log): received a redacted export covering the full period. Accepted as Operation evidence; one incident selected for walkthrough.
Sources referenced
- NIST AI Risk Management Framework (AI RMF 1.0), NIST AI 100-1
- ISO/IEC 42001:2023 — Artificial intelligence management system
- ISO/IEC 27001:2022 — Information security management systems
- ISO/IEC 27002:2022 — Information security controls
- IIA Global Internal Audit Standards (2024)
- AICPA Trust Services Criteria
- ISO 19011:2026 — Guidelines for auditing management systems
Formats: PDF, XLSX
Related service: Framework Assessments & Internal AuditsRelated article: ISO 42001 Internal Audit: An Evidence Request Checklist
Educational resource — not legal, audit or certification advice. Suggested control stages and verification procedures are planning prompts, not completed results. Record actual procedures, evidence, results and limitations separately. Conclusions depend on agreed criteria, procedures and evidence; completing a template does not establish compliance or control effectiveness.
AI System Inventory Template
An editable register for every AI system, model and embedded AI feature in use: purpose, owner, model and provider, data sensitivity, autonomy level, risk tier, regulatory exposure and the assurance status of each entry.
Audience: AI governance leads, CISOs, enterprise architects and internal auditors building or reconciling an AI inventory. Ships as XLSX with dropdowns and a PDF column guide.
Preview
| Inventory ID | System / feature name | Business purpose | Business owner (role) | Technical owner (role) | Type | Model / provider | Agents / connectors (connected systems) | Lifecycle stage | Data sensitivity | Autonomy | Affected parties | Risk tier | Regulatory exposure | Key controls in place | Approval status | Approved by (role) and date | Assurance status | Last review (date) | Next review (date) | Notes |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| INV-007 | Returns-fraud scorer (FICTIONAL EXAMPLE) | Scores product-return requests for likely fraud and recommends a manual check. | Head of Loss Prevention | Data Science Lead | Internal model | Internal gradient-boosted model v3.2 | Reads order history (ERP, read-only); writes a flag to the returns desk queue; no autonomous agent | Production | Personal data | Recommends — human decides | Customers requesting returns; store staff | High | GDPR; consumer protection | Monthly drift report; manual decision required; access review quarterly | Approved with conditions | AI Governance Forum, 2026-03-12 (condition: manual decision retained) | Inspected | 2026-08-14 | 2026-11-14 | Example row — delete before use. |
How to use
- Enter one row per AI system or distinct AI feature, including vendor products with embedded AI and internal experiments that touch production data.
- List every connected system, tool or agent the entry can read from or write to in 'Agents / connectors'; 'Unknown' is an acceptable interim answer and is itself a finding to follow up.
- Record whether the use was approved, by which role and when. 'Not requested' and 'Unknown' entries should be escalated rather than quietly left in place.
- Complete the Risk tier only after Data sensitivity, Autonomy and Affected parties are filled in; the tier should be explainable from those three columns.
- Reconcile the register at least quarterly against procurement, cloud billing and identity-provider application lists; record the reconciliation date in the 'Last review (date)' column.
- The 'Assurance status' column distinguishes Self-attested entries from those Inspected or Tested by a reviewer. Do not report an inventory as 'complete' until reconciliation has been performed.
Fictional example row — Tailspin Retail (not a real organisation)
INV-007 'Returns-fraud scorer': internal gradient-boosted model, owner Head of Loss Prevention, personal data (customer purchase history), connectors 'ERP order history (read-only); returns desk queue (write)', autonomy 'Recommends — human decides', approval 'Approved with conditions' by the AI Governance Forum on 2026-03-12, risk tier High, regulatory exposure 'GDPR; consumer protection', assurance status Inspected 2026-08, next review 2026-11.
Sources referenced
- NIST AI Risk Management Framework (AI RMF 1.0), NIST AI 100-1
- ISO/IEC 42001:2023 — Artificial intelligence management system
- ISO/IEC 27001:2022 — Information security management systems
- ISO/IEC 27002:2022 — Information security controls
- IIA Global Internal Audit Standards (2024)
- AICPA Trust Services Criteria
- EU Artificial Intelligence Act — Regulation (EU) 2024/1689
Formats: XLSX, PDF
Related service: Governance & PolicyRelated article: AI Vendor Risk Assessment: Questions to Ask Before You Buy
Educational resource — not legal, audit or certification advice. Suggested control stages and verification procedures are planning prompts, not completed results. Record actual procedures, evidence, results and limitations separately. Conclusions depend on agreed criteria, procedures and evidence; completing a template does not establish compliance or control effectiveness.
Gap Assessment vs. Internal Audit: What Each Can and Cannot Tell You
A short guide for buyers and boards on the difference between a readiness gap assessment and an internal audit: purpose, independence, evidence standard, output and the conclusions each can legitimately support.
Audience: Executives, audit committee members, compliance leads and anyone deciding which engagement to commission.
Preview
Why the distinction matters
Both engagements can produce findings and recommendations. Their conclusions follow the agreed criteria, scope, procedures and evidence, not the engagement label. A gap assessment may include inspection and testing; an internal audit may focus on a management system, implementation, conformance or selected operational questions. Do not infer period-wide operating effectiveness from either label.
| Aspect | Gap assessment | Internal audit |
|---|---|---|
| Primary question | What differences exist between current practice and agreed criteria? | What does the scoped examination establish against the applicable audit criteria? |
| Independence | Agree objectivity and conflict safeguards; advisory or remediation work may be included. | Apply the relevant framework's independence and objectivity requirements; reporting arrangements vary. |
| Main evidence | Interviews and documents; inspection, observation and testing where agreed. | Evidence appropriate to the audit objectives; may include interviews, inspection, observation, sampling or re-performance. |
| Evidence basis reached | Self-reported, inspected or tested, according to actual procedures. | State the actual procedures and evidence; the label does not imply every control was tested. |
| Control stage covered | Design, implementation or operation, as scoped. | Stages relevant to the audit criteria and objectives; not universally period-wide operation. |
How to use
- Read the comparison table first, then the section that matches the decision you are making.
- Use the 'Questions to ask a provider' section before signing a proposal; the answers reveal which kind of work is actually being offered.
- Share the one-page table with stakeholders who will receive the report, so expectations about assurance are set before the work starts.
Fictional example — Woodgrove Bank (not a real engagement)
Woodgrove commissioned a two-week 'ISO/IEC 42001 gap assessment' and later described the result to its regulator as an audit. The assessment had relied on interviews and policy review; no control was tested. When asked for evidence that the access review operated, the bank had none. The lesson is not that the gap assessment was poor — it was fit for its purpose — but that its conclusion ('policies largely aligned') was reported as if it were a tested one.
Sources referenced
- NIST AI Risk Management Framework (AI RMF 1.0), NIST AI 100-1
- ISO/IEC 42001:2023 — Artificial intelligence management system
- ISO/IEC 27001:2022 — Information security management systems
- ISO/IEC 27002:2022 — Information security controls
- IIA Global Internal Audit Standards (2024)
- AICPA Trust Services Criteria
- IIA Three Lines Model (2020)
- ISO 19011:2026 — Guidelines for auditing management systems
Formats: PDF
Related service: Framework Assessments & Internal AuditsRelated article: Gap Assessment vs. Internal Audit: Scope, Evidence and Deliverables
Educational resource — not legal, audit or certification advice. Suggested control stages and verification procedures are planning prompts, not completed results. Record actual procedures, evidence, results and limitations separately. Conclusions depend on agreed criteria, procedures and evidence; completing a template does not establish compliance or control effectiveness.
How these resources relate to an assessment
Self-report helps identify questions; inspection and testing can support scoped findings. Gap assessments may include testing when agreed, and internal audits do not universally test operating effectiveness over a period. Conclusions follow the agreed criteria, procedures and evidence, not the engagement label. Record actual work and limitations separately from these planning prompts; completing a template establishes no audit or compliance conclusion.
Read how we assess and test controlsOther resources
- Free framework gap self-assessment — an existing self-check to organize initial framework questions.
- Compliance incident response checklist — guidance for reviewing concerns about compliance work.
- Insights & Research — practical guidance on risk, controls and evidence.
Move from preparation to a scoped assessment
Discuss the questions, criteria and evidence a professional engagement would need.