Skip to content
Information technology equipment
ASD ISMISM-1079

ASD ISM 1079 Seek approval for high assurance IT repairs

What it says

ASD's approval is sought before undertaking any maintenance or repairs to high assurance IT equipment.

Quoted as published. Everything else on this page is written by Control Stack.

What it means

In plain English

Get ASD's approval before repairing sensitive IT systems.

Before you fix any crucial IT equipment that's designed to keep sensitive information safe, you need to get the go-ahead from the Australian Signals Directorate (ASD). This is essential because fixing things without approval might unintentionally create security gaps, leaving your data exposed or misused.

Why it matters

If ASD approval isn't obtained before repairing high assurance IT equipment, unauthorised changes may weaken assurance and expose classified data.

How to implement

  1. IT managers should compile a list of all high assurance IT equipment that falls under this control.

    This involves identifying equipment like secure servers or encryption devices. Keep the list updated and make sure it's easily accessible for all relevant staff.

  2. Before any maintenance work is done, IT staff should contact ASD for approval.

    Use a standardised request form that clearly describes the equipment and the nature of the repairs needed. This helps ensure there's a clear record of the request and approval process.

  3. System owners should coordinate with the maintenance team to schedule repairs.

    Ensure that enough time is allocated for ASD to review and approve the request. This prevents delays and complies with the control requirements.

  4. Staff involved in equipment maintenance should be trained on the policy that requires ASD approval for repairs.

    Offer regular training sessions and include this requirement in your onboarding process for new employees.

  5. The IT department should keep records of all communications with ASD regarding repair approvals.

    This includes emails, documents, and any other materials. This ensures transparency and aids in future audits.

Keep it running

Before any repair on high assurance IT equipment, obtain ASD approval, then record who performed the work, what was changed, and approvals granted.

Evidence and audit

  1. Check 1 of 5What an auditor asks for

    Ask for

    The list of high assurance IT equipment: Request documentation identifying the relevant equipment.

    Look at

    How detailed and current the list is.

    Good evidence

    List includes equipment names, locations, and last update date.

  2. Check 2 of 5What an auditor asks for

    Ask for

    To see the repair request form submitted to ASD: Request a sample of recent requests.

    Look at

    Completeness in the description of the repair.

    Good evidence

    Form is well-documented with equipment details and repair nature clearly outlined.

  3. Check 3 of 5What an auditor asks for

    Ask for

    Communications logs between IT and ASD: Request records of approvals or denials from ASD.

    Look at

    Clear communication and timely responses.

    Good evidence

    Log shows consistent follow-ups and ASD's approval before repairs.

  4. Check 4 of 5What an auditor asks for

    Ask for

    About the training schedule for staff: Request evidence of training sessions regarding repair protocols.

    Look at

    Regular and documented training dates. Training sessions held regularly with relevant content indicates strong compliance.

  5. Check 5 of 5What an auditor asks for

    Ask for

    Evidence of follow-up reviews post-repair: Request a report showing post-repair evaluations.

    Look at

    Signs of analysis that repairs were completed without incident.

    Good evidence

    Includes evaluations showing equipment integrity post-repair.

Mappings

Closest match in ISO/IEC 27001: A.7.13, Proper maintenance of equipment, which this control partially meets.

ISO 27001

ISO/IEC 27001: 2 mappings

  • A.7.13Proper maintenance of equipmentPartially meets

Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.