Logging is one of the best tools we have for investigating database security incidents.
It can also become a new sensitive-data repository if teams record everything indiscriminately.
India's CERT-In directions require covered entities such as service providers, intermediaries, data centres, body corporates, and government organisations to enable logs of ICT systems and securely maintain them for a rolling period of 180 days within Indian jurisdiction.
I do not interpret that as an instruction to copy every piece of personal data into logs.
Good security logging records enough evidence to reconstruct important activity without turning the logging platform into a second uncontrolled database.
Log the event, not the entire customer record
Suppose an application queries a customer's account.
For security investigation, I may need to know which application identity connected, when it connected, where it connected from, which database it accessed, whether authentication succeeded, and what privileged activity followed.
I usually do not need the customer's complete profile copied into the log line.
This distinction is fundamental.
Logs should describe activity.
They should not duplicate business data unless there is a specific justified reason.
For organisations using a managed database platform, I would define database audit events alongside application and infrastructure events rather than logging without a data model.
Authentication events matter
I want visibility into successful and failed database authentication.
User or service identity.
Timestamp.
Source system or address.
Destination database.
Authentication result.
Relevant privilege context.
Repeated failures can expose brute-force attempts, broken credentials, or misconfigured services.
Successful access from an unusual source can be even more important.
What I avoid is logging passwords, connection secrets, private keys, or complete authentication tokens.
A log that contains secrets becomes an attack surface.
Privileged actions deserve strong visibility
Routine SELECT activity on a busy application can generate enormous log volume.
Privileged operations are different.
Role changes.
Permission grants.
Database creation.
Schema changes.
User creation.
Security configuration updates.
Backup changes.
Logging configuration changes.
Destructive administrative actions.
I want these events clearly attributable to an identity.
If an attacker obtains administrative access, investigators need evidence of what changed.
Query logging needs judgement
Logging every SQL statement can be useful in specific environments.
It can also capture sensitive values embedded directly in SQL.
A query might contain an email address, phone number, personal identifier, access token, or other data.
I therefore prefer parameterised application queries and logging strategies that separate query structure from sensitive parameter values where possible.
Fingerprinting or query identifiers can help with operational analysis without preserving every literal value.
Network metadata connects the story
Database incidents rarely happen entirely inside the database.
An application host is compromised.
Credentials are used.
Connections reach the database.
Data is queried.
Information leaves through another system.
Network records help reconstruct that path.
That is why I consider cloud networking and security controls part of database observability.
Database logs, firewall events, private-network records, authentication events, and application logs become much more useful when timestamps and identities can be correlated.
Time synchronisation is essential
An incident timeline is useless if every system disagrees about time.
Database server says 10.03.
Application says 10.08.
Network logs say 10.05.
Now the incident team has to guess which event happened first.
CERT-In's directions also address system clock synchronisation.
From an engineering perspective, accurate consistent time is basic observability hygiene.
Protect the logs themselves
Retention creates value only if logs remain trustworthy.
Restrict write and deletion permissions.
Encrypt storage.
Control administrator access.
Monitor attempts to change logging configuration.
Consider immutable or append-oriented storage for important audit data.
Separate ordinary application administrators from people who can erase security evidence where practical.
An attacker who compromises a database account should not automatically gain the ability to delete the logs that record the compromise.
Retention should have an end
If an applicable requirement calls for a rolling 180-day period, I would automate that lifecycle.
Keep the required evidence securely for the required period and delete it according to policy when there is no longer another lawful or operational need.
Keeping security logs forever does not automatically improve security.
It can create a larger archive of sensitive metadata waiting to be exposed.
Minimise PII before collection
The cheapest sensitive log to protect is the one you never created.
I ask teams to review every field.
Do we need a full email address or would an internal user identifier work?
Do we need the request body?
Do we need raw card-related data?
Do we need complete SQL parameters?
Do we need authentication tokens?
Usually, the answer to several of those questions is no.
Good logging is selective.
Capture identity, time, action, source, destination, outcome, privilege changes, security-relevant database events, and enough context to investigate incidents.
Do not use regulatory retention as an excuse to collect unnecessary personal data.
That produces better forensic evidence and a smaller privacy risk at the same time.
Top comments (0)