Standard 2011-0001 001S
Standard for Plans of Action and Milestones (POA&M) Management and Reporting
March 30, 2011
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-02-01, Guidance for Preparing and Submitting Security Plans of Action and Milestones; OMB 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-OCIO Policy for Information Systems Security and Privacy (IS2P) dated September 22, 2010. These standards represent the minimum requirements that shall be employed for all security programs, systems and applications and it supersedes the Standard for Plan of Action and Milestones, dated December 23, 2008, 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.
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 informs risk-based decision making. The following requirements are mandated to facilitate and standardize enterprise-wide POA&M management:
- 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.
- Program- or system-level weaknesses shall be added to a POA&M within 90 days of weakness discovery. Any finding and/or weakness documented for remediation in the final version of an audit document, review document or authorization package shall be considered weakness discovery and shall be included in the quarterly report to OMB.
- All security weaknesses identified during a review, audit, and/or certification process that remain unresolved shall be documented in a POA&M.
- All security weaknesses identified as a result of a security or privacy incident and/or remain unresolved after a security or privacy incident has been closed shall be documented in a POA&M and mitigated accordingly.
- 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.
- 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.
- Each POA&M that corresponds to a project (including systems) shall be linked to an Exhibit 300 or 53 through the use of the unique project identifier (UPI).
- A completed weakness shall remain in the POA&M for one year following weakness remediation, at which time the weakness may be removed from the POA&M and archived.
- The completion of all weaknesses shall be validated, and supported by applicable artifacts.
- 0. The transfer of a weakness from one program- or system-level POA&M to another shall be clearly traceable and justified.
Accurate reporting of an OPDIV’s program- and system-level POA&Ms is critical to the continual awareness of the OPDIV’s and/or Agency’s overall information security and privacy posture. The following requirements are mandated to facilitate standardized POA&M documentation and reporting:
1. OPDIVs shall submit periodic updates to HHS, at least quarterly, to represent the status of weakness mitigation.
2. All weaknesses within a program or system boundary shall be documented and reported. Minor application [child] weaknesses shall be reported in conjunction with the corresponding general support system (GSS) or major application (MA) parent system on which it resides independent of the internal OPDIV management construct.
2.1. Minor application [child] weaknesses may be documented and managed separately from the corresponding GSS or MA on which it resides.
3. The NIST SP 800-53 Revision 3, as amended, control to which the weakness corresponds shall be documented for each weakness, where applicable.
4. The UPI shall be documented for each POA&M that corresponds to a project.
5. The following information shall be reported for every weakness:
5.1. Weakness Identifier: An identifier shall be assigned for each weakness that is unique, and not to be re-used. The weakness identifier shall not change once it is recorded.
5.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.
5.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. The weakness description shall not change once it is recorded.
5.4. Weakness Source: A source shall be reported for all weaknesses. When recording the weakness source, both the type of review 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.
5.5. Point of Contact (POC): A POC shall be identified and documented for each weakness. The POC shall at a minimum refer to the position/role (e.g., Information System Security Officer [ISSO], Privacy Coordinator, System Owner) responsible for resolving the weakness.
5.6. 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. When identifying monetary value, the amount shall be categorized as New Funding, Existing Funding, or Reallocated Funding. Staffing requirements shall be estimated as staff-hours or full time equivalents (FTEs) and categorized as New Staff or Existing Staff.
5.7. Scheduled Completion Date: A completion date shall be assigned to every weakness, to include the month, day, and year using the format: MMDDYYYY. The scheduled completion date shall not change once recorded.
5.8. Milestones with Completion Dates: Each weakness shall have at least one milestone with an associated completion date to facilitate corrective action. Milestone(s) with completion date entries once recorded shall not be removed or changed, however, see 5.9.
5.9. Changes to Milestone Date: Any necessary revision to the original milestone completion date due to the original date being surpassed because additional time or resources are required shall be documented. This revised Milestone Completion Date does not replace the original Milestone Completion Date, but is an amendment.
5.10. Weakness Status: A status shall be assigned to each weakness.
5.8.1 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 Date of Completion shall be recorded for a completed weakness.
5.8.2 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.
5.8.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.
5.11. Weakness Severity: Every weakness shall be categorized as a Significant Deficiency, Reportable Condition, or Weakness based on the risk it poses to the OPDIV’s overall security.
5.9.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.
5.9.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 internal 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.
5.9.3 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 timely and efficiently, as resources permit.
5.12. Weakness Comments: Any additional information or details necessary to clarify weakness information, status and/or traceability shall be documented in the Weakness Comments field.
APPROVED BY & EFFECTIVE ON:
Michael W. Carleton Date
HHS Chief Information Officer and
Deputy Assistant Secretary for Information Technology