ASD ISM 1278 Minimise database error information in software
What it says
Software is designed or configured to provide as little error information as possible about the structure of databases.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishSoftware should reveal minimal database structure details in error messages.
When software malfunctions or runs into a problem, it often displays error messages. This control means that these messages should not reveal too much about the database structure behind them. This is important because if attackers know the details of your database, they could exploit its weaknesses, put your data at risk, and potentially cause financial or reputational harm.
Free. Save your status, tasks and notes.
Why it matters
Detailed database errors can reveal schema/table names and queries, enabling SQL injection and leading to data breach and financial loss.
How to implement
IT team should configure error messages: They should ensure that error messages only contain essential information without revealing database details.
This can be done by modifying the software settings or code to show user-friendly error messages instead.
Software developers should review code: Developers need to review and update the software code to suppress detailed database error messages.
This involves checking how the software communicates errors and making adjustments to reduce information leaks.
System owners should liaise with software vendors: They should ask vendors to provide guidance or updates that minimise database error information in their software.
This could include a patch or setting changes in the software configuration.
IT security staff should conduct tests: They should run tests simulating database errors to ensure that only minimal information is displayed.
They can do this by deliberately causing errors in a safe environment and observing the output.
Office managers should ensure staff awareness: They should inform staff about where to report error messages that seem too detailed.
This can help quickly identify and address potential risks if detailed information is being exposed.
Keep it running
Regularly test error handling so DB/schema details are not disclosed to users; send full errors to secure logs for developer triage.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Software error message policy document: Request documentation that outlines how the organisation controls and manages error messages.
Look at
The sections detailing what information should and should not be included in error messages.
Good evidence
Shows clear guidelines limiting sensitive data exposure.
- Check 2 of 5What an auditor asks for
Ask for
A demonstration of error message handling: Request a practical demonstration of how database errors are handled in the software.
Look at
The error messages generated to ensure they do not reveal sensitive database information.
Good evidence
Is generic messages that inform without exposing technical details.
- Check 3 of 5What an auditor asks for
Ask for
Testing records: Request logs or reports from testing where database error message handling was assessed.
Look at
Documented evidence of testing processes and outcomes.
Good evidence
Includes detailed testing records showing compliance with the control requirements.
- Check 4 of 5What an auditor asks for
Ask for
About communication with vendors: Request emails or meeting notes discussing minimising error information with software vendors.
Look at
Evidence of vendor engagement and advice given.
Good evidence
Shows active communication and steps taken based on vendor recommendations.
- Check 5 of 5What an auditor asks for
Ask for
Staff training records: Request evidence of training sessions for staff on reporting overly detailed error messages.
Look at
Training materials and attendance records.
Good evidence
Demonstrates that staff are aware of reporting procedures and can recognise inappropriate error messages.
Mappings
Closest match in ISO/IEC 27001: A.8.25, Secure development lifecycle, which this control partially meets.
ISO/IEC 27001: 2 mappings
This control partially meets A.8.25.
ISM-1278 requires software to be designed or configured to minimise database error information disclosed to users. This relates to Annex A 8.25 because a secure development lifecycle typically includes requirements for safe error handling and information leakage prevention in application/database interactions. Annex A 8.25 is broader across the full SDLC, while ISM-1278 is a specific secure design/configuration outcome focused on database error message content.
This control partially meets A.8.28.
ISM-1278 requires software to avoid exposing database structure details through error messages. This maps to Annex A 8.28 because secure coding practices commonly include controlling exception handling, sanitising error outputs, and preventing information disclosure that could aid attackers. Annex A 8.28 applies broadly to coding principles across the application, whereas ISM-1278 is a targeted requirement specifically about database-related error information.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.