| name | PE-22_component-marking |
| description | Mark [organization-defined] indicating the impact level or classification level of the information permitted to be processed, stored, or transmitted b |
| category | configuration |
| version | 5.2.0 |
| author | cyberstrike-official |
| tags | ["nist","sp800-53","rev5","pe-22","pe"] |
| tech_stack | ["any"] |
| cwe_ids | [] |
| chains_with | ["AC-3","AC-4","AC-16","MP-3"] |
| prerequisites | [] |
| severity_boost | {"AC-3":"Chain with AC-3 for comprehensive security coverage","AC-4":"Chain with AC-4 for comprehensive security coverage","AC-16":"Chain with AC-16 for comprehensive security coverage"} |
PE-22 Component Marking
High-Level Description
Family: Physical and Environmental Protection (PE)
Framework: NIST SP 800-53 Rev 5
Hardware components that may require marking include input and output devices. Input devices include desktop and notebook computers, keyboards, tablets, and smart phones. Output devices include printers, monitors/video displays, facsimile machines, scanners, copiers, and audio devices. Permissions controlling output to the output devices are addressed in AC-3 or AC-4 . Components are marked to indicate the impact level or classification level of the system to which the devices are connected, or the impact level or classification level of the information permitted to be output. Security marking refers to the use of human-readable security attributes. Security labeling refers to the use of security attributes for internal system data structures. Security marking is generally not required for hardware components that process, store, or transmit information determined by organizations to be in the public domain or to be publicly releasable. However, organizations may require markings for hardware components that process, store, or transmit public information in order to indicate that such information is publicly releasable. Marking of system hardware components reflects applicable laws, executive orders, directives, policies, regulations, and standards.
What to Check
How to Test
Step 1: Review Documentation
Examine the System Security Plan (SSP) and related artifacts for PE-22 implementation details. Verify the organization has documented how this control is satisfied.
Step 2: Validate Implementation
# For cloud environments, use cloud-audit-mcp tools
# For on-premises, review system configurations directly
# Example: Check if account management policies exist
grep -r "account.management\|access.control" /etc/security/ 2>/dev/null
Step 3: Test Operating Effectiveness
Verify the control is actively functioning, not just documented. Check logs, configurations, and operational evidence.
Tools
| Tool | Purpose | Usage |
|---|
| Manual Review | Documentation and interview-based | N/A |
