Background
- The Defense Federal Acquisition Regulation Supplement (DFARS) clause 252.204-7012, titled “Safeguarding Covered Defense Information and Cyber Incident Reporting,” requires contractors and subcontractors to have proper security measures to protect sensitive defense information. This information, referred to as Department of Defense (DoD) Controlled Unclassified Information (CUI) in this context, must be safeguarded when stored or transmitted through a contractor’s internal systems or networks. Contractors are also required to report any cybersecurity incidents affecting these systems to the DoD. To meet this requirement, contractors must follow the security standards outlined in the National Institute of Standards and Technology (NIST) Special Publication (SP) 800-171. Additionally, DFARS clause 252.204-7012 requires contractors to pass on these obligations to subcontractors involved in critical support or handling of DoD CUI. Contractors must also mark or label any DoD CUI as required by their specific contracts to ensure proper identification and handling.
- DFARS provision 252.204-7008, titled “Compliance with Safeguarding Covered Defense Information Controls,” requires companies bidding for contracts to confirm that they will comply with the security requirements in NIST SP 800-171. This includes having a system security plan that defines the boundaries of their systems, operational environments, how security requirements are implemented, and how their systems connect to other systems. If all security requirements are not yet implemented, companies must create and follow action plans detailing how and when they will address the gaps.
- A memorandum from the Under Secretary of Defense for Acquisition and Sustainment (USD(A&S)) dated February 5, 2019, called “Strategically Implementing Cybersecurity Contract Clauses,” directed the Defense Contract Management Agency (DCMA) to establish a consistent, standardized approach to assess contractors’ compliance with NIST SP 800-171 requirements. This assessment is conducted at the corporate level as a strategic alternative to evaluating compliance for each individual contract.
Purpose
- The NIST SP 800-171 DoD Assessment Methodology, Version 1.2 provides a standardized approach for evaluating how contractors are meeting the security requirements outlined in NIST SP 800-171. These requirements are necessary to comply with DFARS clause 252.204-7012, which ensures the protection of sensitive DoD information.
- This methodology is solely intended for assessment purposes. It does not introduce any new requirements or change the existing requirements specified in NIST SP 800-171 or DFARS clause 252.204-7012.
- The DoD will use this methodology to evaluate how well its primary contractors have implemented NIST SP 800-171. Prime contractors can also use this methodology to assess their subcontractors’ compliance with the same standards.
- This methodology was tested through pilot assessments conducted in 2019 by the Defense Contract Management Agency (DCMA), in collaboration with the Defense Counterintelligence and Security Agency (DCSA) and other DoD entities. Based on these pilots, the DoD plans to refine and formally incorporate this methodology into its policies and regulations.
Strategically Assessing a Contractor’s Implementation of NIST SP 800-171
- The NIST SP 800-171 DoD Assessment Methodology provides a way for the DoD to evaluate how well a contractor is following security requirements outlined in NIST SP 800-171 for contracts that include DFARS clause 252.204-7012. Instead of reviewing each contract separately, this approach allows the DoD to assess contractors at a higher, more strategic level and share summary results with relevant DoD teams.
- There are three types of assessments in this methodology (explained in Section 4). These types reflect how thorough the assessment is and how much confidence the DoD has in the results.
- Contractors with contracts that include DFARS clause 252.204-7012 will typically be assessed every three years. However, if there are specific risks, critical issues, or changes in security, assessments may be done more frequently.
Levels of Assessment
- Basic (Contractor Self-Assessment) NIST SP 800-171 DoD Assessment
- The Basic Assessment is a self-review by the contractor to evaluate how well they have implemented the NIST SP 800-171 security requirements. This review is based on their system security plan and follows the guidance outlined in this document.
- The results of the Basic Assessment have a low level of confidence because the contractor generates the score themselves.
- Contractors must document the summary level scores from the Basic Assessment as explained in Section 6 and Annex B of this document.
- Medium NIST SP 800-171 DoD Assessment
- The Medium Assessment is carried out by trained DoD personnel who follow DoD policies and procedures. These assessments are often part of a scheduled visit, such as during a Critical Design Review.
- The Medium Assessment involves a detailed review of the contractor’s system security plan to ensure that it properly explains how each security requirement is met.
- The results of the Medium Assessment are given a medium confidence level.
- DoD assessors must document the summary level scores from the Medium Assessment as outlined in Section 6 of this document.
- High (On-Site or Virtual) NIST SP 800-171 DoD Assessment
- The High Assessment is a thorough review conducted by trained DoD personnel. It involves either an on-site or virtual evaluation to verify the contractor’s security plan and how well they have implemented NIST SP 800-171 requirements.
- During a High Assessment, assessors use evidence such as scanning results, system inventories, and configuration settings to confirm compliance. Demonstrations of security measures, such as multi-factor authentication, may also be required.
- An on-site High Assessment is the preferred approach because it allows assessors to fully verify and validate the effectiveness of the contractor’s security safeguards. Virtual assessments may be used as an alternative but may not provide a complete picture of the risks.
- A virtual High Assessment follows the same process as an on-site assessment but includes extra steps to protect data. All information is securely shared through the DoD Secure Access File Exchange (SAFE) system and reviewed only on authorized devices. Contractor data is destroyed after the assessment following NSA data destruction guidelines.
- Contractors must first complete a Basic Assessment and share the results with the DoD. The High Assessment builds on this by reviewing the Basic Assessment, discussing the findings with the contractor, and verifying compliance. No direct network access is required for assessors during this process.
- The High Assessment provides a high level of confidence in the results.
- DoD assessors document the summary level scores from the High Assessment as described in Section 6 of this document.
NIST SP 800-171 DoD Assessment Scoring Methodology
The scoring methodology in this section provides a standardized way to measure how well contractors are implementing the security requirements outlined in NIST SP 800-171. The score reflects the contractor’s level of compliance, with deductions based on unmet requirements.
- Starting Score | Every contractor begins with a score of 110 points, which represents the total number of security requirements in NIST SP 800-171
- Deductions for Unmet Requirements | Points are subtracted for each security requirement that is not fully implemented. The number of points deducted depends on the importance of the requirement:
- 5 points are deducted for critical requirements that, if unmet, pose a significant security risk. Examples include requirements for access control and preventing unauthorized data access.
- 3 points are deducted for requirements that have a moderate impact on security if not met. These may involve specific aspects of data protection or access limitations.
- 1 point is deducted for requirements that have a limited or indirect effect on security but are still necessary for overall compliance.
- Critical and Weighted Requirements | Some requirements carry more weight because they are fundamental to protecting sensitive information:
- Critical requirements, such as controlling access to systems or protecting data during transmission, are assigned a 5-point deduction.
- Lesser but still important requirements, like limiting access to specific types of media or devices, are assigned a 3-point deduction.
- Basic or supplementary requirements, such as ensuring passwords meet complexity standards, are assigned a 1-point deduction.
- Partial Implementation | In certain cases, partial implementation of a requirement may result in a reduced deduction:
- For example, if multi-factor authentication (MFA) is only implemented for remote or privileged users, 3 points are deducted instead of 5.
- If encryption is used but not validated according to Federal Information Processing Standards (FIPS), 3 points are deducted instead of 5.
- Negative Scores | If many requirements are not met, the contractor’s score can fall below zero. A negative score highlights significant gaps in compliance and increases the contractor’s risk profile.
- System Security Plan (SSP) and Plans of Action | Contractors must have a documented System Security Plan (SSP) that outlines:
- System boundaries.
- How security requirements are implemented.
- Connections with other systems.
- Any unimplemented requirements and associated risks.
- If a contractor does not have an SSP, the assessment cannot be completed, and the contractor will be deemed non-compliant with DFARS clause 252.204-7012
- For any unmet requirements, contractors must develop Plans of Action and Milestones (POA&Ms) that detail how and when the requirements will be implemented.
- Temporary Deficiencies and Exceptions
- Temporary Deficiencies: If a contractor is actively working to fix a problem and has documented it in their action plan, it may still be considered compliant temporarily. For example, if a security update caused a temporary issue with a previously implemented requirement, the deficiency will not lead to a deduction if it is being addressed promptly.
- Enduring Exception: If a requirement cannot be implemented due to unique circumstances (e.g., specialized equipment limitations), it must be documented in the SSP and mitigated where possible. These exceptions are still considered compliant if properly managed.
- Special Cases and Adjustments
- If a contractor does not use specific features, such as remote access or mobile devices, related requirements may be marked as “not applicable” without penalty. However, policies must be in place to ensure these features are not enabled inadvertently.
- Some requirements allow for flexibility based on alternative measures approved by the DoD. For instance, if encryption is not feasible, an approved alternative must still provide adequate protection for sensitive data.
- Documentation and Review
- The results of the assessment, including the final score, are documented. Contractors can review the findings and provide additional information to address any concerns. If contractors disagree with the results, they have 14 business days to respond.
Documenting NIST SP 800-171 DoD Assessment Results
- Summary scores for assessments will be recorded in the Supplier Performance Risk System (SPRS):
- Basic Assessment (self-assessments completed by contractors)
- Medium and High Assessments (conducted by the DoD).
-
- This system gives DoD teams access to contractors’ compliance results for strategic assessments.
- SPRS is governed by DoD Instruction (DoDI) 5000.79, which focuses on sharing and using supplier and product performance information. It allows the DoD to monitor and assess contractor performance and risk management practices.
- SPRS is the main platform for accessing supplier information. DoD acquisition teams use it to evaluate contractor performance and manage risks for contracts.
- Access to Assessment Results:
- Results in SPRS are visible to authorized DoD personnel. They are protected according to DoD Instruction 5000.79.
- Contractors can view their own assessment results in SPRS using the SPRS Software User’s Guide for Awardees/Contractors. This guide provides instructions on accessing results and is available online.
- Contractors Posting Results:
- Contractors can upload the results of their Basic Assessments into SPRS using the Procurement Integrated Enterprise Environment (PIEE) system.
- Details Posted by the DoD for Medium/High Assessments:
- The specific NIST SP 800-171 standard evaluated (e.g., NIST SP 800-171 Rev 1).
- The organization conducting the assessment (e.g., DCMA or another organization identified by a unique code).
- Each system security plan assessed, linked to the contractor’s unique codes ( CAGE codes). If multiple plans or codes exist, they must all be mapped to their corresponding security plans. A brief description of each plan may also be included.
- The date and type of assessment performed (Basic, Medium, or High).
- A summary score (e.g., 105/110), though individual requirement scores will not be included.
- The expected date for achieving a perfect score of 110, based on the contractor’s plan to address any gaps.
- Policy and Procedures Update:
- DoD policies will be updated to instruct procurement officials and contractors to use SPRS to check for completed strategic assessments instead of conducting contract – specific assessments repeatedly.
- Reliance on SPRS Results:
- DoD Components are encouraged to use that assessment results in SPRS instead of adding duplicate assessment requirements for individual contracts.
- Additional Documentation for High Assessments:
- High-level assessments may generate additional documentation beyond the standard information listed above. This material will be marked as For Official Use Only (FOUO) and restricted to internal DoD use.
- The DoD will protect this information from unauthorized access or release, including shielding it under legal exemptions such as the Freedom of Information Act (e.g., Exemption 4, which safeguards trade secrets and confidential business information).
Glossary of Terms
- Enduring exception. Remediation is not feasible; no plan of action required; must be documented within a system security plan.
- Temporary deficiency. Remediation of deficiency is feasible; known fix is in process; requires a plan of action. For the purposes of a DoD NIST SP 800-171 DoD Assessment, a ‘temporary deficiency’ is not based on an ‘in progress’ initial implementation of the requirement. A temporary deficiency arises after implementation. A Temporary deficiency may also apply during the initial implementation of a NIST SP 800-171 requirement if, during roll-out, specific issues with certain equipment is discovered that has to be separately addressed.
Annex A – NIST SP 800-171 DoD Assessment Scoring Template
- The following template illustrates the scoring methodology described in Section 5. If all requirements are met, a score of 110 is awarded. For each requirement not met, the associated value is subtracted from 110. Consistency results from the fact that the assessments are based on what is not yet implemented, or document that all requirements have been met.
- It is important to note an assessment is about the extent to which the company has implemented the requirements. It is not a value judgement about the specific approach to implementing – in other words, all solutions that meet the requirements are acceptable. This is not an assessment of one solution compared to another.
- Scoring for Basic, Medium, and High NIST SP 800-171 DoD Assessments is the same.
- While NIST does not prioritize requirements in terms of impact, certain requirements do have more impact than others. In this scoring methodology security requirements are weighted based on their effect on the information system and DoD CUI created on or transiting that system.
NIST SP 800-171 DoD Assessment Scoring Template
Security Requirement | Value | Comment | ||
3.1.1 | Limit system access to authorized users, processes acting on behalf of authorized users, and devices (including other systems). | 5 | ||
3.1.2 | Limit system access to the types of transactions and functions that authorized users are permitted to execute. | 5 | ||
3.1.3 | Control the flow of CUI in accordance with approved authorizations. | 1 | ||
3.1.4 | Separate the duties of individuals to reduce the risk of malevolent activity without collusion. | 1 | ||
3.1.5 | Employ the principle of least privilege, including for specific security functions and privileged accounts. | 3 | ||
3.1.6 | Use non-privileged accounts or roles when accessing non-security functions. | 1 | ||
3.1.7 | Prevent non-privileged users from executing privileged functions and capture the execution of such functions in audit logs. | 1 | ||
3.1.8 | Limit unsuccessful logon attempts. | 1 | ||
3.1.9 | Provide privacy and security notices consistent with applicable CUI rules. | |||
3.1.10 | Use session lock with pattern-hiding displays to prevent access and viewing of data after a period of inactivity. | 1 | ||
3.1.11 | Terminate (automatically) a user session after a defined condition. | 1 | ||
3.1.12 | Monitor and control remote access sessions. | 5 | Do not subtract points if remote access not permitted. | |
3.1.13 | Employ cryptographic mechanisms to protect the confidentiality of remote access sessions. | 5 | Do not subtract points if remote access not permitted. | |
3.1.14 | Route remote access via managed access control points | 1 | ||
3.1.15 | Authorize remote execution of privileged commands and remote access to security-relevant information. | 1 | ||
3.1.16 | Authorize wireless access prior to allowing such connections. | 5 | Do not subtract points if wireless access not permitted | |
3.1.17 | Protect wireless access using authentication and encryption. | 5 | Do not subtract points if wireless access not permitted | |
3.1.18 | Control connection of mobile devices. | 5 | Do not subtract points if connection of mobile devices is not permitted | |
3.1.19 | Encrypt CUI on mobile devices and mobile computing platforms | 3 | Exposure limited to CUI on mobile platform | |
3.1.20 | Verify and control/limit connections to and use of external systems. | 1 | ||
3.1.21 | Limit use of portable storage devices on external systems | 1 | ||
3.1.22 | Control CUI posted or processed on publicly accessible systems. | 1 | ||
3.2.1 | Ensure that managers, systems administrators, and users of organizational systems are made aware of the security risks associated with their activities and of the applicable policies, standards, and procedures related to the security of those systems. | 5 | ||
3.2.2 | Ensure that personnel are trained to carry out their assigned information security-related duties and responsibilities. | 5 | ||
3.2.3 | Provide security awareness training on recognizing and reporting potential indicators of insider threat. | 1 | ||
3.3.1 | Create and retain system audit logs and records to the extent needed to enable the monitoring, analysis, investigation, and reporting of unlawful or unauthorized system activity. | 5 | ||
3.3.2 | Ensure that the actions of individual system users can be uniquely traced to those users so they can be held accountable for their actions. | 3 | ||
3.3.3 | Review and update logged events. | 1 | ||
3.3.4 | Alert in the event of an audit logging process failure. | 1 | ||
3.3.5 | Correlate audit record review, analysis, and reporting processes for investigation and response to indications of unlawful, unauthorized, suspicious, or unusual activity. | 5 | ||
3.3.6 | Provide audit record reduction and report generation to support on-demand analysis and reporting. | 1 | ||
3.3.7 | Provide a system capability that compares and synchronizes internal system clocks with an authoritative source to generate time stamps for audit records | 1 | ||
3.3.8 | Protect audit information and audit logging tools from unauthorized access, modification, and deletion. | 1 | ||
3.3.9 | Limit management of audit logging functionality to a subset of privileged users. | 1 | ||
3.4.1 | Establish and maintain baseline configurations and inventories of organizational systems (including hardware, software, firmware, and documentation) throughout the respective system development life cycles. | 5 | ||
3.4.2 | Establish and enforce security configuration settings for information technology products employed in organizational systems. | 5 | ||
3.4.3 | Track, review, approve or disapprove, and log changes to organizational systems. | 1 | ||
3.4.4 | Analyze the security impact of changes prior to implementation. | 1 | ||
3.4.5 | Define, document, approve, and enforce physical and logical access restrictions associated with changes to organizational systems. | 5 | ||
3.4.6 | Employ the principle of least functionality by configuring organizational systems to provide only essential capabilities. | 5 | ||
3.4.7 | Restrict, disable, or prevent the use of nonessential programs, functions, ports, protocols, and services. | 5 | ||
3.4.8 | Apply deny-by-exception (blacklisting) policy to prevent the use of unauthorized software or deny-all, permit-by-exception (whitelisting) policy to allow the execution of authorized software. | 5 | ||
3.4.9 | Control and monitor user-installed software. | 1 | ||
3.5.1 | Identify system users, processes acting on behalf of users, and devices. | 5 | ||
3.5.2 | Authenticate (or verify) the identities of users, processes, or devices, as a prerequisite to allowing access to organizational systems. | 5 | ||
3.5.3 | Use multifactor authentication (MFA) for local and network access to privileged accounts and for network access to nonprivileged accounts. | 3 to 5 | Subtract 5 points if MFA not implemented. Subtract 3 points if implemented for remote and privileged users, but not the general user | |
3.5.4 | Employ replay-resistant authentication mechanisms for network access to privileged and non-privileged accounts. | 1 | ||
3.5.5 | Prevent reuse of identifiers for a defined period. | 1 | ||
3.5.6 | Disable identifiers after a defined period of inactivity. | 1 | ||
3.5.7 | Enforce a minimum password complexity and change of characters when new passwords are created. | 1 | ||
3.5.8 | Prohibit password reuse for a specified number of generations. | 1 | ||
3.5.9 | Allow temporary password use for system logons with an immediate change to a permanent password. | 1 | ||
3.5.10 | Store and transmit only cryptographicallyprotected passwords. | 5 | Encrypted representations of passwords include, for example, encrypted versions of passwords and one-way cryptographic hashes of passwords | |
3.5.11 | Obscure feedback of authentication information. | 1 | ||
3.6.1 | Establish an operational incident-handling capability for organizational systems that includes preparation, detection, analysis, containment, recovery, and user response activities. | 5 | ||
3.6.2 | Track, document, and report incidents to designated officials and/or authorities both internal and external to the organization. | 5 | ||
3.6.3 | Test the organizational incident response capability. | 1 | ||
3.7.1 | Perform maintenance on organizational systems. | 3 | ||
3.7.2 | Provide controls on the tools, techniques, mechanisms, and personnel used to conduct system maintenance. | 5 | ||
3.7.3 | Ensure equipment removed for off-site maintenance is sanitized of any CUI. | 1 | ||
3.7.4 | Check media containing diagnostic and test programs for malicious code before the media are used in organizational systems. | 3 | ||
3.7.5 | Require multifactor authentication to establish nonlocal maintenance sessions via external network connections and terminate such connections when nonlocal maintenance is complete. | 5 | ||
3.7.6 | Supervise the maintenance activities of maintenance personnel without required access authorization. | 1 | ||
3.8.1 | Protect (i.e., physically control and securely store) system media containing CUI, both paper and digital. | 3 | Exposure limited to CUI on media | |
3.8.2 | Limit access to CUI on system media to authorized users. | 3 | Exposure limited to CUI on media | |
3.8.3 | Sanitize or destroy system media containing CUI before disposal or release for reuse. | 5 | While exposure limited to CUI on media, failure to sanitize can result in continual exposure of CUI | |
3.8.4 | Mark media with necessary CUI markings and distribution limitations. | 1 | ||
3.8.5 | Control access to media containing CUI and maintain accountability for media during transport outside of controlled areas. | 1 | ||
3.8.6 | Implement cryptographic mechanisms to protect the confidentiality of CUI stored on digital media during transport unless otherwise protected by alternative physical safeguards. | 1 | ||
3.8.7 | Control the use of removable media on system components. | 5 | ||
3.8.8 | Prohibit the use of portable storage devices when such devices have no identifiable owner. | 3 | ||
3.8.9 | Protect the confidentiality of backup CUI at storage locations. | 1 | ||
3.9.1 | Screen individuals prior to authorizing access to organizational systems containing CUI. | 3 | ||
3.9.2 | Ensure that organizational systems containing CUI are protected during and after personnel actions such as terminations and transfers. | 5 | ||
3.10.1 | Limit physical access to organizational systems, equipment, and the respective operating environments to authorized individuals. | 5 | ||
3.10.2 | Protect and monitor the physical facility and support infrastructure for organizational systems. | 5 | ||
3.10.3 | Escort visitors and monitor visitor activity. | 1 | ||
3.10.4 | Maintain audit logs of physical access. | 1 | ||
3.10.5 | Control and manage physical access devices. | 1 | ||
3.10.6 | Enforce safeguarding measures for CUI at alternate work sites. | 1 | ||
3.11.1 | Periodically assess the risk to organizational operations (including mission, functions, image, or reputation), organizational assets, and individuals, resulting from the operation of organizational systems and the associated processing, storage, or transmission of CUI. | 3 | ||
3.11.2 | Scan for vulnerabilities in organizational systems and applications periodically and when new vulnerabilities affecting those systems and applications are identified. | 5 | ||
3.11.3 | Remediate vulnerabilities in accordance with risk assessments. | 1 | ||
3.12.1 | Periodically assess the security controls in organizational systems to determine if the controls are effective in their application. | 5 | ||
3.12.2 | Develop and implement plans of action designed to correct deficiencies and reduce or eliminate vulnerabilities in organizational systems. | 3 | ||
3.12.3 | Monitor security controls on an ongoing basis to ensure the continued effectiveness of the controls. | 5 | ||
3.12.4 | Develop, document, and periodically update system security plans that describe system boundaries, system environments of operation, how security requirements are implemented, and the relationships with or connections to other systems. | N/A | The absence of a system security plan would result in a finding that ‘an assessment could not be completed due to incomplete information and noncompliance with DFARS clause 252.204-7012.’ | |
3.13.1 | Monitor, control, and protect communications (i.e., information transmitted or received by organizational systems) at the external boundaries and key internal boundaries of organizational systems. | 5 | ||
3.13.2 | Employ architectural designs, software development techniques, and systems engineering principles that promote effective information security within organizational systems. | 5 | ||
3.13.3 | Separate user functionality from system management functionality. |
1 |
||
3.13.4 | Prevent unauthorized and unintended information transfer via shared system resources. | 1 | ||
3.13.5 | Implement subnetworks for publicly accessible system components that are physically or logically separated from internal networks. | 5 | ||
3.13.6 | Deny network communications traffic by default and allow network communications traffic by exception (i.e., deny all, permit by exception). | 5 | ||
3.13.7 | Prevent remote devices from simultaneously establishing non-remote connections with organizational systems and communicating via some other connection to resources in external networks (i.e., split tunneling). | 1 | ||
3.13.8 | Implement cryptographic mechanisms to prevent unauthorized disclosure of CUI during transmission unless otherwise protected by alternative physical safeguards. | 3 | ||
3.13.9 | Terminate network connections associated with communications sessions at the end of the sessions or after a defined period of inactivity. | 1 | ||
3.13.10 | Establish and manage cryptographic keys for cryptography employed in organizational systems. | 1 | ||
3.13.11 | Employ FIPS-validated cryptography when used to protect the confidentiality of CUI. | 3 to 5 | Subtract 5 points if no cryptography is employed; 3 points if mostly not FIPS validated | |
3.13.12 | Prohibit remote activation of collaborative computing devices and provide indication of devices in use to users present at the device. | 1 | ||
3.13.13 | Control and monitor the use of mobile code. | 1 | ||
3.13.14 | Control and monitor the use of Voice over Internet Protocol (VoIP) technologies. | 1 | ||
3.13.15 | Protect the authenticity of communications sessions. | 5 | ||
3.13.16 | Protect the confidentiality of CUI at rest. | 1 | ||
3.14.1 | Identify, report, and correct system flaws in a timely manner. | 5 | ||
3.14.2 | Provide protection from malicious code at designated locations within organizational systems. | 5 | ||
3.14.3 | Monitor system security alerts and advisories and take action in response. | 5 | ||
3.14.4 | Update malicious code protection mechanisms when new releases are available. | 5 | ||
3.14.5 | Perform periodic scans of organizational systems and real-time scans of files from external sources as files are downloaded, opened, or executed. | 3 | ||
3.14.6 | Monitor organizational systems, including inbound and outbound communications traffic, to detect attacks and indicators of potential attacks. | 5 | ||
3.14.7 | Identify unauthorized use of organizational systems. | 3 |