- 03
- September
Your auditor asks for accounting data as an Excel file and may run it through AI — is that a data leak? The shortest answer is not automatically: providing data for a statutory audit has a lawful basis, and auditors already carry a confidentiality duty under their professional code. But not knowing which kind of AI they use is a control gap your organisation can close, and should — because if data does leak downstream, you as the originating controller still have obligations under Thailand's PDPA. This article separates the risk into three layers, explains who is responsible for what, and gives a seven-step playbook you can run before the next close.
In one line: Sending accounting data to your auditor is not a leak — but with no AI clause in the engagement letter, no limit on the scope of what you send, and no disclosure log, you have no control over what happens downstream and no answer for your data subjects if something goes wrong.
Why 2026 turned this into a question that needs an answer
Handing accounting data to your external auditor has been routine for decades. What changed is not the handover — it is what happens to that file after it leaves your organisation. Historically an Excel export was opened on an audit associate's laptop, vouched against source documents, and filed into the working papers. Today the same file may be uploaded into an AI tool to summarise it, flag outliers, or run analytical review. That is dramatically faster, and on many engagements more thorough than manual sampling.
Three developments over the past two years moved this from a vague worry to something management needs a position on.
| When | What happened | What it means for the audited entity |
|---|---|---|
| 15 Dec 2024 | The IESBA technology-related revisions to the International Code of Ethics took effect, making explicit that confidentiality means protecting information throughout the data cycle — collection, use, transfer, storage and retention, dissemination, and lawful destruction. | Your auditor already carries an ethical duty over your data along its whole path, including the moment it enters a third party's tool. |
| 2025–2026 | Data-security research kept reporting a rising share of employees pasting corporate data into AI chatbots, with most of those pastes coming from personal accounts the employer cannot see. | The real exposure usually is not firm policy — it is one person in a hurry. |
| 30 Mar 2026 | The UK Financial Reporting Council (FRC) published guidance on using generative and agentic AI tools in audit engagements — which the FRC describes as the first such guidance from any audit regulator globally. | AI in audit is now officially acknowledged as happening. The question moved from "are they using it?" to "how controlled is that use?" |
One point to keep straight: the FRC guidance is a UK instrument and has no binding effect in Thailand. It is, however, the best reference document currently available, and global network firms tend to align methodology across the whole network. The part that matters most to you is simple — the firm and the responsible individual retain full accountability for audit quality no matter how heavily AI tools are used. AI is not a place to park responsibility.
Before answering "is it a leak" — decide which layer would leak
In everyday conversation "data leak" covers everything. Legally and in risk terms, the three layers sitting inside the same spreadsheet carry very different weight, and different controls protect them. Separating the layers first is the highest-leverage step, because it shows you how exposed the file you actually sent really is.
| Layer | What rides along in a typical audit request | What protects it | How worried to be |
|---|---|---|---|
| 1. Corporate financial data | General ledger, trial balance, total revenue, cost of sales, adjusting entries | Your NDA and the engagement letter — Thailand's PDPA does not reach it, because it is not personal data | Moderate |
| 2. Personal data | Employee-level payroll registers; names, addresses and national ID numbers of individual customers or suppliers; benefit details | Thailand's Personal Data Protection Act (PDPA) — breach-notification duties and administrative fines both apply | Highest |
| 3. Structural business intelligence | Margin by individual customer, purchase price by individual supplier, special credit terms, executive compensation | Your NDA plus your own internal access controls | High — once it leaks you are simply at a disadvantage, and no regulator will fine anyone on your behalf |
In practice layers 2 and 3 ride along without being needed for the audit at all, because requests arrive as "the full GL for the year" and finance answers by exporting the entire table as asked. That is the same failure mode described in Sharing Excel files back and forth — how data leaks without anyone noticing: one file becomes the carrier for data that should never have left.
Note: Providing data for a statutory audit already has a lawful basis. It is not an unlawful disclosure, and it does not require individual consent from every data subject. So the question in this article is never "may we send it?" — it is "how do we send it and still retain control over what happens next?"
Who is responsible for what: your auditor is not your data processor
This is widely misunderstood and it changes how you should work. Many organisations try to get their auditor to sign a Data Processing Agreement, the same instrument they use with a payroll bureau. That usually fails — and for a good reason.
Under the interpretation applied across Europe for the GDPR, a statutory auditor is an independent data controller in their own right, not the client's data processor. The reason is professional independence: the auditor decides what data is needed, which procedures to run, and how long to retain working papers, in line with the auditing standards binding on them — not on the instruction of the engaging entity. If the client could direct those decisions, independence would be gone by definition. Thailand's PDPA follows the same controller/processor architecture as the GDPR, but it is worth stating plainly that no Thai regulatory determination squarely on the auditor case has been published as far as we could verify to September 2026.
Three practical consequences follow, and the third is the one you can actually use.
- You cannot dictate their methodology. A unilateral "no AI allowed" instruction has no footing, because they are not processing on your behalf.
- They own the data in their hands. If a breach occurs on their side, the statutory notification duty is theirs as controller.
- But you can negotiate contractual terms freely. An engagement letter is a two-party agreement, not a form you receive and sign. This is your primary lever — which is why item 1 of the playbook below matters most.
The flip side is easy to forget: if a downstream breach affects your data subjects, you as the originating controller still have to be able to show how carefully you chose the recipient and what conditions you attached. Documentation that you asked, set terms, and limited scope is worth far more than a feeling that "they probably handle it well." Your own obligations are covered in PDPA and accounting — the data your finance team holds is more dangerous than you think and PDPA and ERP.
The clock you need to remember: under the Personal Data Protection Committee's notification rules, a controller must report a personal data breach to Thailand's PDPC within 72 hours of becoming aware of it, unless it is assessed as posing no risk; where the risk is high, affected data subjects must be notified together with remediation guidance. A processor who becomes aware must notify the controller within 24 hours. The clock starts at "becoming aware" — which means that if you do not know where your files ended up, you have no way of starting that clock in time.
The variable that actually decides this is not "AI or not" — it is which tier
So the useful question is not "does the firm use AI?" In 2026 the answer is almost always yes. The question that separates real risk from noise is which tier, and where does the data sit, for how long.
| What the firm might be using | Used to train models? | Retained? | Risk level |
|---|---|---|---|
| A model running on the firm's own machines or servers | No — the data never leaves the firm's network | Entirely under the firm's control | Lowest, though it shifts the burden onto the firm's own security posture |
| An API or enterprise plan under a commercial agreement | Major providers state that API and enterprise data is not used to train models by default | Varies by product — a zero-data-retention agreement covers only the eligible products, not everything under the same account | Low if someone actually read the contract. "Not trained on" is not the same as "not retained" |
| An individual paid plan the employee signed up for | Depends on provider and settings — not a default you can rely on | Conversation history is generally retained | Medium to high, and the firm has no visibility into who used what |
| Free tiers, file-conversion websites, browser extensions, unvetted Excel add-ins | Often yes, or with no verifiable commitment either way | Unknown, and nobody is accountable | Highest — this is the case you can fairly call a leak |
The subtler point, and the one most often missed, is the gap between "not used for training" and "not retained." A provider may never train on your data and still keep logs for a period for safety purposes — a different question with different PDPA implications. Between August and September 2026 several major providers adjusted exactly this: some increasing log retention on their most capable models to detect malicious use, others offering customers an option to retain nothing at all. Which means this year's answer is not last year's answer, and the question has to be re-asked periodically. The same principle underpins Claude data governance and security for Thai organisations: read the policy per product and per date, not per brand name. And because AI output still has to be checked before it becomes audit evidence, see also how to verify AI output when the answer looks too credible to question.
A 7-step playbook you can run before the next close
These are ordered by return on effort. Items 1 to 3 take the least work and remove the most exposure, and none of them require the audit firm to change anything first.
1. Add an AI clause to the engagement letter or NDA
Do it once, use it every year. This is the highest-value item because it converts "we hope they handle it well" into a written obligation. At minimum it should cover:
Substance the clause should cover (illustrative draft)
- The auditor will not input company data into public or consumer-tier artificial intelligence tools.
- Where artificial intelligence tools are used in performing the engagement, they must operate under an enterprise agreement providing that data is not used to train or improve models, with a stated data retention and deletion policy.
- The auditor will disclose the category and name of any artificial intelligence tools applied to company data upon the company's written request.
- These obligations extend to subcontractors, network member firms in other jurisdictions, and relevant technology providers.
- The auditor will notify the company without undue delay upon becoming aware that company data has been accessed or disclosed without authorisation.
Item 5 is worth more than it looks, because it is what allows your own 72-hour clock to start in time. Without it you may learn about an incident far too late. The actual wording belongs to your legal counsel or data protection officer — what is above is the substance to cover, not a form to copy.
2. Give what the audit needs, not the whole database
A prepared-by-client (PBC) list is written broadly because the auditor does not yet know what they will find. But answering it with a full table export is your decision, not theirs. Walk the columns one by one and ask whether each is actually used in a procedure. Any column you cannot explain a use for should be dropped before sending. This removes more layer-2 and layer-3 data than anything else on this list, with zero impact on the audit.
3. Replace identifiers with codes (pseudonymisation)
Payroll is the clearest example. The auditor needs to test the accuracy of totals, the calculation, and the accounting entries — all of which work with employee codes rather than every name. Send the file keyed by employee code, keep the code-to-name mapping on your side, and disclose names only for the specific items actually selected for testing. The volume of personal data leaving your organisation drops from hundreds of records to a few dozen.
4. Move from sending files to granting read-only access
Structurally this is the best fix available. An Excel file that has left is invisible forever after. A read-only account inside your own system achieves three things at once: the auditor pulls what they need without waiting on finance, you scope exactly which modules and which periods are visible, and you retain a trail of what was opened and when. As a side effect the finance team's close gets lighter, because nobody is exporting files on demand round after round — the bottleneck described in Why the month-end close keeps running late.
5. If you must send files, do not send them as email attachments
Email attachments are copied without limit, sit in the mailbox of everyone on cc indefinitely, and cannot be revoked. Use a share link with an expiry date, name the recipients individually, and turn on access logging. That alone is a large improvement, particularly since audit team composition changes mid-engagement as a matter of routine.
6. Keep a disclosure log
One table is enough: what was sent, to whom, on what date, through which channel, whose personal data it covered, and who internally approved it. It pays off twice. First, if an incident occurs you can immediately trace which dataset sits with whom — exactly the input you need to assess risk and to notify within 72 hours. Second, it is evidence that your organisation controls disclosures systematically rather than by habit and familiarity.
7. Ask five due-diligence questions — and listen to how fast the answers come
Asking an audit firm about its AI policy is not distrust; it is ordinary management stewardship over your organisation's data and over data subjects who entrusted it to you. Firms that have this organised answer immediately and usually have documentation to hand. The speed and specificity of the answer tells you more than the answer itself.
| Question | An answer that sounds managed | A signal to probe further |
|---|---|---|
| Does the firm have a written policy on using AI with client data? | Yes, and here it is — or an immediate summary of its substance | "Our people don't use it anyway," with no document and no technical control behind it |
| Are the tools the firm's own systems, or external services? | Names the system and the contracting model | "Just the usual tools," or avoids naming anything |
| How long is data retained, and when is it deleted? | Answers in days, or points to the contract term | Answers only "it isn't used for training" — which answers a different question |
| Are there technical controls preventing staff from using personal tools? | Restrictions at device or network level, not just a policy announcement | Relies purely on staff goodwill |
| From which countries is our data processed or accessed? | Names the countries or regions and knows who in the network has access | Cross-border transfer has never been considered |
Where to start if time is short
You do not need all seven at once, and you should not wait for completeness before starting. The sequence that works maps onto cycles you already run.
| Timing | What to do | What you get |
|---|---|---|
| This month | Send the five questions to your audit firm and start the disclosure log (items 6, 7) | You learn the actual position and get a baseline — for the least effort of anything here |
| Before the next engagement renewal | Add the AI clause to the engagement letter or NDA (item 1) | Expectations become obligations, and coverage extends to subcontractors |
| At the next close | Drop unused columns and key payroll files by employee code (items 2, 3) | A material reduction in the personal data that leaves your organisation |
| Longer term | Shift from sending files to granting read-only system access, with an expiring channel for whatever files remain (items 4, 5) | Fewer files leave by design, rather than because one careful person remembered |
The ERP angle: reduce how many files have to leave in the first place
At Grand Linux Solution we built Saeree ERP to support item 4 directly, because Thai public-sector bodies and state enterprises already need it whenever auditors arrive. Role-based access lets you open a dedicated account for the audit team, restrict it to read-only, choose which modules and which periods are visible, set valid-from and valid-to dates so the access closes itself when the engagement ends, and keep an audit trail of who opened which report and when. Your own system administrator does all of this without waiting on a developer.
On AI our position is deliberately narrow: the ERP is the source of truth and AI is an assistant that asks it questions, not a place where data is stored. When AI is connected to the ERP through MCP, access happens through tools with a pre-defined scope, under the same permissions as the user concerned, and it is logged like any other session — as opposed to exporting a whole table and uploading it into an external tool, which is precisely where control breaks. The reasoning behind that design is set out in Using AI safely in your organisation — the AI governance policy you need, and the internal-audit view of the same trade-off is in AI and internal audit — opportunities and risks.
It also has to be said plainly that what an ERP controls stops at your own boundary. A file already in someone else's hands cannot be pulled back by any system. Past that point the only instruments left are the contract and careful counterparty selection. That is why the playbook above starts with the contract rather than with technology. For keeping attached documents secure and detecting copying, we covered that separately in Where PDF files in an ERP are safest to store.
Conclusion
Your auditor possibly running your data through AI is not in itself a data leak. Providing data for an audit has a lawful basis, and auditors carry a confidentiality duty under a professional code whose current version already covers stewardship across the whole data cycle. The real problem is a control gap: you do not know where the file rests, for how long, or who can see it — which leaves you unable to answer your data subjects, and unable to start the 72-hour clock in time if something goes wrong.
The good news is that the gap closes with instruments you already have: one contractual paragraph, deleting unused columns, keying names to codes, and moving from throwing files over the wall to granting read-only access. None of it requires buying anything new, and all of it fits before the next close.
"Once data has left your organisation, technology cannot control it any more — only the contract and your choice of counterparty can. So the first move is to reduce how much data has to leave, not to look for a tool that chases it afterwards."
- Sureeraya Limpaibul | Saeree ERP by Grand Linux Solution
References
- Financial Reporting Council (UK) — AI in Audit: Generative and Agentic AI Guidance (published 30 March 2026)
- IESBA — Handbook of the International Code of Ethics for Professional Accountants (technology-related revisions effective 15 December 2024 — paragraph 114.1 A1 on confidentiality across the data cycle)
- Federation of Accounting Professions (TFAC), Thailand — Code of Ethics for Professional Accountants handbook
- Accountancy Europe — GDPR: implications for auditors (auditors as independent controllers)
- Crowe — Statutory Auditor as Personal Data Controller
- Summary of the Personal Data Protection Committee notification on personal data breach reporting (the 24 / 72-hour timeframes)
- Cyberhaven — Insider Threats in the Age of AI (statistics on corporate data pasted into AI tools and the share from personal accounts)
- The Register — Anthropic promises zero data retention, but customers must check it worked (2 September 2026)
Verified 3 September 2026 — this article is general practice guidance, not legal advice. Contractual wording should be reviewed by your legal counsel or data protection officer.
Want your auditors to pull reports themselves instead of receiving Excel files?
Saeree ERP gives you role-based permissions, time-bounded read-only accounts, and a full audit trail. Talk to the Grand Linux Solution team at no cost.
Request a Free DemoTel 02-347-7730 | sale@grandlinux.com
