Compliance
NZISM and Essential Eight logging requirements
Neither standard says what most pages say it says. Event logging is not one of the Essential Eight and appears nowhere at Maturity Level One, and NZISM sets no mandatory retention period at all.
Everything below is quoted from v3.9, November 2025 and the November 2023 Essential Eight Maturity Model, with control identifiers and markings as the publishers write them.
Two documents, two different shapes
NZISM is a control catalogue. Every requirement has an identifier, a classification scope and a MUST or SHOULD marking, and you comply with it control by control.
The Essential Eight Maturity Model is a ladder. It has no control identifiers at all. Its logging bullets are ASD Information Security Manual controls wearing an “Essential 8” tag, which is why you can reach a maturity level and still not have met the ISM's logging chapter.
Vendor pages flatten both into “the standard requires centralised logging.” Neither one says that in the way the flattening implies, and the differences are where the cost sits.
What the Essential Eight actually requires, level by level
Maturity Level One
Nothing. There is no event-logging requirement at ML1 at all.
Maturity Level Two
Six event classes become centrally logged, and “Event logs from internet-facing servers are analysed in a timely manner to detect cyber security events.”
Maturity Level Three
The same six classes, with the analysis scope widened: non-internet-facing servers and workstations are added. No new event classes, and still no retention period.
The six classes, verbatim
-
“Successful and unsuccessful multi-factor authentication events are centrally logged.”
-
“Privileged access events are centrally logged.”
-
“Privileged user account and security group management events are centrally logged.”
-
“Allowed and blocked application control events are centrally logged.”
-
“PowerShell module logging, script block logging and transcription events are centrally logged.”
-
“Command line process creation events are centrally logged.”
Note what is not on that list: no retention period, at any maturity level. The word “retained” appears in the Maturity Model only under regular backups.
What NZISM actually requires
From Section 16.6 — Event Monitoring, Logging and Auditing. Read the marking and the classification scope together — several of the strongest controls apply only at Top Secret, Secret and Confidential.
“Event logs MUST be archived and retained for an appropriate period as determined by the agency.”
“Disposal or archiving of DNS, proxy, event, systems and other operational logs MUST be in accordance with the provisions of the relevant legislation.”
“Agencies SHOULD retain DNS, proxy and event logs for a minimum of 12 months.”
“Event logs MUST be protected from: modification; unauthorised access; and whole or partial loss within the defined retention period.”
“Agencies MUST maintain system management logs for the life of a system.”
Retention: three answers, and the 18-month figure is in none of them
NZISM sets no period. It mandates that logs be archived and retained “for an appropriate period as determined by the agency”, and separately mandates that disposal and archiving comply with relevant legislation — so the binding period may come from statute rather than from NZISM. The only number in section 16.6 is a Should: twelve months, for DNS, proxy and event logs.
The Essential Eight sets no period either, at any maturity level.
The ASD ISM does. ISM-1988: “Event logs are retained in a searchable manner for at least 12 months.” Two things about it matter. “In a searchable manner” is load-bearing — moving logs to cold archive does not satisfy it. And ASD tags the control “Essential 8: N/A”, so reaching Maturity Level Three does not mean you have met it.
Where does “18 months” come from, then? Not from New Zealand. The strings “18 month” and “eighteen month” appear nowhere in NZISM v3.9 — we searched the full document. The figure traces to ASD's ISM-0991, an Australian control covering DNS and web proxy logs, which ASD rescinded in December 2024. A page telling you New Zealand requires 18 months is quoting a retired control from another country.
What to ingest first
Ordered by how many catalogues name the source and at what strength. Where only one framework names something, that is said — the asymmetries are the useful part.
Authentication events, successful and unsuccessful
- New Zealand
- Named in 16.6.10.C.02 (Should, All Classifications) and mandatory at Top Secret, Secret and Confidential under 16.6.9.C.01.
- Australia
- ML2: multi-factor authentication events, successful and unsuccessful, centrally logged.
The only class both catalogues name that the Essential Eight also requires at ML2. If you ingest one thing, ingest this.
Privileged operations and failed privilege escalation
- New Zealand
- Named in 16.6.10.C.02 — “all privileged operations” and “failed attempts to elevate privileges”.
- Australia
- ML2: privileged access events centrally logged.
Both name it, and it is the class that distinguishes an intruder from a user.
Account and security group changes
- New Zealand
- Named in 16.6.10.C.02 under system user and group administration.
- Australia
- ML2: privileged user account and security group management events centrally logged.
Persistence is usually visible here before it is visible anywhere else.
Application control decisions, allowed and blocked
- New Zealand
- Not named as its own class in 16.6.
- Australia
- ML2: allowed and blocked application control events centrally logged.
An asymmetry worth knowing: this is an Australian requirement with no direct New Zealand equivalent. Blocked events alone are not enough — ASD asks for both.
PowerShell module, script block and transcription events
- New Zealand
- Not named as its own class in 16.6.
- Australia
- ML2: centrally logged.
Also Australia-only. Script block logging is the one most often enabled and then never forwarded.
Command line process creation
- New Zealand
- Not named as its own class in 16.6.
- Australia
- ML2: centrally logged.
Australia-only, and the highest-volume item on this list by a wide margin — which is where a metered licence starts making the decision for you.
Command line process creation is the highest-volume item on that list by a wide margin, which is where a metered licence starts making the prioritisation decision for you. That is a commercial constraint arriving disguised as a technical one — how your SIEM is metered determines whether you get to follow the guidance.
What this page does not claim
-
That WitFoo produces NZISM or Essential Eight control reporting. It does not. This page is a reading of two public documents, not a product claim.
-
That reaching a maturity level or satisfying section 16.6 makes you compliant. Both standards are broader than logging, and an accreditation decision is not ours to make.
-
That this replaces reading the primary sources. Control text is quoted here so you can check it, not so you can skip it — and both documents are revised.
-
That our reading of “in a searchable manner” is ASD’s. That phrase is theirs; the inference that cold archive does not satisfy it is ours, and an assessor may take a different view.
Questions people actually ask
Is event logging one of the Essential Eight?
No. The Essential Eight are eight mitigation strategies, and event logging is not among them. Logging appears inside the Essential Eight Maturity Model as bullets attached to other strategies — and it appears nowhere at Maturity Level One. Six event classes become centrally logged at Maturity Level Two. Maturity Level Three adds no new classes; it only widens the analysis scope from internet-facing servers to non-internet-facing servers and workstations. Anyone telling you the Essential Eight requires centralised logging at ML1 has not read the document.
How long does NZISM require you to keep logs?
NZISM sets no mandatory retention period. Control 16.6.13.C.01 [CID:2028] is a Must at All Classifications and reads in full: “Event logs MUST be archived and retained for an appropriate period as determined by the agency.” The period is explicitly the agency’s to determine. The only number in section 16.6 is a Should — 16.6.13.C.04 [CID:2031], “Agencies SHOULD retain DNS, proxy and event logs for a minimum of 12 months.” Separately, 16.6.13.C.02 is a Must requiring disposal and archiving to comply with relevant legislation, so the binding period may come from statute rather than from NZISM.
Does NZISM require 18 months of log retention?
No. The strings “18 month” and “eighteen month” do not appear anywhere in NZISM v3.9 — we checked the full document. The figure in circulation traces to ASD’s ISM-0991, an Australian control covering DNS and web proxy logs, which ASD rescinded in December 2024. So a page telling you New Zealand requires 18 months is quoting a retired control from another country.
What does the ASD ISM require for retention?
ISM-1988 states: “Event logs are retained in a searchable manner for at least 12 months.” Two things about it matter. “In a searchable manner” is load-bearing — moving logs to cold archive does not satisfy it. And ASD tags the control “Essential 8: N/A”, so it is an ISM obligation rather than an Essential Eight one. ISM-1989 adds that retention follows the National Archives of Australia’s AFDA Express Version 2 minimums, which exceed 12 months for some classes of record.
Does reaching Maturity Level Three mean I have met the ISM’s logging controls?
No, and this is the trap. Every logging bullet in the Essential Eight Maturity Model is an ISM control carrying ASD’s “Essential 8: ML2, ML3” tag — but most of the ISM’s centralised-logging and retention controls are tagged “Essential 8: N/A”, including the 12-month retention control. Maturity Level Three is a statement about eight mitigation strategies, not a statement about the ISM’s event-logging chapter.
What is the difference between a MUST and a SHOULD in NZISM?
A Must is a requirement. A Should is not optional in the ordinary sense — non-compliance has to be risk-assessed, documented and accepted by the Accreditation Authority. Two failure modes follow, and vendor pages usually commit one or the other: treating a Should as a Must and over-engineering, or treating it as a suggestion and leaving no record of the decision. Classification scope matters just as much: several of section 16.6’s strongest controls apply only at Top Secret, Secret and Confidential, and their All-Classifications equivalents are Shoulds.
Collect it all, then decide.
Both standards ask you to prioritise. Neither asks you to prioritise because of what your SIEM charges. WitFoo is licensed flat per appliance with unlimited data rates, so the prioritisation stays a security decision.
Sources: New Zealand Information Security Manual v3.9, November 2025; Essential Eight Maturity Model, Australian Signals Directorate, November 2023; Information Security Manual, September 2026 release. Control text verified against the primary documents on 20 September 2026.