A practical guide to understanding Australia's Information Security Manual, its 992 controls, and how they apply to modern cloud-native organisations running on AWS, containers, and SaaS.
The Information Security Manual (ISM) is Australia's authoritative cyber security framework, developed and maintained by the Australian Signals Directorate (ASD). It provides a comprehensive set of security controls that Australian Government agencies and organisations handling government data are expected to implement. If your company works with government clients, processes government data, or operates in regulated sectors such as defence, health, or finance, the ISM is the benchmark your security posture will be measured against.
Unlike prescriptive technology mandates, the ISM describes security outcomes. It does not dictate which firewall vendor to use or which cloud provider to run on. Instead, it outlines the security objectives an organisation must achieve, leaving the implementation details to you. This outcome-based approach makes the ISM well suited to cloud-native environments, where infrastructure is ephemeral, services are distributed, and the traditional perimeter no longer exists.
The ISM is updated regularly, typically several times per year, to reflect the evolving threat landscape. As of the latest revision, it contains 992 individual controls spanning topics from personnel security through to cryptography, networking, and software development. The breadth of coverage means the ISM touches nearly every aspect of how a cloud-native company designs, builds, and operates its systems. For organisations pursuing IRAP (Information Security Registered Assessors Program) assessments, the ISM forms the control baseline against which assessors evaluate your environment.
The ISM organises its 992 controls into a hierarchical structure designed for navigability. At the top level, controls are grouped into broad topics such as Guidelines for Personnel Security, Guidelines for Communications Infrastructure, Guidelines for ICT Equipment, Guidelines for System Management, and Guidelines for Software Development. Each topic is further divided into subtopics that address specific domains within the broader area.
Individual controls are identified by a unique control ID in the format ISM-XXXX, where XXXX is a numeric identifier. Each control carries a revision number that increments whenever ASD updates the control's wording or intent. This versioning is important for compliance tracking: when a control is revised, your organisation needs to reassess whether existing implementations still satisfy the updated requirements.
Every control includes a description of the security objective, the applicability level (which classification levels it applies to), and the control's purpose. Some controls are procedural, requiring documented policies or processes. Others are technical, specifying configuration requirements for systems and infrastructure. Understanding this distinction matters for cloud-native teams because procedural controls often require organisational documentation, while technical controls can frequently be evidenced through automated tooling, configuration exports, and infrastructure-as-code.
The hierarchical grouping also helps teams divide ownership. Your platform engineering team might own networking and system hardening controls, your identity team handles access control, and your application security team covers the software development guidelines. This natural alignment with modern team structures makes the ISM more practical to implement than monolithic compliance checklists.
Not every ISM control applies to every organisation. Each control specifies one or more applicability levels corresponding to Australia's information classification scheme: NC (not classified), O (OFFICIAL), OS (OFFICIAL: Sensitive), P (PROTECTED), S (SECRET), and TS (TOP SECRET). The higher the classification of data you handle, the more controls become applicable, and the stricter the implementation requirements.
For the vast majority of cloud-native companies working with government clients, the relevant levels are OFFICIAL: Sensitive and PROTECTED. OFFICIAL: Sensitive covers information that requires a degree of protection beyond the baseline, such as personal information, commercial-in-confidence data, or sensitive policy material. If your SaaS platform processes citizen data, health records, or financial information on behalf of a government agency, you are almost certainly operating at the OS level.
PROTECTED applies to information whose compromise could cause damage to national security, defence, or international relations. Cloud-native companies handling defence contracts, intelligence-adjacent work, or critical infrastructure data may need to satisfy PROTECTED-level controls. The jump from OS to P is significant: additional controls come into scope around cryptographic key management, network segmentation, personnel vetting, and data sovereignty.
SECRET and TOP SECRET levels introduce controls around physical security, emanation security (TEMPEST), and compartmentalisation that are rarely relevant to commercial cloud-native companies. Understanding where your organisation sits in this classification hierarchy is the essential first step before attempting ISM compliance. Getting this wrong means either over-investing in controls that do not apply, or under-investing in controls that do.
Most common for cloud-native companies. Covers personal data, commercial-in-confidence, and sensitive government information. The practical starting point for IRAP assessments.
For organisations handling data whose compromise could damage national security. Significantly more controls apply, particularly around cryptography and network isolation.
For cloud-native companies running on AWS, deploying containers, and relying on SaaS tooling, certain ISM topics carry more weight than others. Access control is foundational: the ISM expects robust identity management, multi-factor authentication for all privileged access, time-limited sessions, and the principle of least privilege enforced across all systems. In a cloud-native environment, this translates to IAM policies, SSO integration, conditional access rules, and privileged access management for production environments. With a remote workforce, these controls extend to every device and connection your team uses.
Cryptography controls govern how you protect data in transit and at rest. The ISM has specific requirements around TLS configuration, cipher suite selection, key management practices, and the use of ASD-approved cryptographic algorithms. For AWS-based workloads, this means configuring ACM certificates correctly, using KMS with appropriate key rotation policies, enforcing TLS 1.2 or higher across all endpoints, and ensuring S3 bucket encryption meets the required standard. The ISM's cryptographic guidance is detailed and prescriptive about algorithm choices, which is unusual for an outcome-based framework and reflects the sensitivity of the topic.
Networking controls address segmentation, boundary protection, and traffic management. Cloud VPCs map naturally to the ISM's network zone concepts. You need to demonstrate controlled ingress and egress, logging of network flows, and segmentation between environments of different classification levels. For containerised workloads, network policies, service mesh configurations, and API gateway controls become the evidence artefacts. The ISM also expects monitoring of network traffic for anomalous activity, which aligns with services like AWS GuardDuty and VPC Flow Logs.
System management controls cover patching, configuration hardening, and monitoring. The ISM expects timely patching of security vulnerabilities, with specific timeframes tied to severity. Critical vulnerabilities should be patched within 48 hours, a requirement that aligns with the Essential Eight maturity model. Configuration hardening controls require documented baselines and drift detection. For cloud-native teams, infrastructure-as-code and automated compliance scanning provide strong evidence of meeting these controls.
Software development guidelines address secure coding practices, code review, vulnerability scanning, and release management. If your organisation develops software, whether customer-facing applications or internal tooling, these controls require a documented secure development lifecycle. Static analysis, dependency scanning, container image scanning, and peer code review are all relevant implementation measures. Tools like Dependabot, Snyk, and Trivy generate evidence that maps directly to these ISM controls.
One of the most important exercises in ISM compliance is identifying which controls are not applicable to your environment and formally documenting why. For a cloud-native company with no physical data centres, significant portions of the ISM will not apply. Physical security controls covering server room access, environmental protections, and physical media handling are typically out of scope when your infrastructure runs entirely in AWS or another cloud provider. These controls shift to your cloud provider's responsibility under the shared responsibility model.
Cable management and cabling infrastructure controls are similarly irrelevant when you have no on-premises networking equipment. Emanation security controls, often referred to as TEMPEST, address the risk of electronic signals being intercepted from physical equipment. These controls are primarily relevant at SECRET and TOP SECRET levels and almost never apply to cloud-native commercial operations. Hardware-specific controls around USB device management, removable media, and peripheral equipment may also be scoped out if your workforce operates entirely on managed devices with endpoint management policies enforced through tools like Mosyle or Intune.
However, it is critical to understand that "not applicable" does not mean "ignored." Every control that is deemed not applicable must be formally assessed and excluded with documented justification in your Statement of Applicability (SOA). The SOA is a key artefact in any IRAP assessment. An assessor will scrutinise your N/A justifications to ensure they are genuine and well-reasoned. Simply marking controls as N/A without adequate explanation is a common audit finding and can undermine the credibility of your entire assessment. The SOA should explain the technical or organisational basis for exclusion, such as "This control addresses physical server room access. The organisation operates entirely on AWS cloud infrastructure with no physical data centres. Physical security controls are the responsibility of AWS under the shared responsibility model, as documented in AWS's IRAP assessment report."
A significant development in ISM tooling is ASD's publication of the ISM in OSCAL (Open Security Controls Assessment Language) format. OSCAL is a standardised, machine-readable format developed by NIST for representing security control catalogues, system security plans, and assessment results. By publishing the ISM in OSCAL, ASD has enabled a new generation of automated compliance tooling that can programmatically consume the control catalogue rather than relying on manual parsing of PDF or spreadsheet exports.
The OSCAL publication includes the complete ISM control catalogue in both JSON and XML formats, with each control's metadata, applicability levels, descriptions, and grouping hierarchy preserved in structured data. This means tooling can automatically detect when controls are added, modified, or removed between ISM revisions. For organisations tracking compliance over time, this eliminates the manual effort of diffing spreadsheet versions and reduces the risk of missing updated control requirements.
QuantAssure syncs directly from ASD's official OSCAL publication, importing all 992 controls with their full metadata, topic hierarchy, and applicability levels. When ASD publishes a new ISM revision, QuantAssure detects the changes and updates the control catalogue automatically, highlighting new controls, modified controls, and deprecated controls. This ensures your compliance tracking is always aligned with the latest ISM revision without manual intervention.
QuantAssure syncs from ASD's official OSCAL mirror. When a new ISM revision drops, your control catalogue updates automatically with full change tracking.
The sheer volume of ISM controls makes manual tracking impractical at any meaningful scale. Many organisations begin their ISM journey with a spreadsheet: 992 rows, columns for status, evidence links, assignees, and notes. This approach works for the first few weeks, until the spreadsheet becomes stale. Evidence links break, status updates fall behind, multiple team members create conflicting copies, and when the next ISM revision arrives, someone has to manually reconcile every change. Version control does not exist. There is no audit trail showing who changed what and when. And when the IRAP assessor asks for current status, someone scrambles to update the spreadsheet before the meeting.
The fundamental problem with spreadsheet-based compliance is that it treats compliance as a point-in-time activity rather than a continuous process. You fill in the spreadsheet for the assessment, the assessment happens, and then the spreadsheet rots until the next assessment cycle. In between, your actual security posture changes constantly: new services are deployed, configurations drift, team members rotate, and new vulnerabilities emerge. The spreadsheet captures none of this.
Automation transforms ISM compliance from a periodic scramble into a continuous, maintainable process. When your security tooling generates findings, those findings can be automatically mapped to the ISM controls they relate to. A critical vulnerability detected by Dependabot maps to system management and patching controls. A misconfigured S3 bucket flagged by Security Hub maps to access control and data protection controls. An unencrypted EBS volume maps to cryptography controls. This automated mapping means your control status reflects your actual security posture in near real-time, not a snapshot from three months ago.
Generating the Statement of Applicability becomes a reporting function rather than a manual authoring exercise. Evidence freshness can be tracked automatically, alerting you when evidence for a control has gone stale. Gaps between your current posture and ISM requirements are identified and surfaced proactively, not discovered during an assessment. For organisations pursuing or maintaining IRAP assessed status, this shift from manual to continuous compliance monitoring reduces the assessment preparation burden from weeks of effort to a routine review of an already-current dashboard.
QuantAssure imports the full ISM catalogue from ASD's OSCAL publication, maps your findings to controls automatically, and keeps your Statement of Applicability current.