Most database exposure is not exotic. It is a service account with more rights than anyone remembers granting, a database that never had transparent data encryption switched on, and audit logging that captures everything except the events an investigator would ask for. A security assessment finds those before an auditor or an attacker does.
Read-only. Nothing is changed, and no exploitation is attempted.
Why it matters
Most database exposure is configuration rather than exploitation, which is why it survives the tests that look for exploitation.
A service account with more rights than anyone remembers granting. A database that never had transparent data encryption switched on. Audit logging that captures everything except the events an investigator would ask for.
Misconfigurations, inherited permissions, and logging gaps sit below the layer a penetration test reaches. Nothing is exploited in this assessment and nothing is changed, which is what lets it examine the environment as configured.
They rarely ask whether a system can be broken into. They ask who has access, how it was granted, when it was last reviewed, what is encrypted, and where the log of all of that is kept.
A database security assessment is a structured review of how a database environment is configured, who can reach it, how the data is protected, and what evidence exists that both are true. Fortified Data evaluates five areas: security configuration, access control and authorization, data protection and encryption, auditing and monitoring, and vulnerability management. It produces risk-rated findings, remediation steps for each, and a gap analysis against security best practice and the compliance requirements in scope for the data.
It is a controls assessment rather than a penetration test. Nothing is exploited and nothing is changed. The environment is examined as it is configured, which surfaces the misconfigurations, inherited permissions, and logging gaps a perimeter test never reaches because it stops at the application.
The distinction matters when an audit is the reason for the engagement. An auditor rarely asks whether a system can be broken into. They ask who has access, how it was granted, when it was last reviewed, what is encrypted, and where the log of all of that is kept. Those are configuration questions, and this is the assessment that answers them in writing.
Five areas, assessed in one engagement. Each finding carries a risk rating and a remediation step rather than a note that a control is absent.
Database server hardening against a configuration baseline, the authentication mechanisms in use and the password policy behind them, and how service accounts and encryption keys are configured. Default configurations that were never changed after install are the most common finding in this area.
How role-based access control is actually implemented rather than how it is documented, how users are provisioned and, more importantly, de-provisioned, how privileged access is managed and whether segregation of duties survives contact with the on-call rota, and what administrators can reach.
Encryption of data at rest and in transit, key management practice, transparent data encryption configuration, and whether column-level and row-level security are used where the data classification calls for them.
What audit logging is configured to capture and what it silently does not, how long logs are retained and where, the security monitoring built on top of them, the compliance reporting they feed, and whether an incident response procedure exists that references the database layer at all.
Vulnerability scanning coverage, the patch management process and how far behind it is running, protections against SQL injection at the database layer, and backup security, including whether a restore has ever been tested rather than only scheduled.
One database security assessment report, written so the remediation work can be planned from it without a second discovery exercise.
Every identified vulnerability rated for risk, taking account of what the data is and who can currently reach it, so a low-severity finding on a regulated table is not filed below a high-severity finding on a test copy.
A specific action for each finding, with the effort it involves and the order to do them in. The list is written so that an internal team can execute it without further consulting input.
Current state measured against security best practice and against the compliance requirements in scope for the data, with each gap tied to the control it fails and the evidence needed to close it.
Financial services
From a Fortified Data assessment engagement in financial services. Backups had reported success nightly for long enough that nobody questioned them.
The assessment is run by consultants whose daily work is inside these platforms. Database security lives in permissions, configuration, and encryption settings that a general security review treats as out of scope.
SQL Server, Azure SQL, Oracle, PostgreSQL, and MySQL assessed by the same team. A mixed estate gets one consistent risk picture instead of four reviews written to different standards.
Healthcare, financial services, and retail engagements, where the assessment has to produce evidence an auditor will accept rather than a technical opinion.
Each finding carries a remediation step and an effort estimate, so the report converts into a work plan rather than into a follow-on scoping engagement.
Fortified Data sells no security tooling. Where a control gap is closed by configuration rather than by a purchase, the report says so, which is more often than a vendor assessment tends to find.
The assessment and the report are produced by an onshore team, which matters when the engagement involves access to regulated data.
Written to be handed over
A finding is useful internally. Evidence is what an auditor, a regulator, or an enterprise customer's security questionnaire actually requires, and it is a different document. The gap analysis is written against the frameworks in scope for your data, and these are the five it most often has to serve.
No. A penetration test attempts to break in and reports what succeeded. A Fortified Data database security assessment examines how the environment is configured, who holds which rights, what is encrypted, and what the audit trail would actually show, and reports the gaps whether or not anyone has exploited them. Nothing is exploited and nothing is changed during the assessment. The two are complementary, and the assessment is the one that answers an auditor's questions.
The Fortified Data database health check covers security as one of six areas and reports the significant risks in it. The database security assessment covers five security areas in the depth that an audit or an incident review requires, including privileged access and segregation of duties, key management and transparent data encryption configuration, audit log coverage and retention, and patch currency. Organizations that need breadth start with the health check. Organizations answering to an auditor need this one.
Findings are mapped to the frameworks in scope for your data, which for most Fortified Data clients means HIPAA, SOC 2, PCI DSS, SOX, or GDPR. The assessment reports how the database layer measures against the control expectations those frameworks set and what evidence exists to demonstrate it. Fortified Data does not issue certifications or attestations, and the report is written to support an audit rather than to replace one.
It requires read access to configuration, permissions, and audit metadata in the environments being assessed, which is normally production, because a non-production copy rarely shares its access model. Fortified Data collects and analyzes that information without modifying anything, which is what allows the assessment to run outside a change window.
A critical exposure is raised as soon as it is confirmed rather than held for the final report. The written finding, its risk rating, and its remediation step still appear in the report, so the audit trail is complete, but nobody waits for a document to learn that a privileged account is open.
Yes, and the report is written for that. Each finding carries a specific remediation step, the effort it involves, and the order to work through them in. A significant share of database security findings are configuration changes rather than purchases. Where the remediation work is larger than the team can absorb, Fortified Data can deliver it as a consulting engagement, and that is a separate decision made after the report.
The assessment stands on its own. If the remediation list is larger than the team can absorb, these are the routes.
We run your environment, with 24/7 monitoring, maintenance, and proactive improvement.
A guaranteed 15-minute emergency response plus monthly on-demand hours that bank when unused.
Project-based engagements for migrations, performance tuning, data modernization, business intelligence, and high availability and disaster recovery.
A database security assessment gives you risk-rated findings across configuration, access, encryption, auditing, and patching, a remediation step for each, and a gap analysis you can put in front of an auditor.
Let us show you what's possible.
Two ways to start
Read-only. Nothing is changed, and no exploitation is attempted.