Minimum Cyber Security Standards

Detect Unusual Behaviour

Organisations have implemented a process to detect abnormal activity within their environments, including actions to enable timely and effective mitigations.

PUBLISHED DATE: 30 October 2025

Intent of this Standard

To minimise the time to detect breaches and compromises, organisations need to be able to proactively monitor for any anomalous or unintended changes or activity within their environment. Early detection will assist in limiting the impact of any breach or compromise and enables organisations to activate steps that facilitate their containment and incident response processes.

For this to be successful, an understanding of the baseline operating environment and behaviour will aid in the early detection and identification of unusual or unexpected behaviour. Establishing and maintaining a baseline for an operating environment, in conjunction with regular reviews, will effectively reduce false-positive detection rates.

The area of anomalous behaviour detection is broad, and this Standard seeks to provide guidance on initial deployments. This Standard addresses the areas of successful and unsuccessful user authentication, privilege escalation, and infrastructure utilisation.

Minimum capability maturity level

We have established criteria within a maturity model to provide clarity, including the expected minimum implementation level, which is CS-CMM 2.

Cyber Security Capability Maturity Model

The requirements are intended to meet and comply with each respective level of maturity. The levels provide a pathway that can be used by agencies to assess themselves against, with a view to improving maturity over time.

Each maturity level builds on the requirement from the preceding level.

Below are the requirements for each capability maturity level for this Standard.

  • CMM 4 Quantitively Controlled
    • Network and infrastructure monitoring is elevated to include per-application identification and trend reporting to identify unusual traffic.
    • Implement advanced baselining and detection techniques, including artificial intelligence/machine learning (AI/ML) analysis of all logs.
    • Auto-mitigations are implemented on systems.
    • Use of the network, systems, and tools are tied to a user's identity.
  • CMM 3 Standardised
    • All environments including cloud are centrally monitored, correlated, and analysed for indicators of unusual behaviour and compromise.
    • Ongoing tuning of indicators is undertaken to reduce the level of false positives.
    • Ongoing updating of baseline activity is undertaken to aid in the identification of exceptions.
    • Monitoring and alerting of infrastructure utilisation, including privileged and standard user activity, server, compute, and network is maintained to identify exceptions in behaviour.
    • Introduce automatic mitigation of known bad scenarios, e.g. ‘impossible travel’.
    • Sufficient resources and capabilities exist to act on alerts as they arise.
  • CMM 2 Planned and Tracked
    • Logs for business-critical and externally facing systems are stored centrally and analysed.
    • A series of indicators is developed and manually applied to the logs for review, including repeated authentication failures and login attempts from unexpected or impossible locations.
    • Use of—and changes to—privileged accounts or protected system files are alerted.
  • CMM 1 Informal
    • Logs are typically not centrally managed and/or contained within individual applications only.
    • Logs are available to be reviewed but are not proactively monitored.
    • Logs that are centrally managed are done so on an ad-hoc/best effort basis.

Focus areas

Focus areas are applicable to the Standard and are provided as a guide and not an exhaustive list. Each agency is best placed to identify areas of relevance.

The focus areas for this Standard are:

  • Corporate network

  • Cloud services

  • Software as a service

  • Bring-your-own-device access

  • Internal systems

  • Domain Naming System (DNS).

Suggested actions

The following list is not exhaustive. Organisations should identify which actions are appropriate to implement the Standard based on their current maturity level. However, the following actions follow good practice guidelines:

  • Development of a baseline of utilisation for infrastructure.
  • Monitoring failed login attempts, privileged operations, failed attempts to elevate privileges.
  • Defining a tiered response plan (based on incident categorisation) to activate if unusual behaviour has been identified.
  • Where possible, automatic responses such as lockouts on pre-determined repeated authentication failures are implemented.
  • Allocating of resources to oversee and administer monitoring, detection and reporting.

Key dependencies

To implement this Standard, there are likely to be requisite measures or technologies in place.

A number of dependencies apply to multiple standards. In general, these dependencies are less technology-specific and relate to business processes.

Key dependencies for this Standard include:

  • Centralised logging with adequate log retention function.
  • Monitoring of infrastructure utilisation, including compute and network, occurs.
  • Assets have been identified and their criticality evaluated.
  • Threat intelligence capability to provide indicators of compromise exists.

Measurable outcomes

To establish whether the Standard is being implemented, the outcomes are a tool an organisation may wish (or already have in place) to measure to help make this determination.

The outcomes have been designed to align with the requirements contained in the maturity level.

Outcomes for this Standard include:

  • An ongoing trend/baseline of utilisation of infrastructure, including network telemetry, is maintained and reviewed against.
  • Maintaining a predefined tiered response plan to identify unusual behaviour exists and is regularly tested and updated when required.
  • Centralised immutable logging capability exists.
  • Proactive monitoring and response to unusual behaviour such as:
    • Security-related system alerts and failures
    • Modifications to permissions or protected system files
    • Repeated login failures
    • Authentication from unexpected or ‘impossible travel’ locations
    • Activities outside of regular business hours
    • Unexpected or unusual network and compute utilisation.
Applicable NZISM controls

The NZISM controls listed below provide additional detail to assist with the implementation of this Standard and meeting New Zealand Government compliance requirements.

  • Control reference - 6.2.5.C.01.

    Agencies SHOULD conduct vulnerability assessments in order to establish a baseline. This SHOULD be done:

    • before a system is first used,
    • after any significant incident,
    • after a significant change to the system,
    • after changes to standards, policies and guidelines, and
    • when specified by an ITSM or system owner.

    CID: 1066

  • Control reference - 16.3.5.C.01.

    Agencies MUST:

    • ensure strong change management practices are implemented,
    • ensure that the use of privileged accounts is controlled and accountable,
    • ensure that system administrators are assigned, and consistently use, an individual account for the performance of their administration tasks,
    • keep privileged accounts to a minimum, and
    • allow the use of privileged accounts for administrative work only.

    CID: 1945

  • Control reference - 16.6.10.C.01.

    Agencies SHOULD log the events listed in the table below for specific software components. (Please see NZISM Chapter 16 for complete table).

    CID: 2012

  • Control reference - 16.6.10.C.02.

    Agencies SHOULD log, at minimum, the following events for all software components: 

    • any login activity or attempts, all privileged operations,
    • failed attempts to elevate privileges, 
    • security related system alerts and failures, 
    • all software updates and/or patching,
    • system user and group additions, deletions and modification to permissions, and 
    • unauthorised or failed access attempts to systems and files identified as critical to the organisation.

    CID: 2013

  • Control reference - 18.4.9.C.01.

    Agencies MUST select IDS / IPS that monitor uncharacteristic and suspicious activities.

    CID: 3815

  • Control reference - 23.5.12.C.01.

    Agencies MUST ensure that cloud service provider logs are incorporated into overall enterprise logging and alerting systems or procedures in a timely manner to detect information security incidents.

    CID: 7498

  • Control reference - 23.5.12.C.02.

    Agencies SHOULD ensure that tools and procedures used to detect potential information security incidents account for the public cloud services being consumed by the agency.

    CID: 7499

Top