Enable database audit and log exports

Database logging across AWS is one of the better-value controls in the estate. Turning on an audit log or a CloudWatch export costs nothing on the database itself; the only spend is the downstream storage, which for most stores is a few dollars to low tens of dollars a month and is fully controllable through retention policies and log-type selection. There is no compute penalty and no license. So unlike most findings, this is rarely a real cost trade-off; it is close to a free safety improvement on your most sensitive systems.

Frame each failing control as a line on the risk register rather than a compliance checkbox. A production Redshift warehouse or an Aurora cluster holding customer records carries a far higher expected loss if its access cannot be reconstructed than a quiet dev database, yet both show up as a single red finding. Map the failures to the data behind them and prioritise by sensitivity, not by control count.

The one cost lever worth watching is verbosity. A full query log on a busy OLTP cluster can generate hundreds of GB per day, while a sensibly filtered audit stream (connections plus schema and permission changes) is typically one to two per cent of that volume and still satisfies the auditor. The right finance posture is to fund the logging as infrastructure, require a retention policy on every log group, and approve a specific event filter rather than a blank cheque.

Marco brings the database-logging findings to his finance partner ahead of a SOC 2 review, because the report shows a scatter of red across an RDS PostgreSQL instance, an Aurora MySQL cluster, a Redshift warehouse and two OpenSearch domains, most stood up before the team standardised provisioning. The partner's starting point is one of the better-value reads on the board: turning on an audit log or a CloudWatch export costs nothing on the database itself, no compute penalty and no licence, so the only spend is downstream storage, typically a few dollars to low tens of dollars a month per store and fully controllable through retention and log-type selection. Unlike most findings, this is rarely a real cost trade-off; it is close to a free safety improvement on the most sensitive systems the business owns.

The partner then reframes the list by the data behind each store rather than by control count. A production Redshift warehouse or an Aurora cluster holding customer records carries a far higher expected loss if its access cannot be reconstructed than a quiet dev database, yet both show up as a single red finding. The one cost lever to watch is verbosity: a full query log on a busy OLTP cluster can generate hundreds of GB per day, while a sensibly filtered audit stream, connections plus schema and permission changes, is typically one to two per cent of that volume and still satisfies the auditor. So the finance posture the partner lands on is to fund the logging as infrastructure, require a retention policy on every log group as a hard prerequisite, and approve a specific event filter rather than a blank cheque, then prioritise the work by data sensitivity and treat the age of any open logging finding on a regulated store as the metric to escalate on.

The cost model here is asymmetric in a way that is rare for security work. The database side of enabling logging costs nothing, and the storage is small and controllable; leaving it off creates an unbounded tail risk on the most sensitive systems the business owns. Each failing control is a store where a future incident could not be investigated, and while the probability per event is low, the cost when it lands (forensics, breach notification, regulatory penalties) is large and unpredictable.

The one place the cost can run away is verbosity. A full query log on a busy cluster, or an unbounded CloudWatch log group with no retention policy, can turn a few-dollar control into a few-hundred-dollar one. The finance contribution is to approve a specific, compliant event filter rather than blanket logging, and to make a retention policy a hard prerequisite on every log group, not an afterthought.

The finance role is to attach expected loss to each failing store so the work is prioritised by risk, and to treat the age of an open logging finding as the metric. A control this cheap to satisfy should never sit open for weeks on a store holding regulated data; a rising age is the signal to escalate.

Managed databases are where the most sensitive consolidated data usually lives: customer records, financial reporting, search indexes over everything else. Database logging is the record of who connected to those stores and what they ran. The report shows this as a scatter of separate findings across RDS, Aurora, Redshift and OpenSearch, but the question underneath is one: if a credential is misused or data leaves, can we reconstruct what happened?

The leadership question is not "are we compliant today?" It is "if there is ever an incident on one of these stores, do the logs exist to investigate it?" The defensible end state is that every data-bearing store ships its audit and engine logs off the instance by default, with retention matched to the strictest compliance obligation in scope, not switched on after a scanner complains.

This is rarely a cost decision. The database side is free and the storage is small. It is a governance decision about whether audit evidence is produced by design or only when someone remembers to tick the box on a new cluster.

The database-logging findings reached the executive review after a near-miss the team still talks about: a payments worker was corrupting rows, and by the time anyone went to pull the database log to confirm the cause, the read replica had been recycled overnight by unrelated automation and every relevant line was gone, no export to CloudWatch had ever been configured, so a fifteen-minute confirmation became four days of reconstructing the timeline from application logs. The lesson leadership drew was not about that one database. It was that the company runs managed data stores, across RDS, Aurora, Redshift and OpenSearch, that hold its most sensitive consolidated data and cannot say who connected or what they ran, and that every framework the business reports against expects access to those stores to be logged and retained.

So the executive framing settled on a defensible end state: every data-bearing store ships its audit and engine logs off the instance by default, with retention matched to the strictest compliance obligation in scope, produced by design rather than switched on after a scanner complains. The point leadership keeps returning to is that this is the rare class of control where the risk of inaction is severe, no answer to what the attacker touched after an incident, while the cost of action is engineering time plus a small storage bill. The question is not are we compliant today, it is, if there is ever an incident on one of these stores, do the logs exist to investigate it, and is that a provisioning default so it stops recurring.

Nearly every major data-access incident reduces to the same question afterward: what did the attacker actually touch? On a data store with no audit log, that question has no answer, and the organisation is forced into the most expensive possible response. Database logging is the control that makes a narrow, defensible answer possible on the systems where it matters most.

The cost of getting this wrong is large and well documented, while the cost of fixing it is essentially engineering time plus a small storage bill. This is the rare class of control where the risk of inaction is severe and the cost of action is small, which is exactly the trade leadership should be quickest to approve, and quickest to make a provisioning default so it stops recurring.