DATABASE
SECURITY:
THE SILENT
FAILURES THAT
COST MILLIONS.
A data breach cost, on average, USD 4.88 million globally in 2024 — the highest ever recorded, according to IBM's Cost of a Data Breach report. In healthcare, that figure climbs to USD 9.77 million per incident. In financial services, USD 6.08 million.
And most of those incidents do not begin with a sophisticated nation-state attack. They begin with a database misconfiguration that has been there for months — and nobody knew about it.
$4.88M
average global cost of a data breach in 2024 — IBM Cost of a Data Breach
10x
more breaches in 2024 vs. previous years driven by stolen credentials
30%
of 2024 breaches caused by security misconfigurations in core systems
01
THE PROBLEM IS NOT WHERE YOU THINK
Most companies invest in firewalls, antivirus and network access control. And then leave the database — where all the critical data lives — with default install settings, users with excessive privileges, and no audit log enabled.
The database is the final target of nearly every cyberattack. It is where customer records, financial data, health information and trade secrets sit. But it has historically been the least audited asset in the IT environment.
In 2024, 45% of security breaches happened due to inadequate access controls. Another 30% came from misconfigurations that had been in the environment for months — or years — before being exploited.
"The database is the last destination of nearly every attack. And the first asset IT teams forget to audit."
Free discovery
Does your database have security gaps?
Our Health Check includes a full security audit: users with excessive privileges, exposed configurations, access vulnerabilities and data protection compliance. In a free discovery session, you understand exactly how critical your environment is.
Book a free discovery →Or talk to us directly: WhatsApp
02
THE 7 MOST COMMON DATABASE SECURITY FAILURES
After 35 years running databases in production — and more than 25,000 hours of accumulated consulting — HTI has mapped the patterns that keep repeating. These are the seven failures we find most frequently in the environments we audit:
Failure 1 — Users with excessive privileges
The most common scenario: a developer needed temporary DBA access to fix something. The access was never revoked. Six months later that account still has DROP permission on production tables — and nobody knows.
Excessive privileges are the most silent entry point. They do not trigger alerts. They generate no log without specific monitoring. And when exploited — by an external attacker who compromised the credential, or by an insider — the damage is total.
Failure 2 — Default settings never changed
MySQL, SQL Server, Oracle, PostgreSQL — they all ship with settings that prioritize ease of installation, not security. Default users enabled. Well-known ports open. Simple password authentication. Features turned on that will never be used.
An environment configured three years ago and never reviewed since likely still carries vulnerabilities the vendor has long since patched — but that depend on manual reconfiguration to be closed.
Failure 3 — No audit log
Without an audit log, you do not know who accessed the database, when, what they read, what they changed. In an incident, there is no forensic trail. In an audit, there is no evidence of control.
Worse: without an active log, data exfiltration can run for weeks before any alert. IBM reports that the average time to identify a breach exceeds 200 days in environments without proper monitoring.
Failure 4 — Untreated SQL Injection in application code
SQL Injection is the most documented vulnerability in the history of application security. The OWASP Top 10 has classified it as one of the most recurring since 2003. And it is still being exploited in 2025.
The database itself is not vulnerable to SQL Injection — the vulnerability lives in application code that does not validate inputs before passing them to the database. But the database carries the consequences: exposed data, corrupted tables, unauthorized administrative access.
The technical fix exists and is well documented: prepared statements, input validation, principle of least privilege on the connection account. The problem is that legacy environments rarely receive this review systematically.
Failure 5 — Backups without encryption and without restore tests
An unencrypted backup in accessible storage is a complete database waiting to be stolen. There is no need to break into the production server — just access the backup repository.
Worse: most companies have never tested restoring their backups. A backup silently corrupted six months ago means that, in a disaster, the recovery plan does not exist — only the illusion of one does.
Failure 6 — Outdated versions with known vulnerabilities
Every outdated RDBMS version has a public list of CVEs (Common Vulnerabilities and Exposures) — documented vulnerabilities, with known exploits, available for anyone to look up. An attacker does not need to discover a zero-day. They just consult the list and check whether your database is still on the affected version.
In 2024, 60% of organizations reported breaches caused by components with known vulnerabilities that simply had not been updated.
Failure 7 — Sensitive data without encryption at rest
Tax IDs, card numbers, health data, passwords — stored in plain text in production tables. Anyone with SELECT access to the table has access to the real data. Without encryption at rest, there is no second layer of protection if access control fails.
And under data protection laws like GDPR or LGPD, the absence of encryption for personal data is not just technical risk — it is evidence of negligence in any sanctioning process.
Does your environment show any of these signs?
If you answered yes to two or more items below, your environment needs a security audit:
- Users with DBA access who no longer need that level
- Database on a version more than 12 months without security patches
- No audit log active in the last 30 days
- Backups never tested with a full restore
- Customer data without encryption at rest
- Application connection account with DBA privileges
- No documented access revocation policy
03
WHAT DATA PROTECTION LAW REQUIRES OF YOUR DATABASE
Data protection laws like GDPR (Europe) and LGPD (Brazil) do not specify a particular technology — but they require "technical and administrative measures suitable to protect personal data from unauthorized access and from accidental or unlawful situations". In practice, for databases, this translates into a set of controls most companies still do not have implemented in a documented way.
The main attention points for databases under data protection regulation:
Access control with logging
Who accesses what data, when and for what purpose. Without an active audit log, there is no way to demonstrate control — and without demonstrating it, there is no way to defend yourself in case of regulator notification.
Encryption of personal data
Identity, health, financial and other sensitive data stored in databases needs additional protection beyond access control. Encryption at rest is the most direct technical measure for this.
Documented incident response plan
In case of a breach, regulation requires notifying the authority within a reasonable timeframe. To do that, you need to know an incident occurred — which requires active monitoring — and you need a documented response plan.
"Under data protection law, the absence of technical controls is not just risk of fines. It is evidence of negligence."
Is your environment compliant?
HTI's Database Health Check includes a full data protection compliance analysis: mapping of personal data stored, verification of access controls, identification of sensitive data without encryption and documented remediation recommendations.
→ Learn about the Database Health Check04
HOW TO IDENTIFY SECURITY GAPS BEFORE THEY ARE EXPLOITED
The good news: most database security failures are detectable before they become incidents. The problem is that detection requires methodology, specific tools and accumulated experience — it is not something a single generalist DBA does on the side of day-to-day operations.
A database security audit covers four layers:
Layer 1 — Access and identity
Full review of users, roles, privileges and service accounts. Identification of inactive accounts, excessive privileges and accounts with default passwords. Verification of external access to the database.
Layer 2 — Configuration and hardening
Comparison of database configurations against the vendor's security best practices. Identification of unnecessary active features, exposed ports and insecure parameters.
Layer 3 — Data and encryption
Mapping of tables containing personal or sensitive data. Verification of encryption at rest and in transit. Identification of sensitive data without additional protection.
Layer 4 — Monitoring and audit
Verification of active logs, monitoring coverage and ability to detect anomalous access. Assessment of the incident response plan.
HTI performs this analysis as part of the Database Health Check — a complete technical diagnosis that maps the real security state of your environment and delivers a prioritized remediation roadmap.
05
WHEN A SECURITY PROBLEM IS ALREADY ACTIVE
There is not always time for a planned audit. Some situations require immediate response:
If you have spotted any of these signs, treat it as an active incident and engage specialized support immediately:
- →Unauthorized access identified in logs
- →Customer data exposed or suspected exfiltration
- →Unknown user with access to the database
- →Anomalous query behavior in production
- →Ransomware or unauthorized data encryption
- →Database unreachable with no apparent technical cause
In these cases, every minute matters. HTI keeps a Rapid Response Team available 24 hours a day, 7 days a week, with a 30-minute SLA during business hours and 2 hours outside of them — with no prior contract.
Active incident
Security issue identified right now?
Do not wait. Our Rapid Response Team handles database emergencies 24/7, including security incidents: unauthorized access, data exfiltration and credential compromise.
Engage the emergency team →30-min SLA · No prior contract · talk on WhatsApp
06
CONTINUOUS SECURITY: THE ROLE OF A DEDICATED DBA
A one-off audit solves the diagnosis. But database security is not a project with a beginning, middle and end — it is a continuous discipline. Security patches are released monthly. New users are created and old ones never revoked. Applications change and bring new vulnerabilities.
A Senior DBA dedicated to your environment handles these layers continuously: reviews privileges periodically, applies security patches, monitors anomalous behavior and keeps the audit log always active and analyzed.
HTI offers this service as Remote DBA — a team of Senior DBAs operating from a controlled physical room, with 24/7 NOC and contractual SLA. It is not occasional support: it is continuous sustainment with responsibility for the security of the environment.
→ Learn about HTI's Remote DBA
SECURITY IS NOT AN EVENT. IT IS A PROCESS.
Millions of dollars is the average cost of a breach. But the real cost goes beyond financial: forensic investigation, operational shutdown, legal exposure, customer loss, reputational damage that can take years to rebuild.
Most failures that lead to that scenario are not sophisticated. They are configurations that were never reviewed, users that were never revoked, logs that were never enabled. Problems a technical diagnosis would have identified — before they were exploited.
The first step is knowing where you actually are. Not where you think you are.