TL;DR - Most startup databases fail security audits on the same six issues: shared root credentials, no encryption in transit, overprivileged users, unencrypted or untested backups, no access monitoring, and unpatched software. - This checklist covers each area with actual MySQL commands you can run today, not abstract recommendations. - SOC 2 auditors, enterprise customer security questionnaires, and penetration testers all check the same fundamentals. Get them right and you pass. Skip them and you lose the deal. - Startups that handle the basics — unique users, SSL, least privilege, encrypted backups, login monitoring, and patching — are ahead of 80% of companies at their stage. - You do not need a dedicated security team to implement this. A single developer can complete every item on this list in a day.

Table of Contents

• Database Security Checklist for Startups: What Auditors Actually Look For
• Why Startups Get Audited (and What Happens When They Fail)
• 1. Authentication: No Shared Credentials, No Root Access
• 2. Encryption: In Transit and At Rest
• 3. Access Control: Least Privilege, Not Convenience
• 4. Backups: Encrypted, Tested, and Off-Site
• 5. Monitoring: Know When Something Goes Wrong
• 6. Patching: Stay Current or Get Exploited
• 7. Network Security: Minimize Exposure
• 8. Data Handling: Know What You Store
• The Complete Checklist
• FAQ
• Conclusion

Database Security Checklist for Startups: What Auditors Actually Look For

Your first enterprise customer sends over a security questionnaire. It is 47 pages long. Half the questions are about how you handle database access. Or you decide to pursue SOC 2 compliance because three prospects asked for it. The auditor wants evidence of access controls, encryption, monitoring, and patching. Or a penetration tester scans your infrastructure and the report comes back with findings that make your database look like an open house.

A practical database security checklist prevents all three scenarios. Not a theoretical framework or a 200-page policy document — a concrete list of configurations, commands, and practices that address what auditors, enterprise customers, and penetration testers actually check.

This article is that list. Every item includes the MySQL commands to implement it and an explanation of why auditors care about it. A single developer can complete every item in a day. Most items take less than 10 minutes.

Why Startups Get Audited (and What Happens When They Fail)

Startups encounter database security audits in three contexts:

Enterprise sales. According to a 2025 Vanta survey, 76% of enterprise buyers require vendors to demonstrate security compliance before signing a contract. The most common requirements are SOC 2 Type II, ISO 27001, or completing a custom security questionnaire. Database security is a section in every one of them.

Compliance certifications. SOC 2, HIPAA, PCI DSS, and GDPR all have database security requirements. The 2025 Drata State of Compliance report found that 62% of startups begin compliance work within their first two years, driven primarily by customer requirements.

Investor due diligence. Series A and later investors increasingly include a technical due diligence component. A database running as root with no encryption and no monitoring is a red flag that suggests broader engineering shortcuts.

What happens when you fail: The enterprise deal stalls or dies. The compliance certification is delayed by months while you remediate findings. The penetration test report goes to the prospect's security team and your product gets rejected. In every case, the cost of fixing the issues after discovery is 10x the cost of implementing them upfront.

The good news is that auditors are not looking for perfection. They are looking for the fundamentals. Get the six areas in this checklist right and you will pass the vast majority of security reviews.

1. Authentication: No Shared Credentials, No Root Access

The single most common finding in startup database security audits is shared credentials. The entire team uses root (or one shared user) with the same password, and that password has been in a Slack channel since 2024.

What auditors check

• Are there individual database accounts per person and per application?
• Is the root/superuser account disabled for remote access?
• Are passwords strong and rotated regularly?
• Is there a process for revoking access when someone leaves?

The MySQL commands

Create individual user accounts:

-- Developer account
CREATE USER 'dev_alice'@'%' IDENTIFIED BY 'Kx9$mP2vL8qR3wZn';
GRANT SELECT, INSERT, UPDATE, DELETE ON app_production.* TO 'dev_alice'@'%';

-- Application service account
CREATE USER 'app_service'@'10.0.1.%' IDENTIFIED BY 'Yt7#bN4xH6jW9cFd';
GRANT SELECT, INSERT, UPDATE, DELETE ON app_production.* TO 'app_service'@'10.0.1.%';

-- Read-only analyst account
CREATE USER 'analyst_carol'@'%' IDENTIFIED BY 'Qm5&vR8pJ2wX4kBz';
GRANT SELECT ON app_production.* TO 'analyst_carol'@'%';

Lock down root to localhost only:

-- Check current root access
SELECT user, host FROM mysql.user WHERE user = 'root';

-- Remove remote root access
DROP USER 'root'@'%';
-- or
DELETE FROM mysql.user WHERE user = 'root' AND host != 'localhost';
FLUSH PRIVILEGES;

-- Ensure root only works from localhost
ALTER USER 'root'@'localhost' IDENTIFIED BY 'new-strong-password-here';

Audit existing users:

-- List all users and their hosts
SELECT user, host, authentication_string != '' AS has_password
FROM mysql.user
ORDER BY user;

-- Find users with no password
SELECT user, host FROM mysql.user
WHERE authentication_string = '' OR authentication_string IS NULL;

-- Find users with global (wildcard) host access
SELECT user, host FROM mysql.user WHERE host = '%';

Revoke access immediately when someone leaves:

DROP USER 'former_employee'@'%';
FLUSH PRIVILEGES;

This should be part of your offboarding process. If you do not have an offboarding process, create one. An auditor will ask.

2. Encryption: In Transit and At Rest

Encryption in Transit (SSL/TLS)

Every connection between your application and the database, and every connection from a developer's machine to the database, must be encrypted. Without SSL/TLS, credentials and query data travel in plaintext.

Check if SSL is enabled:

SHOW VARIABLES LIKE 'have_ssl';
-- Should return 'YES'

SHOW STATUS LIKE 'Ssl_cipher';
-- Should return a cipher name, not empty string

Require SSL for specific users:

ALTER USER 'dev_alice'@'%' REQUIRE SSL;
ALTER USER 'app_service'@'10.0.1.%' REQUIRE SSL;

-- Verify
SELECT user, host, ssl_type FROM mysql.user WHERE ssl_type != '';

Require SSL globally (MySQL 8.0+):

-- In my.cnf
-- [mysqld]
-- require_secure_transport = ON

For a complete SSL setup walkthrough, see our MySQL SSL/TLS configuration guide.

Encryption at Rest

Encryption at rest protects data on disk — if someone steals the physical server or a backup drive, the data is unreadable without the encryption key.

MySQL 8.0 InnoDB tablespace encryption:

-- Enable in my.cnf
-- [mysqld]
-- early-plugin-load=keyring_file.so
-- keyring_file_data=/var/lib/mysql-keyring/keyring

-- Encrypt a table
ALTER TABLE users ENCRYPTION = 'Y';

-- Check encryption status
SELECT TABLE_SCHEMA, TABLE_NAME, CREATE_OPTIONS
FROM INFORMATION_SCHEMA.TABLES
WHERE CREATE_OPTIONS LIKE '%ENCRYPTION%';

Managed database providers (AWS RDS, DigitalOcean, GCP Cloud SQL) offer encryption at rest enabled by default using the provider's key management system. If you are on a managed provider, verify it is enabled — it almost certainly is, but auditors want confirmation.

3. Access Control: Least Privilege, Not Convenience

After shared credentials, the second most common audit finding is overprivileged database users. The application service account has GRANT ALL PRIVILEGES when it only needs SELECT, INSERT, UPDATE, and DELETE on specific tables.

What auditors check

• Does each user have only the permissions they need?
• Are there any users with SUPER, FILE, GRANT, or ALL PRIVILEGES that should not have them?
• Are application accounts restricted to specific databases?

The MySQL commands

Audit current privileges:

-- Show all grants for a specific user
SHOW GRANTS FOR 'app_service'@'10.0.1.%';

-- Find users with dangerous global privileges
SELECT user, host,
       Super_priv, File_priv, Grant_priv, Create_user_priv,
       Shutdown_priv, Process_priv, Reload_priv
FROM mysql.user
WHERE Super_priv = 'Y' OR File_priv = 'Y' OR Grant_priv = 'Y'
ORDER BY user;

Fix overprivileged accounts:

-- Remove all privileges and re-grant only what is needed
REVOKE ALL PRIVILEGES ON *.* FROM 'app_service'@'10.0.1.%';
GRANT SELECT, INSERT, UPDATE, DELETE ON app_production.* TO 'app_service'@'10.0.1.%';
FLUSH PRIVILEGES;

Privilege reference for common roles:

No account except root (localhost only) should have ALL PRIVILEGES ON *.*.

4. Backups: Encrypted, Tested, and Off-Site

Having backups is not enough. Auditors check three properties: the backups are encrypted, the backups are stored off-site (not on the same server as the database), and the backups have been tested by restoring them.

The MySQL commands

Create an encrypted backup with mysqldump:

# Dump and encrypt in one step
mysqldump --single-transaction --routines --triggers \
  --all-databases -u backup_user -p | \
  openssl enc -aes-256-cbc -salt -pbkdf2 \
  -out /backup/db-$(date +%Y%m%d).sql.enc

# Store the encryption password in a secrets manager, not on the server

Test a backup by restoring it:

# Decrypt and restore to a test instance
openssl enc -d -aes-256-cbc -pbkdf2 \
  -in /backup/db-20260410.sql.enc | \
  mysql -h test-instance -u root -p

# Verify row counts match production
mysql -h test-instance -e "SELECT COUNT(*) FROM app_production.users;"

Automate and verify:

# Cron job for daily backups
0 3 * * * /usr/local/bin/backup-db.sh >> /var/log/backup.log 2>&1

# Monthly restore test (document the result)
0 4 1 * * /usr/local/bin/test-restore.sh >> /var/log/restore-test.log 2>&1

Store backups off-site: Upload to S3, Google Cloud Storage, Backblaze B2, or any storage that is not on the database server. If the server is compromised, the backups should still be safe.

What auditors want to see

• Evidence of regular automated backups (cron job, logs)
• Evidence that backups are encrypted
• Evidence that backups are stored in a separate location
• Evidence that backups have been successfully restored (a restore test log from the last 90 days)
• A documented backup retention policy (typically 30-90 days, depending on your data requirements)

5. Monitoring: Know When Something Goes Wrong

Auditors do not expect a startup to have a 24/7 security operations center. They expect you to know when something abnormal happens and to have evidence that you review it.

What to monitor

Failed login attempts. A spike in failed logins indicates a brute-force attack or a misconfigured application.

-- Enable connection logging
-- In my.cnf:
-- log_error_verbosity = 3

-- Or install the MariaDB Audit Plugin
INSTALL SONAME 'server_audit';
SET GLOBAL server_audit_logging = 'ON';
SET GLOBAL server_audit_events = 'CONNECT';

Schema changes. Any CREATE, ALTER, DROP, GRANT, or REVOKE in production should be logged and reviewed.

SET GLOBAL server_audit_events = 'CONNECT,QUERY_DDL,QUERY_DCL';

Unusual access patterns. Connections from new IP addresses, queries at unusual times, bulk data exports.

Disk and performance metrics. Sudden spikes in query volume, disk I/O, or connection count can indicate an attack or a runaway query.

Practical monitoring setup

For most startups, the following is sufficient and costs nothing:

1. Install the MariaDB Audit Plugin (or Percona Audit Log) — logs connections and DDL to a file.
2. Ship logs to a centralized system — Datadog, CloudWatch, or even a simple rsyslog setup.
3. Set up basic alerts — email notification on more than 10 failed logins in 5 minutes, or any DDL statement in production.
4. Review logs monthly — a 30-minute review of connection patterns, failed logins, and schema changes. Document the review.

For a deeper dive, see our guide on database access audit trails.

When using browser-based tools for database access, the tool itself should provide session logging. DBEverywhere logs every session — who connected, when, from which IP, and to which database — giving you monitoring data without configuring database-level plugins.

6. Patching: Stay Current or Get Exploited

Running a database version with known vulnerabilities is an automatic audit finding. The NIST National Vulnerability Database lists over 350 CVEs for MySQL and 150+ CVEs for MariaDB. Many are remotely exploitable.

What auditors check

• Is the database running a currently supported version?
• Are security patches applied within a reasonable timeframe (typically 30 days for critical, 90 days for others)?
• Is there a patching process?

Check your current version

SELECT VERSION();
-- Compare against the latest stable release at
-- https://dev.mysql.com/downloads/mysql/
-- or https://mariadb.org/download/

MySQL version support status (as of April 2026)

If you are running MySQL 5.7 or MariaDB 10.5 or earlier, you are on an unsupported version with known, unpatched vulnerabilities. This is a critical finding that will block any compliance certification.

Patching process

1. Subscribe to security announcements (MySQL, MariaDB)
2. Test patches on staging before applying to production
3. Apply critical security patches within 30 days
4. Document the patching date and version

For managed database providers, patching is handled by the provider — but you should still know which version you are running and verify that the provider's maintenance schedule is reasonable. AWS RDS, for example, applies patches during your configured maintenance window automatically.

7. Network Security: Minimize Exposure

Network security for databases comes down to one principle: reduce the number of systems that can reach the database port to the absolute minimum.

Verify what is listening:

# Check which ports MySQL is listening on
ss -tlnp | grep mysql
# or
netstat -tlnp | grep 3306

Restrict by firewall:

# UFW: allow only your application server and your admin IP
sudo ufw deny 3306
sudo ufw allow from 10.0.1.5 to any port 3306
sudo ufw allow from 203.0.113.50 to any port 3306

Use private networking: If your application server and database are in the same data center or cloud region, connect over the private network interface, not the public one. This keeps database traffic off the public internet entirely.

Static IP for remote access: If your team needs browser-based database access from outside the data center, use a service with a static IP that you can whitelist. DBEverywhere provides a single static IP that you add to your database firewall, allowing remote access from any browser without opening the database port to the internet.

For more on why exposing the database port directly is dangerous, see Why You Should Never Expose Port 3306.

8. Data Handling: Know What You Store

Auditors increasingly ask about data classification and handling practices:

• Do you know which tables contain PII (personally identifiable information)?
• Do you know which tables contain financial data or health records?
• Are sensitive columns encrypted at the application level (not just disk-level encryption)?
• Do you have a data retention policy — how long do you keep data, and when is it purged?

Identify sensitive columns:

-- Find columns likely to contain PII (by naming convention)
SELECT TABLE_SCHEMA, TABLE_NAME, COLUMN_NAME
FROM INFORMATION_SCHEMA.COLUMNS
WHERE COLUMN_NAME LIKE '%email%'
   OR COLUMN_NAME LIKE '%phone%'
   OR COLUMN_NAME LIKE '%ssn%'
   OR COLUMN_NAME LIKE '%password%'
   OR COLUMN_NAME LIKE '%credit_card%'
   OR COLUMN_NAME LIKE '%address%'
ORDER BY TABLE_SCHEMA, TABLE_NAME;

This is a starting point for data classification, not a comprehensive audit. But it gives you an immediate answer to "which tables have sensitive data?" that you can provide to an auditor.

The Complete Checklist

Authentication

• [ ] Individual database accounts per person and per application
• [ ] Root/superuser restricted to localhost only
• [ ] No accounts with empty passwords
• [ ] Strong passwords (16+ characters, randomly generated)
• [ ] Documented offboarding process that includes database access revocation
• [ ] Password rotation on a schedule (quarterly minimum)

Encryption

• [ ] SSL/TLS enabled and required for all remote connections
• [ ] require_secure_transport = ON or per-user REQUIRE SSL
• [ ] Encryption at rest enabled (InnoDB encryption or managed provider default)
• [ ] Sensitive columns encrypted at application level (where applicable)

Access Control

• [ ] Every account uses least-privilege grants (no unnecessary ALL PRIVILEGES)
• [ ] No accounts with SUPER, FILE, or GRANT unless specifically needed
• [ ] Application accounts restricted to specific databases (not *.*)
• [ ] Quarterly privilege audit — review all users and their grants

Backups

• [ ] Automated daily backups
• [ ] Backups encrypted at rest
• [ ] Backups stored off-site (not on the database server)
• [ ] Restore tested within the last 90 days (documented)
• [ ] Retention policy defined and enforced

Monitoring

• [ ] Failed login attempts logged and alerted on
• [ ] Schema changes (DDL/DCL) logged
• [ ] Logs shipped to a centralized system (not only on the database server)
• [ ] Monthly log review (documented)

Patching

• [ ] Running a currently supported database version
• [ ] Security patches applied within 30 days (critical) / 90 days (other)
• [ ] Subscribed to vendor security announcements
• [ ] Patching process documented

Network

• [ ] Database port not exposed to 0.0.0.0
• [ ] Firewall rules restrict database access to specific IPs
• [ ] Application connects over private networking where available
• [ ] Remote admin access through SSH tunnel, VPN, or static IP gateway

Data Handling

• [ ] Sensitive data identified and classified
• [ ] Data retention policy documented
• [ ] PII handling documented for compliance questionnaires

FAQ

How long does it take to implement this entire checklist?

For a typical startup MySQL database, a single developer can complete every item on this checklist in one full day (6-8 hours). The individual items are fast — creating user accounts takes 5 minutes, enabling SSL takes 15 minutes, setting up an audit plugin takes 30 minutes. The time-consuming part is documenting everything, which auditors require. If you spread it over a week, spending an hour per day, you will be done before the next security questionnaire arrives.

Do I need all of this for SOC 2?

SOC 2 is principle-based, not prescriptive — it requires you to demonstrate that you have controls in place for logical access, encryption, monitoring, and system operations. Every item on this checklist maps to a SOC 2 Trust Services Criterion. You do not technically need every single item, but an auditor who sees gaps in the basics (shared root credentials, no encryption in transit, no monitoring) will issue findings that require remediation. Completing this checklist puts you ahead of most startups entering the SOC 2 process.

What if we use a managed database (AWS RDS, DigitalOcean)?

Managed database providers handle some items automatically: encryption at rest, patching, backup storage, and network-level firewall configuration. You still own authentication (creating proper users, not using the default admin for everything), least-privilege grants, SSL enforcement at the user level, backup restore testing, access monitoring, and data handling classification. Roughly half the checklist still applies. Auditors understand the shared responsibility model and will ask you about the items you own.

Is this checklist enough for HIPAA?

This checklist covers the database-specific requirements, but HIPAA requires additional controls beyond the database: workforce training, risk assessments, business associate agreements, physical security, and incident response procedures. For the database layer specifically, HIPAA's Security Rule (45 CFR 164.312) maps closely to this checklist — unique user authentication, access controls, audit controls, transmission security, and encryption. Use this checklist as the database component of a broader HIPAA compliance program.

What is the most common finding that blocks enterprise deals?

Shared database credentials. Enterprise security questionnaires almost always ask: "Do individual users have unique accounts for database access?" and "Is root or superuser access restricted?" If the answer is "everyone uses the same password" or "we connect as root," the deal stalls until it is fixed. This is also the easiest item on the checklist to address — create individual accounts and restrict root to localhost. It takes 10 minutes and unblocks deals worth orders of magnitude more than the time invested.

Conclusion

A database security checklist for startups is not about achieving perfect security. It is about covering the fundamentals so thoroughly that auditors, enterprise customers, and penetration testers find nothing to flag.

The six areas — authentication, encryption, access control, backups, monitoring, and patching — are the same ones that every compliance framework checks, every security questionnaire asks about, and every penetration test probes. Get them right and you are ahead of 80% of startups at your stage.

Every item in this article includes the actual MySQL command to implement it. You do not need a security team. You do not need a consultant. You need a terminal, an hour of focus per section, and the discipline to document what you did.

If you want to simplify the remote access portion — eliminating the need to expose database ports, manage SSH keys, or maintain VPN infrastructure — DBEverywhere gives your team browser-based database access through a single static IP that you whitelist. Session logging, automatic timeouts, and per-user access come built in. Try the free tier (5 sessions/month) to see how it fits your workflow.

Start with authentication. Right now. Create individual user accounts and lock root to localhost. It is the highest-impact item on this entire list and it takes 10 minutes.