The reply is a folder, but the question is still unanswered
The control owner sends a link containing thirty documents. The assurance team opens them and cannot identify which period they cover. Several are procedures. Two are screenshots with no capture date. A spreadsheet contains exceptions, but nobody can tell whether it includes the complete population. The recipient has responded promptly. The request has still failed.
Before asking for more documents, read the original email. If it says only "please provide evidence that access is reviewed", the missing detail began with the request. The owner had to decide what review meant, which system mattered and what would count as a satisfactory answer. Those decisions belonged with the person planning the assurance work.
AI can help turn an agreed control and a small inventory into a clearer request schedule. Its contribution is drafting and organisation. The reviewer still decides whether the request is appropriate to the engagement, whether the response answers it and whether additional work is necessary. Keep these decisions visible instead of allowing them to disappear into fluent wording.
For internal audit functions that follow the Institute of Internal Auditors' Global Internal Audit Standards, effective 9 January 2025, Standard 14.1 requires internal auditors to gather information that is relevant, reliable and sufficient for their analyses and evaluations. It does not endorse this particular AI method. Other assurance teams can still borrow the three tests as a practical check. The implication for this workflow is modest: write requests that help the reviewer locate and assess information against the actual objective. Source: IIA
Start with the control that was actually agreed
Copy the supplied control statement into a protected source field. Give it a stable identifier and retain its version or approval reference. Do not begin by asking a model to improve the control. That is a different task, with different authority and potentially different consequences for the work programme.
A control might say that a service owner reviews privileged access each quarter. That wording leaves questions about the systems covered, the evidence of review and the treatment of exceptions. The request writer can make those questions explicit. The writer cannot quietly convert quarterly review into continuous monitoring, or privileged access into every account in the organisation.
Keep the period separate from the response deadline. The period identifies the activity being examined. The deadline tells the recipient when the requested material is due. Mixing them produces replies such as a current screenshot for a historical review. A current view may help explain the system, but it cannot silently stand in for the earlier state.
Also separate the person who responds from the person who owns the control. A records coordinator may collect documents without being authorised to explain why an exception remained open. Name recipients by role in the drafting pack. Confirm their actual responsibilities through the engagement process before the request is issued.
Build a small source pack before opening the chat
For an initial drafting exercise, use the approved control wording, the agreed engagement period and a minimal document inventory. The inventory needs document IDs, titles, dates and a short description of what each item contains. It does not need employee names, account details or unrestricted copies of system logs.
A useful pack also includes the reviewer's known decisions. For example, the reviewer may already have approved a particular system boundary or requested an explanation of unavailable records. Label these decisions as supplied instructions. Otherwise, the model may treat them as suggestions and substitute a broader, more conventional assurance request.
Do not give the model a whole shared drive merely because it can accept files. Decide which information is necessary for the drafting task and use an approved environment. Where personal information is involved, the OAIC's guidance asks organisations to review the product's terms and settings and understand who will have access to data entered into or generated by an AI product. Source: OAIC
Treat document content as evidence to interpret, not instructions to obey. A note inside a source file saying "ignore previous instructions" does not change the authorised task. Tell the model to report unexpected instructions as source content and continue using the reviewer-approved boundaries. Inspect the resulting draft for scope changes even when the prompt contains this safeguard.
A constructed access-review example
Consider a fictional private-sector service team. Its supplied control, C-17, states: "The service owner reviews privileged access to the service each quarter and records decisions and follow-up actions." The exercise covers the July to September quarter. All organisations, identifiers, documents and outputs in this example are constructed. No production system or model performance test is being reported.
The initial correspondence contains three incomplete requests. The first asks for "the latest access list". The second asks for "proof of manager sign-off". The third asks whether "all access issues are closed". Each sounds reasonable in isolation. Together they introduce a current-date bias, an unspecified manager role and an assumption that closure is the only relevant exception state.
The synthetic inventory contains four items. D-01 is a privileged-access extract labelled 30 September. D-02 is a review record labelled 3 October, referring to the quarter ended 30 September. D-03 is an action register with two actions still open. D-04 is a procedure explaining the quarterly review process. Their existence does not establish that the extracts are complete or the review met its requirements.
The bounded AI task is to quote C-17, map each request to the inventory and draft replacement wording. The model must retain the quarterly scope, identify which document might answer each question and list missing facts. It must not declare the control effective or treat the procedure as proof that the review occurred.
For the first request, a useful replacement asks for the privileged-access population used in the review for the specified quarter, its extraction date and an explanation of its coverage. D-01 is a candidate, not an accepted answer. The reviewer needs to know whether it represents the population reviewed or simply the population remaining at quarter end.
The second request asks for the recorded review decisions and the role responsible for making them, linked to the population reviewed. D-02 is the likely starting point. Its October date is not automatically an exception. The supplied control does not specify a completion deadline after quarter end, so the draft records that timing question for the reviewer instead of inventing one.
The third request asks for the action register associated with that review, including open items, owners, recorded status and supporting closure references where relevant. D-03 remains useful despite containing open actions. The model cannot turn "follow-up actions" into a requirement that every action be closed before a response is accepted.
D-04 provides process context. It may explain terminology or where records are kept. It is not substituted for the review record. This distinction lets the recipient see why a perfectly current procedure does not, by itself, answer a question about a particular quarter's activity.
Make the unresolved question easy to answer
The most useful output is not necessarily a cleaner sentence. In this example, it is the unresolved relationship between D-01 and D-02. Did the service owner review the population in D-01, an earlier extract, or a filtered subset? Without that connection, a reviewer may hold two plausible documents that do not describe the same work.
Put this question in its own field, with a role responsible for answering and a reason it matters. A request that says "please confirm the source population for the review record" is more actionable than "provide better evidence". It also gives the recipient a way to explain that the requested record is unavailable.
Do not force an unavailable response into a blank cell. Distinguish not held, not yet located, outside the recipient's authority and not applicable. These are response categories for managing the request, not assurance conclusions. The reviewer assesses the explanation and decides the next step under the engagement's established method.
A useful gap route names who will resolve a scope question and how the answer will be recorded. It does not promise that every gap can be closed with another email. Sometimes the right outcome is a documented limitation or additional procedure, decided by the authorised reviewer rather than generated by the model.
Review the schedule as if you were receiving it
Read each row without access to the drafting conversation. Can the recipient identify the system, the activity, the relevant period and the records requested? Can they see whether an alternative format is acceptable? Can they distinguish mandatory information from an illustrative example of a possible record?
Check that every requested item has a reason. Asking for complete logs because they might be useful increases collection without resolving a defined question. If a smaller record can answer the engagement need, explain that option. If the reviewer requires a particular original record, explain why a summary will not substitute for it.
Next, compare the request with the protected control text. Highlight every noun or condition added by the draft. Some additions merely clarify the response format. Others expand the control, introduce a deadline or imply a retention period. Only the reviewer can decide whether such changes are authorised and supported by the engagement's source material.
Check tone as well as technical accuracy. A request can be precise without sounding accusatory. "Please identify the record used" asks for traceability. "Explain why you failed to keep evidence" assumes a finding before the facts are established. AI-generated formality is not a reason to keep language that prejudges the response.
Manage the reply without losing its provenance
Give each request a stable identifier and ask recipients to use it in their response. Keep the response date, source location and any explanation together. When someone sends an updated document, retain the relationship to the previous response. Do not overwrite the earlier entry merely to make the schedule look tidy.
The companion article's naming method can make this easier, but a filename is not the evidence trail. The request register needs to retain the source reference and the reviewer's assessment. If a file is moved or renamed, test that the recorded reference still leads to the intended item before relying on it.
Use separate states for requested, received and reviewed. "Received" means material arrived. "Reviewed" means someone has assessed it against the request. Neither state alone means the control is effective. An AI-generated summary may help the reviewer navigate a response, but its assertions must remain connected to the underlying records.
Standard 14.6 addresses engagement documentation that supports repeatable work and results. The request schedule is only one part of that documentation. It does not replace the analysis, judgement or retention arrangements required by the organisation and applicable framework. Source: IIA
Trial one request before scaling the method
Select a low-complexity request and have a colleague read it as the recipient. Ask them to describe what they would send and which questions they would raise. Record their interpretation before explaining your own. This small exercise can expose ambiguity that is difficult to see after several rounds of editing.
Then compare the drafted row with its sources. Confirm the dates, control boundary and ownership fields, and inspect every gap the model identified. Remove invented details. Keep useful uncertainties. The aim is a request that a real recipient can answer and a reviewer can assess, not a schedule with every cell filled.
For the next engagement, reuse the structure and the prompt, but replace the source pack. Do not carry forward last quarter's assumptions as if they were approved facts. Start with one control, one period and one answerable request. Build the collection discipline before increasing the volume.
Reusable materials
Evidence-request working pack
All data below is constructed for a fictional private-sector service team. No model run or production review is claimed.
Protected source
C-17: The service owner reviews privileged access to the service each quarter and records decisions and follow-up actions.
Period: 1 July to 30 September 2026. Response deadline: reviewer to confirm; not inferred from control.
Before and proposed after
Copyable request matrix
Prompt
Reviewer checks
- Match each request to C-17 and the agreed engagement scope.
- Resolve population linkage before accepting D-01/D-02 together.
- Confirm recipient, deadline, response channel and approved alternatives.
- Separate received material from reviewed material and assurance conclusions.
- Retain versions and source references under the applicable organisational rules.
Related reading
- AI in Internal Audit: What Still Counts as Evidence
- Give Shared Files a Naming System People Can Follow
References
- The Institute of Internal Auditors, Global Internal Audit Standards, condensed edition, issued 9 January 2024 and effective 9 January 2025, Standards 14.1 and 14.6: https://www.theiia.org/globalassets/site/standards/condensedglobalinternalauditstandards_2024january9_printable.pdf
- Office of the Australian Information Commissioner, Guidance on privacy and the use of commercially available AI products, published 21 October 2024 and updated 17 January 2025: https://www.oaic.gov.au/privacy/privacy-guidance-for-organisations-and-government-agencies/guidance-on-privacy-and-the-use-of-commercially-available-ai-products
TheAICommand. Intelligence, At Your Command.
