Client data copies for analytics: confidentiality risks
The confidentiality and data protection risks when an audit firm copies client data for analytics, and practical ways to hold less and control access.
By Achekam · · 4 min read · For Accountants & audit firms in South Africa, Nigeria, Kenya
An audit senior asks the client's IT manager for "a full extract of the general ledger, the sales ledger and the payroll" so the team can run some analytics. The files arrive on a memory stick. They contain every customer's name and address, every employee's salary and bank details, and years of transactions. Months after the audit, the memory stick is in a drawer and copies of the files are on several laptops.
That scenario is how analytics turns into a confidentiality problem. The more detailed the data, the more useful it is for testing, and the more harm it can do if it goes astray. This article sets out the risks, the ethical principle behind them, and practical ways for a firm in South Africa, Nigeria or Kenya to reduce what it holds and who can see it.
Why holding a copy is the risk
ACCA warns that copying and storing client data for audit data analytics risks breaching confidentiality and data protection laws, because the audit firm holds a copy of large amounts of detailed client data.
The emphasis is on the copy. Before analytics, an auditor looked at a sample of documents on the client's premises and took away working papers. Now the firm may hold the client's whole ledger, and possibly personal information about thousands of the client's customers and staff. South Africa's POPIA, and the data protection laws of Nigeria and Kenya, are concerned with exactly this kind of personal information, whoever happens to hold the copy.
The confidentiality principle
The IESBA Code's five fundamental principles are integrity, objectivity, professional competence and due care, confidentiality, and professional behaviour. The IESBA describes professional behaviour as complying with laws and regulations and avoiding conduct that discredits the profession.
Two of the five bear directly on analytics. Confidentiality governs what the firm does with the client's information. Professional behaviour brings in the data protection laws that apply to it. A firm that keeps detailed client data longer than it needs, or lets it spread across devices, is exposed on both.
Take only what the test needs
The simplest control is to ask for less. Most analytics tests need far fewer fields than a full extract contains. A journal entry test needs dates, accounts, amounts, the user who posted the entry and whether it was manual; it rarely needs customer addresses or employee bank details.
Before requesting data, write down for each planned test:
- which fields it needs, and why;
- which fields can be excluded or masked at source;
- who will receive the data and where it will be held;
- when it will be deleted.
Sharing that list with the client also helps with a separate problem. ACCA warns that the completeness and integrity of client data extracted for analytics cannot be taken for granted, and that specialists are often required to perform the extraction. ACCA notes that clients may be able to make only selected data accessible, or to manipulate the data available for extraction. A clear specification, with a record of how completeness will be checked, addresses both concerns at once.
Achekam keeps the fingerprint, not the file
For journal entry testing, staff load a whole-population journal extract as a CSV file and map its columns, and Achekam flags entries such as manual, weekend, after-hours and post-close postings for staff to select and test. The CSV is not stored; its hash and row count are.
That design means the full extract does not sit in Achekam after the test. The hash and row count let a reviewer confirm later which file was tested and that it had the expected number of rows, without the firm keeping the whole ledger. The original file still exists wherever the team saved it, so the firm's own deletion routine still matters.
Where the firm's files are kept, and who can open them
A firm administrator can point the workspace's file storage at the firm's own S3-compatible bucket, SharePoint, OneDrive or Google Shared Drive, and copy existing files across. For a firm with an established data policy for one of those platforms, that keeps working papers and supporting files under the firm's existing controls.
Access matters as much as location. Partners and administrators can restrict a client, or one engagement, to named people with a reason. A restriction is lifted rather than deleted, and who did what and when is recorded. The account manager and the engagement's partner and manager can always open it. For a client whose data is especially sensitive, a restriction keeps the analytics files within the engagement team. More on access restrictions is in restricting access to a client.
A data-handling note for the engagement file
Add a short note to each engagement that uses analytics:
| Item | What to record |
|---|---|
| Data requested | Fields, period and the test each serves |
| Received | Date, format, how it was transferred, who received it |
| Completeness | How it was checked, and the result |
| Held | Where, and who could open it |
| Deleted | Date and by whom, or why it was kept |
If AI tools are used on the same data, the risks grow; see AI and client data protection.
The principles at their source
The IESBA's page on the International Code of Ethics sets out the fundamental principles, including confidentiality and professional behaviour. Use it to frame the firm's data-handling policy for analytics, and agree the field list with the client before the next extract is requested.
General guidance only, not advice on your own circumstances. Tax and payroll rules change: check the current position with the authority or your adviser.
