Arckit Au Ism Controls

⚠️ 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.

   • Control Domain Applicability Matrix — 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:

     1. Cyber Security Governance — security risk management, security documentation, change management
     2. Cyber Security Incidents — detection, reporting, response, business continuity
     3. Outsourced Services — managed service providers, cloud, supply chain
     4. Security Documentation — system security plans, security risk management plans
     5. Personnel Security — clearance levels, awareness training, separation of duties
     6. Physical Security — facilities, equipment, ICT equipment lifecycle
     7. Communications Infrastructure — fibre, cabling, telephony
     8. ICT Equipment Security — hardware lifecycle, media, sanitisation
     9. System Hardening — operating systems, applications, authentication, network
     10. System Management — administration, monitoring, maintenance, vulnerability mgmt
     11. System Monitoring — event logging, audit, security metrics
     12. Cryptography — cryptographic fundamentals, ASD-approved algorithms, key management
     13. Gateway Security — gateway architecture, content filtering, DLP
     14. Data Transfer — between domains, between systems, data import/export
     15. Cloud and IaaS Considerations — IRAP assessment status, sovereign cloud, shared responsibility
     16. Working-Off-Site Security — remote work, mobile devices, BYOD
     17. Evaluation Activities — Common Criteria, FIPS, vendor product testing

   • Per-Domain Control Applicability Assessment — for each in-scope domain, document:

     • Applicability rationale (which controls apply at the system's classification level)
     • Current implementation status: ✅ Implemented / ⚠️ Partial / ❌ Not Implemented / N/A
     • Evidence supporting the status (cite E8 posture artefact, IRAP report, vendor attestations)
     • Gap description with specific ISM control IDs not yet met
     • Remediation actions with owner and target date
     • Compensating controls if applicable

   • ISM-to-E8 Cross-Reference — show which E8 strategies map to which ISM domains. Reinforces the E8-as-mitigation-subset framing for governance audiences.

   • Compliance Summary — table summarising domain-by-domain compliance posture; overall ISM applicability score (controls implemented / controls applicable).

   • IRAP Assessment Position — if the system holds or pursues IRAP assessment, note the IRAP scope, assessment date, residual risks accepted, and re-assessment cadence. For systems integrating with IRAP-assessed cloud services, note the inherited control posture.

   • ArcKit Evidence Integration — map /skill:arckit-diagram, /skill:arckit-dfd, /skill:arckit-data-model, /skill:arckit-servicenow, /skill:arckit-risk, /skill:arckit-traceability, /skill:arckit-graph-report, and /skill:arckit-maturity-model evidence to ISM domain applicability, CMDB ownership, control gaps, risk treatments, and assurance coverage.

   • Recommendations — prioritised remediation actions grouped by Quick Wins ( < 30 days), Short-Term (30–90 days), Medium-Term (90–180 days). Each recommendation references the specific ISM control ID(s).

7. Populate the External References section per .arckit/references/citation-instructions.md. The ASD ISM (with edition / publication date) MUST appear in the Document Register.

8. Before writing the file, read .arckit/references/quality-checklist.md and verify all Common Checks plus the AUISM per-type checks pass. Fix any failures before proceeding.

9. Write the artefact via the Write tool to projects/<project-id>/<filename>.

10. Show only a summary to the user (one paragraph plus the Compliance Summary table showing per-domain status).

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.