CMS Plan of Action and Milestones (POA&M) Handbook
A complete guide to creating, managing, and closing your system’s POA&M
Last reviewed: 4/5/2023
Related Resources
What is a POA&M?
A Plan of Action and Milestones (POA&M) is a corrective action plan that tracks system weakness and allows System Owners and ISSOs to create a plan to resolve the identified weaknesses over time. A POA&M provides details about the personnel, technology, and funding required to accomplish the elements of the plan, milestones for correcting the weaknesses, and scheduled completion dates for the milestones.
POA&M process overview
The POA&M process begins when a weakness is identified in a CMS FISMA system. Working together, the System/Business Owner and the Authorizing Official (AO) are responsible for mitigating the risk posed by the weakness, with support from the Information System Security Officer (ISSO) and Cyber Risk Advisor (CRA). The steps to the POA&M process are outlined below, and will be described in greater detail throughout the remainder of this guide:
- Identify weaknesses
- Develop a Corrective Action Plan (CAP)
- Determine resource and funding availability
- Assign a completion date
- Execute the Corrective Action Plan (CAP)
- Verify weakness completion
- Accept risk when applicable
Identifying weaknesses
The term “weakness” represents any information security or privacy vulnerability that could be exploited as a result of a specific control deficiency. Weaknesses can compromise a system’s confidentiality, integrity, or availability. All weaknesses that represent risk to the security or privacy of a system must be corrected and the required mitigation efforts captured in a POA&M. For the purpose of this document, the term “weakness” as defined in NIST SP 800-53, rev. 5 will be synonymous with the terms finding and vulnerability. These terms are defined below:
Finding – During an assessment or audit, the security and privacy controls of a system are tested, or exercised. A system either satisfies the requirements or a control or does not satisfy it. Findings are the result of the assessment or audit. Findings that do not satisfy a control must be addressed with a POA&M.
Vulnerability – A vulnerability is a weakness in a system, a system’s security procedures, its internal controls, or its implementation that could be exploited or triggered by a threat source.
Finding weaknesses
Weaknesses may be found during an internal or external audit, review, or through Continuous Diagnostics and Mitigation (CDM) efforts. There are a number of specific sources that help system teams identify weaknesses:
- HHS OIG Audits
- Government Accountability Office (GAO) Audits
- Chief Financial Officer (CFO) Reviews
- OMB A-123 Internal Control Reviews
- Annual Assessments
- FISMA Audits
- Cybersecurity and Risk Assessment Program (CSRAP) or Security Control Assessments (SCA)
- Medicare Prescription Drug, Improvement, and Modernization Act of 2003 (MMA) Section 912 Audits
- Internal Revenue Service (IRS) Safeguard Reviews
- Department of Homeland Security (DHS) Risk Vulnerability Assessments (RVA)
- DHS Cyber Hygiene
- Penetration Testing
- Vulnerability Scanning
During these assessments, reviews, and audits, weaknesses can be found either proactively or reactively.
Proactive - Proactive weakness identification occurs during regular system reviews conducted by CMS.
Reactive - Reactive weakness determination indicates that the weakness was identified during an audit or external review, like a penetration test.
Weaknesses are always documented by the source that identified them, and it’s important to indicate the identification source as you create your POA&M.
Weakness severity levels
There are three severity levels for all weaknesses discovered during assessments, audits, and tests. The risk the weakness poses to the agency’s overall security and privacy posture determines a weakness’ severity level . There are three levels of severity as defined by OMB: significant deficiency, reportable condition, and weakness.
| Weakness severity levels | |
| Significant deficiency | A weakness is considered a significant deficiency if it drastically restricts the capability of the agency 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. Senior management must be notified and immediate or near immediate corrective action must be taken. |
| Reportable Condition | A reportable condition is a weakness that affects the efficiency and effectiveness of agency operations. Due to its lower associated risk, corrective actions for a reportable condition may be scheduled over a longer period of time. The control auditor or assessor will make the determination that a weakness is a reportable condition. |
| Weakness | All other weaknesses that do not rise to the level of a significant deficiency or reportable condition must be categorized as a weakness. They must be mitigated in a timely and efficient manner, as resources permit. |
The weakness severity level can be obtained from the source or the audit report. Most findings will generally be categorized as a “weakness”. In the event that a weakness is designated as a “significant deficiency”, then contact the CISO mailbox for further guidance.
Weakness risk level
NIST SP 800-30 contains the definitions and the practical guidance necessary for assessing and mitigating identified risks to IT systems. Risk level is dependent on multiple factors, such as Federal Information Processing Standard (FIPS) 199 category, operating environment, compensating controls, nature of the vulnerability, and impact if a system is compromised.
Risk can be evaluated either qualitatively or quantitatively and is typically expressed in its simplified form as:
RISK = THREAT x IMPACT x LIKELIHOOD
The result of the analysis of the risk(s) from following the NIST SP 800-30 guide will recommend the overall risk level assigned to FISMA system of record.
Root Cause Analysis (RCA)
All weaknesses must be examined to determine their root cause prior to documentation in the
POA&M. Root Cause Analysis (RCA) is an important and effective methodology used to correct information security or privacy weaknesses by eliminating the underlying cause. Various factors are reviewed to determine if they are the underlying cause of the weakness. Proper evaluation ensures the cause, not the symptom, is treated and prevents resources from being expended unnecessarily on addressing the same weakness.
Prioritizing weaknesses
CMS takes a risk management approach to ensure that critical and high-impact weaknesses
take precedence over lower security weaknesses. The following chart will help CMS System/Business Owners and ISSOs prioritize weaknesses on an ongoing basis to ensure that high-priority weaknesses receive the funding and the resources necessary to remediate or mitigate the most significant risks.
| Prioritization factor | Description |
| Risk level/severity | Weaknesses on a High or Moderate system or weaknesses that contribute to a material weakness, significant deficiency or reportable condition will normally require more immediate resolution. This prioritization factor must consider the following elements:
|
| Analysis | The weakness must be analyzed to determine if there are any other processes or system relationships that it may affect.
Systemic issues represent much greater risk and may be a higher priority. |
| Source | What is the source of the weakness? For example, if the weakness resulted from an audit and is considered a significant deficiency, then greater attention should be focused on this weakness. |
| Visibility | Has the weakness drawn a high level of visibility external to the system or program? In some cases, a lower level weakness is a higher priority due to visibility. There are times when senior management or outside organizations focus on a specific weakness. Such weaknesses may take priority. |
Regardless of how the weakness is found and how severe it is, it’s critical that system teams work together to create a Corrective Action Plan (CAP) to address it.
Develop a Corrective Action Plan (CAP)
After weaknesses have been identified and the root cause has been determined, a Corrective Action Plan (CAP) must be developed. The CAP identifies:
- The specific tasks, or “milestones”, that need to be accomplished to reduce or eliminate weakness
- The resources required to accomplish the plan
- A timeline for correcting the weakness including a completion date
The milestones in the CAP must provide specific, action-oriented descriptions of the tasks/steps that the stakeholder will take to mitigate the weakness. When creating your milestones, be sure that they are:
Specific – target a specific area for improvement
Measurable – quantify or at least suggest an indicator of progress
Assignable – specify who will do it
Realistic – state what results can realistically be achieved, given available resources
Time-related – specify when the result(s) can be achieved.
The number of milestones written per weakness must directly correspond to the number of steps or corrective actions necessary to fully address and resolve the weakness. Each weakness must have at least one corresponding milestone with an estimated completion date and resource requirements to remediate the weakness. The chart below provides samples of compliant and non-compliant milestones that system teams can use when writing their CAP.
Examples of appropriate milestones
| POA&M description | Example | Milestones with completion dates |
| Vulnerability scanning does not incorporate the entire environment as documented in the System Security and Privacy Plan (SSPP) | Inappropriate |
|
| Vulnerability scanning does not incorporate the entire environment as documented in the System Security and Privacy Plan (SSPP) | Appropriate |
|
| Audit logs are not periodically reviewed | Inappropriate |
|
| Audit logs are not periodically reviewed | Appropriate |
|
The CAP should be a collaborative effort with stakeholders including the CISO, System/Business Owners, System Developers and Maintainers, ISSOs, and others as needed. These stakeholders ensure that the CAP is created, executed, monitored, and worked to closure or risk-based acceptance.
OMB provides a standard POA&M format which is utilized at CMS. This structure improves the stakeholders’ ability to easily locate information and organize details for analysis. The CAP format includes a location for the identified program weakness, any associated milestones, and the necessary resources required.
Once the CAP is documented, the plan must be entered into CFACTS in the form of a series of milestone records. The status of the POA&M will automatically be moved from “draft” to “ongoing” 30 days after the weakness creation date. Once a milestone has been accepted/approved and closed, the record must be retained for one year.
Determine resource and funding availability
Making funding decisions is often a collaborative exercise that involves multiple system personnel and stakeholders. Examples of questions to ask to determine if your team has the resources to appropriately respond to a weakness are:
- Is one team or person enough or will the participation of a larger team be needed?
- Can the task be accomplished within a week or will it take several months?
- How serious is the weakness?
- What is this weakness’ risk level?
- How complex is the CAP?
- Do we need to purchase equipment?
- Can the weakness be addressed with existing funding or will we require new allocation from an existing budget source?
- Will my addressing this milestone require changes to existing policy or code?
The System/Business Owner, ISSOs, and other stakeholders must ensure that adequate resources are allocated to mitigate or remediate weaknesses. They must also work together to determine the funding stream required to address the weakness, and any full-time equivalent (FTE) resources required to remediate or mitigate each weakness on the POA&M. The resources required for weakness remediation must fall into one of the following three categories:
- Using current resources allocated for the security and/or management of a program or system to complete remediation activities
- Reallocating existing funds that are appropriated and available for the remediation, or redirecting existing personnel
- Requesting additional funding or personnel
Duplicate or similar weaknesses shall be documented in one POA&M, existing or new, to avoid inconsistencies. If a related POA&M already exists, the additional weakness shall be noted in the comment field.
Assign a completion date
System/Business Owners, ISSOs, and other stakeholders must determine the scheduled completion date for each weakness using the criteria established by the remediation and mitigation timeline, the risk level, and the severity level. The milestone(s) completion date must not exceed the scheduled completion date assigned to the weakness.
It is also a good practice to first determine the milestones with completion dates, as this will help determine a more accurate overall scheduled completion date for the weakness. The weakness schedule completion date is a calculated date. It is determined by the identified date and the risk level. The scheduled completion date established at the creation of the weakness must not be modified after the weakness is reported to OMB. POA&Ms become reportable once the status changes from “Draft” to “Ongoing” in CFACTS.
If a weakness is not remediated within the scheduled completion date, a new estimated completion date must be determined and documented in the Changes to Milestones and Comment fields in the POA&M in CFACTS.
NOTE: In use cases where a responsive and timely POA&M cannot be developed, the ISSO can choose to consider the Risk Based Decision (RBD) process to request the Authorizing Official (AO) to consider a risk acceptance until such time the vulnerability can be remediated.
Execute the Corrective Action Plan (CAP)
A designated Point of Contact (POC), responsible for ensuring proper execution of the CAP, must be identified for each weakness and its milestones. Individual(s) responsible for the execution of the CAP vary widely depending on the organization, system, milestones, and weakness.
This POC resource will be key to identifying an “owner” of the milestone and ensuring the milestone is worked to the eventual remediation of the weakness or acceptable mitigation of the weakness. Once the planning of the necessary corrective action is complete and adequate resources have been made available, remediation or mitigation activities will proceed in accordance with the plan.
If the completion of a milestone extends past its original estimated completion date, an update to the milestone and the completion date of the milestone must be captured in the “Changes to Milestone” field of CFACTS. If the scheduled completion date has passed before the weakness is remediated or mitigated, the weakness must default to “Delayed” status and a justification with a new estimated completion date must be documented in the “Comment” field and the “Changes to Milestone” field of the relevant weakness in CFACTS.
Verify weakness completion
CMS requires that all information in the POA&M be updated at least quarterly, ensuring accuracy for efficient tracking and reporting. As part of the review process, the ISSO will:
- Validate that the weakness is properly identified and prioritized
- Ensure that appropriate resources have been made available to resolve the weakness
- Ensure that the schedule for resolving the weakness is both appropriate and achievable
Accept risk when applicable
A POA&M is a plan to resolve unacceptable risks. In rare cases, the Business Owner can present a case for accepting the risk to the AO or CIO, who may make the decision to accept the risk at their discretion. This is part of the Risk Based Decision (RBD) process. After approval, RBDs shall be reviewed at least annually to ensure the risk remains acceptable and updated as events occur and information changes. RBDs are managed in CFACTS under the "RBD" tab.
Closing a POA&M
POA&Ms designated as Low and Moderate are closed by the ISSO and spot audited by a CRA.
POA&Ms designed as Critical and High are closed by the CRA.
POA&Ms generated from audits should be reviewed by the auditor prior to closure.
POA&Ms resulting from a Penetration Test (PenTest) are closed by the PenTest team after the re-test has been performed.
Reports
Reporting is a critical component of POA&M management, and CMS reports its remediation efforts on a monthly basis. The information in the POA&M must be maintained continuously to communicate overall progress. CMS must submit POA&M updates at least once a month (by the 3rd business day of each month) to HHS to demonstrate the status of POA&M mitigation or remediation activities.
CMS must submit the following information in accordance with the Department POA&M reporting requirements:
- All POA&Ms associated with a program, system and/or component that are within an authorization boundary. POA&Ms must be tied to the individual system and/or component and not the authorization boundary.
- An explanation associated with each delayed POA&M and a revised estimated completion date.
- Completed POA&Ms for up to one year from the date of completion.
Weakness remediation and mitigation timeline
After positive identification of scan findings or approval of security assessment and/or audit report, all findings/weaknesses shall be documented in a POA&M, reported to HHS, and remediated/mitigated within the following remediation timelines.
- Critical within 15 days
- High within 30 days
- Moderate within 90 days
- Low within 365 days
Business Owners, ISSOs, and/or other POA&M stakeholders must work together to determine the scheduled completion date for each POA&M within the specified remediation timelines. These timelines are based on the date the weakness is identified, not the date the POA&M is created. Stakeholders should complete and submit their CAAT templates in a timely manner to allow for the maximum time to complete the remediation/mitigation.
If it is determined that additional time is needed to remediate or mitigate a weakness, the justification with a modified estimated completion date shall be documented in the POA&M in the Changes to Milestones and Comment fields in CFACTS. If weaknesses are not remediated within the scheduled completion date, the status shall change to “Delayed”.
Weaknesses discovered during a government audit
Weaknesses identified during a government audit (i.e., Inspector General or GAO audit) shall be documented in the POA&M after the audit draft report is produced, regardless of CMS acceptance of the identified weakness(es). Disagreements on findings that cannot be resolved between CMS and the auditing office shall be elevated to the Department for resolution. Systems must review and update POA&Ms at least quarterly. In addition, compensating controls must be in place and documented until weaknesses are remediated or mitigated to an acceptable level of risk.
CFACTS
Stakeholders must use CFACTS, the CMS GRC tool, to identify, track, and manage all system weaknesses and associated POA&Ms to closure for CMS information systems. Users who need access to CFACTS may request an account and appropriate privileges through the Enterprise User Administration (EUA). The job code is CFACTS_User_P. Once the job code is assigned, the user must email the CISO mailbox at ciso@cms.hhs.gov to notify the CISO of the user’s role (ISSO, System Developer, or System/Business Owner).
The CFACTS User Manual provides detailed instructions for processing POA&M actions in the CFACTS tracking system. The User Manual can be accessed under the CFACTS Documents section on the CFACTS Artifacts page which can be accessed by clicking on the CFACTS Artifacts icon on the welcome page.
POA&M Glossary
The following glossary will help system teams understand the language of the POA&M process.
| Term | Definition |
| Annual Assessment | The process of validating the effective implementation of security and privacy controls in the information system and its environment of operation within every three hundred sixty-five (365) days in accordance with the CMS Information Security (IS) Acceptable Risk Safeguards (ARS) Including CMS Minimum Security Requirements (CMSR) Standard, to determine the extent to which the controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting established security and privacy requirements. |
| Audit | An independent review and examination of records and activities to assess the adequacy of system controls, to ensure compliance with established policies and operational procedures, and to recommend necessary changes in controls, policies, or procedures. |
| Capital Planning and Investment Control | A decision-making process for ensuring that investments integrate strategic planning, budgeting, procurement, and the management of or in support of Agency missions and business needs. [OMB Circular No. A-11]. The term comes from the Clinger-Cohen Act of 1996; while originally focused on IT, it now applies also to non-IT investments. |
| Common Control | A security or privacy control that is inherited by one or more organizational information systems. See Security Control Inheritance. |
| Completed | A status assigned when all corrective actions have been completed or closed for a weakness and the weakness has been verified as successfully mitigated. Documentation is required to demonstrate the weakness has been adequately resolved. When assigning the status of ‘Completed’, the date of completion must also be included. |
| Completion date | The action date when all weaknesses have been fully resolved and the corrective action plan has been tested. |
| Control activities | The policies and procedures that help ensure that management directives are carried out. They help ensure that necessary actions are taken to address risks to achievement of the entity’s objectives. Control activities, whether automated or manual, help achieve control objectives and are applied at various organizational and functional levels. |
| Control deficiency | A deficiency that exists when the design or operation of a control does not allow management or employees to, in the normal course of performing their assigned functions, prevent or detect breaches of confidentiality, integrity, or availability on a timely basis. (See also design deficiency or operations deficiency) |
| Corrective Action Plan (CAP) | The plan management formulates to document the procedures and milestones identified to correct control deficiencies. |
| Criteria | A context for evaluating evidence and understanding the findings, conclusions, and recommendations included in the report. Criteria represent the laws, regulations, contracts, grant agreements, standards, specific requirements, measures, expected performance, defined business practices, and benchmarks against which performance is compared or evaluated. Criteria identify the required or desired state or expectation with respect to the program or operation. |
| Delayed | A status assigned when a weakness continues to be mitigated after the original scheduled completion date has passed. When assigning the status of ‘Delayed,’ an explanation must be provided in the milestone as to why the delay is occurring, as well as the revised completion date. |
| Design deficiency | A deficiency that exists when a control necessary to meet the control objective is missing or an existing control is not properly designed, so that even if the control operates as designed the control objective is not always met. |
| Draft | A status that indicates that a weakness requires review and approval prior to “official” entry in the POA&M. Types of review that may take place while a weakness is in draft status would be: reviewing to determine if the weakness already exists and would be a duplicate; reviewing to determine if the organization will accept the risk, or apply for a waiver; etc. |
| Evidence | Any information used by the auditor, tester, or evaluator, to determine whether the information being audited, evaluated, or assessed is stated in accordance with the established criteria. |
| FISMA Audit | A FISMA assessment designed to determine areas of compliance and areas requiring remediation to become FISMA compliant. |
| Federal Information Security Modernization Act (FISMA) | Requires agencies to integrate information technology (IT) security into their capital planning and enterprise architecture processes at the agency, conduct annual IT security reviews of all programs and systems, and report the results of those reviews to the OMB. [NIST SP 800-65] |
| Findings | Conclusions based on an evaluation of sufficient, appropriate evidence against criteria. |
| Information Security Risk | The risk to organizational operations (including mission, functions, image, reputation), organizational assets, individuals, other organizations, and the Nation due to the potential for unauthorized access, use, disclosure, disruption, modification, or destruction of information and /or information systems. |
| Primary Information System Security Officer (ISSO) | Individual with assigned responsibility for maintaining the appropriate operational security and privacy posture for an information system or program. |
| Initial audit findings | Any type of audit conducted on a financial system or a non-financial system. |
| Internal control | An integral component of an organization’s management systems that provides reasonable assurance that the following objectives are being achieved: effectiveness and efficiency of operations, reliability of financial reporting, or compliance with applicable laws and regulations. |
| Management controls | The security or privacy controls (i.e., safeguards or countermeasures) for an information system that focus on the management of risk and the management of information system security and privacy. |
| Material weakness | Material weaknesses includes reportable conditions in which the Secretary or Component Head determines to be significant enough to report outside of the Department. Material weakness in internal control over financial reporting is a reportable condition, or combination of reportable conditions, that results in more than a remote likelihood that a material misstatement of the financial statements, or other significant financial reports, will not be prevented or detected. |
| Metrics | Tools designed to facilitate decision making and improve performance and accountability through collection, analysis, and reporting of relevant performance-related data. |
| Non-conformance | Instances in which financial management systems do not substantially conform to financial systems requirements. Financial management systems include both financial and financially-related (or mixed) systems. |
| Ongoing | A status assigned when a weakness is in the process of being mitigated and has not yet exceeded the original scheduled completion date. |
| Operational controls | The security or privacy controls (i.e., safeguards or countermeasures) for an information system that are primarily implemented and executed by people (as opposed to systems). |
| Operations deficiency | A deficiency that exists when a properly designed control does not operate as designed or when the person performing the control is not qualified or properly skilled to perform the control effectively. |
| Pending verification | A status that indicates that all milestones/corrective actions have been completed but require review and sign-off to ensure effective resolution. |
| Plan of Action and Milestones (POA&M) | A FISMA mandated corrective action plan to identify and resolve information security and privacy weaknesses. A document that identifies tasks needing to be accomplished. It details resources required to accomplish the elements of the plan, any milestones in meeting the tasks, and scheduled completion dates for the milestones. |
| Potential impact | The loss of confidentiality, integrity, or availability could be expected to have: (i) a limited adverse effect (FIPS 199 low); (ii) a serious adverse effect (FIPS 199 moderate); or (iii) a severe or catastrophic adverse effect (FIPS 199 high) on organizational operations, organizational assets, or individuals. |
| Program | An organized set of activities directed toward a goal or particular set of goals or objectives for which the program is accountable; a distinct set of activities and strategies organized toward achieving a specific purpose. A program is a representation of what is delivered to the public. Programs usually operate for indefinite or continuous periods, but may consist of several projects or initiatives. |
| Reportable condition | Reportable conditions overall include a control deficiency, or combination of control deficiencies, that in management’s judgment, must be communicated because they represent significant weaknesses in the design or operation of an internal control that could adversely affect the organization’s ability to meet its internal control objectives. |
| Resilience | The ability to continue to: (i) operate under adverse conditions or stress, even if in a degraded or debilitated state, while maintaining essential operational capabilities; and (ii) recover to an effective operational posture in a time frame consistent with mission needs. [NIST SP 800-39, Adapted] |
| Risk | A measure of the extent to which an entity is threatened by a potential circumstance or event, and typically a function of: (i) the adverse impacts that would arise if the circumstance or event occurs; and (ii) the likelihood of occurrence. Information system-related security and privacy risks are those risks that arise from the loss of confidentiality, integrity, or availability of information or information systems and reflect the potential adverse impacts to organizational operations (including mission, functions, image, or reputation), organizational assets, individuals, other organizations, and the Nation. |
| Risk accepted | A status assigned when the weakness risk has been accepted. When assigning this status, an acceptance of the risk must be certified by the appropriate Authorizing Official and documented accordingly. The weakness and corresponding risk must be monitored periodically to ensure the associated risk remains at an acceptable level. |
| Safeguards | Protective measures prescribed to meet the security and privacy requirements specified for an information system. Safeguards may include security and privacy features, management constraints, personnel security, and security of physical structures, areas, and devices; synonymous with security and privacy controls and countermeasures. |
| Scheduled or estimated completion date | A realistic estimate of the amount of time it will take to complete all associated milestones for a POA&M. |
| Security Control Assessment (SCA) | The testing and/or evaluation of the management, operational, and technical security controls in an information system to determine the extent to which the controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the security requirements for the system. [NIST SP 800-37] |
| Security Control Inheritance | A situation in which an information system or application receives protection from security and privacy controls (or portions of security and privacy controls) that are developed, implemented, assessed, authorized, and monitored by entities other than those responsible for the system or application; entities either internal or external to the organization where the system or application resides. See Common Control. |
| Significant deficiency | A weakness in an agency’s overall information systems security and privacy program or management control structure, or within one or more information systems, that significantly restricts the capability of the agency to carry out its mission or 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 agency head and outside agencies must be notified and immediate or near-immediate corrective action must be taken. |
| Technical controls | Security controls (i.e., safeguards or countermeasures) for an information system that are primarily implemented and executed by the information system through mechanisms contained in the hardware, software, or firmware components of the system. [FIPS 200] |
| Threat | Any potential danger to information or systems. A potential threat event, if realized, would cause an undesirable impact. The undesirable impact can come in many forms, but often results in a financial loss. A threat agent could be an intruder accessing the network through a port on the firewall, a process of accessing data in a way that violates that security or privacy policy, a tornado wiping out a facility, or an employee making an unintentional mistake that could expose confidential information or destroy a file’s integrity. |
| Vulnerability | The absence or weakness of a safeguard that could be exploited; the absence or weakness of cumulative controls protecting a particular asset. Vulnerability is a software, hardware, or procedure weakness that may provide an attacker the open door he is looking for to enter a computer or network and have unauthorized access to resources within the environment. |
| Waiver | A status provided when the weakness risk has been accepted and justification has been appropriately documented. Justification of non- compliance must follow the agency's waiver policy and be documented accordingly. |
| Weakness | The absence of adequate controls. |