An application server can be rebuilt from an image. The database is the one system where a single mistake costs everything at once, because once copies of those records are in someone else’s hands, no version of the incident ends cleanly.

The uncomfortable part is how ordinary most database breaches are. Verizon’s 2026 Data Breach Investigations Report analysed more than 22,000 confirmed breaches and found exploitation of a known vulnerability, not some novel technique, the most common way in. One scan of internet reachable databases found 46.3% of the 30,515 instances tracked already carried a ransom note or wipe message. Those systems were simply findable. IBM’s Cost of a Data Breach research puts the 2026 global average at USD 4.99 million, an all time high. The seven practices below are not new. What decides the outcome is whether each was an engineering decision during the build or a line item added afterwards.

1. Give the database its own server, and its own blast radius

A database sharing a host with the application that queries it gives one compromised web process local access to the data files, the socket, and often credentials in an environment variable. The database belongs on dedicated infrastructure, in a private subnet, with no route to the public internet and no inbound path except from the application hosts that need it.

The rule when someone asks for an exception: a database server should be harder to reach than the web tier, not equally hard. If yours is reachable from a laptop on the office network, a CI runner, or an analytics tool set up once in a hurry, you do not have isolation. You have a database with more front doors than you can name. That is a design decision, far cheaper to make during custom software development than to retrofit once twelve services already reach the same instance.

2. Treat the host as part of the attack surface

Hardening guides tend to stop at the database engine. Attackers do not. The operating system, SSH configuration, backup agent, monitoring sidecar, and the admin panel someone installed to ease a migration are all the same target. A practical baseline:

• Host firewall rules that deny by default and allow only named source groups.
• No shared administrative accounts. Every human gets a named identity, every service its own credential.
• Multi factor authentication on administrative access, preferring short lived credentials over static passwords.
• Logging of every access to the data, kept somewhere the database administrator cannot quietly edit.

That last point matters more than it sounds. Broken Access Control ranks A01 in the OWASP Top 10:2025 and Security Misconfiguration A02. Both are failures of who can do what, not of cryptography.

3. Encrypt at rest, and store the keys somewhere else

Encryption at rest is worth exactly as much as your key management. A database encrypted with a key sitting in a config file on the same volume is a locked door with the key taped to it.

Use transparent data encryption or filesystem level encryption for the whole store, then column level encryption for the fields that would actually hurt: identifiers, payment data, health records, credentials. Keys belong in a hardware security module or managed key vault, with scheduled rotation and access logged separately from the database. Enforce TLS at the server, so a misconfigured client cannot silently downgrade to plaintext.

For regulated data this is the first control an auditor examines. It is standing practice in fintech and healthcare systems, where the detail (which fields, which key hierarchy, who can decrypt) separates a passing review from a finding.

4. Configure the engine deliberately, not by default

Every major engine ships with capable security features and with defaults tuned for getting started quickly. Those are not the same thing. Default ports, default accounts, permissive bind addresses, verbose errors, and broad grants are normal on day one and dangerous on day ninety.

Work through the engine’s own security benchmark once, record what changed and why, and keep that configuration in version control so drift is visible. Grant permissions per role against specific tables, not per convenience: applications connect with an account that can do their job and nothing more, never as a superuser because one migration once needed it. Parameterised queries belong here too. Injection slipped to A05 in the current OWASP ranking but remains one of the most reliable ways to turn a web form into a data export.

5. Back up on a schedule, and prove the restore

Most teams have backups. Fewer have a restore they have actually performed. An untested backup is a hypothesis.

The working version: automated backups on a defined frequency, one copy offsite in a separate account or region, one copy immutable so ransomware cannot encrypt your recovery path along with production, and a restore rehearsal on a calendar. Record how long a full restore takes: that number is your real recovery time objective, whatever the policy document claims. Ransomware appeared in 48% of breaches in the 2026 DBIR, and the only control that reliably changes the outcome is a restore path the attacker cannot reach.

6. Patch on a cycle, not after an incident

Since known vulnerabilities are the most common entry point in current breach data, patch cadence is not maintenance overhead. It is a primary control.

Set a defined window, subscribe to the advisories for your engine version, and include everything in the path: the database, the host operating system, the drivers, the connection poolers, and the ORM. Track patch latency, the time between a fix being published and it running in production, and give that number an owner. Teams that run this well wire it into the delivery pipeline rather than someone’s calendar, which is much of what ongoing DevOps support is for.

7. Audit like an attacker, on a fixed schedule

Internal review tells you whether the system matches your intentions. It cannot tell you whether those intentions were sufficient. For that you need someone actively trying to get in.

Run configuration reviews and access recertification quarterly, revoke credentials nobody needs any more, and commission independent penetration testing against the data layer annually and after significant architectural change. Scope it to the paths people forget: backup storage, replica instances, staging environments loaded with production data, and reporting tools holding cached copies. Findings are only useful when tracked to closure with an owner and a date; an audit read once and filed leaves you with the same posture as no audit.

Start with what you can actually answer

Before planning a program of work, answer three questions: which identities can reach the production database right now, when was the last successful restore test, and how long since the engine was patched. Most teams are surprised by at least one.

Uncomfortable answers are a scoping exercise, not a crisis. 247 Labs works with engineering leaders on exactly this: reviewing an existing data layer, hardening it without stalling delivery, and building the next system so these controls are structural rather than bolted on. See how we approach that on our cybersecurity services page, or get in touch to talk through your setup.