Skip to content
Cyber security roles
ASD ISMISM-1587

ASD ISM 1587 Annual security status reporting for systems

What it says

System owners report the security status of each system to its authorising officer at least annually.

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

What it means

In plain English

System owners must annually report each system's security status to an authorising officer.

System owners have to check and report how secure their systems are at least once a year to the person in charge of approving them. This is important because it keeps everyone aware of any risks or weaknesses in the systems, so they can fix problems before they lead to data leaks or other issues that could damage the organisation's reputation or operations.

Why it matters

Missing annual security status reports can conceal system risks, leaving issues unreported to the authorising officer and increasing breach likelihood.

How to implement

  1. System owners should schedule an annual review with the authorising officer to discuss the system's security.

    They can do this by setting a fixed date each year and preparing a short report on recent security assessments and updates done on the system. This ensures that the officer is kept informed and can advise on necessary actions.

  2. System owners should create a checklist of security measures currently in place for the system.

    This checklist might include antivirus software status, firewall rules, and whether regular software updates are being applied. Reviewing and updating this checklist before meeting with the authorising officer helps provide a clear picture of the system's security.

  3. The IT team should run a security assessment on each system before the annual review.

    This could involve vulnerability scanning and checking access controls to find any weak points. The results should be compiled into a report to inform discussions during the formal review.

  4. System owners should organise a follow-up session after the review meeting to outline any required improvements.

    They can work with IT and staff concerned with system security to address any weaknesses identified during the initial review. Documenting these plans helps track progress and ensure accountability.

  5. The business manager should ensure records of these reviews are maintained.

    Using a simple filing system, they can store reports, checklists, and meeting notes in a central location. This makes it easy to retrieve documents for auditing or subsequent reviews.

Keep it running

Schedule annual security status reports and submit them to the authorising officer; include changes, incidents, outstanding risks and remediation progress.

Evidence and audit

  1. Check 1 of 4What an auditor asks for

    Ask for

    The most recent system security status report: Request the report submitted to the authorising officer.

    Look at

    The report's details, such as the systems reviewed, findings, and recommendations.

    Good evidence

    Report will be dated within the last year and provide a thorough assessment that matches system characteristics.

  2. Check 2 of 4What an auditor asks for

    Good evidence

    Record will be signed by both parties and include agreed steps to improve system security.

  3. Check 3 of 4What an auditor asks for

    Ask for

    To see the security measure checklist: Verify the checklist contains current information on antivirus use, firewall settings, software updates, and other security practices.

    Good evidence

    Checklist is regularly updated, reflecting the last review findings.

  4. Check 4 of 4What an auditor asks for

    Look at

    Reports for any identified risks and the steps taken to mitigate them. Good reports will include clear descriptions of vulnerabilities found and actions taken to resolve them.

Mappings

Closest match in ISO/IEC 27001: A.5.35, Independent review of information security, which partially overlaps with this control.

ISO 27001

ISO/IEC 27001: 1 mapping

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