In 2017, a Bupa Global employee with broad database access downloaded the health insurance data of half a million customers and attempted to sell it. Application database access controls determine whether a single authorised user can reach every record in your finance and health systems, or only the records they need.
Marco Cavani
Cybersecurity Analyst
In 2017, a Bupa Global employee accessed the company’s CRM system and extracted the personal and health insurance data of approximately 547,000 customers. The employee did not need to breach any security perimeter. They used their authorised credentials to access a database they were permitted to use. What the controls had not prevented was the extraction of records far beyond the scope of any legitimate work task.
The employee attempted to sell the stolen data. Bupa became aware of the breach and reported it to the UK Information Commissioner’s Office. The ICO fined Bupa 175,000 pounds for failing to have appropriate technical and organisational measures to protect the data.
The central control failure was not authentication or access provisioning. The employee had legitimate access to the CRM. The failure was the absence of controls that would have prevented or detected one user extracting records for half a million customers in a single session.
Application Database Access controls for Groups D, E, and F address the risk that authorised users of finance, payroll, HR, and ERP applications can access data beyond what their role requires, either through direct database query access or through application functions that return unrestricted data sets.
The risk has several dimensions:
Unrestricted query access: In many ERP and finance system deployments, support staff, administrators, and developers have direct SQL or equivalent database access that bypasses all application-level authorisation controls. A query that returns all records in a table is indistinguishable in most logs from a query that returns a single record, unless data volume monitoring is in place.
Application functions with no row-level restriction: Application interfaces that allow users to export reports or run ad-hoc queries without row-level access controls allow any user to extract all records in the dataset, regardless of their operational need.
Separation of database administration from application access: Database administrators (DBAs) who hold unrestricted access to the underlying database of a finance or HR application can read and modify records without using the application interface, bypassing all application-level authorisation, logging, and workflow controls.
Reporting and extract functions: Finance and ERP applications that provide bulk data extract or reporting functions without restricting the volume or scope of data accessible to a given user create a data theft pathway that is operationally indistinguishable from legitimate report generation.
The Bupa case illustrates a specific variant: the authorised user who extracts all records, not just those relevant to their current task. Without controls on query scope, data volume, or bulk extract, this type of insider data theft is difficult to prevent and slow to detect.
The employee at Bupa Global had access to the CRM system in the course of their employment. CRM systems in insurance and health contexts contain detailed customer records including personal information, policy details, and health data.
The extraction was performed through the application interface or direct database access in a manner that produced a dataset of 547,000 customer records. The absence of data volume monitoring or anomalous extract detection meant that the extraction was not flagged in real time. Bupa became aware of the breach through other means.
The ICO’s investigation identified that Bupa had failed to:
The ICO noted that the breach could have been prevented or detected earlier with appropriate technical controls. Bupa’s remediation involved implementing monitoring controls and reviewing the data access rights of staff with access to sensitive customer databases.
No data volume monitoring: The extraction of records for 547,000 customers produced a data volume that was many times the volume of any legitimate operational task. The absence of monitoring for anomalous data volumes allowed the extraction to proceed without detection.
Unrestricted record scope in application access: The employee’s application access did not restrict the records they could access to a subset aligned with their operational role. An insurance CRM that allows any user to search and export any customer record, regardless of geographic or portfolio assignment, has a fundamental data segmentation gap.
No DLP at the application or network layer: The absence of data loss prevention controls at the application or network exit points allowed the extracted data to leave the organisation without inspection.
No context-aware monitoring: Even if the application did not have native monitoring, a security information system that correlated application session activity with data volume would have flagged the anomalous extraction pattern.
Row-level security in ERP and CRM applications: Application access controls are implemented at the row level, restricting each user to records within their assigned portfolio, geographic region, or business unit. An employee in one region cannot query or export records for customers in another region.
Data volume thresholds and alerting: The application and the database layer are configured to alert when a single user session accesses or exports data above a defined volume threshold. The threshold is set at a level that permits legitimate operational tasks while flagging bulk extracts.
DBA access separation from application data: Database administrators who manage the underlying database infrastructure of finance and ERP applications do not hold roles that allow them to read application data outside of a formally approved, monitored session.
Audit logging at the application and database layer: All application data access events are logged at the database layer, capturing the user, timestamp, query or function, and number of records returned. Logs are reviewed for anomalous patterns.
Data loss prevention at network exit: Network DLP controls inspect outbound data flows for patterns consistent with application data extracts and block or alert on large structured data transfers.
When auditing Application Database Access for Groups D, E, and F, an IT auditor will typically:
Assess database access segregation: Identify all users with direct database access (SQL) to the underlying database of key finance, payroll, and ERP applications. Confirm that DBA access is separated from application data roles. Test whether direct database queries bypass application audit logging.
Test row-level access controls: For key applications, test whether a user with a defined role can access records outside their assigned scope. For example, can a user assigned to one business unit access records for another? Flag the absence of row-level controls as a finding.
Review data export and reporting controls: Assess whether application reporting and export functions restrict the volume or scope of data accessible to individual users. Test whether an end user can generate a report or extract covering all records in the system. Flag unrestricted exports as a finding.
Test data volume monitoring: Confirm that controls exist (application-native or SIEM-based) that detect and alert on anomalous data volumes in application sessions. Test the threshold configuration. Flag the absence of volume monitoring as a finding.
Assess DLP coverage: Confirm that data loss prevention controls are in place at the network layer or application exit points. Test whether a structured data extract from a finance or CRM application would be detected by DLP controls.
Review database access logs: Request application and database audit logs for the period. Test whether they capture the user, timestamp, and number of records accessed for key transactions. Confirm that logs are reviewed for anomalous patterns.
The Bupa case is not unusual. Insurance, healthcare, finance, and retail organisations routinely deploy CRM and ERP systems with insufficient data segmentation and no data volume monitoring. The combination means that the first indication of an insider data theft is often an external notification rather than an internal alert.
Implement row-level security in every system that holds personal or sensitive data. Users should only be able to access records within the scope of their role. This is a configuration requirement, not a technology purchase.
Define a maximum records-per-session threshold and enforce it. Any session that accesses more records than any legitimate single-user task could require is anomalous. Define the threshold. Alert on it. Investigate breaches.
Separate DBA access from application data. The DBA who manages your Oracle or SQL Server instance should not also hold roles that allow reading of HR or customer data. This is a fundamental access separation requirement.
Log at the database layer, not just the application layer. Application-layer logs that can be bypassed by direct database access are incomplete. Database audit logging captures all access, regardless of path.
Test your DLP before you need it. If your data loss prevention controls have never been tested against a realistic bulk extract scenario, you do not know whether they would detect it.
The MarcoWeb ITGC Tool covers Application Database Access across Groups D, E, and F, with structured assessment templates for DBA separation, row-level security, and data volume monitoring.
Written by
Marco Cavani
Cybersecurity analyst and IT governance professional. Author of digital reports on threat intelligence, critical infrastructure security, and IT audit frameworks.
In July 2020, a teenager convinced Twitter employees to hand over access to an internal admin tool that could control any account on the platform. Obama, Biden, Musk, and Apple were among the victims. Privileged access management is the control that limits the blast radius when an insider is compromised.
A Ubiquiti employee used shared cloud admin credentials to steal gigabytes of data, then posed as an anonymous hacker demanding a ransom. When everyone knows the password, nobody can be held accountable. Generic and shared accounts are the accountability gap that auditors close.
Christopher Dobbins was terminated by Stradis Healthcare and used retained credentials to delete thousands of records needed to ship personal protective equipment during a global pandemic. Access termination is not an HR process. It is a security control.
Get the latest cybersecurity reports, threat intelligence, and IT governance insights delivered straight to your inbox. No spam. Unsubscribe any time.
No spam. Unsubscribe at any time.
The RACM ITGC SaaS platform helps audit professionals manage IT General Controls assessments, from risk and control mapping to workpaper generation and evidence tracking.
