BSBXCS404 Contribute to cyber security risk management

Strip the competency language away and the unit asks one question: can you help an organisation decide what to protect, how much to spend protecting it, and whether the protection is working, and can you write that down in a way that someone else can act on and audit?

That is risk management. The "cyber" in front of it changes the threats and the controls, but not the discipline. An organisation that manages its work health and safety risk, its financial risk and its cyber risk well is doing the same five things in each case: setting the scope and the appetite, identifying what could go wrong, working out how likely and how bad, choosing what to do about it, and checking later whether the choice held. The standards this page uses, ISO 31000 above all, were written to be the same for every kind of risk, and the better cyber security frameworks are built on top of them rather than beside them.

The unit was written in 2020. That matters, because the five years since have produced the fastest period of change in Australian cyber and privacy law in the history of either, and a change in the threat itself that the 2020 material does not anticipate. Three things in particular were not on the page when the unit was accredited, and they now sit at the centre of the subject:

• The law now has clocks in it. In 2020 an Australian organisation had one notification obligation with a soft deadline ("as soon as practicable"). As at October 2026 the same organisation may have a 72-hour ransomware payment report, a 12-hour or 72-hour critical infrastructure incident report, a 72-hour APRA notification, and, if the second tranche of privacy reform passes as drafted, a 72-hour data breach notification. Each clock starts at a different moment and runs to a different regulator.
• Identity is the perimeter, and the cloud is the estate. The 2020 learner material assumes an on-premises Windows network with a firewall around it. Most organisations now run on Microsoft 365 or Google Workspace, with identity as the control plane, and the question "where is the perimeter?" has no answer. Phishing for credentials, not malware, is the leading cause of the breaches the OAIC sees.
• Artificial intelligence sits on both sides. It is an attacker capability (synthetic voice and video, industrialised social engineering, AI-assisted reconnaissance) and a thing the organisation now has to govern, procure and secure in its own right. The September 2026 release of ASD's Information Security Manual added controls for AI agents that did not exist a year earlier.

So the approach on this page is to teach the discipline as the standards describe it, then to put each part of the unit against the law, the frameworks and the threat as they stand in October 2026. Where the delivered material is dated, the current position carries the section; where a thing is still moving, it is described as moving, with dates.

One more orientation point, because it shapes how to read everything that follows. The unit is for someone who contributes. The board owns the risk appetite. The executive owns the decision to accept, reduce, share or avoid a risk. The risk function, or the IT lead in a small organisation, owns the register and the process. The person this unit describes drafts, analyses, consults, presents, records, monitors, checks, reports and escalates. Knowing where that line sits, and saying so when a decision is not yours to make, is part of the competency, not an admission of weakness.

Half the difficulty in this subject is vocabulary, because the same words are used differently in general risk management, in information security and in everyday speech. The definitions below are the ones that hold across ISO 31000, ISO/IEC 27005 and NIST, and they are worth learning precisely because a risk register written in loose language is a risk register nobody can act on.

Risk is the effect of uncertainty on objectives (ISO 31000:2018). The definition is deliberately neutral: an effect can be positive or negative, and a risk only exists in relation to something the organisation is trying to achieve. In cyber security the objectives are usually expressed through the confidentiality, integrity and availability of information and systems, and the effects are almost always negative, so the working definition becomes: the possibility that a threat exploits a vulnerability to cause harm to an asset.

Asset is anything of value to the organisation that needs protecting. Information (patient records, payroll, intellectual property, credentials), systems (the practice management server, the identity provider, the payment gateway), services (email, the website, the booking system), people (the one administrator who knows how the finance system works), and reputation. The learner guide's point still stands: information is as much an asset as the server it sits on, and the value of an asset is not what it cost but what its loss would cost.

Threat is a potential cause of an unwanted incident. A threat has a source (a threat actor: criminal group, insider, state actor, hacktivist; or a non-human source: flood, power failure, software defect) and an action (phishing, exploitation of a vulnerability, misconfiguration, theft of a device). NIST's four threat families, adversarial, accidental, structural and environmental, are a useful check that a threat list is not only about hackers.

Vulnerability is a weakness that a threat can exploit: an unpatched service, a shared administrator password, an untrained receptionist, a backup that has never been restored, a contract with no security clause. Vulnerabilities are the thing an organisation can most directly change, which is why most controls are vulnerability reductions.

Likelihood is the chance that the threat event occurs and succeeds, and consequence (or impact) is the harm if it does. Risk is a function of the two. Inherent risk is the level before any controls are considered; residual risk is what remains after the controls in place are taken into account; target risk is the level the organisation wants to reach after planned treatment.

Risk appetite is the amount and type of risk an organisation is willing to pursue or retain in order to achieve its objectives; risk tolerance is the acceptable variation around that appetite for a particular risk, usually expressed as a threshold. A board might say "we have a low appetite for risks to patient data and a moderate appetite for risks to internal productivity tools"; the tolerance would then be the specific rating above which a patient-data risk must be treated rather than accepted. The 2020 activity book lists "risk tolerance" as one of four risk treatment strategies; it is not, and the confusion between tolerance (a threshold) and acceptance (a decision) is common enough to be worth correcting at the start.

Control (or safeguard, or countermeasure) is a measure that modifies risk, by reducing likelihood, reducing consequence, or both. Controls are classified by what they do (preventive, detective, corrective, and sometimes deterrent and compensating) and by what they are (administrative, technical, physical). Control effectiveness is the degree to which a control actually does what it is meant to do, which is a different thing from whether it exists on paper, and most of the evaluation work in this unit is about that difference.

Risk owner is the person with the accountability and authority to manage a risk. Every risk in a register needs one, and it should be a role rather than a name, so the register survives staff turnover.

Two more terms, because they are used throughout the rest of the page. Threat event is a specific instance of a threat acting ("a phishing email leads a staff member to enter their Microsoft 365 password into a fake login page"), and it is the thing you rate. Risk scenario is the fuller description that joins threat event, asset, vulnerability and consequence into a single sentence that a non-specialist can read, and a register written as scenarios rather than as one-word labels ("ransomware", "phishing") is one that executives can actually discuss.

Did you know?

The word "risk" entered English in the seventeenth century from Italian and French maritime insurance, where risco was the hazard a cargo faced at sea. The modern discipline grew out of the same trade: the first risk registers were ship manifests with a column for what could be lost. The structure has not changed much. An asset, a hazard, a likelihood, a consequence, and a decision about who carries the loss.

The 2020 material names ISO 31000 and NIST and gestures at the Essential Eight. The current picture is richer, and the useful thing to understand is not the content of each framework but how they stack. There are three layers, and a risk management strategy that cites a document from the wrong layer for the job is a common failure.

flowchart TD
  G[Governance and risk management process<br/>ISO 31000:2018, COSO ERM 2017, the IIA Three Lines Model, AICD Cyber Security Governance Principles v2] --> F[Cyber security frameworks: what good looks like<br/>NIST CSF 2.0, ISO/IEC 27001:2022 with 27005:2022, ISM, PSPF, CPS 234]
  F --> C[Control catalogues and baselines: what to actually do<br/>Essential Eight, ISM controls, CIS Controls v8.1, NIST SP 800-53]
  C --> A[Assurance and measurement: is it working?<br/>Essential Eight maturity assessments, ISO 27001 audit, CPS 234 tripartite reviews, SOCI annual CIRMP report, penetration tests, KRIs]
  A -. feeds back into .-> G

The process layer: ISO 31000 and its relatives

ISO 31000:2018 Risk management, Guidelines is the international standard for the risk management process itself, written to apply to any kind of risk in any kind of organisation. It is short, principles-based and not certifiable (nobody is "ISO 31000 certified"; it is guidance, not a management system standard). Its process is the backbone of every section on this page: establish the scope, context and criteria; identify risks; analyse them; evaluate them against the criteria; treat them; monitor and review; and, running alongside all of that, communicate and consult, and record and report.

flowchart LR
  S[Scope, context and criteria] --> I[Risk identification]
  I --> AN[Risk analysis]
  AN --> E[Risk evaluation]
  E --> T[Risk treatment]
  T --> M[Monitoring and review]
  M --> S
  CC[Communication and consultation] --- S
  CC --- I
  CC --- AN
  CC --- E
  CC --- T
  CC --- M
  RR[Recording and reporting] --- T
  RR --- M

The 2018 edition is current as at October 2026. A revision is under way: ISO's catalogue lists ISO 31000:2018 at the "to be revised" stage with a committee draft, ISO/CD 31000, under development, following a systematic review that closed in October 2024. A committee draft is an early stage, so a new edition is some way off and its content is not settled; the principles and process described here are not expected to change in substance. Its companion IEC 31010:2019 catalogues the assessment techniques (risk matrices, bow-tie analysis, Monte Carlo simulation, fault trees and several dozen others) and is the reference when the question is "which method?". Australia adopts both as AS ISO 31000:2018 and AS IEC 31010:2019.

COSO's Enterprise Risk Management framework (2017 edition) is the other major process framework, more common in financial services and in US-headquartered organisations; it integrates risk with strategy and performance and is the lens many boards use. The IIA's Three Lines Model (2020) is the governance pattern that most of the organisational material in this unit assumes: management owns and manages risk (first line), risk and compliance functions provide expertise and challenge (second line), and internal audit provides independent assurance (third line), with the governing body above all three. The 2020 revision deliberately dropped the word "defence" from the old "three lines of defence" because the lines are meant to collaborate, not to defend against each other. Where does the person this unit describes sit? Usually in the first line, sometimes in the second; almost never in the third.

For Australian boards, the AICD and Cyber Security Cooperative Research Centre Cyber Security Governance Principles, version 2 (25 November 2024) translate all of this into five principles directors are expected to apply: set clear roles and responsibilities; develop, implement and evolve a comprehensive cyber strategy; embed cyber security in existing risk management practices; promote a culture of cyber resilience; and plan for a significant cyber security incident. Version 2 added material on digital supply chain risk, data governance and incident response, which tells you where the 2022 original was thin. If a board paper in this unit needs a reference point the directors will recognise, this is it.

The framework layer: NIST CSF 2.0 and ISO/IEC 27001

The NIST Cybersecurity Framework 2.0, published 26 February 2024, replaced version 1.1 (2018). The delivered session material still teaches the five functions of version 1.1, Identify, Protect, Detect, Respond and Recover; version 2.0 added a sixth, Govern, placed at the centre, covering organisational context, risk management strategy, roles and responsibilities, policy, oversight and, new in 2.0, cyber security supply chain risk management. The addition is the single most relevant change for this unit, because Govern is where risk appetite, the risk management strategy and the escalation routes live, and version 1.1 had no proper home for them. The other change worth knowing is scope: version 1.1 was written for US critical infrastructure; version 2.0 is explicitly for all organisations of any size and sector. The framework still has its three parts: the Core (functions, categories and subcategories of outcomes), the Tiers (Partial, Risk Informed, Repeatable, Adaptive, which describe how rigorous the organisation's risk governance and management practices are) and Profiles (a current profile and a target profile, and the gap between them is the improvement plan). The CSF is voluntary, free and outcome-based: it tells you what a good program achieves, not which controls to deploy, which is why it is usually paired with a control catalogue.

ISO/IEC 27001:2022 Information security management systems is the certifiable standard, and the one a supplier will wave at you. The 2022 edition replaced 2013, restructured the Annex A controls from 114 in fourteen groups to 93 in four themes (organisational, people, physical, technological), and added eleven new controls including threat intelligence, cloud services security, data leakage prevention and secure coding; an amendment in 2024 added climate change to the context clause. Organisations certified to the 2013 edition had until 31 October 2025 to transition, so as at October 2026 any live certificate is to the 2022 edition. Its clause 6.1 requires a documented information security risk assessment and treatment process, and the method for doing that is ISO/IEC 27005:2022, which is the cyber-specific application of ISO 31000 and the best single description of how an information security risk assessment is meant to run. ISO/IEC 27002:2022 is the implementation guidance for the controls. The useful mental model: 31000 is the process for any risk; 27005 is that process applied to information; 27001 is the management system you can be audited against; 27002 is the control guidance underneath.

In Australian government and in anything that touches it, the Information Security Manual (ISM) from ASD is the framework and the control catalogue in one. It is updated roughly quarterly; the September 2026 release is current as at the date on this page, and its changes are discussed under technology, supply chain and artificial intelligence below. The Protective Security Policy Framework (PSPF), now published in annual releases by the Department of Home Affairs, is the policy layer above it for Commonwealth entities. For APRA-regulated financial institutions, CPS 234 Information Security (2019) and CPS 230 Operational Risk Management (in force from 1 July 2025) are the equivalent, and they are discussed in the legal section.

The control layer: the Essential Eight, the ISM and CIS

The Essential Eight is ASD's prioritised baseline of mitigation strategies: application control, patch applications, configure Microsoft Office macro settings, user application hardening, restrict administrative privileges, patch operating systems, multi-factor authentication and regular backups. It is not a risk management framework and never claimed to be; it is a set of controls chosen because they stop the attacks ASD most often responds to, and the Essential Eight Maturity Model (current edition November 2023) describes four levels, Maturity Level Zero through Three, defined by the sophistication of the adversary the controls are designed to withstand. That definition is worth stating precisely, because the delivered session material describes the levels as "partially implemented", "mostly implemented" and "fully implemented", and that is not what ASD means. Maturity Level One is designed against adversaries using commodity tradecraft and tooling available to anyone; Level Two against adversaries willing to invest more time and effort in a target; Level Three against adaptive adversaries who exploit the opportunities a weakness provides. The levels are about who you can withstand, and an organisation picks a target level by assessing which adversary it is likely to face. The November 2023 revision tightened patching timeframes (critical or actively exploited vulnerabilities in internet-facing services within 48 hours), brought multi-factor authentication for access to sensitive data forward to Level One with phishing-resistant methods weighted at higher levels, and tightened privileged access requirements.

The Essential Eight is itself in transition. On 15 June 2026 ASD opened consultation on evolving it into a broader Essentials series, grounded in the ISM, with Essentials for enterprise IT as the first chapter and further chapters foreshadowed; consultation closed on 12 July 2026. ASD's stated reasoning is that the 2017 model was designed for on-premises Windows environments and does not translate cleanly to cloud, shared responsibility and software-as-a-service, and that the replacement will be more principles-based and will explain the adversary techniques behind each mitigation. As at October 2026 nothing has been published beyond the consultation notice, the November 2023 maturity model remains the current document, and ASD has said organisations already using the Essential Eight can expect "strong alignment with their existing controls and investments". A named ASD official has described in an interview an indicative path of deprecating the Essential Eight about twelve months after consultation and retiring it around twenty-four months, but that is one person's expectation, not a published schedule. The practical consequences for this unit: learn the Essential Eight, because it is what contracts, audits and government procurement reference today; and when writing a risk management strategy or a contract, reference "ASD's current baseline mitigation guidance" rather than naming the Essential Eight, because a document that names a framework outlives the framework.

CIS Critical Security Controls v8.1 (June 2024) is the international equivalent, eighteen controls with three Implementation Groups (IG1, IG2, IG3) that play the same role as the Essential Eight's maturity levels; IG1 is CIS's definition of "essential cyber hygiene" and maps well to Maturity Level One. CIS also publishes CIS Benchmarks, which are hardening guides for specific products (Windows 11, Microsoft 365, AWS, and so on). The word "benchmark" will come up again in the evaluation section with a different meaning, so hold onto the distinction: a CIS Benchmark is a configuration standard; a benchmark in the unit's sense is a reference point for measuring performance.

NIST SP 800-30 Revision 1 (September 2012) is the US guide for conducting risk assessments and is still current; it is the origin of the threat-source, threat-event, vulnerability, likelihood and impact structure used above, and its appendices contain the scales most organisations copied. NIST SP 800-37 Revision 2 is the Risk Management Framework that US federal systems follow, more relevant to government than to this unit. NIST SP 800-61 Revision 3 (April 2025) replaced the 2012 incident handling guide and, importantly, reorganised incident response around the six CSF 2.0 functions rather than its old four-phase lifecycle; it is discussed with incident response below.

Threat knowledge: MITRE ATT&CK

MITRE ATT&CK is the catalogue of adversary tactics, techniques and procedures observed in real intrusions, organised as a matrix from reconnaissance through to impact. It is not a control framework but it is where the "regular threat assessment" the unit asks for becomes concrete: a threat assessment that says "ransomware" is a label, while one that says "initial access via phishing (T1566) and valid accounts (T1078), persistence via scheduled tasks, lateral movement via remote services, impact via data encrypted for impact (T1486)" can be mapped to controls and tested. ATT&CK is released twice a year; version 20 was released on 13 October 2026 and added AI-enabled techniques and a campaign describing an AI-assisted intrusion into government infrastructure, which is a measure of how fast the threat side is changing. The cyber attack lifecycle taught in the session material (reconnaissance, weaponisation and delivery, exploitation, installation, command and control, actions on objectives) is Lockheed Martin's older Cyber Kill Chain from 2011; it is still a good teaching model and ATT&CK is its detailed successor.

Quantification: FAIR

Factor Analysis of Information Risk (FAIR), maintained by the FAIR Institute and standardised by The Open Group as Open FAIR, is the main method for expressing cyber risk in money rather than colours. It decomposes risk into loss event frequency (threat event frequency times vulnerability) and loss magnitude (primary and secondary losses), uses calibrated ranges rather than point estimates, and produces a distribution of expected annual loss. It is used where boards want cyber risk in the same units as every other risk on the register, and where cyber insurance limits need justifying. It is discussed further under analysis.

How the layers are used together

An Australian health provider in 2026 might reasonably run its risk process to ISO 31000 (as its WHS and clinical risk already are), describe its security program to the board using the six NIST CSF 2.0 functions, hold its information security management system to ISO/IEC 27001:2022 because its largest customer asks for the certificate, implement the Essential Eight to Maturity Level Two as its technical baseline, use ATT&CK to describe the threats in its register, and report maturity each year against the Essential Eight assessment process. None of that is contradictory; each document is doing a different job. The error to avoid is the one the delivered material edges toward, treating "the Essential Eight" as if it were a risk management methodology. It is the treatment; the methodology is what decides that this treatment is the right one.

The first element of the unit is consultation: determining, with stakeholders, the scope of risk management appropriate to the organisation and its industry. ISO 31000 calls this establishing the scope, context and criteria, and it is the step most often skipped by technical people who want to get to the controls. Skip it and the register ends up full of risks nobody owns, rated on a scale nobody agreed, treated to a level nobody asked for.

Who the stakeholders are

A stakeholder is anyone who can affect, or is affected by, the organisation's cyber risk decisions. The 2020 activity book's list (risk manager, CFO, CEO and board, legal and compliance, operations, HR and employees, customers and suppliers) is a reasonable start; the 2026 version is longer and the additions are the ones that matter most:

• The board or governing body, which owns the risk appetite and, under the Corporations Act and the AICD principles, is accountable for oversight of cyber risk. In a small business this is the owner; in an NT government agency it is the chief executive and the audit and risk committee.
• The executive, who make the accept, reduce, share or avoid decisions and sign the risk treatment plan.
• The risk, compliance and legal functions, who own the method, the register and the legal obligations, and who need to be in the room when a decision has a reporting clock attached.
• IT and security operations, who know the actual estate (and whose asset list will disagree with finance's).
• Operational technology owners, in any organisation that runs plant, building management, medical devices or vehicles, because those networks are now reachable from the corporate one and were not designed to be.
• Business process owners, who know what the data is for and what downtime costs, and whose consent is needed before a control changes how they work.
• People and culture, for training, acceptable use, and anything that touches employee monitoring or discipline.
• Suppliers and managed service providers, because a large share of the organisation's controls now run on their infrastructure and under their staff, and the law increasingly makes the organisation answerable for them.
• Customers and the public, whose personal information is the asset most often at stake and whose expectations are now written into the law.
• Regulators, whose guidance defines "reasonable steps", and insurers, whose policy conditions increasingly define the minimum control set.

The consultation methods the learner guide lists (meetings, workshops, interviews, surveys, focus groups) are all still used. What has changed is that the most productive consultation for cyber risk scoping is usually a structured workshop with a draft on the table rather than a blank-page brainstorm, because stakeholders respond better to "here is our proposed scope, appetite and scale; what is wrong with it?" than to "what are your risks?". Open questions ("what would hurt most if it stopped working for a week?") get you the assets and the consequences; closed, probing questions ("is the booking system in scope? who owns it? is it hosted or on-premises?") pin the boundaries down. The foundation skills in the unit descriptor name exactly those two kinds of question.

Establishing context: what "appropriate to organisation and industry" means

The scope of risk management has to fit the organisation. The things that set it:

The external context. The industry and its regulators (health, finance, critical infrastructure, government and small business each have a different legal baseline, set out in the legal section); the threat environment for that industry (ASD and the OAIC both publish by sector, and health and finance lead both lists); the supply chain the organisation depends on; and the expectations of customers and partners, including contractual security requirements, which for many small organisations are the only external force that moves them.

The internal context. Objectives and strategy; structure, size and geography (a Darwin-based organisation with a Katherine office and remote community sites has a different availability risk profile from a Sydney office); the existing risk management framework, because cyber risk should sit inside it rather than beside it; the technology estate and who runs it; culture and capability; and resources, which for a small organisation means being honest that the scope is "what one part-time person can monitor".

The risk criteria. This is the piece most often left implicit and it should be written down before any risk is rated: the likelihood and consequence scales and what each level means in this organisation's terms; the risk matrix and the rating bands; the appetite and tolerance for each category of risk; and the rules for when a risk must be escalated. A consequence scale that says "Major: financial loss above $500,000, or an eligible data breach affecting more than 1,000 individuals, or clinical services unavailable for more than 24 hours" is usable; one that says "Major: significant impact" is not. The criteria are the thing stakeholders most need to agree on, because everything downstream is measured against them.

The boundaries. Which systems, sites, data, processes, suppliers and people are in scope, and which are deliberately out and why. Scope creep in cyber risk management looks like a register that started with the clinical system and now has 400 entries covering the office printer, and the fix is a scope statement the same size as the capacity to maintain it.

A written outcome of this step, in practice, is a short risk management scope and criteria document, one to three pages, approved by whoever owns the risk framework, that the register and the treatment plan then refer to. In an organisation that already has an enterprise risk management policy, cyber risk should adopt its scales and matrix rather than inventing new ones, so that a cyber risk rated "High" means the same thing to the board as a WHS risk rated "High".

Risk appetite statements

Appetite is set above the level this unit describes, but the person contributing has to be able to read one, apply it and draft a proposal that fits it. A usable cyber risk appetite statement names categories and says something different about each. For example: no appetite for risks that would breach a legal obligation to notify or report, so those risks must always be treated to the lowest practicable level; low appetite for risks to the confidentiality of personal and health information; moderate appetite for risks to internal productivity systems where recovery within two business days is achievable; and an explicit statement about the organisation's position on paying ransoms (most Australian organisations now state that they will not, and in any case must report a payment within 72 hours, as the legal section explains). The AICD principles ask boards to set and periodically review exactly this.

Scope in a small organisation and in the public sector

Most Australian organisations are small, and most of the delivered material is written for an enterprise. For a small organisation the scope step is simpler and more important: the asset list fits on a page, the stakeholders are the owner, the accountant, the IT provider and the staff, the criteria can be a three-by-three matrix with dollar and downtime figures the owner recognises, and the appetite is usually "we cannot afford to be down for more than a day and we cannot afford a breach that requires notifying our customers". ASD's small business hub on cyber.gov.au is pitched at exactly this and is the right reference.

For an NT public sector organisation the context is set by the Information Act 2002 (NT) and the NT Government's cyber security policy framework, and the stakeholders include the NT Information Commissioner, the Department of Corporate and Digital Development as the whole-of-government ICT provider, and the audit committee. The scope question there is usually about shared services: which controls does the agency own, and which does it inherit from the central provider and only need to verify?

With scope and criteria set, the work is to produce a list of risks and to rate them. The unit's second performance criterion asks you to review critical risk management strategies "appropriate to the level of risk", which presumes you can establish the level of risk in the first place.

Identification: the asset-threat-vulnerability method

The most reliable method for a first register is to work from assets outward, as ISO/IEC 27005 describes. For each asset in scope, ask what threats could act on it, what vulnerabilities would let them, and what the consequence would be. The session material's asset categories (data, intellectual property, funds, system availability) and its reminder to include secondary assets (the server the data sits on, the identity provider that gates access to it, the backup that would restore it) are sound. What the 2020 material lacks is the current threat side, so here it is.

What the threat actually looks like in 2026. ASD's Annual Cyber Threat Report 2024 to 2025, released 14 October 2025, reports that ASD received over 84,700 cybercrime reports in the year (one every six minutes), responded to more than 1,200 cyber security incidents (up 11 per cent), and answered over 42,500 calls to the Australian Cyber Security Hotline. The average self-reported cost of cybercrime rose 14 per cent for small business to $56,600 per report, and 8 per cent for individuals to $33,000. The report describes state actors as a serious and growing threat to government, critical infrastructure and business, and ransomware and data theft extortion as increasing in frequency. Its four headline recommendations are the clearest statement of where ASD thinks organisations are weakest: implement best-practice logging, replace legacy technology, manage third-party risk, and prepare for post-quantum cryptography. The 2025 to 2026 edition is due in the last quarter of 2026; check whether it has superseded these figures.

On the privacy side, the OAIC recorded 1,205 data breach notifications in calendar 2025, the highest since the scheme began in 2018 and up 8 per cent on 2024; 716 of them (about 59 per cent) were attributed to malicious or criminal attack, and the top sectors were health service providers (225), finance (157), the Australian Government (118), business and professional associations (103), and education and legal, accounting and management services (81 each). In the OAIC's last narrative report before it moved to a statistics dashboard (July to December 2024), phishing leading to compromised credentials was the leading cyber incident type at 34 per cent of cyber incidents, with compromised or stolen credentials by unknown method at 21 per cent and ransomware at 24 per cent, and human error accounted for 37 per cent of all breaches in the first half of 2025. The practical reading: the most likely threat event for most Australian organisations is a person giving away a credential, not a zero-day exploit, and a register that rates "sophisticated nation-state attack" as High while leaving "staff member enters password into fake login page" unrated has its priorities inverted.

Threat identification techniques that work. Start from the organisation's own incident history and near misses. Add the threat types ASD and the OAIC report for the sector. Use ATT&CK to turn each threat into a sequence of techniques, so that the register records how an attack would actually proceed through this organisation's environment. Use ASD's alerts and advisories, and the ASD Cyber Security Partnership Program (free to join and the source of sector-specific threat intelligence) for the current picture. Consider the non-adversarial families: a Top End wet season, a fibre cut on the Stuart Highway, a cloud provider outage, a faulty software update (the CrowdStrike incident of 19 July 2024, discussed later, took about 8.5 million Windows systems offline worldwide and was not an attack). Then check the list against the "omissions" that 2020 material does not prompt for: the AI-enabled social engineering threat; identity-based attacks on cloud tenants (token theft, consent phishing, MFA fatigue); third-party and supply chain compromise; operational technology reachable from the office network; and data the organisation has forgotten it holds.

Vulnerability identification. Vulnerability scanning and penetration testing find the technical weaknesses; the ISM's September 2026 release moved the expected cadence of vulnerability assessment and penetration testing from annually to every six months after deployment. Configuration review against CIS Benchmarks or the ISM finds the misconfigurations. Essential Eight assessments find the control gaps. But the most consequential vulnerabilities in the OAIC's data are not technical: untrained staff, no multi-factor authentication, unmonitored alerts, no tested backup, and a contract that puts personal information with an overseas provider who has none of those either. Two scoring systems help prioritise the technical findings: CVSS (the Common Vulnerability Scoring System, currently version 4.0) rates how bad a vulnerability is in the abstract, and EPSS (the Exploit Prediction Scoring System) estimates the probability that it will actually be exploited in the next 30 days; the US CISA Known Exploited Vulnerabilities catalogue lists the ones that already are. A patching program that treats a CVSS 9.8 vulnerability with an EPSS of 0.01 the same as a CVSS 7.5 on the KEV list is wasting effort, and this is the kind of "guideline for updating technology" the unit's knowledge evidence has in mind.

Analysis: qualitative

Most organisations rate risk qualitatively, with a likelihood scale, a consequence scale and a matrix. The session material's five-point scales are the common Australian pattern and are used here:

Likelihood	Meaning
Rare	May occur only in exceptional circumstances; not expected within five years
Unlikely	Could occur at some time; perhaps once in two to five years
Possible	Might occur; perhaps once a year
Likely	Will probably occur in most circumstances; several times a year
Almost certain	Expected to occur; monthly or more often

Consequence	Meaning (example criteria for a mid-sized health provider)
Insignificant	No personal information involved; no service interruption; cost under $5,000
Minor	Limited internal disruption under four hours; cost under $25,000; no notification required
Moderate	A service unavailable for up to one business day; or a data breach assessed as not eligible; cost under $100,000
Major	Clinical or customer-facing services unavailable for more than one day; or an eligible data breach requiring notification; or regulatory attention; cost under $500,000
Severe	Extended loss of critical services; or a large eligible data breach with likely serious harm; or civil penalty proceedings; cost above $500,000

With likelihood scored one to five and consequence one to five, the session material multiplies them to give a rating from one to 25, banded as insignificant (1 to 4), low (5 to 9), moderate (10 to 14), high (15 to 19) and extreme (20 to 25). Each band carries a required response: no action, manage by routine procedure, assign management responsibility, senior management attention, and detailed planning or immediate action.

That works, and the unit expects you to be able to use it. It is also worth knowing its limits, because the better risk literature has criticised multiplicative heat maps for twenty years. The scales are ordinal, not numeric: "Likely" is not numerically four times "Rare", so multiplying the scores produces a number that looks precise and is not. The bands compress very different risks into the same colour (a 5 and a 9 are both "low"). Ratings are subjective and drift with whoever is in the room. And the matrix cannot be summed, so "we have twelve high risks" says nothing about the total exposure. The remedies are modest and practical: write the scale definitions in observable terms (dollars, hours, numbers of individuals) so two assessors land on the same cell; rate likelihood for the threat event succeeding, not merely occurring; rate the inherent risk and the residual risk separately so the register shows what the controls are doing; record the rationale in a sentence next to each rating; and calibrate periodically by having a second person rate a sample blind. Where the stakes justify it, move to quantification.

Analysis: quantitative

The classic quantitative method rates risk in money, and the unit's numeracy foundation skill is about being able to do this arithmetic and interpret it.

Single Loss Expectancy (SLE) is the expected loss from one occurrence of the threat event: asset value multiplied by the exposure factor, where the exposure factor is the proportion of the asset's value lost in that event.

Annualised Rate of Occurrence (ARO) is how many times a year the event is expected (0.2 means once in five years).

Annualised Loss Expectancy (ALE) is SLE multiplied by ARO: the expected loss per year from that risk, which is the figure that can be compared with the annual cost of a control.

The value of a safeguard (its net benefit) is the reduction in ALE it produces, minus its annual cost: (ALE before the control) minus (ALE after the control) minus (annual cost of the control). A positive result means the control pays for itself in expected loss avoided; a negative one means the organisation is spending more on the control than the risk it removes, which can still be the right decision for a regulatory or reputational reason, but should be made knowingly. The session material prints this formula with multiplication signs in place of the subtractions; the subtraction form is the correct one and the only one that produces a meaningful number.

A worked example, with figures in the range a Darwin allied health practice might use. The practice management system holds the clinical and billing records of 9,000 patients; replacing the system and recovering the data from a ransomware event, including downtime, forensic and legal costs and the notification exercise, is valued at $400,000 (the asset value for this scenario). The exposure factor for a successful ransomware event is estimated at 60 per cent, so SLE is $240,000. With no multi-factor authentication on remote access and backups on the same network, the ARO is estimated at 0.2 (once in five years), giving an ALE of $48,000 a year. The proposed treatment is phishing-resistant multi-factor authentication for all remote and administrative access plus immutable, segregated backups with a quarterly restore test, at an annual cost of $12,000. With the treatment, the ARO is estimated at 0.05 and the exposure factor at 25 per cent (the backups make recovery a matter of days rather than weeks), so the ALE after is $400,000 × 0.25 × 0.05 = $5,000. The safeguard value is $48,000 − $5,000 − $12,000 = $31,000 a year. That is the number to put in front of the practice owner, and it is a very different conversation from "we recommend MFA".

The honest caveat, which belongs in any paper using these numbers: every input is an estimate, the ARO especially. The discipline is in stating the estimates and their basis, giving ranges where the uncertainty is large, and revisiting them when evidence arrives. FAIR formalises this by replacing point estimates with calibrated ranges and running a Monte Carlo simulation to produce a distribution of annual loss (a 90 per cent chance the loss is between X and Y, a 10 per cent chance it exceeds Z), which is the form in which boards and insurers increasingly expect to see cyber risk. Tools for it exist, including free ones; for this unit, understanding that the ranges exist and why is enough.

Evaluation: comparing against the criteria

Analysis produces a rating; evaluation decides what to do with it. Against the criteria set in the scoping step, each risk is either within appetite (accept, with a named owner and a review date), above appetite (treat, with priority set by rating), or above a threshold that requires escalation to a specific level before any decision is made (the legal-obligation risks, in most statements). The output is a prioritised list, and the unit's wording "appropriate to level of risk" means exactly that the treatment effort should be proportionate to the rating: a low risk gets a routine control and an annual look; an extreme risk gets a funded project, a senior owner and monthly reporting until it is brought within tolerance.

Did you know?

Risk matrices are often credited to the US military's MIL-STD-882 system safety standard of 1969, which introduced the hazard severity and probability categories most modern matrices still copy. The criticism that multiplying ordinal scales produces misleading rankings is almost as old; Louis Anthony Cox's 2008 paper "What's wrong with risk matrices?" is the one usually cited, and it shows that a matrix can rank a worse risk below a better one. The lesson is not to abandon the matrix, which remains the most communicable tool there is, but to know what it cannot do.

Once a risk is above appetite, the organisation chooses a treatment. ISO 31000 lists seven options, which the session material and most practical registers collapse into four. The vocabulary varies (mitigate and reduce are the same thing; transfer and share are the same thing; retain and accept are the same thing) and the learner guide's "five principal strategies" lists mitigation and reduction separately, which is a duplication. The four:

Avoid. Stop or do not start the activity that creates the risk. The session material's example is the right shape: an online shop decides not to build customer accounts and store personal information because it cannot secure them, and offers generic recommendations instead. Avoidance is also the right answer for data the organisation does not need: the Privacy Act already requires destruction or de-identification of personal information no longer needed (APP 11.2), and every record not held is a record that cannot be breached. The OAIC's analysis of the large Australian breaches of 2022 and 2023 found, over and over, that the organisations were holding years of data about former customers that they had no current use for.

Reduce (mitigate). Implement controls that lower likelihood, consequence or both. This is where the Essential Eight, the ISM controls and the CIS Controls live, and it is the treatment applied to most risks on most registers. Controls that reduce likelihood: multi-factor authentication, patching, application control, email filtering, security awareness training, least privilege. Controls that reduce consequence: segregated and immutable backups, network segmentation, an incident response plan that is actually exercised, encryption of data at rest so that a stolen laptop is a lost asset rather than a notifiable breach, cyber insurance for the financial consequence. The best treatments do both.

Share (transfer). Move part of the consequence to another party, by contract or by insurance. Outsourcing to a managed service provider shares the work and some of the liability, but the organisation remains the APP entity and remains responsible under the Privacy Act for personal information it discloses to a provider; the legal section comes back to this, because the law's position on third parties has hardened. Cyber insurance is discussed below. The session material's note that some practitioners classify insurance as a mitigation rather than a transfer is a reminder that the categories are less important than the decision.

Accept (retain). Make an informed decision to take no further action, because the risk is within appetite, or because the cost of treatment exceeds the benefit, or because no practicable treatment exists. Acceptance is a decision, not a default: it must be made by someone with the authority to make it, recorded with the rationale, and given a review date. The activity book's "risk tolerance" is not a treatment option; it is the threshold that tells you whether acceptance is available. One subtlety from ISO 31000: if an organisation accepts a risk, it should still plan for the risk materialising, which for cyber risk means the incident response plan covers it.

Choosing between them: the risk treatment plan

The output of treatment selection is a risk treatment plan, and the unit's performance criteria about "response options" and "document approved risk management strategies" are asking for this document. For each risk it records: the treatment options considered; the chosen option and why; the specific controls to be implemented; the expected residual risk rating after treatment; the owner of each action; the resources and budget; the target date; how implementation will be verified; and how the risk and the control will be monitored afterwards. Where the options have been costed, the cost-benefit analysis sits alongside. The session material is right that a cost-benefit analysis should ensure the control does not cost more than the loss it prevents, and the quantitative method above is how that is done.

A worked treatment selection for the two risks that recur through this page:

Risk scenario	Options considered	Chosen response	Residual target
A staff member enters their Microsoft 365 credentials into a phishing page; the attacker uses the account to access patient records and send further phishing from the practice's domain	Accept (rejected: eligible breach likely); reduce via security awareness training alone (rejected: lowers likelihood but not enough); reduce via phishing-resistant MFA plus conditional access plus training; share via cyber insurance for the response cost	Reduce: enforce MFA with phishing-resistant methods for all users, block legacy authentication, quarterly phishing simulation with training; insurance retained for consequence	Likelihood Unlikely, consequence Moderate: Low
An unpatched vulnerability in the internet-facing remote access gateway is exploited and ransomware is deployed across the practice network, encrypting the practice management system and its backups	Avoid (rejected: remote access is needed by visiting clinicians); reduce via patch timeframes aligned to the Essential Eight plus segregated immutable backups plus EDR; share via managed detection and response	Reduce: 48-hour patching for critical or exploited vulnerabilities on internet-facing services, immutable offline backups with quarterly restore test, EDR with managed monitoring	Likelihood Rare, consequence Major: Low to Moderate

Cyber insurance in 2026

Cyber insurance has changed since the 2020 material described it as a simple transfer. The Australian market tightened sharply after the 2021 and 2022 ransomware years, and the current pattern is that insurers set a minimum control baseline as a condition of cover, typically multi-factor authentication on remote access and email, endpoint detection and response, segregated and tested backups, privileged access management and a patching standard, and will decline or exclude where it is absent. Policies commonly exclude losses arising from war and state-sponsored attack (the Lloyd's market mandated such exclusions from 2023), from known unpatched vulnerabilities, from failure to maintain the controls declared on the proposal form, and from regulatory fines where the law does not allow them to be insured. Ransom payments may or may not be covered; where they are, the insurer's negotiators are typically involved, and in Australia the payment must now be reported to ASD within 72 hours regardless of who pays it. For the risk register, the implications are: insurance treats the financial consequence only, not the operational or reputational one; the proposal form is a set of representations about controls that the organisation must actually keep true; and the policy's conditions are, in effect, an externally imposed control baseline that the monitoring step must track.

Controls, by type, and why the mix matters

Controls are usually classified two ways at once, and the register should record both because they predict different failure modes:

• By function. Preventive controls stop the event (MFA, patching, application control, access control). Detective controls find it when it happens (logging and monitoring, EDR, file integrity checks, the staff member who reports the odd email). Corrective controls limit and recover from it (backups, incident response, segmentation that contains lateral movement). Deterrent controls discourage the attempt (visible monitoring, acceptable use agreements, legal notices). Compensating controls stand in where the ideal control is impracticable (enhanced monitoring of a legacy system that cannot be patched).
• By nature. Administrative (policy, procedure, training, contracts, background checks), technical (the software and hardware controls), and physical (locks, access cards, cable management, the server room door).

An organisation whose register is all preventive and technical has no plan for the day prevention fails, and ASD's own recommendations (logging, legacy replacement, third-party management, post-quantum preparation) are a reminder that detection and recovery are where most organisations are weakest. The November 2023 Essential Eight revision's emphasis on backups, logging of privileged activity and incident-ready configurations reflects the same lesson.

The knowledge evidence singles out four "key risk management strategies": regular organisational training, regular threat assessment, a cyber security incident response plan, and clear escalation routes. They are the administrative backbone of every program and the ones a non-technical contributor can most directly influence. Each is taken in turn, with its 2026 shape.

Regular organisational training

Security awareness training reduces the likelihood of the single most common threat event in the OAIC's data. The session material's content list still holds (current threats, red flags, what to do if you suspect an attack, what to do during one) and it should now include three things it did not in 2020: the AI-enabled version of social engineering (a voice on the phone that sounds like the CEO, a video call with a convincing but synthetic CFO, a flawless email in the house style), with the verification habit that defeats it, which is to confirm any request to change payment details or move money through a pre-established, independent channel; consent phishing and MFA fatigue, where the attacker tricks the user into approving access rather than typing a password; and the organisation's own AI use policy, so staff know what data they may and may not put into which tools. The ISM's September 2026 release turned the first of those into a control (ISM-2126: verify requestors through a pre-established or independent channel before changing account or banking details or making financial transactions), which is a sign of how mainstream the deepfake fraud risk has become.

Phishing simulations are the standard way to test and reinforce training and the session material's guidance on running them is correct: they are a training tool, not a disciplinary one, results should be reported at team level, and the metric that matters is the report rate (how many people reported the simulated phish) as much as the click rate. A program that punishes clicks produces staff who hide mistakes, which is the opposite of the feedback culture the unit's fifth performance criterion in Element 2 is asking for. Training should be role-based: finance staff get payment fraud; executives get whaling and their own exposure on social media; IT staff get privileged access and change control; everyone gets the basics at induction and annually. Record completion, because "regular organisational training" with no evidence of who completed it is not a control a regulator will credit, and the FIIG case in the legal section shows a court treating the absence of mandatory training as one of the failures.

Regular threat assessment

A threat assessment is a periodic, structured answer to "what is trying to hurt us now, and how?". Its sources, in rough order of specificity: the organisation's own logs, alerts and incidents; ASD alerts and advisories and the Partnership Program feed; sector information-sharing bodies (the health and financial sectors have their own); the annual ASD threat report and the OAIC's statistics for the sector baseline; vendor threat intelligence where the organisation subscribes; and ATT&CK for the technique-level view. The cadence depends on the organisation: a small practice might do it annually with the IT provider and at any major change; an organisation with a security function does it continuously and summarises quarterly. The output feeds the register: new threats become new or re-rated risks, and the September 2026 ISM now expects threat hunting informed by threat intelligence at least every three months (ISM-2153), which is the operational end of the same activity.

The assessment should also look inward at change. New systems, a cloud migration, a merger or acquisition (the Australian Clinical Labs case turns on an acquired business's weaknesses), a new supplier, a new AI tool, staff turnover in a key role, and a change in the law are each a trigger for re-assessment, and the feedback processes section below is about making sure those triggers are noticed.

A cyber security incident response plan

The plan is the organisation's pre-made decisions for the day a control fails. The session material teaches the six-phase SANS model (preparation, identification, containment, eradication, recovery, lessons learned) and the learner guide teaches NIST's older four-phase version; both remain common and either is acceptable. The current NIST guidance, SP 800-61 Revision 3 (April 2025), reorganised incident response as a profile of CSF 2.0: the preparation work sits under Govern, Identify and Protect, and the incident itself runs through Detect, Respond and Recover, with lessons learned feeding back into Govern and Identify. The point of the change is to stop organisations treating incident response as a separate technical procedure and to make it part of risk management, which is exactly this unit's framing. ASD's cyber security incident response planning guidance and plan template on cyber.gov.au, and its readiness and exercise guidance, are the Australian references and are written for organisations without a security team.

What the plan must contain, as at 2026: the definition of an incident and the severity matrix that classifies it; roles and contact details, including out-of-hours and the alternates; the decision rights (who can take a system offline, who can authorise a ransom negotiation, who speaks to media); the technical playbooks for the common scenarios (credential compromise, ransomware, business email compromise, lost device, insider misuse, supplier breach); the legal and regulatory notification map, with every clock from the legal section and who starts each one; the evidence preservation steps, because the ISM now expects remediation to be planned from trusted systems separate from the compromised one (ISM-1731) and sequenced to limit re-compromise (ISM-1732); the communications plan for staff, customers, regulators and media; the cyber insurer's notification requirements, which usually require contact before engaging responders; and the post-incident review. It must be tested: a tabletop exercise at least annually, and a full exercise for the scenarios the risk register rates highest. An untested plan is a document; a tested one is a control. The FIIG judgment lists "no incident response plan tested at least annually" among the failures that cost the firm $2.5 million.

Clear escalation routes

An escalation route answers, in advance, "who do I tell, how, and by when, when I see something I cannot or should not handle myself?". It is the control that turns a receptionist's suspicion into a contained incident instead of a breach discovered by a journalist. It needs: a single, simple first step that everyone knows (a phone number, an email address, a button in the mail client); a triage point that is staffed, or on call, with a service level for acknowledgement; a severity matrix that maps the kind of event to the level it must reach and how fast (a suspicious email: the help desk, same day; a suspected credential compromise: the IT lead, within the hour; a suspected data breach involving personal information: the privacy officer and the executive, immediately, because the 30-day assessment clock and possibly a 72-hour clock have started); named roles at each level with alternates; and the external routes, to ASD's ReportCyber, the OAIC, the cyber insurer, the police, APRA or the Department of Home Affairs as applicable. The route must also run sideways and downwards: the executive needs a way to hear from the person who saw the problem without three layers of softening in between, and the person who raised it needs to hear what happened. The non-compliance and feedback section returns to this.

flowchart TD
  A[Anyone notices something odd] -->|single reporting channel| B[Help desk or IT lead triages within the agreed time]
  B -->|not an incident| C[Record, close, feed into awareness]
  B -->|incident, no personal information, contained| D[IT lead handles under playbook; logged in incident register]
  B -->|suspected credential or system compromise| E[Security or IT lead within one hour; containment starts]
  B -->|personal information possibly involved| F[Privacy officer and executive immediately; NDB assessment clock starts]
  E --> G{Severity matrix}
  F --> G
  G -->|significant or reportable| H[Incident commander, legal, insurer; regulator clocks checked; board informed]
  H --> I[External reports: ReportCyber, OAIC, APRA, Home Affairs, police as applicable]
  D --> J[Post-incident review feeds the risk register]
  H --> J

Two performance criteria sit here: presenting options for risk management strategies for approval within the scope of your own role, and documenting the approved strategies. The first is about writing and speaking for decision-makers; the second is about the register and its companions.

Writing for a decision

The learner guide's advice on communicating upward is sound and dated at the same time: put it in business terms, know your audience, lead with the conclusion, use data, focus on impact. What it does not say is what the document looks like. A risk options paper for an executive or a board, in the form most Australian organisations use, runs to two or three pages and has: a one-paragraph summary with the recommendation first; the risk, as a scenario, with its current rating and how that compares with appetite; the options considered, each with cost, expected residual risk, implementation time and the main trade-off, in a table; the recommendation and why; what is being asked of the decision-maker, precisely (approve option B, approve $12,000 recurring, note the residual risk, assign the owner); and the consequences of not deciding. Attach the detail; do not lead with it. If the board uses the AICD principles, frame the paper around them, because directors will be looking for evidence that they are discharging the oversight duty described there.

Two things about the "within the scope of own role" wording. First, it means the paper recommends; it does not decide, and the language should make that clear ("recommended for approval by..."). Second, it means knowing what approval route a given decision needs: an IT lead may be able to approve a control change within budget; a decision to accept a risk above tolerance, to change the appetite, or to spend outside budget goes up a level; and anything with a legal notification consequence goes to whoever holds that accountability. The scope document from the first step should say which decisions sit where, and if it does not, asking is the right contribution.

Oral presentation follows the same pattern: conclusion first, the one number or scenario that makes the case, the options in one slide, the ask. Anticipate the questions a non-technical decision-maker asks: how likely is this really, what happens if we do nothing, what are others in our industry doing, is this a legal requirement, and what is the smallest thing we could do now. Have a two-sentence answer to each.

The risk register

The register is the single document that holds the organisation's cyber risks, their ratings, their owners, their treatments and their status, and the unit's knowledge evidence names "reviewing currency of risk register" as a required organisational procedure. It can be a spreadsheet, a tab in the enterprise risk system, or a module in a governance, risk and compliance (GRC) platform; the format matters less than the fields and the discipline of keeping them current. A register row for a cyber risk should carry at least:

• An identifier and the date raised.
• The risk scenario, as a sentence: threat source, threat event, vulnerability, asset, consequence.
• The category (confidentiality, integrity, availability; or the organisation's own taxonomy) and any legal obligation it touches.
• Likelihood, consequence and rating for inherent risk, with the rationale.
• Existing controls and an assessment of their effectiveness.
• Likelihood, consequence and rating for current residual risk.
• The treatment decision (avoid, reduce, share, accept), the approved controls, the owner of each action and the target date.
• The target residual rating after treatment.
• The risk owner (a role).
• Key risk indicators and the monitoring method.
• Review date and the trigger events that would bring the review forward.
• A change log: who changed what, when, and why.

Two companion documents complete the set. The risk treatment plan described above holds the detail of each approved treatment and is the record the unit means by "document approved risk management strategies". A risk acceptance record (sometimes a form) records each decision to accept a risk above the routine threshold, signed by the person with the authority to accept it, with the rationale, any conditions and the review date, so that an auditor or a regulator can see that acceptance was a decision and not an oversight.

Currency of the register is a procedure, not an aspiration. A workable one: every risk is reviewed at least at its review date (quarterly for high and extreme, half-yearly for moderate, annually for low); any trigger event (an incident, a new system, a supplier change, a legal change, a threat advisory, an audit finding) brings forward the review of the risks it touches; the whole register is reviewed with the risk owners at least annually; the version is controlled and the change log kept; and a summary (new risks, re-rated risks, overdue treatments, risks accepted above tolerance) goes to the executive or audit and risk committee on a set cycle. The question to ask of any register is "when was this row last touched, and by whom?", and a register where the answer is "at the last audit" has stopped being a control.

GRC tools automate the reminders, the workflow and the reporting, and link risks to controls to evidence to policies, which is useful once the register has more than a few dozen rows or more than one person maintaining it. For most small organisations a well-structured spreadsheet with a review calendar does the job; the discipline is the control, not the software.

The unit's knowledge evidence asks for data protection legislation, notifiable data breach legislation, Australian privacy laws and established international legislation. The delivered material covers the Privacy Act and the NDB scheme as they stood in 2020 and cites GDPR and California's CCPA. Everything in this section postdates or substantially changes that picture, and this is the part of the page most likely to need re-checking within six months. For the legislation itself the companion page on this site, VU23223 Apply cyber security legislation, privacy and ethical practices, has the fuller treatment; this section covers what a risk management contributor needs, with emphasis on the obligations that create risks, the clocks that have to be in the incident plan, and the enforcement that tells you what "reasonable" now means.

The Privacy Act 1988 and the Australian Privacy Principles

The Privacy Act 1988 regulates how personal information is handled by Australian Government agencies and by private sector organisations with annual turnover above $3 million, together with all private health service providers and some other small businesses regardless of turnover (these are the "APP entities"). Its thirteen Australian Privacy Principles set the rules, and for cyber risk management the one that does the work is APP 11: an APP entity must take reasonable steps to protect the personal information it holds from misuse, interference and loss, and from unauthorised access, modification or disclosure (APP 11.1), and must destroy or de-identify personal information it no longer needs (APP 11.2). Since 11 December 2024 the Act has also said expressly that the reasonable steps include technical and organisational measures (APP 11.3), which removed any argument that a policy without a control, or a control without a policy, was enough.

"Reasonable steps" is a standard, not a checklist, and the OAIC's guidance on it, together with the two court decisions discussed below, is the best available description of what a regulator expects: a security program proportionate to the organisation's size, the sensitivity and volume of the information, the threat environment and the practicability of the measures; governance and accountability; staff training; access controls and authentication; monitoring and detection; incident response; destruction of data no longer needed; and management of third parties who hold the information. The Essential Eight is frequently cited in OAIC material as an example of the technical baseline a reasonable organisation would consider.

The penalty regime was transformed in two steps, and the figures the 2020 material would have given are long gone. From December 2022, a serious or repeated interference with privacy by a body corporate attracts a maximum penalty of the greater of $50 million, three times the benefit obtained, or (if the benefit cannot be determined) 30 per cent of adjusted turnover in the relevant period. From 11 December 2024 the Privacy and Other Legislation Amendment Act 2024 added two lower tiers so that the OAIC no longer has to prove "serious": a penalty of up to $3.3 million for a body corporate for an interference with privacy that does not meet the serious threshold, and a penalty of up to $330,000 for a body corporate for specified administrative breaches (a non-compliant privacy policy, a non-compliant eligible data breach statement, and similar), the last enforceable by infringement notice without going to court. The same Act created a statutory tort for serious invasions of privacy, in force from 10 June 2025, under which an individual can sue directly, which for a risk register means a breach now carries a class-action consequence as well as a regulatory one. It also gave the OAIC power to issue compliance notices and strengthened its investigation powers.

Two further tranche-one measures commence on 10 December 2026 and should already be in the register as compliance risks with that date: privacy policies must describe any automated decision-making that uses personal information to make, or substantially assist in making, decisions that significantly affect individuals; and the OAIC must have registered a Children's Online Privacy Code by that date, binding services likely to be accessed by children.

The Notifiable Data Breaches scheme

Under Part IIIC of the Privacy Act, in force since 22 February 2018, an APP entity that has reasonable grounds to believe an eligible data breach has occurred must notify the OAIC and the affected individuals as soon as practicable. An eligible data breach is unauthorised access to, unauthorised disclosure of, or loss of personal information that a reasonable person would conclude is likely to result in serious harm to any of the individuals concerned, and where remedial action has not removed that likelihood. Where the entity only suspects a breach, it must carry out a reasonable and expeditious assessment, which the Act expects to be completed within 30 days. The notification must include the entity's details, a description of the breach, the kinds of information involved, and the steps individuals should take.

The session material's statement that the scheme applies to organisations with turnover above $3 million is incomplete: it applies to every APP entity, which includes all health service providers and the other categories brought in regardless of turnover, and to credit reporting bodies, credit providers and tax file number recipients. A sole-practitioner physiotherapist is an APP entity; a $2.9 million builder is not, unless another category catches it. This is a scoping question in the first step, and getting it wrong in either direction is a risk in itself.

The scheme's statistics are now published through the OAIC's Notifiable Data Breach statistics dashboard, launched in November 2025 and updated twice a year, with the data on data.gov.au; the twice-yearly narrative report that the 2020 material would have cited ended with the July to December 2024 edition. Calendar 2025, as noted above, set a record at 1,205 notifications.

Two changes to the scheme are in prospect and both belong in a register as emerging compliance risks. First, the second tranche of privacy reform: the Attorney-General's Department released the exposure draft Privacy Amendment (Personal Data Protection) Bill 2026 and its consultation paper on 31 August 2026, with consultation closing 18 September 2026 and the Government stating an intention to introduce the legislation before the end of 2026. As drafted, it would require notification to the OAIC within 72 hours of becoming aware of an eligible data breach, with incomplete initial notifications allowed where reasons are given; add a positive obligation to contain a breach and mitigate harm; replace the collection, use and disclosure principles (APPs 3, 4 and 6) with a single "fair and reasonable" test with seven factors; and strengthen APP 11 to require ongoing evaluation of security, retention and destruction practices and visibility over what personal information is held. It would not remove the small business exemption or the employee records exemption, and it does not add a direct right of action beyond the statutory tort. Commencement dates in the draft are blank and, on tranche one's precedent, the penalty and power provisions are likely to commence on Royal Assent. Second, the OAIC's own practice: its enforcement since 2024 has treated the time between awareness and notification as a contravention in its own right, as the Australian Clinical Labs case shows.

What the regulators have done with these powers

Three matters between October 2025 and July 2026 set the current meaning of "reasonable steps" more clearly than any guidance.

Australian Information Commissioner v Australian Clinical Labs Limited (No 2) [2025] FCA 1224, decided 7 October 2025, was the first civil penalty ordered under the Privacy Act: $5.8 million, made up of $4.2 million for 223,000 contraventions of APP 11.1 (one per affected individual), $800,000 for failing to carry out a reasonable and expeditious assessment of a suspected breach, and $800,000 for failing to notify as soon as practicable, plus $400,000 toward the OAIC's costs. ACL had acquired the Medlab Pathology business on 19 December 2021; Medlab was hit by ransomware in February 2022; ASD warned ACL on 25 March 2022 that Medlab data might have been ransomed; the third-party investigation ACL commissioned examined 13 of 127 computers, did not profile the attacker and reviewed logs only to a limited extent; data appeared on the dark web by 16 June 2022; ACL notified the OAIC on 10 July 2022 and affected individuals on 27 October 2022. The court's findings for a risk management reader: Medlab's capability to detect and respond was deficient and ACL neither found that before the acquisition nor fixed it quickly after; heavy reliance on a single third-party provider in place of internal capability was itself a failure; and an assessment that is not reasonable and expeditious is a separate contravention from the breach. The per-individual penalty theory is what makes the headline figures large, and it is the theory the OAIC is running in its civil penalty proceedings against Optus (commenced May 2024) and Medibank (commenced June 2024), which arise from the 2022 breaches; watch for those outcomes, because they will set the figures for breaches at the ten-million-individual scale.

Australian Securities and Investments Commission v FIIG Securities Limited [2026] FCA 92, orders made by consent on 9 February 2026, was ASIC's first penalty for cyber security failures: $2.5 million plus $500,000 costs and an independent compliance expert. FIIG, a fixed-income broker holding an Australian financial services licence, suffered a May 2023 intrusion in which about 385 gigabytes of data on about 18,000 clients was stolen; ASD alerted it on 2 June 2023 and it did not properly investigate until 8 June. The admitted failures read like an Essential Eight assessment report: weak passwords and access controls for privileged accounts; no multi-factor authentication for remote access; no regular penetration testing or vulnerability scanning; firewalls and security software not configured appropriately; no incident response plan tested at least annually; no mandatory cyber security awareness training; insufficient resources and no suitably qualified people; no one monitoring threat alerts; no structured patching plan; endpoint detection software not monitored daily; and gaps in Active Directory configuration, log retention and control reviews. The legal basis was the Corporations Act, not the Privacy Act: sections 912A(1)(a), (d) and (h), the licensee's obligations to provide financial services efficiently, honestly and fairly, to have adequate resources, and to have adequate risk management systems. Justice Derrington noted that a successful attack does not of itself prove a breach; what proved it was the absence of the controls. ASIC's earlier case, against RI Advice (judgment 2022, proceedings from 2020), had established the principle at a general level; FIIG shows the regulator now expects a specific, scheduled control set, and the court accepting that list is the closest thing Australia has to a judicially endorsed minimum standard for a regulated financial firm.

The Qantas preliminary inquiries, closed by the Privacy Commissioner on 16 July 2026, are the counterweight. In mid-2025 an attacker used social engineering against an overseas contact centre provider Qantas had contracted and obtained personal information of about five million Australians. The Commissioner's inquiries found that Qantas had audited the provider before the incident, had trained the contact centre agents in cyber and data protection, had processes to destroy or de-identify information no longer needed, and had acted to reduce the impact during and after the breach; she concluded that the evidence did not support a likely breach of the Privacy Act, that a breach can occur despite reasonable steps, and that a full investigation would not be proportionate. The lesson pairs with ACL: reasonable steps are what you did before the breach and how you handled the breach, not whether a breach happened. The same release carried the Commissioner's warning that agentic and advanced AI will increase cyber security risk and that organisations should continuously review and strengthen their security.

The Cyber Security Act 2024

Australia's first standalone cyber security statute, the Cyber Security Act 2024, received Royal Assent on 29 November 2024 and, as the Department of Home Affairs summarises it, created four things, each with a risk management consequence.

Ransomware and cyber extortion payment reporting, in force from 30 May 2025. An organisation with annual turnover above $3 million (and every responsible entity for a critical infrastructure asset, regardless of turnover) that makes, or has made on its behalf, a ransomware or cyber extortion payment must report it to the Department of Home Affairs through ASD's ReportCyber within 72 hours of making the payment or becoming aware that it was made. The report covers the incident, the demand, the payment and the communications with the extorting party. The penalty for not reporting is a civil penalty of 60 penalty units (about $19,800 at the current penalty unit value), modest by design; the obligation is about visibility, not punishment, and Australia has not banned ransom payments. For the register: the decision to pay is an executive decision with a legal clock attached, the incident plan must name who makes it and who reports it, and any cyber insurance policy that covers ransom payments must be read alongside this obligation.

A limited use obligation, protecting information an organisation voluntarily gives the National Cyber Security Coordinator or ASD during an incident from being used against it in civil or regulatory proceedings (with exceptions, including for criminal matters and for enforcing the Act itself). It exists to make early engagement with ASD safe, and it changes the calculus in an incident plan: calling ASD early is now the lower-risk option.

The Cyber Incident Review Board, a no-fault body modelled on transport safety investigation, established under rules in force from 30 May 2025, with its members appointed on 4 May 2026 under the chair of Narelle Devine, Telstra's global chief information security officer, alongside senior security executives and academics from Boeing Australia, NBN Co, Toll, SA Power Networks, Allens and UNSW. It will review significant incidents and publish recommendations; no review had been announced at the time of the appointment. Expect its reports to become, over time, the Australian equivalent of the US Cyber Safety Review Board's reports on Microsoft and on Log4j, and a source of lessons for registers.

Security standards for consumer smart devices, under rules registered on 4 March 2025 and in force from 4 March 2026: manufacturers and suppliers of internet-connectable consumer devices must meet minimum security requirements drawn from the European standard ETSI EN 303 645 (no universal default passwords, a vulnerability disclosure policy, and transparency about the period of security updates) and provide a statement of compliance. For a risk register this is a supply chain question: devices bought from March 2026 should carry the statement, and the fleet bought before it does not.

The Security of Critical Infrastructure Act 2018

The SOCI Act applies to responsible entities for critical infrastructure assets across eleven sectors (communications, data storage or processing, defence industry, energy, financial services and markets, food and grocery, health care and medical, higher education and research, space technology, transport, and water and sewerage). The obligations that drive cyber risk management: registration of the asset; mandatory cyber incident reporting to ASD within 12 hours of becoming aware of an incident having a significant impact on the asset's availability, and within 72 hours for one having a relevant impact; and, for the asset classes to which it has been switched on, a Critical Infrastructure Risk Management Program (CIRMP) covering cyber and information security, personnel, supply chain and physical and natural hazards, with an annual report approved by the board within 90 days of the end of the financial year. The Security of Critical Infrastructure and Other Legislation Amendment (Enhanced Response and Prevention) Act 2024 extended the regime to data storage systems that hold business-critical data and are used with a critical asset, widened the Government's information-gathering and direction powers to all serious incidents with relevant impacts rather than only cyber ones, and gave the Secretary of Home Affairs the power to direct an entity to vary a CIRMP that has a serious deficiency, with a civil penalty of up to 250 penalty units for non-compliance. Anyone whose employer is a responsible entity, or supplies one, is working inside this regime, and the annual CIRMP attestation is one of the maturity reporting mechanisms the unit asks about.

Directors, ASIC and APRA

The Corporations Act 2001 imposes on directors and officers a duty of care and diligence (section 180) that ASIC has said, and the AICD principles assume, extends to oversight of cyber risk; the FIIG and RI Advice cases apply the licensee obligations in section 912A, and ASIC has stated that it will consider action against individual directors where cyber governance is deficient, although it has not yet brought one. For APRA-regulated entities (banks, insurers, superannuation funds), CPS 234 Information Security (2019) requires board accountability for information security, a capability commensurate with the threat, control testing, and notification to APRA within 72 hours of a material information security incident and within 10 business days of a material control weakness that cannot be remediated promptly. CPS 230 Operational Risk Management, in force from 1 July 2025 (with transition for existing arrangements with material service providers to 1 July 2026), requires an operational risk management framework, tolerance levels for disruption to critical operations, business continuity planning and a register of material service providers with contractual rights to information and audit. CPS 230 is the clearest statutory expression in Australia of the third-party risk that the rest of this page keeps returning to.

The Scams Prevention Framework

The Scams Prevention Framework Act 2025 took effect on 21 February 2025 and creates obligations on designated sectors to prevent, detect, report, disrupt and respond to scams, overseen by the ACCC, with sector codes and a single external dispute resolution scheme. Banks, telecommunications providers and digital platforms were designated by instrument in force from 23 May 2026; the sector codes and rules were released as exposure drafts on 28 May 2026; and the first substantive obligations commence no earlier than 31 March 2027. The connection to this unit is that business email compromise and payment redirection, which are scams in the Act's terms and cyber incidents in ASD's, now have a regulatory framework on the financial institution side, and that an organisation's own payment verification control (ISM-2126 again) is what determines whether a loss is recoverable.

Criminal law and the Northern Territory

Part 10.7 of the Criminal Code Act 1995 creates the Commonwealth computer offences (unauthorised access, modification and impairment), relevant here because the unit's threats are crimes, because an organisation's own testing must stay within authorisation, and because the Australian Federal Police and state police are among the external escalation routes.

For the NT public sector, the Information Act 2002 (NT) contains the Information Privacy Principles that bind NT government agencies and local councils, with the NT Information Commissioner as regulator; the Act has no mandatory data breach notification scheme of its own, though the Commissioner encourages voluntary notification, and an NT agency that is also a Commonwealth contracted service provider or handles tax file numbers picks up Commonwealth obligations as well. The state picture is uneven: New South Wales has had a mandatory notification scheme for its public sector since November 2023, Queensland's commenced on 1 July 2025, and Western Australia's Privacy and Responsible Information Sharing Act commenced on 1 July 2026; Victoria, South Australia, Tasmania, the ACT and the NT had none as at October 2026. A risk register for a public body therefore has to be built against the jurisdiction's own Act, not the Commonwealth one.

Government policy that sets the baseline

The 2023 to 2030 Australian Cyber Security Strategy is the policy frame for all of the above; the Government announced its second phase, Horizon 2, on 11 June 2026, and the Cyber Security Act, the SOCI amendments, the smart device standards, the ransomware reporting rule and the Essentials series all descend from the strategy's first horizon. For Commonwealth entities the PSPF, published in annual releases, mandates the Essential Eight and the ISM; for everyone else they are guidance that regulators, courts and insurers treat as the measure of reasonableness.

Established international legislation

The unit asks for "established international legislation" and the 2020 material offers GDPR and the CCPA. Both remain, and four more regimes now matter to an Australian organisation, either because it operates or sells into those jurisdictions, because its suppliers do, or because Australian law has borrowed from them.

The EU General Data Protection Regulation (in force since 25 May 2018) is still the reference point: it applies to processing of EU residents' data wherever the processor sits, requires breach notification to the supervisory authority within 72 hours, and carries penalties of up to 4 per cent of global annual turnover or €20 million. Australia's 72-hour proposal in tranche two is a direct borrowing.

The EU NIS2 Directive (transposition deadline 17 October 2024) imposes risk management and incident reporting obligations on essential and important entities across eighteen sectors, with a 24-hour early warning, a 72-hour incident notification and a one-month final report; transposition is uneven, and on 8 July 2026 the European Commission referred Spain, Ireland, France and the Netherlands to the Court of Justice for failing to notify complete transposition. The Digital Operational Resilience Act (DORA) has applied to EU financial entities and their critical ICT providers since 17 January 2025 and is the European counterpart to CPS 230. The EU Cyber Resilience Act places security obligations on manufacturers of products with digital elements; its vulnerability and incident reporting obligations (a 24-hour early warning of an actively exploited vulnerability, 72-hour notification, final report within 14 days of a fix) apply from 11 September 2026, with the rest of the regulation applying from 11 December 2027, and Australia's smart device standard is the consumer-grade cousin of the same idea. The EU AI Act became generally applicable on 2 August 2026, though the AI Digital Omnibus (Regulation (EU) 2026/1744) deferred a substantial part of the high-risk obligations to December 2027 and August 2028.

In the United States, the SEC's cyber security disclosure rules (in force from December 2023) require listed companies to disclose a material cyber security incident on Form 8-K within four business days of determining it is material, and to describe their cyber risk management and governance annually; Australian companies listed in the US, and the Australian subsidiaries of US groups, are inside this. The Cyber Incident Reporting for Critical Infrastructure Act (CIRCIA) of 2022 will require covered entities to report incidents to CISA within 72 hours and ransom payments within 24 hours; the final rule was sent to the Office of Management and Budget for review on 1 October 2026 after missing an October 2025 statutory deadline, and reporting becomes mandatory only once it is published and takes effect. The California Consumer Privacy Act, as amended by the California Privacy Rights Act, remains the leading US state privacy law, now one of around twenty.

The United Kingdom's Cyber Security and Resilience (Network and Information Systems) Bill, introduced to the Commons in November 2025 to update the UK's NIS regime and extend it to managed service providers and data centres with a 24-hour initial incident report, was at report stage in the House of Lords in October 2026 and had not received Royal Assent. New Zealand's Privacy Act 2020 requires notification of privacy breaches causing serious harm "as soon as practicable", in the Australian pattern.

The reporting clocks, in one place

The practical output of all of this for an incident response plan and a risk register is a table of who must be told, by when, and from what moment the clock runs. As at October 2026, for an Australian organisation:

Obligation	Who it binds	Clock	Runs from
Eligible data breach notification, Privacy Act Part IIIC	All APP entities	As soon as practicable; assessment of a suspected breach within 30 days. Tranche two proposes 72 hours to notify the OAIC	Reasonable grounds to believe (or suspect) an eligible data breach
Ransomware or cyber extortion payment report, Cyber Security Act 2024	Businesses with turnover above $3 million; all SOCI responsible entities	72 hours	Making the payment, or becoming aware it was made
Critical infrastructure cyber incident report, SOCI Act Part 2B	Responsible entities for critical infrastructure assets	12 hours (significant impact on availability); 72 hours (relevant impact)	Becoming aware of the incident
Material information security incident, APRA CPS 234	APRA-regulated entities	72 hours; material control weakness within 10 business days	Becoming aware
Material cyber incident disclosure, SEC Form 8-K Item 1.05	US-listed companies	Four business days	Determining the incident is material
Personal data breach, GDPR Article 33	Controllers processing EU residents' data	72 hours	Becoming aware
Significant incident, EU NIS2	Essential and important entities in the EU	24-hour early warning; 72-hour notification; one-month final report	Becoming aware
Actively exploited vulnerability or severe incident, EU Cyber Resilience Act	Manufacturers of products with digital elements sold in the EU	24-hour early warning; 72 hours; 14 days after a fix	Becoming aware (obligation applies from 11 September 2026)
Cyber insurance notification	Policyholders	As the policy states; often "immediately" and before engaging responders	Discovery

A risk register entry for "we miss a mandatory reporting deadline" is now a reasonable thing to have, with the incident plan's notification map as its control.

Element 2 begins with supporting the communication of approved risk management strategies to required personnel, and the knowledge evidence asks for procedures for developing communications plans. A strategy that has been approved but not communicated is still only a document.

What a communications plan contains

A communications plan for a risk management strategy, in the form most organisations use, is a table: for each audience, the message they need, the channel, the timing and frequency, the owner, the evidence that it landed, and the route for feedback. The audiences for a typical cyber risk strategy and the message each needs:

• All staff need to know what has changed for them (a new MFA method, a new way to report suspicious email, a new rule about AI tools), why (the risk, in one sentence), and what to do. Channel: a short all-staff message from a leader, repeated at team meetings, with a one-page quick reference, and a training module where behaviour has to change.
• Managers and team leads need the same plus their role in it (checking completion, handling questions, modelling the behaviour) and the escalation route. Channel: a managers' briefing before the all-staff message, so they are not learning it at the same time as their teams.
• IT and security operations need the technical detail, the implementation plan, the monitoring they are expected to run and the thresholds for escalation. Channel: the treatment plan itself and a change record.
• Executives and the board need confirmation of what was approved, the implementation timeline, the key risk indicators they will see and when, and the residual risk they have accepted. Channel: the governance reporting cycle.
• Suppliers and partners affected by a control (a managed service provider who has to change how they access systems, a contact centre provider who has to meet a new standard) need the requirement in writing, a date and a confirmation step. Channel: contract variation or a formal notice, not an email thread.
• Customers and the public, where a change affects them (a new authentication step on a portal), need plain-language notice in advance.

The learner guide's channel discussion (email, print, face-to-face, teleconference, visual aids) is still accurate as far as it goes; the practical rule is that behaviour change needs more than one channel and more than one exposure, that the message should come from the line of authority the audience answers to rather than from "IT", and that a control which changes how people work needs a feedback route open before it goes live, because the first week will find the cases nobody anticipated.

Policies, standards, procedures and guidelines

The unit's knowledge evidence repeatedly refers to organisational policies and procedures, and the distinction between the document types is itself part of communicating a strategy. A policy states what the organisation requires and why, at a level that rarely changes, and is approved at executive or board level ("all access to systems holding personal information requires multi-factor authentication"). A standard sets the specific, measurable requirement that satisfies the policy ("phishing-resistant MFA per ISM guidance; SMS codes are not acceptable for privileged accounts"). A procedure is the step-by-step instruction for doing a task ("how to enrol a new staff member's authenticator"). A guideline is recommended practice where the organisation allows discretion. The learner guide's example of a physical access policy and its reception procedure illustrates the layering. An approved risk management strategy is usually communicated by updating all four: the policy carries the decision, the standard carries the control, the procedure carries the work, and the guideline carries the advice.

The policies a cyber risk program normally rests on: information security (the umbrella), acceptable use, access control and authentication, data classification and handling, incident response, business continuity and disaster recovery, third-party and supplier security, change management, backup, remote working and bring-your-own-device, and, since 2024 in most organisations, acceptable use of artificial intelligence. Each should name an owner, a review cycle and the standard it points to, and each is a line in the compliance monitoring described next.

Two performance criteria sit here: contributing to monitoring cyber security risk according to the selected strategies, and assisting in determining compliance with the implemented mitigation strategies. They are different activities and it helps to keep them apart. Monitoring risk asks "is the risk changing?"; checking compliance asks "are the controls we approved actually in place and being followed?". The learner guide's treatment of monitoring is a 2020 vendor product list (one of the products named, SolarWinds, was itself the vehicle of the most consequential supply chain compromise of that year), so this section is built fresh.

Monitoring the risk: key risk indicators

A key risk indicator (KRI) is a measurable quantity that moves before the risk materialises, chosen so that a change in it triggers attention. A key performance indicator (KPI) measures whether an activity is being done. The distinction is the one the learner guide draws between KPIs and benchmarks, applied one level down: "percentage of staff who completed training" is a KPI for the training strategy; "phishing simulation click rate" and "number of real phishing emails reported per month" are KRIs for the credential compromise risk. Good KRIs for the common cyber risks:

• Credential compromise: MFA coverage (per cent of accounts, and per cent of privileged accounts, with phishing-resistant methods); number of accounts with legacy authentication enabled; sign-in risk events flagged by the identity provider; phishing simulation click and report rates; count of consent grants to third-party applications.
• Ransomware and exploitation: number of internet-facing systems with a critical or exploited vulnerability older than 48 hours; median time to patch by severity; count of systems past end of support; EDR coverage; last successful backup restore test and the time it took.
• Third-party risk: number of suppliers holding personal information without a current security assessment; number of supplier accounts with standing privileged access; supplier incident notifications received.
• Detection and response: mean time to detect and mean time to respond for the incidents that occurred; alert backlog; percentage of alerts triaged within the service level.
• Data: volume of personal information held past its retention period; number of unstructured data stores with open sharing.

Each KRI needs a threshold (the green, amber and red bands), an owner, a source (ideally a system that produces it automatically rather than a person compiling it) and a reporting cadence. A dozen well-chosen indicators on one page, trended over time, are more useful to an executive than a fifty-line dashboard, and the trend is the point: a KRI that has never changed is either a very stable control or a number nobody is actually measuring.

The tooling that does the measuring

The categories, rather than products, because the products change yearly. Endpoint detection and response (EDR) on every workstation and server, monitored daily by someone qualified (the FIIG failure list includes EDR that was installed but not watched). Security information and event management (SIEM), or its cloud-native equivalents, to centralise logs and alert on patterns; ASD's first 2025 recommendation was best-practice logging, and the September 2026 ISM expects provider access, OAuth consents, certificate services, AI agent tool use and WMI activity all to be logged centrally. Managed detection and response (MDR) services for organisations that cannot staff monitoring around the clock, which is most organisations below a few hundred staff. Vulnerability management platforms that scan, score with CVSS and EPSS, and track time to remediate. Identity provider signals (Microsoft Entra, Google Workspace, Okta) for risky sign-ins, impossible travel, token anomalies and consent grants, which for a cloud-first organisation are the richest detective source there is. Attack surface management services that show what the organisation looks like from the internet. Essential Eight assessment tooling, including ASD's own guidance and the commercial scanners that report maturity per strategy. The monitoring design task is to decide which of these produce the KRIs above, who reads the output, and what happens when a threshold is crossed; a tool with no reader is a cost, not a control.

Determining compliance with the implemented strategies

Compliance checking asks whether the approved controls exist, are configured as the standard requires, and are being operated as the procedure describes. The FIIG and ACL judgments, and APRA's CPS 234 supervision, all turn on the gap between a control's existence on paper and its operating effectiveness, so the checking has to look at both. The methods, in increasing order of independence:

• Self-assessment by the control owner against a checklist (the Essential Eight Maturity Model's own assessment guidance is the most used in Australia). Fast and cheap, and the least reliable, because people assess their own work generously.
• Configuration and evidence review by someone else: pulling the MFA policy from the tenant rather than asking whether MFA is on; sampling training completion records; reading the backup job logs and the restore test report; checking patch status from the vulnerability scanner rather than the change tickets.
• Technical testing: vulnerability scans, penetration tests (the ISM now expects both every six months after deployment), phishing simulations, backup restore tests, and the Essential Eight assessment process, which ASD publishes as a method with a defined evidence standard.
• Internal audit, as the third line, testing controls on a sample basis against the standard and reporting to the audit committee.
• External assessment: an IRAP assessment for systems handling government data, an ISO/IEC 27001 certification audit, a CPS 234 tripartite review for APRA entities, a SOC 2 Type II report for a provider, or the independent compliance expert the court imposed on FIIG.

The output is a compliance report that says, for each approved control: in place or not; configured to standard or not; operating as intended or not; the evidence relied on; and the gaps, each with an owner and a date. Non-compliance found here feeds the next section.

Reporting mechanisms for tracking cyber security maturity

The unit's knowledge evidence asks specifically about mechanisms for tracking organisational cyber security maturity, and in Australia in 2026 there are several, each with a defined audience:

• Essential Eight maturity assessment, reported per strategy as Maturity Level Zero to Three against a target level, following ASD's assessment process guide. The common currency of Australian cyber maturity reporting and the one the PSPF requires Commonwealth entities to report annually. Its future name may change with the Essentials series; its function will not.
• NIST CSF 2.0 tiers and profiles, used to describe program maturity (Partial to Adaptive) and to show the gap between the current and target profile; the natural choice for an organisation that reports to international parents or partners.
• ISO/IEC 27001 certification and surveillance audits, which report conformity rather than maturity but are what customers ask for.
• The SOCI annual CIRMP report, board-approved, which attests to the risk management program for critical infrastructure assets and must now disclose any variation directions received.
• CPS 234 and CPS 230 reporting to APRA, including the periodic independent tripartite review of information security that APRA has run across regulated entities since 2021.
• Board and audit committee reporting, usually quarterly, built on the KRIs above, the register summary, incident statistics and the status of treatments, framed against the AICD principles.
• Cyber insurance proposal forms, which are a maturity attestation in all but name and are now renewed annually with increasing specificity.
• Capability maturity models with five-level scales (initial, repeatable, defined, managed, optimising), which some organisations prefer for program-level reporting; the US Department of Energy's C2M2 is the best-known cyber-specific one.

The thing to understand about maturity reporting is that each mechanism measures something slightly different (controls, program, conformity, attestation) and a board that sees "Maturity Level Two" without knowing which mechanism produced it has been told less than it thinks. The contributor's job is usually to assemble the evidence and draft the report; being able to say which measure it is, and what it does not cover, is the competence.

Element 2 closes with two performance criteria: addressing non-compliance within the scope of your own role and escalating where required, and assisting in establishing feedback processes that give warning of potential new risks.

Addressing non-compliance

Non-compliance is any case where an approved control is not in place, not configured to standard or not being followed, and it is found by the compliance checking above, by monitoring, by an incident, or by someone reporting it. The learner guide treats it mostly as a people problem (knowledge, motivation, role confusion, laziness), which is one source among several. A fuller diagnosis, because the fix depends on the cause:

• The control was never implemented (the project slipped, the budget went elsewhere, the supplier did not deliver). Fix: the treatment plan's owner and date, escalated if the date has passed.
• The control was implemented but is misconfigured or has decayed (the MFA policy excludes a group someone added for a vendor; the backup job has been failing silently since a storage change). Fix: a change under change management, and a KRI so it is seen next time.
• The control is in place but people are working around it because it obstructs the work (shared accounts because provisioning takes a week; files emailed to personal accounts because the file share does not work from home). Fix: usually the process, not the person; a control that generates workarounds is a control with a design problem, and the feedback route is how you find out.
• The control is being deliberately bypassed (a privileged user disabling EDR, a manager instructing staff to ignore a policy). Fix: escalation, every time, through the route the policy names, and with the evidence preserved, because this is a conduct matter and potentially an insider threat.
• The standard itself is wrong or out of date (a password policy still requiring 90-day rotation that the ISM stopped recommending years ago). Fix: update the standard, through its owner.

"Within the scope of own role" governs the response. A contributor can raise a non-compliance with the control owner, agree a fix and a date, record it in the register, and follow it up; can correct a configuration they are authorised to change; and can provide training or a reminder. A contributor cannot discipline, cannot accept a risk on the organisation's behalf, cannot override a manager, and should not investigate suspected misconduct beyond preserving the evidence. The learner guide's advice on the conversation is good: articulate the impact, be factual, show what you have already tried, keep it about the behaviour and not the person. When that does not resolve it, or when the non-compliance is serious, deliberate, or involves personal information or a legal obligation, the escalation route takes over.

Escalation, in practice

The escalation route was designed in the strategies section; here it is used. The things that decide the level: the rating of the risk the control was treating (non-compliance in a control for an extreme risk is itself an extreme finding); whether a legal obligation is engaged (a privacy officer must know immediately about any non-compliance that could already have resulted in unauthorised access to personal information, because the assessment clock may have started); whether the non-compliance is deliberate; whether it involves a privileged user or a supplier; and whether the control owner has the authority and resources to fix it. Each escalation should be in writing, should say what was found, when, the evidence, the risk, what has been done, and what decision or action is being requested, and should name the time by which a response is needed. The register's change log records that the escalation happened. If the person escalated to decides to accept the risk rather than fix the control, that is their decision to make and the risk acceptance record is where it goes; if they are not the person with that authority, the escalation continues upward.

Organisational policies set the route and the contributor follows it, which is the point of the performance criterion's wording. Where no policy says who to escalate to, the default is the control owner, then the risk owner, then the person the risk owner reports to, and in any case involving personal information, the privacy officer in parallel.

Feedback processes that warn of new risks

The last performance criterion in Element 2 asks for feedback processes that provide warning of potential new risks, according to organisational requirements. The learner guide answers this with customer satisfaction surveys and net promoter scores, which is not what the unit is asking for. Feedback here means the channels through which the organisation learns, early, that a risk has changed or a new one has appeared. The ones that matter:

• Staff reporting, through the single reporting channel in the escalation route, for suspicious email, lost devices, odd system behaviour, pressure to bypass a control, and near misses. The volume of reports is itself a KRI: a rise in reported phishing is a warning that a campaign is targeting the organisation; a fall to zero is a warning that the channel has stopped working.
• Near-miss and incident reviews, with every incident, however small, producing a short lessons-learned record that is checked against the register: was the risk on it, was it rated right, did the control work, what does the register need to say now.
• Threat intelligence inputs: ASD alerts and the Partnership Program, sector sharing bodies, vendor advisories, the CISA KEV catalogue, and the regular threat assessment, each with a named person responsible for reading it and a procedure for turning a relevant item into a register review.
• Change triggers, built into the organisation's own processes: new system or supplier onboarding has a security review step; the change advisory board asks the risk question; procurement asks for the supplier's security posture; projects have a risk assessment gate; the HR process flags role changes and departures for access review; the legal or compliance function tracks legislation.
• Supplier notifications, required by contract: a provider must tell the organisation of incidents affecting its data within a stated time, and the ISM now expects all provider access to be logged in a way the provider cannot alter (ISM-2125).
• Monitoring thresholds: the KRIs above, with amber and red bands that generate a review rather than a dashboard colour.
• Audit and assessment findings, from internal audit, external assessment, penetration tests and the Essential Eight assessment, each finding becoming a register entry or a treatment action.
• Regulatory and legal horizon scanning: someone reads the OAIC, ASD, Home Affairs, APRA and ACCC releases, the legislation tracker, and the sector regulator, and raises anything with a commencement date as a compliance risk with that date. The 10 December 2026 privacy commencements and the tranche two bill are the current examples.
• Customer and public feedback, which the learner guide was reaching for: a customer who reports a phishing email impersonating the organisation, or a researcher who reports a vulnerability in the website, needs a route in and a response. A published vulnerability disclosure policy with a security contact (a security.txt file on the website is the convention) is now expected of any organisation with a public web presence and is required of smart device manufacturers.

"According to organisational requirements" means the feedback processes should be formalised in the policies and procedures, with owners and cadences, not left to whoever happens to read the news. A culture where people report what they see without fear is the precondition for all of it, which is why the phishing simulation guidance above matters beyond phishing.

Element 3 asks for benchmarks to track the effectiveness of risk management strategies, support for evaluating that effectiveness, and updating the strategies with new information. This is the "did it work?" step, and it is the one most organisations do least well, because the people who implemented a control rarely want to find out that it is not working.

Choosing benchmarks

The learner guide's distinction holds: a KPI measures progress against the organisation's own goal; a benchmark compares against a reference point, which may be the organisation's own past, a peer, an industry figure or a published standard. Both are needed. The reference points available for cyber risk management in Australia:

• Published control baselines, which give a binary or graded benchmark: the Essential Eight Maturity Model's target level (is each strategy at the level we set?); the ISM's controls for the system's classification; CIS Controls Implementation Group 1 as "essential cyber hygiene"; the cyber insurer's minimum control set; and, where a regulator has effectively endorsed a list, that list (the FIIG failure list, read in the positive, is a reasonable benchmark for a small financial firm).
• Published statistics for the sector, which benchmark exposure and outcomes: the OAIC's dashboard figures for the sector's breach sources and the time taken to identify and notify; ASD's incident and cost figures; IBM's annual Cost of a Data Breach report, whose 2026 edition put the Australian average at $4.22 million (financial services $6.31 million, technology $5.51 million, health $5.09 million), with breaches that took more than 200 days to identify and contain costing $5.17 million against $3.26 million for those resolved faster; and the Verizon Data Breach Investigations Report for the global pattern.
• The organisation's own history: the same KRIs trended over quarters and years, which is the benchmark that most reliably shows whether a strategy is working.
• Peers, through sector sharing groups and the ASD Partnership Program, where organisations compare maturity levels and incident experience in confidence.
• Time-based benchmarks drawn from the law and the frameworks: 48 hours to patch an exploited internet-facing vulnerability; 30 days to assess a suspected breach; the organisation's own stated recovery time objective for each critical system; mean time to detect and respond compared with the previous period.

The benchmarks for a given strategy should be chosen when the strategy is approved, not after, so that the "before" measurement exists. A training strategy approved in March with a benchmark of "simulation click rate below 5 per cent and report rate above 60 per cent within twelve months, from a baseline of 18 per cent and 12 per cent" can be evaluated; one approved with no baseline cannot.

Evaluating effectiveness

Effectiveness is evaluated against three questions, in order. Was the strategy implemented as approved, on time and within budget (an implementation question, answered by the compliance checking)? Is the control operating as intended (an operating-effectiveness question, answered by testing: restore the backup, run the simulation, attempt the lateral movement in a penetration test, check the logs are actually reaching the SIEM)? And has the risk moved to its target residual rating (an outcome question, answered by the KRIs, the incident record and a re-assessment of the risk with the control's measured effectiveness in place)? A strategy can pass the first two and fail the third, which usually means the analysis underestimated the threat or the control was treating the wrong vulnerability; that is a finding, not a failure of the evaluation.

The methods, drawn from the same list as compliance checking but aimed at outcome: control testing and technical testing; the incident and near-miss record read against the register (did the risks that materialised have the rating and the controls the register said?); tabletop and live exercises of the incident plan, scored against the plan's own objectives and against the reporting clocks; red team or adversary emulation exercises built from ATT&CK techniques, for organisations at the level where that is proportionate; post-implementation reviews at a set interval after each treatment; and, for the program as a whole, the periodic maturity assessment. The learner guide's long description of a consultant-led framework review (its "Y model" of present situation, wanted situation and what needs to change) is one way to do a whole-of-program evaluation and is not wrong; the lighter version most organisations can afford is an annual review of the register and the treatment plan with the risk owners, informed by a year of KRIs, incidents and test results, producing a short report to the executive on what worked, what did not, and what is proposed.

Updating the strategies

The last performance criterion is updating risk management strategies with new information as required, and it closes the ISO 31000 loop. The inputs are everything the feedback and evaluation steps produce: a changed threat, a new vulnerability, an incident, a test result, an audit finding, a change in the business, a new supplier, a new law, a control that turned out not to work, or a control that worked so well the residual risk is now within appetite and the monitoring can be lightened. The procedure for each is the same: re-assess the risk with the new information; decide whether the treatment still fits; propose the change through the same approval route the original strategy used, in proportion to the change (a configuration adjustment within the standard needs a change record; a new control with a cost needs the options paper); update the register, the treatment plan, the policies and procedures, the communications and the incident plan as applicable; re-set the benchmarks; and record the change with its reason. Then communicate it, because an updated strategy that the people who operate the control do not know about has not been updated.

flowchart LR
  A[Approved strategy and baseline benchmarks] --> B[Implement and communicate]
  B --> C[Monitor KRIs; check compliance]
  C --> D[Evaluate: implemented? operating? risk at target?]
  D -->|yes| E[Maintain; review at interval]
  D -->|no| F[Diagnose: analysis, control design, or operation]
  F --> G[Update strategy via approval route; re-set benchmarks]
  G --> B
  H[Feedback: incidents, threat intel, change triggers, audits, law] --> F
  H --> C
  E --> C

Three of the knowledge evidence items sit together here: guidelines required for updating technology, industry-specific procedures for applying risk management strategy, and the supply chain and cloud material that the 2020 unit does not name but that every one of the enforcement cases above involves.

Updating technology: patching, change and end of life

The guidelines that govern technology updates in an Australian organisation are, in descending order of authority for most: the Essential Eight's patching timeframes, the ISM's patching and change management controls, the vendor's own support lifecycle, and the organisation's change management procedure.

The Essential Eight patching timeframes (November 2023 model, as set out in the maturity model) at Maturity Level One: patches, updates or vendor mitigations for vulnerabilities in internet-facing services within 48 hours when the vendor assesses them as critical or when working exploits exist, and within two weeks otherwise; within two weeks for the commonly targeted desktop applications (office productivity suites, browsers and their extensions, email clients, PDF software, security products), tightening to 48 hours for critical or exploited vulnerabilities in those applications from Maturity Level Two; and within one month for the operating systems of workstations and of servers and network devices that are not internet-facing. Vulnerability scanning is expected daily for internet-facing services and at least weekly for the commonly targeted desktop applications. Applications and operating systems that are no longer supported by the vendor are to be removed, which is the "replace legacy technology" recommendation in ASD's threat report expressed as a control. These timeframes are the benchmark for the patching KRI, and the EPSS and KEV prioritisation described earlier is how a small team meets them.

Change management is the procedure that stops an update from becoming an incident. Its elements: a request with the risk assessed (what could this change break, and what is the back-out plan); testing in a non-production environment where one exists; staged rollout to a pilot group before the fleet; a maintenance window and communication; a back-out plan that has been tried; and a record. The lesson of 19 July 2024, when a faulty content update to CrowdStrike's Falcon sensor crashed about 8.5 million Windows systems worldwide, grounded airlines, stopped payments and closed hospitals' systems, with damage estimated above US$10 billion, is that even a security vendor's routine update is a change, that staged rollout and the ability to roll back are controls, and that the risk register should carry "a trusted vendor's update causes an outage" as a scenario with a recovery plan. Session 6's point that updates are a double-edged sword is right; the response is not to patch less, which the Essential Eight timeframes do not allow, but to patch through a process. The ISM's September 2026 release added two controls that belong here: software dependencies pinned to approved versions (ISM-2154) and reproducible builds so that release artefacts can be independently verified (ISM-2155), both responses to supply chain attacks delivered through updates.

End of life is a risk in its own right. A system past vendor support receives no patches, so every new vulnerability in it is permanent; the register should carry each such system, with the compensating controls (isolation, enhanced monitoring, restricted access) and the replacement date, and the ISM and the Essential Eight both treat unsupported software as a Maturity Level Zero finding.

The supply chain and third parties

Every enforcement case on this page involves a third party: Medlab was an acquired business; FIIG's weaknesses were found by ASD, not by FIIG; Qantas's breach was through an overseas contact centre provider; the CrowdStrike outage was a vendor's update; the SolarWinds compromise of 2020 was a vendor's build system. ASD's third 2025 recommendation is to manage third-party risk, CSF 2.0 added supply chain risk management to the Govern function, CPS 230 requires a register of material service providers with audit rights, and the AICD's version 2 added digital supply chain risk to the directors' principles. The 2020 unit does not mention any of it.

A third-party risk procedure, in the form a contributor can draft: an inventory of suppliers with access to systems or data, tiered by the sensitivity of what they hold and the criticality of what they do; a security assessment proportionate to the tier before onboarding (a questionnaire and evidence for the low tier; a SOC 2 report, ISO/IEC 27001 certificate, IRAP assessment or on-site review for the high tier); contract terms covering security requirements, incident notification within a stated time, audit rights, data location and return or destruction at exit, and sub-contracting; technical controls for supplier access (unique accounts, MFA, least privilege, time-bound and logged, which the ISM's new controls ISM-2124 and ISM-2125 now specify); monitoring during the relationship, including the supplier's own breach history and the KRIs above; and a defined exit. The Privacy Act's position is that an APP entity that discloses personal information to a provider, including an overseas one (APP 8), remains accountable for it; the Qantas outcome shows what discharging that accountability looks like, and the ACL outcome shows the alternative.

The cloud and shared responsibility

The session material's cloud content (the IaaS, PaaS and SaaS models, the shared responsibility model, the good practices) is sound and is the one part of the delivered material that did not need updating, so it is only summarised here. The provider is responsible for the security of the cloud (the physical facilities, the hardware, the virtualisation and, as the model goes up the stack, the operating system, middleware and application); the customer is responsible for security in the cloud, which at every service model includes the data, the identities and access, and the configuration of the service. The practical consequence for a risk register is that most cloud risks are identity and configuration risks, not infrastructure risks: an open storage bucket, an over-privileged service account, a tenant without conditional access, a user who consented to a malicious application. The ISM's September 2026 OAuth controls (only administrators may consent to third-party applications; consents reviewed every six months; device code flow disabled unless required) and its session protection controls (tokens bound to the issuing device; sessions revoked on credential reset or risky sign-in) are the current statement of where cloud identity risk sits. For government, the ISM's cloud guidance and the IRAP assessment of the provider set the baseline; for everyone else, the provider's own security baseline documentation (Microsoft's and Google's are extensive) and the CIS Benchmark for the platform are the standards to check configuration against.

Operational technology and connected devices

Medical devices, building management, plant control, vehicle fleets and the smart devices in the office are now on, or reachable from, the corporate network, and they have three properties that change the risk assessment: they often cannot be patched on the Essential Eight timeframes, or at all; their failure is a safety or availability consequence rather than a confidentiality one; and they were frequently installed by a contractor with a remote access path nobody reviewed. The register treatment is usually segmentation and monitoring rather than patching, the consequence scale needs a safety dimension, and the smart device security standard from March 2026 is the procurement control. ASD has foreshadowed an operational technology chapter of the Essentials series for this reason.

Industry-specific procedures

The unit asks for industry-specific knowledge of suitable procedures, and the legal section gives most of it. In summary, what changes by sector in how the same risk management process is applied:

• Health: the Privacy Act applies regardless of turnover; health information is sensitive information with the higher APP standard; the My Health Records Act 2012 adds its own obligations for connected providers; clinical safety is a consequence category; medical devices are operational technology; and health leads the OAIC's breach statistics every period.
• Financial services: CPS 234, CPS 230 and the Corporations Act licensee obligations, with APRA and ASIC as active regulators and the FIIG list as the de facto baseline; the Scams Prevention Framework from 2027; and the highest average breach cost in Australia.
• Critical infrastructure: the SOCI Act's registration, reporting and CIRMP obligations; the Cyber Security Act's ransomware reporting regardless of turnover; and the Government's direction and assistance powers.
• Commonwealth government: the PSPF, the ISM, Essential Eight maturity reporting, IRAP, and the Privacy Act's agency provisions.
• NT public sector and local government: the Information Act 2002 (NT), the NT Government's cyber policy and the shared ICT services arrangement, and the NT Information Commissioner.
• Small business: no Privacy Act coverage below $3 million unless a category applies, but the same threats, the ransomware reporting rule above $3 million, insurers' control baselines, customer contracts, and ASD's small business guidance as the practical standard.
• Education and research: SOCI coverage for higher education, large volumes of personal information about minors (with the Children's Online Privacy Code from December 2026), and research data with foreign interference considerations.

The process is the same in each; the criteria, the legal clocks, the consequence scale and the regulator differ, and the scoping step is where that is captured.

The unit was accredited before generative AI was a product. As at October 2026 artificial intelligence belongs in a cyber risk register in three distinct ways, and conflating them is the commonest error in the AI risk material now circulating.

AI as an attacker capability

The threat side first, because it changes likelihood ratings across the register. Generative models have removed the tells that security awareness training relied on: phishing email in fluent English in the organisation's own style, at scale, personalised from scraped public information; synthetic voice that passes for a known executive on a phone call; synthetic video sufficient for a conference call. The 2024 case in which an employee of the engineering firm Arup transferred about US$25 million after a video call with what appeared to be the company's chief financial officer and colleagues, all of them synthetic, is the standard illustration, and the pattern has been repeated at smaller scale against Australian businesses since. AI also lowers the cost of reconnaissance, vulnerability discovery and exploit development; ATT&CK version 20, released 13 October 2026, added AI-enabled techniques and a campaign describing an AI-assisted intrusion, which is the catalogue catching up with what incident responders have been seeing. The OAIC's Commissioner, closing the Qantas inquiries in July 2026, warned specifically that agentic and advanced AI will increase cyber security risk.

For the register, the response is not a separate "AI risk" row but a re-rating of the social engineering and reconnaissance risks already there, and a change to the controls: verification of payment and account changes through an independent, pre-established channel (ISM-2126), which no deepfake can defeat; phishing-resistant authentication, which does not care how convincing the email was; and training that teaches staff that a familiar voice or face is no longer evidence of identity.

AI as something the organisation deploys and must govern

The second way is AI inside the organisation: staff using public chatbots with company data, business units buying AI features in software they already have, developers using AI coding assistants, and, increasingly, AI agents that take actions in systems rather than only producing text. IBM's 2026 Cost of a Data Breach report found that 43 per cent of breached organisations had experienced a breach involving unsanctioned "shadow AI" (up from 20 per cent the year before), that AI-related breaches had risen from 13 to 21 per cent of the total, that only 32 per cent of breached organisations had AI policies in place, and that 92 per cent of organisations with an AI-related breach lacked proper AI access controls at the time; in Australia the same report put the average breach cost for organisations with no AI security tooling at $5.21 million against $3.46 million for those using it extensively.

The governance position in Australia, as at October 2026, is that there is no AI-specific statute. The Government's National AI Plan of December 2025 decided not to proceed with mandatory guardrails for high-risk AI and to rely on existing technology-neutral law supported by voluntary guidance, with an Australian AI Safety Institute established in early 2026 to monitor developments and recommend legislative change where existing law proves inadequate; the position is contested and worth re-checking. The guidance an Australian organisation is expected to align with is the Department of Industry, Science and Resources' Guidance for AI Adoption (21 October 2025, replacing the September 2024 Voluntary AI Safety Standard), whose six practices (decide who is accountable; understand impacts and plan accordingly; measure and manage risks; share essential information; test and monitor; maintain human control) are a risk management process in all but name. The OAIC's two guidance documents of October 2024, on using commercially available AI products and on developing and training generative AI models, establish that privacy obligations apply to personal information put into an AI system and to personal information in its output, with no exemption. Internationally, ISO/IEC 42001:2023 is the certifiable AI management system standard, built on the same structure as ISO/IEC 27001, and NIST's AI Risk Management Framework 1.0 (January 2023) is the US equivalent of the CSF for AI, with its own four functions (Govern, Map, Measure, Manage). The OWASP lists for large language model applications and for agentic applications, covered on this site's VU23222 page, catalogue the technical vulnerabilities.

The ISM's September 2026 release turned much of this into controls, and they are the current benchmark for an Australian organisation deploying AI: human approval before an AI application takes sensitive or high-impact actions (ISM-2113); a unique identity for each AI agent, distinct from users and from other agents (ISM-2133); an AI agent register recording owner, purpose, identities, credentials, and the tools and data each agent can reach (ISM-2134 and 2135); and, under the heading of excessive agency, agents limited to the minimum tools and permissions, tool use requiring both user and task-scoped authorisation, external content treated as untrusted, and all tool invocations and outputs logged (ISM-2156 to 2159). The register entries that follow: unsanctioned use of public AI services with personal or confidential information (treat with an AI acceptable use policy, approved tools, data loss prevention and training); AI features in procured software that process personal information in ways the privacy policy does not describe (treat through procurement review and the APP 1 and APP 5 obligations); AI agents with standing access to systems (treat through the ISM controls above); and reliance on AI output without human review in decisions that affect people (treat through the human control practice and, from 10 December 2026, the automated decision-making transparency requirement).

AI as a control

The third way is the defender's. EDR, identity providers, email security and SIEM platforms now use machine learning for detection, and generative assistants are being built into security operations tooling for triage and investigation; the IBM figures above suggest the organisations using them extensively detect breaches faster (68 days faster in Australia in the 2026 report) and spend less per breach. For this unit, two points. AI in the security stack is a control like any other, to be evaluated for operating effectiveness, and its own failure modes (false positives, model drift, an attacker learning what it does not detect) belong in the register. And AI assistants are a reasonable tool for drafting the documents this unit describes, a first draft of a risk register, an incident plan, a policy, provided the person using them knows the subject well enough to find what is wrong, verifies every legal and framework reference against the source, and treats the output as a draft for human judgement, which is the same standard the unit sets for the human contributor.

The knowledge evidence asks for business process design principles in relation to risk management. The principle underneath all of them is that risk is cheapest to manage when it is designed out of the process rather than controlled after the fact, and the specific principles a contributor should be able to apply when reviewing or designing a process:

• Secure by design and privacy by design. Security and privacy requirements are specified at the start of a project or process change, risk-assessed at the design stage, and verified before go-live, rather than added by the security team afterwards. The project risk assessment gate in the feedback section is the mechanism; ASD and its international partners' Secure by Design guidance, and the OAIC's privacy impact assessment guidance, are the references.
• Data minimisation. Collect only the personal information the process needs, keep it only as long as it is needed, and destroy or de-identify it after (APP 3 and APP 11.2 now; the "fair and reasonable" test and the strengthened APP 11 if tranche two passes). A process that does not hold the data cannot breach it.
• Least privilege and separation of duties. Each role in a process gets the access it needs and no more, and no single person can both initiate and approve a sensitive action (a payment, a change to a supplier's bank details, a privileged configuration change). The payment verification control that defeats business email compromise is a separation-of-duties control.
• Defence in depth. No process relies on a single control; a phishing email has to get through the filter, the user, the MFA, the conditional access policy, the EDR and the monitoring before it becomes an incident. Design the process so that each layer is independent.
• Fail safe and fail closed. When a control fails, the process should stop or degrade to a safe state rather than continue without the control; a payment process whose verification step is "unless the approver is on leave" has designed its own bypass.
• Resilience and recoverability. Every critical process has a documented recovery time objective and recovery point objective, a tested way to operate without its systems for the duration of the RTO, and backups that can meet the RPO. Business continuity and disaster recovery planning is risk treatment for the availability risks, and CPS 230 made it a regulatory requirement for financial entities.
• Auditability. The process produces records sufficient to show afterwards who did what and when; logging is a design decision, and ASD's first recommendation in its 2025 threat report was better logging because so many incident investigations founder on its absence.
• Human factors. A control that people cannot comply with while doing their job will be worked around; design the secure path to be the easy path (single sign-on, password managers, a report-phishing button, a fast provisioning process).
• Proportionality. The control set should fit the risk; a process that moves no money and holds no personal information does not need the same design as one that does, and over-controlling the low-risk processes is how security teams lose the goodwill they need for the high-risk ones.

Mapping a process (who does what, with which system, handling which data, approved by whom) is the first step of applying any of these, and a process map with the risks and controls annotated on it is one of the most persuasive documents a contributor can put in front of a process owner, because it shows the control in the owner's own terms rather than the security team's.

To make the elements concrete, here is the cycle applied to a fictional organisation of a kind common in the Top End: Arafura Allied Health, a Darwin practice with 28 staff across physiotherapy, occupational therapy and psychology, a second clinic in Palmerston and outreach to three remote communities, running a cloud-hosted practice management system, Microsoft 365, and a remote access gateway for visiting clinicians, with IT provided by a local managed service provider.

Scope and criteria. The practice owner, the practice manager, the clinical lead, the MSP's account manager and the bookkeeper meet for a two-hour workshop with a draft on the table. Scope: all systems and data used in patient care, billing and staff administration at both clinics and on outreach; the MSP and the practice management vendor are in scope as third parties; the owner's personal devices are out of scope and are not to be used for practice data. Context: the practice is an APP entity regardless of turnover because it is a health service provider; it is not a critical infrastructure asset; it holds health information, which is sensitive information; its cyber insurer requires MFA, EDR and tested backups; the wet season regularly interrupts power and connectivity at the outreach sites. Criteria: the five-by-five matrix with consequence levels written in the practice's terms (Major: clinic unable to see patients for more than a day, or an eligible data breach; Severe: an eligible breach involving psychology records, or regulatory proceedings). Appetite: no appetite for risks that would breach the notification obligations or the confidentiality of psychology records; moderate appetite for availability risks at the outreach sites, where paper fallback exists. Decision rights: the owner approves spending above $5,000 and any risk acceptance above Moderate; the practice manager owns the register.

Identification and analysis. The asset list fits on a page. The threat assessment uses the OAIC's health sector figures and ASD's small business figures, the MSP's incident history for similar clients, and the practice's own near misses (two staff reported convincing phishing emails impersonating the practice management vendor in the last quarter). Eighteen risks are identified; two are rated Extreme and are the ones carried through below.

Risk one: a staff member enters their Microsoft 365 credentials into a phishing page; the attacker reads mailboxes containing referral letters and patient correspondence, sets a forwarding rule, and sends invoice-redirection emails to patients and suppliers. Likelihood Likely (4), consequence Major (4), inherent rating 16, High, bordering Extreme; current controls are SMS-based MFA on some accounts and annual induction training; residual rating 12, Moderate, above appetite for health information.

Risk two: a critical vulnerability in the remote access gateway is exploited before the MSP patches it; ransomware is deployed across both clinics, encrypting local files and the backup share on the same network; the practice management system, being cloud-hosted, is not encrypted but is unreachable while workstations are rebuilt. Likelihood Possible (3), consequence Severe (5), inherent 15, High; current controls are monthly patching and a nightly backup to a network share; residual 15, High, above appetite.

Quantification for the owner: the ransomware scenario is worked as in the analysis section (ALE before $48,000; ALE after $5,000; control cost $12,000; safeguard value $31,000 a year).

Options and approval. A two-page paper to the owner sets out, for each risk, three options with costs and residual ratings, and recommends: for risk one, phishing-resistant MFA (passkeys or authenticator app with number matching) for all accounts, blocking of legacy authentication and of mail forwarding to external addresses, conditional access requiring a managed device for mailbox access, quarterly phishing simulation with role-based training, and a payment-change verification procedure; for risk two, the MSP's patching standard aligned to the Essential Eight timeframes with the gateway on a 48-hour service level for critical vulnerabilities, immutable cloud backups segregated from the network with a quarterly restore test, EDR on every device with the MSP's managed monitoring, and the gateway replaced with the cloud identity provider's remote access service at the next renewal. Both within the owner's decision rights; cyber insurance renewed with the new control set declared. The owner approves, and both decisions, with the residual targets (risk one to Low; risk two to Low to Moderate) are recorded in the risk treatment plan and the register.

Communication. The practice manager briefs the two clinic leads first, then all staff at the monthly meeting, with a one-page guide to the new sign-in and a demonstration of the report-phishing button; the MSP receives the patching standard as a contract variation with the 48-hour service level and an incident notification clause; the practice management vendor is asked in writing for its current security assessment; patients see a notice about the new verification step for any change to payment details.

Monitoring and compliance. KRIs on a one-page quarterly report: MFA coverage (target 100 per cent, phishing-resistant for all privileged accounts); accounts with legacy authentication (target zero); simulation click and report rates (baseline 18 and 12 per cent); gateway vulnerabilities older than 48 hours (target zero); last restore test date and duration; EDR coverage; phishing reports received. Compliance is checked quarterly by the practice manager pulling the tenant's conditional access and MFA reports directly, reading the MSP's patch and backup reports, and sighting the restore test; the MSP's attestation alone is not accepted.

Non-compliance, escalation and feedback. In the second quarter the restore test is found not to have been run and the MSP's report has said "backups successful" for three months. The practice manager raises it with the MSP's account manager, records it in the register, sets a date, and escalates to the owner when the date passes, with the risk two residual rating provisionally returned to High; the test is run, takes eleven hours, and the recovery time objective is revised. The feedback processes established: the report-phishing button with a monthly count; a standing item at the staff meeting; the MSP's advisory feed with the practice manager named as reader; a security review step added to the practice's procedure for buying any new software; the OAIC's and ASD's releases checked monthly; and the register review brought forward for any incident, supplier change, or new system.

Benchmarks, evaluation and update. Twelve months on: click rate 4 per cent, report rate 63 per cent, against the published baseline; MFA phishing-resistant on 100 per cent of privileged and 90 per cent of all accounts; one real credential phishing attempt blocked by conditional access; gateway patched inside 48 hours in all four critical cases; restore tested quarterly at under four hours since the revision. Risk one is re-rated Unlikely and Moderate (6, Low), within appetite; risk two is re-rated Rare and Major (4, Insignificant to Low), within appetite, with the gateway replacement completed. The evaluation report to the owner proposes lightening the monitoring on risk two to half-yearly, adding a new Extreme risk raised by the threat assessment (a psychologist's use of a public AI transcription tool for session notes, found through the new software review step), and a compliance risk with a commencement date (the automated decision-making disclosure in the privacy policy, 10 December 2026, triggered by the practice management vendor's new AI triage feature). The register, the treatment plan, the policies and the insurance declaration are updated, the changes are communicated, and the cycle begins again.

Every element and performance criterion in the unit descriptor appears in that story, and the two risks are different in threat, vulnerability, consequence and treatment, which is what the performance evidence requires. More to the point, it is what the work actually looks like in an organisation of that size.

These notes were built from the official unit of competency and assessment requirements for BSBXCS404 Release 1 (training.gov.au, document generated 1 March 2025) and the Victoria University unit page for nominal hours (read 14 October 2026), together with the delivered material in the unit folder: the 2020 learner guide (version 6.0, 28 February 2020), the 2020 class activity book (version 3.0, 1 July 2020), and the Charles Darwin University Brambling session pages for BSBXCS404, sessions one to six, as updated between 9 October and 6 November 2025. The delivered material's structure, its scales and its cloud content were kept where they held; its legal content, its framework versions, its monitoring material and its treatment of feedback were replaced from the sources below, all read between 14 and 15 October 2026 unless stated.

Risk management standards and frameworks: ISO's catalogue entry for ISO 31000:2018 showing the 2023 confirmation and the ISO/CD 31000 revision under development; the ISO/TC 262 news page on the Task Group 5 study (undated); the NIST Cybersecurity Framework 2.0 (26 February 2024); NIST SP 800-30 Revision 1 (September 2012), SP 800-37 Revision 2 and SP 800-61 Revision 3 (April 2025); the CIS Controls page confirming version 8.1 as current (undated); the MITRE ATT&CK updates page for version 20 (13 October 2026); the AICD and CSCRC Cyber Security Governance Principles version 2 page (published 25 November 2024); the IIA Three Lines Model (2020) and COSO ERM (2017) from general knowledge of the published documents.

ASD material: the consultation notice on the evolution of the Essential Eight (cyber.gov.au, 15 June 2026, consultation closing 12 July 2026); the Essential Eight Maturity Model (November 2023) and its patching timeframes; the ISM September 2026 changes document (cyber.gov.au, published August 2026 for the September release); the ASD and Defence Minister releases for the Annual Cyber Threat Report 2024 to 2025 (14 October 2025); and a third-party transition tracker (nanosolutions.io, checked against cyber.gov.au 25 August 2026) for the reported but unpublished deprecation timeline, which is described on the page as an official's interview expectation rather than ASD policy.

Australian law and enforcement: the Privacy Act 1988 and the Cyber Security Act 2024 on the Federal Register of Legislation; the Department of Home Affairs Cyber Security Act page (updated 8 October 2026) and its Cyber Incident Review Board media release (4 May 2026); the Cyber Security (Security Standards for Smart Devices) Rules 2025 (registered 4 March 2025); Gadens' summary of the tranche two exposure draft, "Tranche 2 Privacy Act Reforms: What you need to know" (9 September 2026); the OAIC media release on 2025 data breach notifications reaching an all-time high (6 July 2026) and its Notifiable Data Breach statistics dashboard page (published 4 November 2025, modified July 2026), with a Front Row Technology summary (11 July 2026) for the July to December 2024 incident-type figures; Ashurst's analysis of Australian Information Commissioner v Australian Clinical Labs (No 2) [2025] FCA 1224 (undated, late 2025) and the OAIC's statement of 8 October 2025; Allens' analysis of ASIC v FIIG Securities [2026] FCA 92 (25 February 2026); the OAIC media release on the completion of its Qantas preliminary inquiries (16 July 2026); Clayton Utz on the SOCI Enhanced Response and Prevention Act (7 April 2025); HSF Kramer on stage one of the Scams Prevention Framework (10 June 2026); and Perks McCann on Western Australia's privacy reforms commencing 1 July 2026 (July 2026). The Medibank and Optus proceedings are described as commenced in 2024 without an outcome stated.

International law: ACB Security's overview of the EU Cyber Resilience Act, AI Act and NIS2 milestones (31 August 2026); Paubox on the CIRCIA final rule's submission to OMB (8 October 2026); the UK Parliament bills page for the Cyber Security and Resilience (Network and Information Systems) Bill (updated 13 October 2026); GDPR, DORA, the SEC disclosure rules and the CCPA from the published instruments.

Statistics and threat: IBM's 2026 Cost of a Data Breach report via SecurityBrief Australia (31 July 2026) for the Australian figures and Kiteworks (30 July 2026) for the global and shadow AI figures; the ASD threat report figures as above; the CrowdStrike outage of 19 July 2024 and the Arup deepfake fraud of 2024 from contemporaneous public reporting. Australian AI policy (the Guidance for AI Adoption of 21 October 2025, the National AI Plan of December 2025 and the AI Safety Institute) follows the treatment on this site's VU23223 page, verified September 2026, and the OAIC's AI guidance of October 2024.