Security audits

Database security audit

Where your most sensitive records live: who can reach them, who can read them, and whether anyone would notice if they did.

Configuration by configuration and grant by grant, we review self-managed MySQL, PostgreSQL, Microsoft SQL Server, Oracle Database, MongoDB, Redis and Elasticsearch, and managed services including Amazon RDS, Google Cloud SQL, Azure SQL and MongoDB Atlas. Each instance is measured against its CIS Benchmark or the vendor's security guidance, then against how your applications use it: the accounts, secrets, network paths and queries. You receive ranked changes, each naming the exact parameter, grant or rule to alter.

Best for: Teams holding payment, health, identity or customer records whose database access grew faster than anyone's review of it, and teams facing a customer audit, a certification or a move to a managed service.
Duration: 3 to 7 working days
Standards: CIS Benchmarks for Oracle MySQL, PostgreSQL, Microsoft SQL Server, Oracle Database and MongoDB
Redis and Elasticsearch vendor security guidance
PCI DSS v4.0.1 Requirements 3, 7, 8 and 10
OWASP ASVS 5.0 (V13 Configuration, V14 Data Protection)
Israel Privacy Protection Regulations (Data Security) 5777-2017, Regulations 8 to 10 and 16

Signals you need this now

Engineers, analysts or support staff reach production through shared accounts, and nobody can produce the list of who can read customer data today.
A database, search cluster or cache has a public IP address, or an allow-list containing 0.0.0.0/0 that was meant to be temporary.
Connection strings with passwords sit in environment files, CI variables, wiki pages or old commits.
Snapshots and backups are encrypted, yet any engineer with access to the cloud console can copy, share or restore them.
An engine version is out of vendor support, or patches wait for a maintenance window that never quite arrives.
Audit logging is off, or on and unread, so a bulk export by a valid account would look like normal traffic.
Production data was copied into staging, analytics or a developer's laptop to debug something, and the copy may still be there.

How the audit runs

Read-only by default and in this order, with a short written update at the end of each day and an immediate call if anything critical turns up.

1
Inventory instances and data
We list every engine, instance, replica, snapshot and backup location, and mark which hold regulated or sensitive data. Instances found in cloud inventories or connection strings that nobody mentioned are added before assessment starts.
2
Capture configuration read-only
Through a read-only account you create, we export server settings, parameter groups, users, roles, grants, audit settings and network rules. Scripts give coverage, and every result is then checked by hand against your architecture.
3
Measure against benchmarks and vendor guidance
Each instance is scored against its CIS Benchmark (Oracle MySQL, PostgreSQL, Microsoft SQL Server, Oracle Database or MongoDB) or the vendor's security guidance (Redis, Elasticsearch), and managed services against the provider's own controls. Every deviation appears in the scorecard; only those that create risk in your environment become findings.
4
Trace effective privilege
We follow privilege the way the engine evaluates it, including roles inherited through groups, ownership, default privileges, rights to execute procedures, and links to other databases. Every human and service account is matched to a person or system that needs it.
5
Review the application side
With your developers we sample the queries, ORM calls and stored procedures that touch sensitive tables, look for injection-prone patterns, and trace where connection secrets are stored and how they rotate.
6
Report, walk through and retest
Ranked findings name the parameter, grant or rule to change and the side effects to expect. We walk your DBAs or platform engineers through them, then run the free retest of every fixed finding within 30 days of report delivery and reissue the report.

What we check

Grouped as they appear in the report. The scoping call settles which groups apply to you.

Authentication and account hygiene

Default, sample and vendor accounts removed or locked, and built-in superusers (sa, postgres, root, elastic) kept out of applications and daily work
Modern authentication: SCRAM-SHA-256 in PostgreSQL with no md5 or trust entries left in pg_hba.conf, no accounts on legacy authentication plugins in MySQL, and Windows or Microsoft Entra authentication for SQL Server where possible
Personal accounts for people through single sign-on or IAM database authentication, with no shared human logins
Service accounts with one owner and one purpose each, unable to log in interactively, and rotated
Accounts reconciled against HR and identity-provider records, so leavers lose access

Network exposure and segmentation

Listeners bound to private interfaces, never to a public address
Security groups, firewall rules and allow-lists free of 0.0.0.0/0 and of broad office or VPN ranges
Redis and Elasticsearch unreachable from untrusted networks; Redis's own guidance is that it is designed to be accessed by trusted clients inside trusted environments
Administrative access through a bastion, VPN or identity-aware proxy, with session logging
Production, staging and analytics separated, so a compromise of one does not reach the others

Encryption in transit and at rest

TLS required for client connections rather than merely offered, with clients verifying the server certificate
Replication, cluster and backup traffic encrypted as well as client connections
Encryption at rest for data files, logs, replicas and snapshots, with keys held in a KMS or HSM and key administration separated from database administration
Field-level encryption or tokenisation for the columns whose disclosure would matter most: card data, national identifiers and health records

Privilege model and least privilege

Effective privileges for every account, including inherited roles, PUBLIC grants and default privileges
Application accounts limited to the schemas and operations they use, with no DDL, ownership or superuser rights at runtime
Dangerous capabilities removed: command execution (xp_cmdshell in SQL Server, COPY ... PROGRAM in PostgreSQL), file access (the FILE privilege in MySQL), and unreviewed extensions or CLR assemblies
Linked servers, database links and cross-database ownership chaining reviewed wherever privilege crosses a trust boundary
Separation of duties: the people who administer a database are not the only ones who can read or alter its audit trail

Auditing and logging

Authentication successes and failures, privilege changes and schema changes logged on every instance
Access to sensitive tables logged at a level you can afford to keep, using pgAudit, SQL Server Audit, Oracle Unified Auditing or MongoDB auditing
Logs shipped off the host to a store that database administrators cannot modify
Alerts for bulk exports, new privileged accounts, disabled auditing and logins from unexpected networks
Retention that matches your incident response needs and regulatory obligations

Backup security

Backups and snapshots encrypted, with access to the keys reviewed separately from access to the backups
No public snapshots, and cross-account or cross-project sharing limited and logged
Dumps and exports kept off laptops, file shares and broadly readable object storage
Backups protected from deletion by the credentials that run production, through immutability or a separate account
A recent test restore, with a measured time to recover

Patch level and lifecycle

Engine versions checked against vendor support lifecycles, with an upgrade path for anything past end of life
Security patches applied within a defined window, including drivers, extensions and connectors
Managed-service maintenance windows and minor-version upgrades on a schedule someone owns
Operating system and container image patching on self-managed hosts

Configuration against CIS Benchmarks and vendor guidance

CIS Benchmarks for Oracle MySQL, PostgreSQL, Microsoft SQL Server, Oracle Database and MongoDB, scored and then reviewed by hand for context
Redis: protected mode left on, named ACL users instead of one shared requirepass password, and ACL rules (Redis now deprecates renaming commands) that deny CONFIG, MODULE and FLUSHALL to applications
Elasticsearch: the security features it has configured automatically on first start since version 8.0 left enabled, TLS on the HTTP and transport layers, anonymous access off, and the elastic superuser kept out of applications
MongoDB: authorisation enabled, bindIp restricted to the interfaces clients use, and server-side JavaScript disabled where nothing needs it
Oracle Database: default accounts locked, Unified Auditing configured, and the output of Oracle's Database Security Assessment Tool (DBSAT) reviewed with you

Data classification and masking

Sensitive columns found and tagged: card data, credentials, national identifiers, health and financial records
Dynamic or static masking for support, analytics and development access
Production copies in staging, test and analytics environments found, then masked or removed
Data kept beyond its purpose identified for deletion

Injection resilience from the application side

Queries built with bound parameters or a safe ORM API, and every raw-query escape hatch reviewed by hand
MongoDB operators such as $where, and aggregation stages built from user input, checked for operator injection
Stored procedures that assemble dynamic SQL from their inputs
Least privilege as the backstop: what an injected query could read, change or execute with the application's account
Database errors that leak SQL, schema or driver details to users

Secrets in connection strings

Credentials removed from source code, container images, CI logs and configuration repositories, history included
Secrets held in a cloud secret manager or vault and fetched at runtime, with rotation that does not need a deployment
Short-lived credentials or IAM authentication wherever the platform supports them
Connection strings that disable TLS or certificate verification

Managed cloud databases

Amazon RDS and Aurora: public accessibility off, IAM database authentication, TLS enforced in the parameter group, encrypted snapshots, and no public or unexpected cross-account snapshot sharing
Google Cloud SQL: private IP or the Cloud SQL Auth Proxy instead of broad authorised networks, an SSL mode that refuses unencrypted connections, IAM database authentication, and customer-managed keys where policy requires them
Azure SQL: Microsoft Entra authentication, the firewall exception that admits all Azure services reviewed, private endpoints, auditing, and ownership of the transparent data encryption keys
MongoDB Atlas: an IP access list free of 0.0.0.0/0, private endpoints or peering, database users scoped per application, MFA on Atlas accounts, and database auditing where the cluster tier supports it
Control-plane logging (AWS CloudTrail, Google Cloud Audit Logs, the Azure activity log, the Atlas activity feed) for changes to database resources, with alerts when an instance is made public, a snapshot is shared, auditing is switched off or an administrator password is reset

What we find most often

Anonymised patterns that recur in audits of this kind, with the severity they usually carry and the change that closes each one.

Critical Search cluster or cache open to the internet
An Elasticsearch, OpenSearch or Redis instance on a public address without authentication, holding a copy of customer data that was only ever meant to be an index or a cache.
Fix: Take it off the public network today, turn on authentication and TLS, and check its logs for access you cannot explain, which would make it an incident.
Critical Application connects as the superuser
The production application uses the database owner or superuser account, so a single injection flaw becomes full read and write access and, on some engines, command execution on the host.
Fix: Create a least-privilege role for each service, move ownership and DDL to a migration account used only at deploy time, and rotate the old credentials.
High Shared logins and no audit trail
Engineers and support staff share one read-write account and audit logging is off, so nobody can say who exported a table or when.
Fix: Issue personal accounts through single sign-on or IAM authentication, enable audit logging for sensitive tables, and ship the logs off the host.
High Unmasked production copies in staging
Full production data restored into staging or analytics, where access control, monitoring and patching are all weaker than in production.
Fix: Mask or synthesise data for lower environments, and delete the existing unmasked copies along with their snapshots.
High Password still in the repository history
A production connection string was committed, deleted later, and survives in the history of the repository and its clones; the password was never changed.
Fix: Rotate the credential first, then move secrets into a manager and add secret scanning to every pull request.
Medium TLS offered but not required
The server accepts encrypted connections but also plaintext ones, and clients connect without verifying the certificate, so protection depends on every client being configured correctly.
Fix: Require TLS on the server and certificate verification in every client, then confirm from connection metadata that nothing still connects in plaintext.
Medium Snapshots shared more widely than the database
Access to the live database is tightly controlled, but its snapshots are shared with other accounts or projects, and whoever can restore one has the whole data set.
Fix: Remove unnecessary shares, encrypt snapshots with keys whose policy you control, and alert on new share events.
Low Stale accounts and grants
Accounts for leavers, retired services and one-off migrations still exist with their grants intact: each one is a working login that no current person or system owns.
Fix: Remove them, then reconcile database accounts against your identity provider on a fixed schedule.

What you receive

Instance inventory with data classification, owner and exposure for every engine, replica, snapshot and backup location
Benchmark scorecard per instance, against the CIS Benchmark or vendor guidance, with each deviation judged in the context of your environment
Effective-privilege map showing who and what can read, change or export sensitive data, inherited access included
Ranked findings naming the exact parameter, grant, network rule or connection setting to change, and the side effects to expect
Logging and alerting recommendations sized to what you can store and have staff to review
Walkthrough with your DBAs or platform team, and a free retest of every fixed finding within 30 days of report delivery, with the report reissued

Scan, audit, penetration test or red team?

Four kinds of assessment that are often confused. They answer different questions, and most security programmes need more than one.

The tinted Security audit column is the service on this page. Scroll the table sideways to compare all four.

How a vulnerability scan, a security audit, a penetration test and a red team differ
Dimension	Vulnerability scan	Security audit	Penetration test	Red team
Purpose	Find known vulnerabilities and misconfigurations quickly and repeatedly.	Measure configuration, code and controls against a named standard, and prove each result with evidence.	Show what an attacker can achieve within a defined scope.	Test whether your people, detection and response stop a realistic adversary pursuing an objective.
Method	Automated tools matching signatures and versions, with no human judgement unless someone triages the output.	Read-only review of settings, grants, code and evidence, with tools for coverage and people for judgement.	Manual, adversarial testing that chains weaknesses together, with automation used only for coverage.	A covert, objective-led campaign across technical and human attack paths, run against live defences.
Depth	Broad and shallow: everything it can reach, nothing it cannot recognise.	Broad and deep on configuration: every instance, setting and control in scope.	Deep on exploitable paths within scope; less exhaustive on configuration.	Narrow and deep: a few paths to one objective, followed as far as they go.
Access needed	Network reachability, plus credentials for authenticated scans.	Read-only accounts, configuration exports, repositories or dashboards that you grant.	Test accounts and an agreed scope; sometimes source code or architecture notes.	A signed objective and a small group who know; as little insider information as possible.
What you receive	A machine-generated list, often long, ranked by generic severity.	Ranked findings mapped to the standard, each with the setting or line to change, plus a coverage matrix.	Exploited findings with reproduction steps, evidence, business impact and fixes.	An attack narrative and timeline set against what your team detected, missed and how quickly it responded.
Typical duration	Minutes to hours, repeated on a schedule.	Three to fifteen working days, depending on the estate or the codebase.	One to two weeks for most single applications or networks.	Several weeks, including planning and the debrief.
Best when	You need continuous hygiene between deeper assessments.	You need assurance against a standard, a baseline before testing, or evidence for a customer or an auditor.	You need to know whether an attacker can get in or escalate, before a launch or a deal.	You have a working security function and want to know whether it holds under pressure.
Standards	Vulnerability feeds identified by CVE and scored with CVSS.	OWASP ASVS 5.0, CIS Benchmarks, PCI DSS v4.0.1 and vendor hardening guides.	PTES, NIST SP 800-115, the OWASP Web Security Testing Guide and MITRE ATT&CK.	MITRE ATT&CK and threat-led frameworks such as TIBER-EU.
What it will not tell you	Whether a finding is exploitable, or anything about business logic and access control.	Whether a determined attacker can chain the gaps together; that is the test's job.	Whether your team would detect and contain the attack while it is happening.	Every weakness in scope: it follows the shortest path to its objective.

Questions buyers ask

How is a database audit different from a penetration test?

A penetration test asks whether an attacker can reach your data. A database audit asks what happens once someone, attacker or insider, has a foothold or a valid account: it reviews every instance's configuration, grants, logging and backups against a benchmark, which an external test rarely sees. They work well together: a network penetration test or a cloud configuration review shows the paths in, and the audit shows how far each path reaches.

Will you need to see our data?

No. We need a read-only account that can see configuration, users, roles, grants and audit settings, not table contents. Where classification needs a closer look, we review column names and types, or run counts and pattern checks you approve, and record exactly what was queried.

Can you audit managed databases such as Amazon RDS, Cloud SQL, Azure SQL or MongoDB Atlas?

Yes. With a managed service much of the risk moves to the control plane: who can change network rules, share snapshots, reset the administrator password or switch off auditing. We review that configuration and its IAM alongside the engine settings that remain yours.

Is a CIS Benchmark score enough for our auditors?

A score is where the audit starts. Benchmark tools check settings without knowing your architecture, so some failures are irrelevant and some passes hide real exposure. We report the score for traceability, then explain which deviations matter and why.

Will the audit affect database performance?

Configuration capture is a handful of read-only queries and API calls. Anything heavier, such as measuring audit-log volume or sampling query plans, is scheduled with you and run against a replica where one exists.

Which regulations does this help with?

Most frameworks covering personal or payment data expect you to restrict access, log it and protect backups, which is what this audit evidences. In Israel, the Data Security Regulations require a database at medium or high security level to have an automated mechanism that logs access to its systems, with the records kept for at least 24 months (Regulation 10), and an audit at least once every 24 months by an auditor trained in data security who is not the database's own data security officer (Regulation 16); this report gives that auditor the configuration, privilege and access-logging evidence. For PCI DSS v4.0.1 the findings map to requirements 3, 7, 8 and 10; for other frameworks, including those that apply in the EU, see the compliance overview.

Scope your database security audit

A 45-minute scoping call ends with a fixed quote and a proposed start date; the written scope follows by email. On the call we agree the estate, the standard and the access.

Scope an engagement How the scoping call works