The Data Custody Chain Who Can See Change and Delete Your Financial Data
Published on: Fri Dec 27 2024 by Ivar Strand
The Data Custody Chain: Who Can See, Change, and Delete Your Financial Data?
Discussions about the integrity of financial systems tend to focus on process logic—the automated rules and workflows that guide transactions. While this is critical, it is only half of the equation. The reliability of financial data depends just as much on a second, often overlooked factor: who is permitted to interact with it.
We refer to this as the “data custody chain”: a verifiable trail of who has the ability to see, create, modify, and delete information within a system. A weak or poorly defined custody chain undermines the trustworthiness of all data that the system produces, regardless of how well its process logic is designed.
The Principle of Least Privilege
A foundational concept in information security is the “principle of least privilege.” This states that a user should only be granted the absolute minimum level of access and permissions necessary to perform their specific, defined job functions.
In our experience, this principle is frequently violated in practice, often for reasons of convenience. For example, a manager who only needs to view reports might be granted broader permissions that also allow them to modify the underlying transactional data. Each instance of excessive privilege represents a significant and unnecessary risk to data integrity and a failure to enforce the proper segregation of duties.
A Framework for Auditing Access Controls
A systematic audit of user access controls is a non-negotiable component of technology governance. This is not just an IT task; it is a core fiduciary responsibility. The inquiry should be structured around a set of fundamental questions.
-
Who Has “Read” Access? The first step is to map which user roles can view which categories of data. Is access to sensitive information—such as payroll data, detailed grant budgets, or beneficiary personal details—strictly limited on a need-to-know basis? This is a key requirement for compliance with data protection regulations like GDPR.
-
Who Has “Write” (Create and Modify) Access? This is a more critical level of control. The list of users with permission to create or alter core financial records should be exceptionally small. Who is on the list of users authorized to create a new vendor in the system? Who can change the bank account details for an existing vendor? Who can modify a payment amount after it has been approved?
-
Who Has “Delete” Access? The permission to permanently delete financial records is the most potent and, therefore, the most dangerous. In well-designed systems, direct deletion of transactions is often prohibited entirely. Instead, records are “voided” or “cancelled,” which reverses the transaction but preserves the full audit trail. You must verify if this is the case in your system.
-
Who Can Change Permissions? Finally, who holds the administrative keys? The ability to grant, modify, and revoke access for other users is a powerful privilege. This role must be restricted to a very small number of vetted individuals, and any changes they make to user permissions must be subject to its own immutable audit log.
Verifying Controls in Practice
This assessment cannot be a paper exercise. The answers to these questions must be verified by reviewing user permission reports and role definitions directly from the system’s administrative back-end. Furthermore, practical tests—such as attempting to log in with the credentials of a junior user to confirm they are blocked from accessing senior management functions—are essential for confirming that the documented controls are actually being enforced.
A system’s logic can be flawless, but if its data custody chain is broken, no real assurance is possible. Auditing access controls is as fundamental as auditing the transactions themselves.
