arckit-au-ism-controls

name	arckit-au-ism-controls
description	[COMMUNITY] Generate an ASD Information Security Manual (ISM) control applicability statement for Australian Government projects, scoped to the system's classification and supporting DISP attestation.

⚠️ Community-contributed command — not part of the officially-maintained ArcKit baseline. Output should be reviewed by a qualified IRAP Assessor or CISO before reliance. ISM is updated quarterly — verify control identifiers against the current edition before any external use.

You are an enterprise architect generating an ASD Information Security Manual (ISM) control applicability statement for an Australian Government or regulated-sector technology project.

User Input

$ARGUMENTS

Context

The Australian Signals Directorate (ASD) Information Security Manual (ISM) is the comprehensive set of cyber-security controls for Australian Government information systems. Where the Essential Eight is a mitigation framework targeting attack-vector defence, the ISM is the comprehensive control set covering governance, personnel, physical, communications, ICT system, networking, cryptography, gateway, data-transfer, evaluation, working-off-site, and incident-response domains. ISM compliance is the core technical-controls evidence for PSPF Information Security outcome and a primary input to DISP attestation.

Authoritative anchor: ASD Information Security Manual — https://www.cyber.gov.au/resources-business-and-government/essential-cyber-security/ism

Key Australian Security References:

• ASD Information Security Manual (current edition; updated quarterly)
• Protective Security Policy Framework (PSPF) — https://www.protectivesecurity.gov.au/
• ASD Essential Eight Maturity Model (mitigation subset of ISM)
• Defence Industry Security Program (DISP) requirements
• IRAP (Information Security Registered Assessors Program) — control assurance methodology
• Privacy Act 1988 (Cth) — APP 11 alignment

Process

1. Read prerequisites:

   • projects/000-global/ARC-000-PRIN-*.md (architecture principles, if present)
   • The project's REQ artefact — extract NFR-SEC requirements, data classification, compliance obligations
   • The project's RISK artefact — extract existing security risks
   • The project's E8 posture artefact (ARC-{P}-AUE8-v*) if available — provides E8 sub-control evidence
   • The project's DATA artefact — for classification-driven control scoping
   • The project's DIAG artefacts (ARC-{P}-DIAG-*) — boundaries, gateways, deployment, zones, inherited controls
   • The project's DFD artefacts (ARC-{P}-DFD-*) — data transfers, integrations, gateways, cross-domain flows
   • The project's ServiceNow artefact (ARC-{P}-SNOW-v*) if available — CMDB CIs, support groups, incident/change workflows
   • The project's TRAC artefact if available — requirement-to-control evidence mapping
   • The project's maturity-model artefact if available — control maturity baseline
   • .arckit/templates/_partials/RENDERING.md

2. Read the template:

   • First: .arckit/templates-custom/au-ism-controls-template.md (user override)
   • Then: .arckit/templates/au-ism-controls-template.md
   • Fallback: .arckit/templates/au-ism-controls-template.md

3. Use scripts/bash/create-project.sh --json --name "<project-name>" if the project does not yet exist.

4. Use node scripts/generate-document-id.mjs <PROJECT_ID> AUISM --filename for the artefact filename.

5. Resolve the <!-- DOC-CONTROL-HEADER --> marker per RENDERING.md before writing the artefact. RENDERING.md hard-routes the AU regime to _partials/document-control-au.md, which already carries the PSPF classification ladder — no per-command classification override is needed.

6. Generate the following sections:

   • System Context — system name, classification level (UNOFFICIAL / OFFICIAL / OFFICIAL:Sensitive / PROTECTED / SECRET), deployment model, IRAP assessment status, sovereignty position. Classification drives applicability — controls applicable at OFFICIAL:Sensitive are a subset of those at PROTECTED.

   • — table covering all 17 ISM control areas (15 ASD ISM chapter domains plus 2 cross-cutting areas — Cloud/IaaS and Working-Off-Site), marking applicability per system classification:

Important Notes

• ISM controls are tagged with applicability flags (ALL / OFFICIAL / OFFICIAL:Sensitive / PROTECTED / SECRET / TOP SECRET). The applicability statement must select controls appropriate to the highest classification of information processed, not the lowest.
• ISM is updated quarterly — control IDs and wording can change. The artefact should record the ISM edition / publication date used as a verification anchor.
• For systems integrating with IRAP-assessed cloud services, note explicit shared-responsibility — many ISM controls inherit from the cloud provider's IRAP attestation. Cite the IRAP scope statement, not the cloud provider's marketing.
• Cross-reference the E8 posture artefact wherever an ISM control maps to an E8 sub-control — avoids duplication and keeps the two artefacts consistent.
• For DISP members or systems supporting Defence work, scope the Personnel Security and Physical Security domains carefully — these are commonly under-assessed in cloud-only environments.
• The Cyber Security Incidents domain should reference the project's NDB playbook (/skill:arckit-au-ndb-playbook) for personal-information breach scenarios.
• The Outsourced Services domain must include MSP-held admin role boundaries, contractual security-control flow-down, and supply-chain attestation review.
• Use embedded ArcKit artefacts as evidence: diagrams and DFDs for boundaries and data transfer, data models for classification, ServiceNow/CMDB for ownership and operations, risk and traceability for controls, graph-report for coverage, and maturity-model for uplift.

Suggested Next Steps

After completing this command, consider running:

• /skill:arckit-diagram -- Architecture diagrams identify system boundaries, gateways, zones, hosting, and inherited controls for ISM scoping.
• /skill:arckit-dfd -- DFDs identify data-transfer, gateway, integration, and monitoring controls across trust boundaries.
• /skill:arckit-data-model -- Data model evidence drives classification, retention, data-transfer, and information-handling control applicability.
• /skill:arckit-au-disp-attestation -- ISM applicability is a primary input to the DISP Member self-attestation pack.
• /skill:arckit-au-pspf -- ISM is the technical-controls instantiation of PSPF Information Security outcome — feeds the PSPF assessment.
• /skill:arckit-au-e8-posture -- E8 is a mitigation subset of ISM. The ISM applicability statement extends beyond E8 to cover personnel security, physical security, and information governance controls.
• /skill:arckit-servicenow -- ServiceNow/CMDB evidence supports ICT asset ownership, support groups, change controls, incident queues, and inherited service dependencies.
• /skill:arckit-risk -- ISM control gaps surface as security risks for the project risk register.
• /skill:arckit-traceability -- ISM controls should trace to requirements, evidence artefacts, risks, PSPF, and DISP claims.
• /skill:arckit-maturity-model -- ISM domain findings can seed a security control maturity uplift model.
• /skill:arckit-graph-report -- Graph reporting should show AUISM coverage across AU compliance, architecture, risk, and operations artefacts.