ASD ISM 1536Central Logging of Software Database Queries and Errors
Official control statement
All queries to databases from software, and any resulting crash or error messages, are centrally logged.
Quoted as published. Everything else on this page is written by Control Stack.
In plain English
Every query your applications send to a database, plus any crash or error it produces, must land in a central log store rather than being scattered or lost.
What this means in practice
Applications talk to databases constantly: reading records, writing updates, running searches. This control says two things about that traffic. First, every query that software sends to a database must be logged. Second, any crash or error message that comes back from those queries must be logged too. And both must go to a central place, not sit on individual servers or inside the database engine's own local files. Why does that matter? Database errors are often the first visible sign of an attack. SQL injection attempts typically generate malformed queries and a burst of syntax errors before an attacker finds one that works. A compromised application account may start issuing queries it never normally runs, such as bulk reads of a whole customer table. If those queries and errors are only kept locally, an attacker who has already reached the server can delete them, and your security team may never see them at all. Central logging fixes both problems. The records are copied off the system that generated them, so they survive tampering or a crash, and they sit alongside your other logs where analysts and monitoring tools can correlate them. It also gives developers and operators a single place to reconstruct what an application actually asked the database to do when something went wrong.
Framework
ASD Information Security Manual (ISM)
Control effect (Control Stack)
Detective
Classifications
NC, OS, P, S, TS
ISM last updated
Sept 2026
Control Stack last updated
29 Sept 2026
E8 maturity levels
N/A
Guideline
Guidelines for software developmentTopic
Software interaction with databases
Why it matters
Without central logging of database queries and their errors, injection attacks, credential misuse and unauthorised data access can proceed undetected, because the tell-tale malformed queries and error bursts are never seen by anyone. When an incident is discovered, investigators cannot reconstruct which records were queried, changed or extracted, so the organisation may be unable to scope a breach, meet notification obligations or prove what data was affected. Locally held logs can also be altered or destroyed by an attacker with access to the server, or simply lost when the application crashes, leaving no reliable record at all.
Operational notes
Day to day, this control lives in three places: the application code or database driver that emits query and error events, the forwarding agent or connector that ships them to the central log platform, and the central platform itself.
Query logging can be voluminous. Operations teams usually need to agree a format that captures the query text, the calling application, the database and account used, the timestamp and the outcome, while handling volume through structured logging, compression and appropriate retention tiers. Every query must still be logged, so do not sample. Sensitive values embedded in queries (passwords, personal data in WHERE clauses) should be masked or parameterised so the log itself does not become a data leak.
Errors and crashes deserve particular care. Make sure that exceptions thrown by the database driver, connection failures, timeouts and the database engine's own error responses are all captured, not just the successful queries. Stack traces from application crashes triggered by database calls should be forwarded as well.
Watch for silent gaps: a new microservice that was never wired to the forwarder, a log agent that stopped after a patch, or a developer who changed the logging level to reduce noise. Regular checks that each application known to talk to a database is actually producing entries in the central store are the simplest way to keep coverage complete.
Implementation tips
- Application owners: inventory every piece of software that connects to a database and record which database, connection account and data access layer (ORM, driver or stored procedure interface) each one uses, so nothing that issues queries is missed from the logging design.
- Developers: enable query logging at the data access layer (for example ORM statement logging or a database driver interceptor) and configure it to emit each executed query with timestamp, application name, database, account, and outcome, in a structured format such as JSON, with sensitive parameter values masked.
- Developers: add global exception handling around database calls so that driver exceptions, connection failures, timeouts, database engine error codes and any resulting application crash or stack trace are written to the same log stream as the queries that caused them.
- Platform or logging engineers: install and configure a log-forwarding agent (or native integration) on each application host, container or serverless function so that query and error logs are shipped in near real time to the organisation's central log platform, and confirm delivery with a test query and a deliberately failing query.
- Operations team: build a coverage check on the central platform that lists each database-connected application and alerts when one stops sending query or error events for a defined period, and add this check to the onboarding checklist for any new application or service.
Audit / evidence tips
- AskAsk for the list of applications that connect to databases and the logging design or standard that applies to them.Look atCheck that the design explicitly requires logging of every query issued by software and of any crash or error message that results, and that it names the central destination.GoodA documented standard covers all database-connected applications, requires both queries and resulting errors or crashes to be logged, and points to a single central log platform.
- AskAsk to see the logging configuration for a sample of applications, such as ORM or driver settings and exception handling code.Look atConfirm that query logging is switched on, that database exceptions and errors are caught and written to the log, and that entries are sent to the forwarder rather than only to a local file.GoodConfiguration and code show statement logging enabled and error handlers in place, with output routed to the central logging agent for each sampled application.
- AskAsk for a live search in the central log platform for a specific application's database activity over a recent period.Look atLook for actual query entries from that application, and separately for error or crash entries, with timestamps, application name, database and account identified.GoodBoth queries and errors from the chosen application are visible in the central platform, arriving close to real time, with enough detail to identify who ran what against which database.
- AskAsk the team to demonstrate a deliberately failing database call in a test environment and then show it in the central logs.Look atCheck whether the error message, and any crash or stack trace it produced, appears centrally along with the query that triggered it.GoodThe induced error is found in the central log store within minutes, showing the offending query and the resulting error message or crash details.
- AskAsk how the organisation confirms that every database-connected application is still sending logs centrally.Look atLook for a coverage report, heartbeat check or alert that fires when an application's query or error logs stop arriving, and for evidence it has been acted on.GoodA recurring coverage check compares the application inventory against log sources and raises alerts for gaps, with records showing gaps were identified and closed.
Cross-framework mappings
How ISM-1536 relates to controls across ISO/IEC 27001, ISO/IEC 42001, Essential Eight, and ASD ISM.
ISO 27001
| Control | Notes | Details |
|---|---|---|
layersPartially meets(1)expand_less | ||
| Annex A 8.15 | ISM-1536 requires central logging for all software-to-database queries and any resulting crash or error messages | |
E8
| Control | Notes | Details |
|---|---|---|
handshakeSupports(1)expand_less | ||
| E8-MF-ML2.9 | ISM-1536 requires central logging of all software database queries and the resulting crash or error messages | |
These mappings show relationships between controls across frameworks. They do not imply full equivalence or certification.
Related ASD ISM controls in Software development
See all Guidelines for software development controls, or browse the full ASD ISM library.