Skip Navigation
  • Text Size: A A A
  • Print
  • Email
  • Facebook
  • Tweet
  • Share
  • Print
  • Email
  • Facebook
  • Tweet
  • Share

Standard 2012-0001.001S

Standards for Plans of Action and Milestones (POA&M) Management and Reporting
November 28, 2012


This document provides standards for managing and reporting the Department of Health and Human Services (HHS) Plans of Action and Milestones (POA&Ms) by the Operating Division (OPDIV) Chief Information Officers (CIOs)/Chief Information Security Officers (CISOs). The standards presented in this document reflect requirements defined by the Office of Management and Budget (OMB) Circular A-130, Management of Federal Information Resource; the Federal Information Security Management Act (FISMA) of 2002; OMB Memorandum (M)-04-25, Fiscal Year (FY) 2004 Reporting Instructions for the Federal Information Security Management Act; OMB M-10-15, FY 2010 Reporting Instructions for the Federal Information Security Management Act and Agency Privacy Management; and the HHS Office of the Chief Information Officer (OCIO), Policy for Information Systems Security and Privacy (IS2P) dated July 7, 2011. The standards detailed in this document represent the minimum requirements that shall be employed for all HHS security programs, systems, and applications and supersede the Standard for Plans of Action and Milestones, dated March 30, 2011, which established this standard practice for HHS. This document does not supersede any other applicable law or higher level agency directive, policy, or guidance. All references noted below are subject to periodic revision, update, and reissuance.

POA&M Management

Effective POA&M management of program- and system-level weaknesses increases the awareness of an OPDIV’s security posture, identifies systemic areas to address, and contributes to developing informed risk-based decisions. The following requirements are mandated to facilitate and standardize enterprise-wide POA&M management:

1.      Every information technology (IT) system shall have a POA&M to identify, manage, and mitigate weaknesses. Each OPDIV must also maintain at least one program-level POA&M to identify, manage, and mitigate programmatic weaknesses. [1]

1.1.   A Universal Unique Identifier (UUID) shall be recorded to tie the system to a system POA&M. The UUID is derived from the HHS Enterprise Architecture Repository (HEAR).

1.2.   Each POA&M that corresponds to a project (including systems) shall be linked to an OMB Exhibit 300 or 53 through the use of the unique investment identifier (UII).

1.3.   Prior to decommission of a system, all weaknesses for the system must be closed. Closed does not necessarily mean remediated. Weaknesses must be closed to demonstrate that the weakness is no longer open or active; however, a weakness would not have remediation activities conducted for a system that is no longer in operation.

2.      All security and privacy weaknesses shall be recorded and managed in a POA&M.

2.1.   Program- or system-level weaknesses shall be added to a POA&M [2] within 90 days of weakness discovery. [3]

2.2.   All security and privacy weaknesses identified during a review, audit, and/or security authorization process that remain unresolved [4] shall be documented in a POA&M. [5]

2.2.1.      Any finding identified by an Inspector General (IG) shall be documented in the POA&M, regardless of OPDIV acceptance. Disagreements on findings that cannot be resolved between the OPDIV and IG must be elevated to the Department for resolution. [6]

2.3.   All security and privacy weaknesses identified as a result of a security or privacy incident that remain unresolved after a security or privacy incident has been closed shall be documented in a POA&M and mitigated accordingly.  

2.4.   A completed weakness shall:

2.4.1.      Remain in the POA&M for one year following weakness remediation.  After one year, the weakness may be removed from the POA&M and archived. [7]

2.4.2.      Be validated, and supported by applicable artifacts. [8]  

2.5.   The transfer of a weakness from one program- or system-level POA&M to another shall be clearly traceable and justified.

3.      The following information shall, at a minimum, be documented and managed for every weakness:

3.1.   Weakness Identifier: An identifier shall be assigned for each weakness that is unique, and shall not to be re-used. The weakness identifier shall not change once it is recorded.

3.2.   Weakness Creation Date: The date on which the weakness, with its required informational elements, is officially entered in a program- or system-level POA&M shall be documented.

3.3.   Weakness Description: A description shall be created for each weakness in a POA&M. Sufficient information is required to enable appropriate oversight and tracking; adequately describe the weakness; and facilitate the creation of specific milestones to address the weakness. The weakness description and associated milestones shall not reveal sensitive information. [9] The weakness description shall not change once it is recorded.

3.4.   Weakness Source: A source shall be reported for all weaknesses. When recording the weakness source, the source name, type of review, [10] and the date on which the review was conducted or published shall be provided. If the weakness represents a repeat finding, each source in which the weakness was identified shall be documented.

3.5.   Security Control: Where applicable each weakness shall correspond to the appropriate security control identified in the National Institute for Standards and Technology (NIST) Special Publication (SP) 800-53, as amended.

3.6.   Point of Contact (POC): A POC shall be identified and documented for each weakness. The POC shall include:

3.6.1.      The position/role (e.g., Information System Security Officer [ISSO], Privacy Coordinator, System Owner) responsible for resolving and/or tracking the mitigation of the weakness.[11]

3.6.2.      Contact information such as name, phone number, and/or e-mail address, for ease of traceability and accountability.

3.7.   Resources Required: The resources required to successfully complete the weakness shall be estimated and documented. The estimate shall be based on the total resources required to fulfill all the milestones necessary for weakness mitigation. Resources shall be estimated as monetary value and/or staffing requirements.

3.7.1.      When identifying monetary value, the amount shall be categorized as New Funding, Existing Funding, or Reallocated Funding.

3.7.2.      Staffing requirements shall be estimated as staff-hours or full time equivalents (FTEs) and categorized as New Staff or Existing Staff. [12]

3.8.   Weakness Milestone(s): Each weakness shall have at least one milestone [13] with an associated completion date to facilitate corrective action. [14] Milestone(s) with completion date entries once recorded shall not be removed or changed.

3.9.   Changes to Milestone(s): Any necessary revision to an original milestone and/or a milestone completion date shall be documented. A revision to a milestone or its completion date does not replace the original Milestones with Completion Dates information, but is an amendment.

3.10. Scheduled Completion Date: A completion date shall be assigned to every weakness, to include the month, day, and year. The scheduled completion date shall not change once it is recorded. [15]

3.11. Estimated Completion Date: When a weakness is delayed beyond the original scheduled completion date, an estimated completion date must be set to document the revised plan for completion.

3.12. Actual Completion Date: An actual completion date shall be recorded on which the weakness has been remediated, validated, and the status of the weakness should be set to “complete.”

3.13. Weakness Status: A status shall be assigned to each weakness.

3.13.1. Ongoing/Open - This status is assigned only when a weakness is in the process of being mitigated and has not yet exceeded the associated Scheduled Completion Date. [16]

3.13.2. Completed/Closed - This status is assigned when all corrective actions have been completed for a weakness such that the weakness is successfully mitigated. Documentation shall be required to demonstrate the weakness has successfully been resolved. The Actual Completion Date shall be recorded for a completed weakness (for more information see paragraph 3.12). [17]

3.13.3. Delayed - This status is assigned when a weakness is being mitigated after the associated Scheduled Completion Date has passed. An explanation shall be provided in the Weakness Comments field.

3.13.4. Risk Accepted – This status indicates that the weakness risk has been accepted. When assigning this status, an acceptance of the risk should be certified by the appropriate OPDIV management and documented in the POA&M accordingly. Additionally, the weakness and corresponding risk should be monitored periodically to ensure the associated risk remains at an acceptable level. Justification of risk acceptance must be documented. [18]

3.13.5. Waiver – This status is assigned when the weakness risk has been accepted and justification has been appropriately documented. Justification of non-compliance must be documented in the Departmental Information Security Policy/Standard Waiver Request Form. [19]

3.13.6. Cancelled – This status is recorded when a weakness is recorded by mistake. Note that information regarding the cancellation of this weakness should be appropriately documented in the Comments field.

3.14. Weakness Severity: Every weakness shall be categorized as a Significant Deficiency, Reportable Condition, or Other Weakness based on the risk it poses to the OPDIV’s overall security. [20

3.14.1. Significant Deficiency– A weakness is considered a significant deficiency if it drastically restricts the capability of the Department or OPDIV to carry out its mission or if it compromises the security or privacy of its information, information systems, personnel, or other resources, operations, or assets. In this context, the risk is great enough that the Department or OPDIV Head and outside agencies must be notified, and immediate or near-immediate corrective action must be taken. 

3.14.2. Reportable Condition– A reportable condition is a weakness that does not rise to the level of significant deficiency yet is still important enough to be reported to OpDiv management. A security or privacy weakness that affects the efficiency and effectiveness of Department or OPDIV operations may be considered a reportable condition. Due to its lower associated risk, corrective actions for a reportable condition may be scheduled over a longer period of time. 

3.14.3. Other Weakness– All other weaknesses that do not rise to the level of a significant deficiency or reportable condition should be categorized as a weakness and mitigated in a timely and efficient manner, as resources permit.

3.15. Weakness Risk: The importance of the identified security control weaknesses or deficiencies (i.e., the direct or indirect effect the weaknesses or deficiencies may have on the overall security state of the information system, and hence on the risk exposure of the organization, or ability of the organization to perform its mission or business functions), rated as High, Moderate, or Low.

3.16. Weakness Comments: Any additional information or details necessary to clarify weakness information, status, and/or traceability shall be documented in the Weakness Comments field.

4.      A risk-based management approach shall be applied to the mitigation of each POA&M weakness, which should include prioritization by criticality and the availability of resources. [21]

POA&M Reporting

Accurate reporting of an OPDIV’s program- and system-level POA&Ms is critical to the continual awareness of the OPDIV’s and/or Department’s overall information security and privacy posture. Although not all of the elements below are required to be reported regularly, they must be readily available to be reported upon request by the Department. The following requirements are mandated to facilitate standardized POA&M documentation and reporting:

1.      OPDIVs shall submit periodic updates to the Department at least monthly, quarterly, and annually to represent the status of weakness mitigation.

2.      All weaknesses within a program or system boundary shall be documented, managed and reported.

2.1.   Minor application [child] weakness must be reported in one of the following two ways:

2.1.1.    Minor application [child] weaknesses may be documented, managed, and reported in conjunction with the corresponding general support system (GSS) or major application (MA) parent system on which they reside.

2.1.2.    Minor application [child] weaknesses may be documented, managed, and reported separately from the corresponding GSS or MA on which they reside. 


2.2.   Any finding and/or weakness identified in the final version of an audit document, review document, or authorization package shall be included in any requested reporting to the Department, OMB, Federal Network Systems (FNS), or other entity.

3.      The following information shall be reported for every POA&M:

3.1.   UUID

4.      The following information, following the management standards outlined in the POA&M Management section above, shall be reported for every weakness:

4.1.   Weakness Identifier

4.2.   Weakness Creation Date

4.3.   Weakness Description

4.4.   Weakness Source

4.5.   Weakness Control

4.6.   POC

4.7.   Resources Required

4.8.   Scheduled Completion Date

4.9.   Estimated Completion Date

4.10. Actual Completion Date

4.11. Weakness Status [22]

4.11.1. Ongoing/Open

4.11.2. Completed/Closed

4.11.3. Delayed

4.11.4. Risk Accepted [23]

4.11.5. Waiver [24]

4.11.6. Cancelled [25]

4.12. Weakness Severity

4.12.1. Significant Deficiency

4.12.2. Reportable Condition

4.12.3. Other Weakness

4.13. Weakness Risk

4.14. Weakness Comments



                                /s/                                                                                            November 28, 2012      

Frank Baitman                                                                                                   Date

HHS Chief Information Officer and Deputy Assistant Secretary for Information Technology 


[1] OMB M-04-25, FY 2004 Reporting Instructions for the Federal Information Security Management Act, August 23, 2004.

[2] In some cases, a weakness may be considered an acceptable risk.  Such a determination shall be certified by OPDIV management (e.g., the OPDIV CISO) and documented in the POA&M accordingly. The weakness shall be reviewed periodically to ensure the associated risk remains acceptable.

[3] Findings identified via an audit (internal review or an external audit) are not considered discovered until the final report has been issued.

[4] HHS Memorandum, Security of Information Technology Systems, November 10, 2009.

[5] OMB M-04-25, FY 2004 Reporting Instructions for the Federal Information Security Management Act, August 23, 2004.

[6] HHS Memorandum, Resolving Security Audit Finding Disputes, May 13, 2010.

[7] Ibid.

[8] Ibid.

[9] Sensitive information is information that has a degree of confidentiality such that its loss, misuse, unauthorized access, or modification could compromise the element of confidentiality and thereby adversely affect national health interests, the conduct of HHS programs, or the privacy of individuals entitled under the Privacy Act or the Health Insurance Portability and Accountability Act (HIPAA), as defined in HHS Memorandum: Updated Departmental Standard for the Definition of Sensitive Information, May 18, 2009.

[10] OMB M-04-25, FY 2004 Reporting Instructions for the Federal Information Security Management Act, August 23, 2004.

[11] Ibid.

[12] Ibid.

[13] Milestones are the specific, action-oriented steps necessary to mitigate a weakness. The number of milestones articulated per weakness shall directly correspond to the number of steps or corrective actions necessary to fully address and resolve the weakness.

[14] OMB M-04-25, FY 2004 Reporting Instructions for the Federal Information Security Management Act, August 23, 2004.

[15] Ibid.

[16] Ibid.

[17] Ibid.

[18] Justification for risk acceptance may include the use of compensating controls to lower the risk to an acceptable level.

[19] Waiver references the acknowledgement at the executive level (CISO). If an OPDIV requires a waiver for each accepted risk, this would be considered compliant with this requirement.

[20] OMB M-04-25, FY 2004 Reporting Instructions for the Federal Information Security Management Act, August 23, 2004.

[21] OMB M-04-25, FY 2004 Reporting Instructions for the Federal Information Security Management Act, August 23, 2004.

[22] Some OPDIVs will have additional weakness statuses that can and will be reported to the Department.

[23] Risk Accepted weaknesses will be counted as a closed weaknesses when reported to OMB.

[24] Waived weaknesses will be counted as closed weaknesses when reported to OMB.

[25] Cancelled weaknesses will be removed from the overall total weakness numbers and will not be reported to OMB.