Tech-Zone Article
When “Read-Only” Is Not Enough: Data Handling Risks Every Auditor Must Revisit
Recent reports surrounding an alleged data exposure at Bank of Baroda have again drawn attention to a practical risk present in almost every audit engagement that involves sensitive customer or operational data.
According to publicly available information, the bank has stated that the incident involved the compromise of one employee’s email account, that its core banking systems were not accessed, and that a forensic investigation is under way. Nothing has been conclusively established.
The episode nonetheless surfaces a broader issue that both auditors and organisations would do well to examine afresh.
What happens when a legitimate identity is compromised?
The question becomes especially important when that identity already has legitimate access to large volumes of sensitive information.
The familiar safeguard and its limits
Auditors routinely request, and are granted, read-only access to client systems and data. The logic is sound.
Read-only rights prevent the auditor from altering records and reduce the possibility of the auditor becoming a vector for accidental or fraudulent manipulation. It supports separation of duties and helps protect the integrity of the client's records. That control remains essential.
But read-only access addresses primarily one type of risk: the risk of modification. It does not, by itself, eliminate the risk of unauthorised disclosure.
Consider the information an auditor may legitimately encounter during an engagement: customer application forms, loan appraisal notes, KYC documents, internal reports, financial statements, branch-level data, employee records, correspondence and years of supporting documentation.
An auditor may have no ability whatsoever to change these records. But if the identity through which that information is accessed is compromised, the information may still be exposed.
That changes the question an auditor should be asking.
It is no longer sufficient to ask: “Can this user change the data?”
The auditor should also ask: “If this user's identity is compromised, how much of the organisation's data can be exposed?”
That is a very different question.
| Traditional Question | Modern Risk Question |
| “Can this user change the data?” | “If this user's identity is compromised, how much data can be exposed?” |
When access itself becomes the risk
The traditional distinction between read-only and read-write access is useful, but it can create a false sense of security if treated as the complete access-control assessment.
A user who cannot modify a record can still potentially view a large number of records.
A user who cannot delete a document can still potentially download it.
A user who cannot approve a transaction can still potentially access sensitive information surrounding that transaction.
In other words, the absence of modification rights does not mean the absence of information risk.
This matters because sensitive data is increasingly available through interconnected systems rather than a single application.
An employee's corporate identity may provide access not only to email, but also to document repositories, cloud storage, collaboration platforms and other business applications.
Consequently, compromising one legitimate identity may potentially expose information far beyond the application that the user was originally working with.
The attacker does not necessarily have to break into the organisation's core system.
The legitimate account may already provide a route to valuable information.
The identity may have a much larger footprint than expected
This is particularly relevant where people routinely handle information from multiple locations, branches, departments or business units.
Imagine an employee who receives or compiles reports from across an organisation.
Over time, that person's mailbox or document repository may accumulate:
• Reports from multiple locations
• Historical correspondence
• Spreadsheets
• PDF documents
• Customer information
• Internal reviews
• Supporting documents
• Sensitive operational information
None of this may have been deliberately collected into one “high-risk” database. It may simply have accumulated through normal business activity.
That creates an important risk.
The organisation may believe it has protected its major systems because those systems require strong authentication and carefully controlled permissions. Yet a significant amount of information may have found its way into ordinary email accounts, shared folders or collaboration platforms.
The result can be a single point of failure.
The question is therefore not only: “How secure is our core system?”
It is also: “How much sensitive information is accessible through each legitimate identity?”
Read-only does not mean risk-free
For auditors, this distinction is particularly important.
Read-only access remains an appropriate safeguard because an auditor should not ordinarily be able to alter the client's underlying records.
But the fact that an account is read-only should not end the discussion.
The auditor may still need to consider:
• How much information is being made available?
• Is all of it necessary for the engagement?
• Is access limited to the relevant entity, period or assignment?
• Does the user have access to information accumulated from earlier assignments?
• Can information be downloaded or copied?
• What happens to information that is downloaded?
• Does the same identity have access to other repositories or applications?
These are not necessarily questions requiring a technical cybersecurity audit.
They are simply questions about how sensitive information is being accessed and handled.
That distinction is important for the general CA.
An auditor does not need to become a cybersecurity engineer to recognise that an account with access to ten documents presents a different exposure from an account with access to ten years of documents across an organisation.
The principle of “need” deserves more attention
Most professionals are already familiar with the principle of least privilege: users should receive only the permissions necessary for their role.
But auditors can take the idea one step further.
The relevant question is not merely: “Does this user have permission?”
It is: “Does this user need access to all of this information?”
An auditor may legitimately require access to financial records for a particular assignment.
That does not automatically mean that the same identity needs unrestricted access to every historical record, every business unit or every repository.
This is where need-to-know becomes important.
Access should be appropriate not merely because it is technically possible, but because there is a genuine business or audit requirement for it.
The same principle applies to information retained after an assignment.
A document that was necessary six months ago may no longer need to remain accessible to the same identity today.
The longer sensitive information remains unnecessarily accessible, the larger the potential exposure if the account is compromised.
What should an auditor do differently?
The answer is not to stop using read-only access.
Nor is it to refuse access to sensitive information. Audits cannot be performed without examining the information relevant to the engagement.
The more practical approach is to become more conscious of data handling.
An auditor should, wherever practical, request only the information genuinely necessary for the assignment rather than accepting unnecessarily broad access simply because it is convenient.
Where information can be reviewed within the client's controlled environment, that may be preferable to creating multiple copies of sensitive files.
Where downloading is genuinely necessary, the auditor should recognise that the security responsibility does not end when the file reaches the auditor's computer.
The file may subsequently exist in downloads folders, email attachments, shared folders, backup systems or other locations.
It is therefore worth asking a simple question: “Where does this data go after I access it?”
That question is surprisingly easy to overlook.
The auditor's device becomes part of the picture
Once sensitive client information is legitimately transferred outside the client's environment, the auditor's own working environment becomes relevant.
A client may have strong security controls around its servers and applications.
Those controls cannot protect a copy of the information sitting elsewhere.
This does not mean that auditors need to build elaborate security systems for every engagement.
Basic discipline matters.
Sensitive engagement information should not casually find its way into personal email accounts, unprotected portable devices or locations that are accessible to people who have no legitimate reason to see it.
Similarly, keeping large quantities of client information indefinitely “just in case” increases exposure without necessarily adding audit value.
The principle is straightforward:
If the information is no longer required, retaining it indefinitely creates risk without providing a corresponding benefit.
The organisation has a responsibility too
This is not solely an auditor's problem.
The client organisation controls the architecture through which its information is stored and accessed.
Management should therefore consider whether sensitive information is unnecessarily concentrated behind individual identities and whether access remains appropriate as employees change roles or responsibilities.
An account may have accumulated access over several years without anyone deliberately deciding that the individual should have such broad access.
That is one reason periodic review of access matters.
Organisations should also consider whether a compromised account can be identified and contained quickly and whether they would be able to determine what information may have been exposed.
The objective is not to treat every employee as a security threat.
It is simply to recognise that legitimate identities can become attack targets.
A broader lesson from the recent incident
The facts surrounding any particular incident will ultimately be established by investigation.
It would therefore be inappropriate to draw conclusions about the identity of the compromised user or the precise route through which information may have been exposed before those facts are established.
The underlying lesson, however, does not depend on those details.
Every organisation has legitimate users.
Every legitimate user has some level of access.
And every access permission creates a potential exposure if the corresponding identity is compromised.
This is why information security cannot be viewed only through the traditional question of whether a user can modify the underlying records.
Confidentiality matters too.
The risk is not simply that someone might change a number.
The risk may be that someone could obtain information that the organisation never intended to leave its controlled environment.
Key Takeaways:
• Read-Only Protects Integrity, Not Confidentiality: Read-only access prevents data manipulation, but does not by itself prevent unauthorised disclosure if an identity is compromised.
• Access Rights and Data Accumulate: Over time, ordinary user accounts and associated repositories can accumulate years of historical files, emails and reports, creating a significant concentration of sensitive information behind a single identity.
• Shift from “What Can I Change?” to “What Can I See?”: Modern data handling requires auditors and organisations to look beyond basic system permissions and consider whether access to sensitive information is genuinely necessary.
Closing thought
The facts surrounding the recent incident will ultimately be established by investigation. The broader lesson, however, does not depend on those details.
Read-only access remains an important safeguard against alteration and fraud. But it should not be mistaken for a complete answer to information-security risk. In an environment where a single legitimate identity may have access to large volumes of sensitive information, the ability to view data can itself represent significant exposure.
The next time an auditor is given access to a client system, it is worth asking not only: “What can I change?”
but also: “If this identity were compromised, what could it expose — and does it really need access to all of it?”
That is not a cybersecurity question reserved for specialists. It is increasingly becoming a basic question of professional data handling.
Read-only may prevent the auditor from changing the organisation's data. It does not necessarily prevent a compromised identity from exposing it.
