Course Preview

Database Auditing and Compliance

Database auditing records who accessed or changed database resources, what they did, when it happened, and whether it succeeded. Compliance work turns those records into protected, reviewable evidence that specific security and privacy requirements are operating as intended.

itDatabases and data storage | OpenSkills.info

Course pathWalk it in order

Look it upDip in anytime

Go furtherLeaves this page

Don't Panic: Database Auditing and Compliance

Database auditing is the record of activity that matters when somebody needs to establish who did what to a database and when. It exists because a transaction log can help restore data but cannot, by itself, explain accountability. A monitoring dashboard can announce trouble. An audit trail has the less glamorous task of leaving evidence behind after everyone has gone home and remembered their meeting.

The shape to keep is an evidence chain. A requirement becomes a control objective, then an audit policy, then an event record, then protected storage, review, and remediation. Each link has an irritating habit of being necessary. A perfectly configured database switch does not establish that the right events were selected, that records survived delivery, or that anyone reviewed an exception.

The important decision is not which product has the longest feature list. It is what one event source can actually see. Native auditing understands database objects and privileges. A proxy sees only traffic that crosses its path. Cloud logs can show management activity without showing every SQL statement. Application correlation, a shared request value linking application and database events, is needed when connection pooling makes many people look like one database account. The vocabulary is less poetic than it sounds, which is probably for the best.

The surprising part is that more logging can weaken the result. Full SQL text and parameters can contain sensitive data. Broad capture can consume storage, add latency, and hide the few events a reviewer needs in a large pile of technically accurate clutter. The target is enough evidence for the control objective, not a diary written by every query the database has ever considered.

Protection also reaches farther than a retention setting. Immutability, resistance to changing or deleting records under the relevant threat model, fails when an administrator can disable collection, redirect the destination, or suppress an alert before a record arrives. That is why the pipeline, its roles, its clocks, its capacity, and its failure signals belong to the control alongside the records.

Read the Intro for the full data path and its trust boundaries. Open Slides for the source comparison and the fail-open or fail-closed decision. Keep the Cheatsheet nearby when mapping events, testing failures, or assembling a bounded evidence package. The Quiz checks whether the distinctions survive contact with a plausible system. They should. The system may object, but that is what tests are for.

Where this skill leads

Relevant careers

See how this topic contributes to broader role-level skill maps.

Sources