ASD ISM 1911 Centralised logging of software errors and usage
What it says
Security-relevant usage, error messages and crashes for software are centrally logged.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishImportant software activities and errors are logged to a central system for security tracking.
This control is about keeping track of what goes right and wrong in your software by logging errors and important activities to a central location. It matters because if you're not aware of issues, you can't fix them, which can lead to bigger problems like data breaches or software failures that disrupt your business.
Free. Save your status, tasks and notes.
Why it matters
Without centralised logging of software errors, crashes and security-relevant usage, incidents may go unseen, delaying detection and causing outages or data compromise.
How to implement
The IT team should set up a central logging system where all software errors and important usage events are recorded.
This can be done by integrating logging tools that collect and send data from each software application to a main server where it can be reviewed.
Managers should ensure that their teams understand the importance of logging software issues.
They can achieve this by organising regular training sessions that explain how logging helps catch errors early and prevent larger security incidents.
IT staff should configure alert mechanisms within the logging system to notify them when certain types of errors or unusual activities occur.
This involves setting specific criteria for notifications and ensuring these alerts go to the person who can address the issue immediately.
Software developers should work with the IT team to identify which activities and errors are security-relevant and need to be logged.
This requires reviewing the software's use cases and potential vulnerabilities to decide what needs to be monitored.
HR should encourage an organisational culture that reports software issues quickly.
This can be fostered by setting up a simple process for staff to report problems, ensuring they know how to do it, and reassuring them that it's a positive step to improve overall security.
Keep it running
Configure software to forward errors, crashes and security-relevant usage events to a central log store; monitor/alert on patterns and investigate anomalies promptly.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
The central logging policy document: Request the policy that outlines how software error and usage logging is handled.
Look at
Descriptions of what should be logged and who oversees reviewing these logs.
Good evidence
Includes a clear responsibility matrix and detailed logging instructions.
- Check 2 of 5What an auditor asks for
Ask for
Access to the central logging dashboard.
Look at
The configuration to ensure that critical software events are logged and accessible by authorised team members.
Good evidence
Shows a clean interface where different types of events can be reviewed.
- Check 3 of 5What an auditor asks for
Good evidence
Will have logs with consistent detail that allows for effective issue tracing.
- Check 4 of 5What an auditor asks for
Ask for
A record of alerts triggered by logging: Look to see if the alerts have effectively notified relevant staff about issues.
Good evidence
Would contain a list of alerts with follow-ups showing resolution steps.
- Check 5 of 5What an auditor asks for
Look at
Evidence that staff have received training on how to report and respond to logged events.
Good evidence
Includes dated training materials and sign-off sheets from attendees.
Mappings
Closest match in ISO/IEC 27001: A.8.15, Logging of activities and events, which this control partially meets.
ISO/IEC 27001: 2 mappings
This control partially meets A.8.15.
ISM-1911 requires the centralisation of security-relevant software usage, error messages, and crashes. ISO/IEC 27001:2022 Annex A 8.15 mandates the production, storage, protection, and analysis of activity logs, exceptions, and faults generally. ISM-1911's specific focus on software centralisation is encompassed within the broader requirements of Annex A 8.15.
This control supports A.8.16.
ISM-1911 mandates centralised logging of software usage, errors, and crashes, which aids the monitoring and evaluation of anomalies under ISO/IEC 27001:2022 Annex A 8.16. While the latter requires broader monitoring, logging as per ISM-1911 supports identifying anomalous behaviour.
ASD Essential Eight: 3 mappings
This control supports E8-AC-ML3.4.
E8-AC-ML3.4 requires organisations to analyse event logs from non-internet-facing servers in a timely manner to detect cyber security events. ISM-1911 supports this by ensuring software usage, errors and crashes are centrally logged, providing the raw log data needed for meaningful analysis. Without ISM-1911-style log capture/centralisation, E8-AC-ML3.4 analysis may be incomplete or ineffective, though E8-AC-ML3.4 extends beyond software error/usage logs to broader server event logging.
This control supports E8-AH-ML2.15.
E8-AH-ML2.15 requires timely analysis of cyber security events to identify incidents. ISM-1911 requires centralised logging of security-relevant software usage, error messages and crashes, which increases visibility and creates a consolidated event dataset that can be analysed to identify incidents. ISM-1911 is about collecting and centralising a particular category of logs, while E8-AH-ML2.15 is about analysing events (from any source) quickly to determine whether they constitute an incident.
- E8-MF-ML3.4Analyse event logs from non-internet-facing servers timely to detect security eventsSupports
This control supports E8-MF-ML3.4.
E8-MF-ML3.4 requires timely analysis of event logs from non-internet-facing servers to detect cyber security events. ISM-1911 requires central logging of security-relevant software usage, errors and crashes, which can be key event sources residing on internal servers and needed for effective analysis. ISM-1911 is about ensuring relevant logs are captured centrally, while E8-MF-ML3.4 is about the monitoring/analysis activity performed on those logs.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.