| name | AC-20(3)_non-organizationally-owned-systems-restricted-use |
| description | Restrict the use of non-organizationally owned systems or system components to process, store, or transmit organizational information using [organizat |
| category | authorization |
| version | 5.2.0 |
| author | cyberstrike-official |
| tags | ["nist","sp800-53","rev5","ac-20-3","ac","enhancement"] |
| tech_stack | ["aws","azure","gcp","linux","windows"] |
| cwe_ids | ["CWE-284"] |
| chains_with | [] |
| prerequisites | ["AC-20"] |
| severity_boost | {} |
AC-20(3) Non-organizationally Owned Systems — Restricted Use
Enhancement of: AC-20
High-Level Description
Family: Access Control (AC)
Framework: NIST SP 800-53 Rev 5
Non-organizationally owned systems or system components include systems or system components owned by other organizations as well as personally owned devices. There are potential risks to using non-organizationally owned systems or components. In some cases, the risk is sufficiently high as to prohibit such use (see AC-20 b. ). In other cases, the use of such systems or system components may be allowed but restricted in some way. Restrictions include requiring the implementation of approved controls prior to authorizing the connection of non-organizationally owned systems and components; limiting access to types of information, services, or applications; using virtualization techniques to limit processing and storage activities to servers or system components provisioned by the organization; and agreeing to the terms and conditions for usage. Organizations consult with the Office of the General Counsel regarding legal issues associated with using personally owned devices, including requirements for conducting forensic analyses during investigations after an incident.
What to Check
How to Test
Step 1: Review Documentation
Examine the System Security Plan (SSP) and related artifacts for AC-20(3) 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