Australian Information Security Manual: Key Updates and How to Stay Compliant

Key Takeaways

• The ISM is a risk-based cyber security framework published by ASD for protecting IT and OT systems.
• The recent June 2026 update adds important guidance around AI applications, AI-supported security testing, and AI-assisted software development.
• Cryptography language has been tightened to focus on ASD-approved cryptography for data at rest and data in transit.
• Compliance teams need to track control ownership, evidence, system boundaries, risk acceptance, and monitoring activity.
• Machine-readable ISM releases make it easier to connect ISM controls to GRC workflows and compliance automation.

What Is the Australian Information Security Manual?

The Australian Government Information Security Manual, commonly referred to as the ISM, is a cyber security framework from the Australian Signals Directorate.

The ISM gives organizations guidance for protecting systems, applications, networks, data, and operational technology. It covers a wide range of security domains, including cyber security roles, documentation, incidents, physical security, personnel security, system hardening, monitoring, software development, networking, cryptography, and data transfers.

The ASD information security manual is built around a risk management approach. Organizations use it to decide which controls apply to their systems and how those controls should be implemented. They also use it to document risk decisions and support assurance activities.

For teams already working with broader cyber frameworks, the ISM can sit alongside frameworks such as NIST, Essential Eight, ISO 27001, SOC 2, and privacy obligations. The challenge is making those frameworks work together instead of managing each one in isolation.

The June 2026 ISM Update 

The June 2026 update reflects several shifts that security and compliance teams are already feeling.

AI is now part of real operating environments. Software development is increasingly AI-assisted. Threat detection is being supported by AI models. Employees share work-related information across online services. Cryptography requirements need to be clear across data at rest and data in transit. Security monitoring needs to support ongoing assurance rather than point-in-time review.

The update does not change the basic idea of the information security manual, but it does strengthen the need for disciplined control management. Teams need to know what changed, which systems are affected, who owns the response, and what evidence will prove the work has been completed.

AI Controls Signal a Broader Governance Shift

One of the most important updates is the addition of AI-related controls.

The June 2026 changes add controls for AI applications that process classified data. These applications should not directly access external public data sources. The update also recommends that AI applications flag defined risky actions for human approval before execution. It further recommends that organizations establish and monitor baselines for expected AI application behavior and performance.

These controls serve as a useful signal for all organizations, even those outside classified environments. AI governance is becoming part of security control management. It is no longer enough to ask whether AI tools are allowed. Teams need to understand what data AI applications can access, what actions they can take, when human approval is required, and how abnormal behavior will be detected.

Organizations building an AI governance program should treat these controls as part of a wider operating model. AI use needs ownership, policy, risk assessment, monitoring, and evidence. It also needs a clear path into remediation when controls are missing or weak.

Software Development Guidance Now Accounts for AI-Assisted Work

The June 2026 update also clarifies that software development guidance applies to human, AI-assisted, AI-powered, and AI-driven development activities. It notes that references to software developers can include both humans and AI agents.

This represents a significant evolution in development standards. Many organizations are adopting AI coding tools faster than their policies and control testing can adapt. The ISM update recognizes that software development controls need to cover the reality of how software is being produced today.

The update also adds a control for maintaining a secure software development policy. It adds guidance that software developers who lack sufficient cyber security knowledge and skills for their projects or tasks should not be used. It also recommends using suitable AI models to augment software security testing.

Cryptography Updates Put More Focus on Precision

The June 2026 changes also tighten the language around cryptographic protection.

The ISM renamed the existing data protection principle to cryptographic protection. It also replaced references to ASD-approved algorithms and protocols with ASD-approved cryptography. The purpose is to avoid excluding high assurance cryptographic algorithms and protocols.

Other updates clarify the use of ASD-approved cryptography when data is encrypted at rest or communicated over network infrastructure. Mobile applications that communicate sensitive or classified data over public network infrastructure are also called out.

For compliance teams, this means cryptography should be treated as a control area with clear evidence. Teams should be able to show what data is encrypted, where encryption is applied, which cryptographic methods are used, how keys are managed, and whether exceptions have been approved.

This shift creates a practical need for evidence reuse. Encryption controls often support multiple frameworks and obligations. A single control may support ISM, privacy, supplier assurance, cloud security, and customer due diligence.

Personnel Security Now Includes Online Exposure

The ISM update adds new Australian government information security manual controls around work-related information posted on unauthorized online services. Personnel should be advised not to post information about security clearances and briefings. They should also limit posting information about work-related duties, skills, and experience.

Addressing this control area is timely and necessary. Adversaries often build targeting profiles from public information. Job roles, clearance details, project descriptions, technical skills, and organizational relationships can all become useful intelligence.

For organizations, the compliance task is not only to update awareness training. Teams should define what types of work-related information create risk, where employees are most likely to share it, and how reporting should work when risky information is posted.

The stronger approach connects personnel security to broader cyber risk. The issue should not live only in training records. It should also connect to threat modeling, access reviews, incident response, and executive reporting where exposure creates material risk.

Continuous Monitoring

Another important change is the split of the existing control on continuous monitoring plans into separate controls. One focuses on documentation development. The other focuses on the performance of security assessments.

An ISM program should answer several questions:

Compliance Area	What Teams Need to Track
System Scope	Which systems are in scope and how boundaries are defined
Control Selection	Which ISM controls apply to each system
Ownership	Who owns each control and related evidence
Monitoring	How control performance is reviewed over time
Assessment	How control effectiveness is tested
Remediation	How gaps become tracked work
Risk Acceptance	Who approves residual risk and why

Continuous control monitoring is essential for keeping these controls visible. ISM compliance should not depend on a rushed evidence cycle before an assessment. It should be supported by an operating rhythm that keeps controls visible.

How to Stay Compliant With the ISM

Staying compliant with the ISM starts with treating it as a risk-based program rather than a static checklist.

1. Define the systems in scope. This includes system boundaries, business criticality, data sensitivity, resilience objectives, and relevant operating environments.
2. Select and tailor controls. Not every control applies in the same way to every system. Teams should document why a control applies, how it is implemented, and whether any tailoring or exception has been approved.
3. Assign ownership. Every control needs a responsible owner. Evidence should not sit with one compliance person who has to chase every system owner before an assessment.
4. Maintain system documentation. This includes the system security plan, incident response plan, change and configuration management plan, continuous monitoring plan, assessment reports, and remediation plans where applicable.
5. Connect findings to remediation. If an ISM control is weak, missing, or not operating as intended, it should become a tracked task with an owner, due date, status, and link back to the relevant risk.
6. Monitor updates. The ISM changes regularly. Organizations should review each update, identify affected controls, assess business impact, and update evidence expectations.

How Centraleyes Helps

Centraleyes helps organizations manage ISM compliance as part of a connected risk and compliance program.

Teams can centralize framework requirements, map controls across obligations, assign control owners, collect evidence, track remediation, and maintain visibility across systems and business units. Centraleyes also supports risk register workflows, vendor risk management, AI governance, audit readiness, and executive reporting.

Navigating complex compliance requirements like the ISM often requires specialized knowledge. Information security manual consultants can help organizations bridge the gap between regulatory requirements and operational reality, ensuring that control frameworks are both effective and sustainable.

FAQs

1. Is the ISM Legally Mandatory?

The ISM is not automatically mandatory for every organization. It may become required through legislation, government direction, contract terms, procurement expectations, or sector-specific obligations. Organizations should confirm which legal or contractual requirements apply to them.

2. Who Should Own ISM Compliance?

ISM compliance should usually be owned by security leadership, with support from risk, compliance, IT, OT, system owners, and executive stakeholders. Control ownership should sit with the teams responsible for implementation and operation.

3. How Often Is the ISM Updated?

The ISM is updated regularly. Organizations should build a process for reviewing updates, identifying affected controls, updating documentation, and assigning any remediation work.

4. How Does the ISM Relate to Essential Eight?

Essential Eight is a prioritized set of mitigation strategies published by ASD. The ISM is broader and includes principles, guidelines, and controls across many cyber security domains. Many organizations use both.

5. What Is the Best Way to Prepare for an ISM Assessment?

Start with scope. Define the systems, select applicable controls, assign owners, collect evidence, document risk decisions, and track remediation. The strongest preparation happens continuously, not only before an assessment.