HHS Standard for Plan of Action and Milestones (POA&M)

December 23, 2008

HHS Standard 2008-0005.001S
Standard for Plan of Action and Milestones (POA&M)


Introduction

This document establishes standards for developing, maintaining, 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) Memorandum (M) 02-01, Guidance for Preparing and Submitting Security Plans of Action and Milestones; M-08-21, FY 2008 Reporting Instructions for the Federal Information Security Management Act and Agency Privacy Management, dated July 14, 2008; Federal Information Security Management Act (FISMA) of 2002; and  OMB Circular A-130, Management of Federal Information Resources.

 

These standards shall be employed for all systems and applications and reported to the Department on a regular basis—at least quarterly—to coincide with NIST guidance and FISMA requirements. The following is effective immediately: 

1.      All information technology (IT) security weaknesses which represent risks to the security of OPDIV and HHS systems and information require a planned mitigation strategy in the form of a POA&M.(1)  These POA&Ms shall be entered and managed in the Department's authoritative FISMA data reporting and management tool.  These POA&Ms shall be developed within a timely manner of the weakness discovery.  Common sources of weaknesses include IT and non-IT focused audits, regular testing of information security controls, and certification and accreditation (C&A) activities.(2)

2.      POA&Ms shall be specific to the OPDIV information security program or system in which the weakness was identified.  Each program and system reported within the Department’s FISMA reporting tool shall have a corresponding POA&M.

3.      POA&M weaknesses shall be prioritized by criticality (i.e., weaknesses with the greatest potential impact to the organization’s mission are addressed first).   

4.      OPDIVs shall submit periodic updates, no less than quarterly, via the FISMA reporting tool that demonstrate progress in identifying and mitigating weaknesses.  

5.      A completed weakness shall remain in the POA&M for one year following weakness remediation, at which time the weakness may be removed from POA&M reporting and archived.   

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

7.      All POA&Ms require the following information for every weakness reported in the FISMA reporting tool:

7.1.   Weakness Identifier: An identifier shall be assigned to each weakness.  The naming convention for an IT system weakness identifier shall begin with the name of the associated OPDIV, then the name of the associated system, the quarter (Q), fiscal year (FY) during which the weakness was first recorded on the POA&M, and a sequence number  (e.g., OPDIV_System Name_A_2003_01).  The naming convention for a program weakness identifier shall use the program name in lieu of a system name (e.g., OPDIV_Program Name_A_2003_01).  The weakness identifier shall not change once it is recorded in the FISMA reporting tool.

7.2.   Weakness Description: A description shall be created for each weakness in a POA&M.  Sufficient information is required to enable appropriate oversight and tracking, demonstrate awareness of the weakness, and facilitate the creation of specific milestones to address the weakness.(3)  The weakness description shall not change once it is recorded in the FISMA reporting tool.

7.3.   Weakness Source: Identify sources for all weaknesses.  When recording the weakness source, both the type of review and the date on which this review was conducted or published shall be provided (e.g., 2008 program review, 2008 Inspector General [IG] Audit, 2007 Chief Financial Officer [CFO] Audit, etc.). 

7.4.   Point of Contact (POC): A POC shall be identified and documented for each weakness reported.  The POC shall refer to the position/role (e.g., Information System Security Officer [ISSO], system owner) responsible for resolving the weakness; the POC may not include an individual name.

7.5.   Resources Required:  The resources required to successfully complete the weakness shall be estimated.  The estimate shall be based on the total resources needed to fulfill all the milestones necessary for weakness correction.  Resources shall be estimated as monetary value or staffing requirements.  When identifying monetary funding, the amount shall be categorized as New Funding, Existing Funding, or Reallocated Funding.  Staffing requirements shall be estimated as man-hours or full time equivalents (FTEs) and categorized as New Staff or Existing Staff.

7.6.   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 in the FISMA reporting tool. (4)

7.7.   Milestones with Completion Dates: Each weakness shall have a corrective action plan documented that identifies specific actions to correct the weakness.  Each weakness shall document at least one milestone with an associated completion date.  Milestone with Completion Date entries shall not change once recorded in the FISMA reporting tool. (5)

7.8.   Weakness Status:  A status of Completed, Ongoing, or Delayed shall be assigned to each weakness.

7.8.1.      Completed—This status is assigned when all corrective actions have been applied to a weakness such that the weakness is successfully mitigated.  The Date of Completion shall be recorded for a completed weakness.

7.8.2.      Ongoing—This status is assigned only when a weakness continues to be mitigated and has not yet exceeded the associated Scheduled Completion Date.

7.8.3.      Delayed—This status is assigned only when a weakness continues to be mitigated after the associated Scheduled Completion Date has passed.  An explanation shall be provided in the Weakness Comments field. 

7.9.   Weakness Severity:  Every weakness shall be categorized as either a Significant Deficiency, Reportable Condition, or Weakness based on the risk it poses to the OPDIVs’ overall security. 

7.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 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. 

7.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 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. 

7.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.

 

APPROVED BY & EFFECTIVE ON:

 

/s/                                            December 23, 2008            

Michael W. Carleton                                                                   Date

HHS Chief Information Officer and

Deputy Assistant Secretary for Information Technology

NOTES:

(1) In some cases, a weakness may not be documented in the POA&M because a determination was made that the continued existence of the weakness is an acceptable risk. Such a determination shall be certified by OPDIV management (e.g., the OPDIV Chief Information Security Officer [CISO]) and documented accordingly. Suggested means of documentation include the system self assessment, the system security plan, or the system certification letter. Once the documentation is complete, it is not necessary for the weakness to be included in the POA&M; however, the weakness shall be reviewed periodically to ensure the associated risk remains acceptable.

(2) Any finding identified by an Inspector General (IG) or other audit 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.

(3) Information identifying the exact location of the vulnerability (e.g., server name or Internet Protocol [IP] address) shall not be included in the weakness description. It is acceptable to substitute specific vulnerability information with a reference where additional information can be obtained by individuals with a need to know.

(4) If the time to correct the weakness extends beyond the original scheduled date of completion, the status of the weakness shall be changed to ‘delayed,’ and reasons for the delay shall be noted in the ‘Weakness Comments’ field. A revised scheduled date of completion shall also be documented in the ‘Weakness Comments’ fields.

(5) Identify revised milestone and/or anticipated date of completion in the ‘Changes to Milestones’ field