How to Audit Databases: Security Audit Steps and Checklist

Databases hold the most sensitive data most organizations have: customers, payments, health records and intellectual property. When you audit databases, you check who can reach the data, how it is protected, whether activity is logged and whether you can recover it after a failure. This guide works for MySQL, MariaDB, PostgreSQL, SQL Server, Oracle and cloud-managed databases.

Scope

A database audit usually covers:

• database servers and cloud database services;
• the operating systems and networks they run on;
• user accounts, roles and privileges;
• configuration and patch level;
• encryption, backups and logging;
• processes for changes and access requests.

Start with a list of databases, their owners and the type of data each holds. Then focus on the ones with personal, financial or regulated data.

Useful tools

• Built-in views: for example information_schema and pg_roles in PostgreSQL, mysql.user in MySQL, and sys.server_principals in SQL Server.
• Benchmarks: CIS Benchmarks exist for all major database engines.
• Vulnerability scanners: tools such as Nessus or OpenVAS check versions and settings.
• Cloud tools: AWS Security Hub, Microsoft Defender for Cloud and similar services flag risky database settings.

Steps to perform the audit

1. Inventory: list instances, versions, owners and data classification.
2. Review access: export users, roles and privileges, and compare them with job needs.
3. Check configuration: compare settings with the CIS Benchmark or vendor hardening guide.
4. Check patching: compare versions with vendor security advisories.
5. Review protection: confirm encryption in transit and at rest, and test backups.
6. Review logging: confirm that logs capture logins and privileged actions, and that someone reviews them.
7. Report: rank findings and agree on fixes with owners.

Checklist

Access control

• Each person uses a named account; nobody shares admin logins.
• Applications use dedicated accounts with only the privileges they need.
• Default accounts are disabled or have strong passwords.
• Owners review privileged access regularly.
• Developers have no routine write access to production data.

Network and authentication

• Only application servers and admin hosts can reach database ports.
• No database listens directly on the internet.
• Connections use TLS.
• Authentication integrates with central identity where possible.

Configuration and patching

• The engine version is supported and patched.
• Unneeded features, sample databases and extensions are removed.
• Secure settings follow a hardening baseline.

Data protection

• Encryption at rest protects sensitive databases.
• Sensitive columns, such as card numbers or Aadhaar numbers, are masked or tokenised where possible.
• Test environments use masked or synthetic data.

Backup and recovery

• Backups run on schedule and are encrypted.
• At least one copy is offline or immutable.
• The team tests restores and measures recovery time.

Logging and monitoring

• Logs record logins, failed logins, privilege changes and schema changes.
• Logs go to a central SIEM, where alerts flag unusual activity.
• Database activity monitoring covers the most sensitive systems.

Common findings

Typical issues include shared admin accounts, application accounts with full privileges, databases reachable from the whole office network, missing encryption on backups and logs that nobody reviews.

Related guides

• How to audit applications
• How to audit storage systems

Sources

• ISACA: IT audit resources

Preparing for an ISO 27001 or IT audit? Our ISO 27001 readiness assessment finds your gaps before the auditor does. You can also start with our free ISO 27001:2022 readiness checklist, or contact us for a quote.