Claude suits internal audit work that involves long documents and a fixed way of writing. A Claude Project holds the reference files for one engagement and a standing instruction, so every chat inside it already knows the approved scope, the risk and control matrix, your rating scale and your observation format. It drafts and compares; it does not test transactions, and the internal auditor stays responsible for the evidence and the conclusions.
This guide shows how an internal audit team in India would set up a Project for one engagement, the flow from scope document to draft observations, and the prompts to run inside it.
Start here for the files that go into the Project:
| Need | Use this |
|---|---|
| The scope document to load | Scope of Work Generator |
| The RCM to load | RCM Builder |
| The observation format the standing instruction refers to | Observation Report Generator |
| A rating scale with written definitions | Issue Rating Matrix Generator |
| Where AI fits across the whole audit | AI in internal audit 2026 |
Why a Project, and what is different for internal audit
Three durable features of Claude matter here. It reads long documents, such as a full policy manual, and answers across the whole of them. A Project keeps reference files and a standing instruction for every chat in it. Artifacts put a draft RCM, memo or table in a separate pane that you can revise and copy out.
Two earlier guides cover Claude for statutory audit: building an AI audit workflow in Claude Projects and Claude for Indian audit work. They tell firms to load methodology only and keep client material out. An internal audit engagement Project goes one step further, because it holds the scope, the RCM and the entity's policies. That step needs authority.
- In-house team. The documents are your company's own. Use an account your organisation has approved for internal documents, and follow its information-security policy.
- CA firm. The documents are the client's. Get the client's written agreement to the tool and the classes of document before loading anything.
Either way, the Project holds documents about how the process is meant to work. It does not hold transaction data or personal data.
Step 1: what to load, and what to leave out
| Load | Preparation |
|---|---|
| Approved scope document or engagement letter extract | Remove fees and commercial terms |
| RCM, current version | Replace names with roles |
| Prior-year report for the area, with action taken status | Mask names; remove investigation matters |
| Policies, SOPs and the delegation of authority for the process | Remove annexures listing people, salaries or bank details |
| Your observation template and rating definitions | As they are |
Leave out ledgers, Day Book or ERP exports and bank statements; payroll, employee, customer and vendor master data; whistle-blower and investigation material; legal advice; and board papers or unpublished results of a listed company.
Name the Project by a code ("IA-2026-07 P2P"), not by the company's name. Check your plan's data-use and retention settings before loading, and note what you found in the engagement file.
Step 2: the standing instruction
Paste this into the Project's instructions and edit the bracketed parts.
ROLE
You assist an internal audit team in India on one engagement: an internal
audit of [process] for [period]. You draft and compare. You do not test
transactions and you do not conclude whether a control operated.
REFERENCE FILES
The approved scope document is the boundary of the work. The RCM is the
list of controls. The entity's policies are the criteria. When you rely on
a file, name the file and the clause or page.
OBSERVATION FORMAT
Five parts, in this order: Condition, Criteria, Cause, Effect,
Recommendation. Then Management response (blank), Owner (role), Target
date (blank).
- Criteria must quote a clause from a Project file or a requirement I
supply. Otherwise write "CRITERIA TO BE CONFIRMED".
- If my facts do not establish the cause, write "CAUSE NOT YET
ESTABLISHED" and list the questions that would establish it.
RATING SCALE
High, Medium, Low, as defined in the rating file. Propose a rating only
when I ask, give the reason against the definition, and label it
"PROPOSED - AUDITOR TO DECIDE".
CITATIONS
Never invent a section, rule, circular, standard or policy clause number.
Cite law or standards only if the text is in a Project file or I have
pasted it. Otherwise write "CHECK LAW:" and describe the topic in words.
FACTS AND ASSUMPTIONS
Use only facts in the files or my messages. Mark every assumption as
[ASSUMPTION]. Never invent numbers, dates, names or sample results. If
something is missing, ask.
STYLE
Indian English, rupees in lakh and crore, neutral tone, no blame on
individuals.
Step 3: a worked flow, from scope document to draft observations
An illustrative engagement: procure-to-pay, April to September 2026.
| Step | In the Project | Outside it |
|---|---|---|
| 1. Scope | List what is in, out and unclear (prompt 1) | Settle unclear points with the approved plan and process owner |
| 2. RCM against policy | Compare RCM, policy and delegation of authority (prompt 2) | Decide which gaps are real |
| 3. Walkthrough | Questions by control (prompt 3); notes to memo (prompt 4) | Hold the walkthrough, trace a transaction, get the memo confirmed |
| 4. Test programme | Draft test steps (prompt 5) | Decide populations and samples; reconcile the data; perform the tests |
| 5. Observations | Draft from verified results (prompt 6); challenge responses (prompt 7) | Verify each figure, set the rating, share the draft with the auditee |
| 6. Report | Summary (prompt 8) and consistency check (prompt 9) | Read against the full report |
The right-hand column is the audit; the left saves drafting time. At step 4 the chat assistant stops and testing begins: tests across every transaction run in a spreadsheet or a testing tool, as described in continuous internal audit and full-population testing.
Prompts to run inside the Project
The standing instruction carries the rules, so these are short. Each repeats the two that matter most.
1. Read the scope
Read the approved scope document. List in three tables: (a) what is in
scope, with clause or page; (b) what is expressly out of scope; (c) what
is unclear and should be agreed in writing (entities, locations, period,
systems, sub-processes). Mark every assumption as [ASSUMPTION]. Do not
cite section or standard numbers that are not in the document.
2. RCM against the policy
Compare the RCM with the [procurement policy] and the delegation of
authority. Table 1: policy requirements with no matching RCM control
(clause | requirement | suggested control). Table 2: RCM controls with no
basis in any policy. Table 3: where RCM and policy disagree on a limit,
approver or frequency, quoting both exactly. Mark every assumption as
[ASSUMPTION]. Do not invent clause, section or standard numbers.
3. Walkthrough questions
For each key control in the RCM for [sub-process], write walkthrough
questions: how the control is performed (who, when, on which document or
screen), what happens when it is bypassed or the approver is absent, what
evidence is retained, and one document to ask for. Add questions that
test whether any related observation in the prior-year report is fixed.
Mark every
assumption as [ASSUMPTION]. Do not invent menu paths, field names or
section numbers.
4. Notes to a walkthrough memo
Below are my walkthrough notes (roles, not names). Produce a memo:
numbered process steps, the control at each step with its RCM reference,
documents and screens seen, open points. Where my notes do not say who
performs or approves a step, write "NOT STATED IN NOTES". List every
difference from the RCM or policy as a possible design gap for me to
validate. Mark every assumption as [ASSUMPTION]. Do not cite section or
standard numbers.
Notes:
[paste]
5. Test programme
For each key control in the RCM for [sub-process], draft a test of
operating effectiveness: population and source report, completeness
check, attributes to test, what counts as an exception, evidence to
retain. Where the control leaves a data trail, also describe in words a
test that could run across every transaction. Do not propose sample
sizes. Mark every assumption as [ASSUMPTION]. Do not name tables, fields
or section numbers you are not given.
6. Draft an observation from verified results
Draft an observation in our format from the verified facts below. Quote
the criteria clause from the Project files. Add no figure, date or name
that is not in my facts. Do not rate it. Then list each fact used and its
source (my message or a named file). Mark every assumption as
[ASSUMPTION]. Do not invent section, rule, standard or clause numbers.
Verified facts (names masked):
[paste]
7. Challenge a management response
Below is management's response to observation [ref]. State: does it
accept the facts, does it address the cause or only the instances, is
there an owner (role) and a date, what evidence would show closure. List
my follow-up questions in order of importance. Do not judge who is right.
Mark every assumption as [ASSUMPTION]. Do not add section, rule or
standard numbers.
Response:
[paste]
8. Executive summary for the audit committee
From the final observations in this chat, draft a one-page summary: scope
covered and not covered (from the scope document), overall view in two
sentences, a table (observation in one line | rating I assigned | owner |
date), repeat observations against the prior-year report in the Project.
Keep every
number, rating and qualifier exactly as given. Mark every assumption as
[ASSUMPTION]. Do not add section or standard numbers.
9. Consistency check before issue
Check the draft report below against the Project files. Report in a
table: criteria that do not match the quoted policy clause; numbers that
differ between summary and detail; observations outside the approved
scope; ratings that do not fit our definitions, with the reason; every
section, rule or standard number, flagged "VERIFY CITATION" (do not add
or correct one). Do not rewrite. Mark every assumption as [ASSUMPTION].
Draft:
[paste]
A parallel set for ChatGPT is in ChatGPT for internal audit: prompts, uses and limits.
Reviewing long policies and contracts against a control checklist
Reviewing a long document against a checklist is where a long-document assistant saves the most time. Ask for a clause-by-clause answer with the words quoted.
10. Checklist review
Review the attached [vendor contract / policy] against the checklist
below. For each item: Addressed (Yes / Partly / No) | clause number and
the exact words relied on | what is missing or unclear. If you cannot
find a clause, write "NOT FOUND" and do not infer one. Then list clauses
that create a risk the checklist does not cover. Mark every assumption as
[ASSUMPTION]. Do not cite any law, section or standard that is not in the
document.
Checklist:
[paste]
An illustrative extract of what comes back, for an outsourced payroll contract:
| Checklist item | Addressed | Clause and words relied on | Gap |
|---|---|---|---|
| Right to audit the service provider | Partly | 14.2: "Client may request reports on controls once a year" | Reports only; no access to premises or records |
| Notice of a data incident | No | NOT FOUND | No clause on notifying the client |
| Return or deletion of data at exit | Partly | 18.4: "shall return Client materials" | Silent on deletion and backups |
Then open the contract and read every quoted clause. A "NOT FOUND" needs a search of your own, because the point may sit in a schedule that was not uploaded. The third-party and outsourcing risk checklist supplies checklist items.
Limits and data rules
- It does not test. Whether a control operated is established by your testing.
- It can misquote the files it holds. Check quoted words against the document.
- It can invent citations. The standing instruction reduces this; it does not remove it. See AI hallucinations in audit.
- Answers vary, which is acceptable for drafting and not for a test a reviewer must re-perform.
- A Project is not the audit file. Save outputs you rely on into the working papers.
- Personal data stays out. Under the Digital Personal Data Protection Act, 2023, duties for personal data stay with whoever decides how it is used; loading it into a tool does not pass them to the vendor. See DPDP for CA firms and can you upload client ledgers to AI tools?.
- Close the Project with the engagement, and remove the files in line with your retention policy.
What to record
For each working paper where the Project assisted, note:
- The tool and Project code, and that an approved account was used.
- The files in the Project at the time (name and version).
- The task, for example "RCM compared with procurement policy v3".
- The output relied on, saved in the file with a reference.
- What was verified against source, and what was changed or rejected.
- Preparer and reviewer, with dates.
That follows ICAI's SIA 330 on internal audit documentation, as it stands in the October 2022 compendium: the file should show the purpose of a procedure, the source of evidence, the outcome, and who performed and reviewed it. Keep one engagement-level note as well: the authority under which documents were loaded, and the data-use settings checked. ICAI's revised set, in the February 2026 compendium that ICAI lists as applicable from 1 April 2026, includes a standard titled "Use of Tools"; we have not verified its text, so check the ICAI Internal Audit Standards Board compendium. The two numbering sets are explained in internal audit in 2026: what has changed.
Where a team wants testing and drafting in one place, with exceptions tied to entries, that is the job of an internal audit platform such as CORAA, not of a chat Project.
Claude for internal audit FAQ
Can Claude be used for internal audit in 2026?
Yes, for drafting and document review: comparing an RCM with policies, preparing walkthrough questions, drafting observations from verified facts and reviewing contracts against a checklist. It does not test transactions or decide whether a control worked.
What is a Claude Project, and why use one for an internal audit engagement?
A Claude Project is a workspace with its own reference files and a standing instruction that apply to every chat in it. For an engagement, the scope, RCM, policies, rating scale and observation format are set once, so drafts are consistent and tied to the right documents.
What files should I upload to a Claude Project for internal audit?
Upload the approved scope, the RCM, the prior-year report for the area and the entity's policies, with names and sensitive annexures removed, and only with authority. Leave out ledgers, ERP exports, bank statements and any employee, customer or vendor personal data.
Can Claude review a policy or contract against a control checklist?
Yes. Ask for a clause-by-clause answer that quotes the exact words relied on and says "not found" where there is no clause. Then read every quoted clause yourself and search for anything reported as not found.
Related CORAA resources
- AI in internal audit 2026: the stage-by-stage guide
- ChatGPT for internal audit: prompts, uses and limits
- How to build an AI audit workflow in Claude Projects (statutory audit)
- Internal audit report format: observations, ATR and audit committee reporting
- Internal Audit AI Strategy Template