ASD Essentials IT.DET-01.3 Establish Centralised Event Log Storage Protected from Unauthorised Access and Tampering
What it says
Establish a centralised event log storage capability that protects logs from unauthorised access or modification.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishKeeps event logs in one central store only approved staff can open and no one can tamper with.
Event logs record things such as who signed in, what changed and what ran. They are often key to investigating a break-in. The organisation keeps them in one central store, apart from the systems that create them. To meet this, only security operations and others with a written need can get in, and all access is logged. Logs are protected from tampering and deletion, and kept as long as investigations, laws and contracts require.
Free. Save your status, tasks and notes.
Where this action applies
What's in each domain?Visibility and response: a capability domain, which ASD applies across all phases from the start.
Why it matters
Without a protected central store, an intruder with admin access can erase or fake the record of what they did. Open, unwatched access lets evidence be read or wiped. Without a set retention period, logs can be deleted before a long-running break-in is investigated.
How to implement
The security operations lead should set up a dedicated central log store, such as a log management platform or cloud archive.
List every in-scope system it must hold logs from, and chase any that are missing.
The platform owner should run the store separately from the systems it logs, with its own administrators.
Turn on write-once storage or retention locks, so no one can change or delete stored logs.
The platform owner should encrypt all stored logs, limit who manages the keys, and add integrity checks to every log type.
For example, record a digital fingerprint (hash) of each file and recheck it on a schedule.
The security operations lead should give access only to security operations and other roles with a written need, read-only by default.
Log every sign-in, search and export, and alert on unusual access.
The security lead, with legal and records advisers, should set how long to keep each log type to meet investigation, regulatory and contract needs.
The platform owner then sets the store to match.
Keep it running
The security operations team runs the store, watches for systems that stop sending logs and keeps enough space for the full retention period. Send changes to retention, integrity or access settings through change management. Treat any attempt to alter stored logs or weaken protections as a security event. This action applies organisation-wide, in every priority phase, so set the store up early and extend it as systems come into scope.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Ask for the store's design, the in-scope system list and which systems currently send logs.
Look at
Whether logs sit only on source systems, or listed systems are missing or patchy in the report.
Good evidence
Every listed system is sending logs, and gaps are tracked until fixed.
- Check 2 of 5What an auditor asks for
Ask for
Ask to see a source system administrator try to edit or delete a stored log.
Look at
Whether stored logs can be deleted even where editing is blocked, or some log types are unprotected.
Good evidence
No unauthorised person, including source system admins, can change or delete stored logs of any type.
- Check 3 of 5What an auditor asks for
Ask for
Request the storage encryption settings and the latest integrity check results.
Look at
Whether encryption or integrity checks are missing, unproven or cover only part of the store.
Good evidence
All stored logs are encrypted and integrity-checked, so any unauthorised change would be spotted.
- Check 4 of 5What an auditor asks for
Ask for
Ask for the access list, each role's written need and the store's own access logs.
Look at
Whether live accounts lack a recorded need, access goes unlogged, or large exports raised no alert.
Good evidence
Every live account matches a recorded need, and each unusual access alert was investigated.
- Check 5 of 5What an auditor asks for
Ask for
Ask for the retention requirement for each log type and the retention set in the store.
Look at
Whether retention is defined, and whether the oldest entries show any log type kept too briefly.
Good evidence
Each log type is kept as long as investigation, regulatory and contract needs require.
ASD indicators of good practice (12)
The indicators below are quoted as published from ASD's Assessment evidence guide for enterprise IT. These optional indicators help an assessor judge the action in each domain where it applies: if any not effective statement is true, the action is rated not effective; if every applicable fully effective statement is true and no other statement is, it is rated fully effective; otherwise it is rated partially effective. ASD says the indicators "do not replace expert judgement, nor are they intended to serve as a checklist".
Not effective(4)
- NE-1No centralised capability exists for storing event logs collected from systems across the environment.
- NE-2Stored logs have no protection against modification or deletion by administrators of the systems generating them.
- NE-3Access to the centralised capability is not restricted, or access is granted to roles without a documented need.
- NE-4Log retention requirements are not defined.
Partially effective(4)
- PE-1A centralised capability exists but does not receive logs from in-scope systems, or coverage is inconsistent.
- PE-2Stored logs are protected from modification, but the controls do not consistently prevent deletion, or controls are not applied to all log types.
- PE-3Access is restricted to a defined set of roles but access is not logged or monitored.
- PE-4A retention period is defined but is inconsistently applied, or some log types are retained for shorter periods than required.
Fully effective(4)
- FE-1A centralised event log storage capability is in place for logs collected from in-scope systems.
- FE-2Stored logs are protected against unauthorised access, modification and deletion through technical controls including access restrictions, encryption at rest and integrity protection.
- FE-3Access to the centralised capability is restricted to security operations personnel and other roles with a documented need, with access logged and monitored.
- FE-4Log retention requirements are defined and aligned to investigative, regulatory and contractual obligations, with retention applied consistently across log types.
Mappings
Closest match in ISO/IEC 27001: A.5.33, Protection of Records, which this control partially meets.
ISO/IEC 27001: 3 mappings
This control partially meets A.5.33.
IT.DET-01.3 requires a centralised event log storage capability that protects logs from unauthorised access or modification. As event logs are records, this is a specific case of Annex A 5.33, which requires records to be protected from loss, destruction, falsification, unauthorised access and unauthorised release. Annex A 5.33 applies to all organisational records and a wider set of threats, while IT.DET-01.3 is limited to event logs held in a central store.
This control partially meets A.8.15.
IT.DET-01.3 requires a centralised event log storage capability that protects logs from unauthorised access or modification. This is a specific implementation of the storage and protection elements of Annex A 8.15, which requires logs to be produced, stored, protected and analysed. Annex A 8.15 also covers producing and analysing logs and does not require storage to be centralised.
This control supports A.5.28.
IT.DET-01.3 requires a centralised event log storage capability that protects logs from unauthorised access or modification. Holding logs in a protected central store preserves their integrity so they can be relied on as evidence of information security events, which supports the evidence preservation required by Annex A 5.28. Annex A 5.28 requires procedures for identifying, collecting, acquiring and preserving evidence generally, while IT.DET-01.3 addresses only the secure storage of logs.
ASD Essential Eight: 4 mappings
This control partially overlaps E8-AC-ML2.6.
IT.DET-01.3 requires a centralised event log store that protects logs from unauthorised access or modification; E8-AC-ML2.6 (application control) requires event logs to be protected from unauthorised modification and deletion, overlapping on modification.
This control partially overlaps E8-AH-ML2.13.
IT.DET-01.3 requires a centralised event log store that protects logs from unauthorised access or modification; E8-AH-ML2.13 (user application hardening) requires event logs to be protected from unauthorised modification and deletion, overlapping on modification.
This control partially overlaps E8-MF-ML2.7.
IT.DET-01.3 requires a centralised event log store that protects logs from unauthorised access or modification; E8-MF-ML2.7 (multi-factor authentication) requires event logs to be protected from unauthorised modification and deletion, overlapping on modification.
This control partially overlaps E8-RA-ML2.8.
IT.DET-01.3 requires a centralised event log store that protects logs from unauthorised access or modification; E8-RA-ML2.8 (restrict administrative privileges) requires event logs to be protected from unauthorised modification and deletion, overlapping on modification.
ASD Information Security Manual: 3 mappings
This control partially overlaps ISM-1405.
IT.DET-01.3 requires a centralised event log storage capability that protects logs from unauthorised access or modification; ISM-1405 requires a centralised event logging facility to be implemented, the core of that action without its protection requirement.
This control partially overlaps ISM-1985.
IT.DET-01.3 requires a centralised event log storage capability that protects logs from unauthorised access or modification; ISM-1985 requires event logs to be protected from unauthorised access, covering the access part of that protection.
This control partially overlaps ISM-1988.
IT.DET-01.3 requires a centralised event log storage capability that protects logs from unauthorised access or modification; ISM-1988 requires event logs to be retained in a searchable manner for at least 12 months, adding a retention requirement for stored logs.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.