ASD ISM 1564 System owner produces plan of action and milestones after assessment
What it says
At the conclusion of a security control assessment for a system, a plan of action and milestones is produced by the system owner.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishWhen a security control assessment of a system finishes, the system owner writes up a plan of action and milestones so the findings turn into tracked, dated remediation work.
A security control assessment tells you which controls on a system are working and which are missing, weak or not implemented as intended. On its own, that report changes nothing. This control requires that, at the conclusion of the assessment, the system owner produces a plan of action and milestones (often called a POA&M). It is the document that lists what the assessment found, what will be done about each item, and the milestone dates by which the work will be finished. Two things in the statement matter. First, the timing: the plan is produced at the conclusion of the assessment, not months later when someone remembers. Second, the ownership: the system owner produces it. The assessor identifies the gaps, but the person accountable for the system decides how and when they will be closed, because they hold the budget, the priorities and the authority to make changes. Why it matters in the real world is simple. Assessment findings that are never converted into a plan tend to sit in a report on a shared drive while the same weaknesses stay open for the next attacker or the next assessment. A plan of action and milestones gives the organisation a single, accountable record of the residual risk on the system and a schedule for reducing it, which is what authorising officers, executives and auditors need in order to make an informed decision about whether the system should keep operating.
Free. Save your status, tasks and notes.
Why it matters
If no plan of action and milestones is produced after a security control assessment, the findings have no owner, no schedule and no visible status. Weaknesses identified in the assessment remain unremediated for an indefinite period, the true residual risk of the system is hidden from the people who authorise it to operate, and the same deficiencies are rediscovered at the next assessment. Without the system owner producing the plan, remediation decisions are made (or not made) by whoever happens to read the report rather than by the person accountable for the system, and the organisation cannot demonstrate to an authorising officer or auditor that assessment findings are being managed.
How to implement
The security assessor, or the assessment coordinator, closes each security control assessment by delivering the final findings to the system owner together with a blank plan of action and milestones template and a due date for its completion.
The system owner populates the plan with one entry per assessment finding, recording the affected control, the deficiency, the planned remediation action, the person responsible and a target milestone date.
The system owner, with the security team, assigns a priority to each entry based on the severity of the finding so that the milestone dates reflect which weaknesses must be closed first.
The system owner files the completed plan with the system's other authorisation records (such as the system security plan and assessment report) and notifies the authorising officer or security governance forum that it is available.
The system owner schedules a recurring review of the plan (for example monthly or at each change board) to update status, record any slipped milestones with a new date and rationale, and close entries once remediation has been verified.
Keep it running
Treat the plan of action and milestones as a standing output of every security control assessment rather than a one-off document. Build the hand-off into the assessment process itself: when the assessor delivers the final assessment report, the system owner (or their delegate) is expected to return a completed plan within an agreed window, and the assessment is not considered closed until that plan exists.
A workable plan is usually a simple register, one row per finding, recording the assessed control, the deficiency, the planned remediation, the responsible person, the target milestone date and the current status. Keep it alongside the system's other authorisation documents so it is easy to locate at reauthorisation and easy to hand to an auditor.
Day to day, the plan is a living record. The system owner should review it on a regular cadence, update status as milestones are met or slip, and record the reason and new date when a milestone changes. Where a finding will be accepted rather than fixed, note that decision in the plan so the residual risk is visible rather than silently dropped. When a system is reassessed, close out the items that were verified as remediated and carry forward anything still open into the new plan.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Ask for the most recent security control assessment report for the system and the plan of action and milestones that followed it.
Look at
Compare the two documents to confirm a plan exists for that assessment and that it was produced by the system owner rather than the assessor or an unrelated team.
Good evidence
A plan of action and milestones exists for the assessment, is signed off or attributed to the system owner, and is dated at or shortly after the conclusion of the assessment.
- Check 2 of 5What an auditor asks for
Ask for
Ask for the list of findings in the assessment report and the entries in the plan of action and milestones.
Look at
Trace each assessment finding to a corresponding entry in the plan and check that nothing was dropped or merged away.
Good evidence
Every finding from the assessment appears in the plan with a planned action, a responsible person and a milestone date, or a documented decision to accept the risk.
- Check 3 of 5What an auditor asks for
Ask for
Ask how the organisation defines when an assessment is concluded and when the plan is due.
Look at
Look at the assessment procedure or authorisation process to see whether producing the plan is a required step at the end of the assessment rather than an optional follow-up.
Good evidence
The documented process requires the system owner to produce the plan at the conclusion of the assessment, with a stated timeframe, and recent assessments show that this happened.
- Check 4 of 5What an auditor asks for
Ask for
Ask for the plans of action and milestones for two or three other systems that were assessed in the last cycle.
Look at
Check that the practice is applied consistently across systems and that each plan identifies the system owner as its author.
Good evidence
Each assessed system has its own plan produced by its system owner, using a consistent format and produced at the conclusion of the relevant assessment.
- Check 5 of 5What an auditor asks for
Ask for
Ask for the system's authorisation records (such as the system security plan or authorisation package) that name the system owner.
Look at
Compare the named system owner with the person recorded as the author or approver of the plan of action and milestones.
Good evidence
The person who produced the plan is the system owner named in the system's authorisation records, or a delegate formally acting on their behalf, rather than the assessor or an unrelated team.
Mappings
Closest match in ISO/IEC 27001: A.5.35, Independent review of information security, which this control depends on.
ISO/IEC 27001: 1 mapping
This control depends on A.5.35.
ISM-1564 requires the system owner to produce a plan of action and milestones at the conclusion of a security control assessment for a system. The plan relies on an independent assessment having been performed, which aligns with the Annex A 5.35 requirement for independent review of information security at planned intervals or after significant change. Annex A 5.35 covers the organisation's overall approach to information security, while ISM-1564 addresses the remediation plan that follows a system-level assessment.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.