AC-20(3): Non-organizationally Owned Systems — Restricted Use

AC-20(3) requires you to restrict when and how non-organizationally owned systems (for example, personal laptops, home desktops, unmanaged tablets, BYOD endpoints, or third-party components) may process, store, or transmit your organization’s information, using explicit, pre-defined restrictions. Operationalize it by defining approved use cases, enforcing them with technical controls, and retaining evidence that exceptions are authorized and monitored.

Key takeaways:

• Define “non-organizationally owned” and enumerate allowed scenarios, data types, and required safeguards for each.
• Enforce restrictions with endpoint, identity, and network controls; policy alone rarely satisfies assessors.
• Keep recurring evidence: inventories, configurations, exceptions, and monitoring outputs tied to the restriction rules.

The ac-20(3): non-organizationally owned systems — restricted use requirement is a practical control, not a policy exercise. Your assessor will look for one thing: proof that organizational information does not casually flow onto unmanaged or externally owned devices and components without deliberate restrictions and technical enforcement. That includes common realities like BYOD, contractor-owned laptops, vendor-managed jump boxes, and engineers accessing production systems from personal endpoints.

AC-20(3) sits in the Access Control family, but the operational work spans endpoint management, identity, network architecture, and third-party risk management. You need a crisp rule set (what is allowed, what is prohibited, and under what conditions), then an implementation that makes the “bad paths” hard or impossible. Where business needs require exceptions, you need documented approval, compensating controls, and monitoring.

This page translates the requirement into an operator-ready procedure: scope decisions, restriction patterns, control mappings, evidence to retain, audit questions you will get, and an execution plan you can run as a CCO/GRC lead with IT and security.

Regulatory text

“Restrict the use of non-organizationally owned systems or system components to process, store, or transmit organizational information using {{ insert: param, ac-20.03_odp }}.” ¹

What the operator must do: define the restriction criteria (the “organization-defined parameters”), then implement controls so only approved non-organizational systems/components can handle organizational information, under approved conditions, with enforcement and evidence. NIST frames this as a restriction requirement, not a blanket prohibition; you choose the restriction model and must show it works ².

Plain-English interpretation

Non-organizationally owned systems are devices or components you do not own and do not fully manage. AC-20(3) requires you to decide, in writing and in configuration, whether those systems can touch your data at all. If they can, you must restrict:

• What information they can process/store/transmit (by classification and system boundary).
• Which users can use them (by role, employment type, third party status).
• Which activities are allowed (view-only, no download, admin prohibited, etc.).
• Which security conditions must be true (MFA, device posture, encryption, logging, DLP, session controls).
• How exceptions work (who approves, for how long, and what monitoring applies).

A simple “BYOD allowed” statement is not a restriction. A restriction is an enforceable rule set plus proof of enforcement.

Who it applies to

Entity scope

• Federal information systems and contractor systems handling federal data commonly inherit this requirement through NIST-based programs ².

Operational scope (where you will feel it)

• BYOD and remote work: personal laptops/phones accessing email, SaaS, VDI, or internal apps.
• Contractors and temps: using contractor-owned endpoints or tools.
• Third-party operations: vendor-managed support systems, remote admin tools, and hosted components.
• Component-level risk: “system components” includes things like externally owned gateways, diagnostic devices, or shared infrastructure elements you do not control.

Systems in scope Any system that processes, stores, or transmits organizational information. This becomes urgent for systems with sensitive regulated data, elevated privileges, or production access paths.

What you actually need to do (step-by-step)

1) Define “non-organizationally owned” in your environment

Write a scoped definition that your IT and security teams can implement. Common buckets:

• Personally owned devices (employee BYOD)
• Contractor/consultant devices
• Third-party administered devices or components (including managed services tooling)
• “Shadow IT” endpoints that are not enrolled in your management stack

Output: AC-20(3) restriction standard (one-pager is fine if precise).

2) Create an allowlist of approved use cases (and explicitly prohibit everything else)

Build a table that expresses restrictions as enforceable rules.

Scenario	Allowed data/actions	Required controls	Prohibited
Personal phone accessing email	View email; no local export of attachments unless encrypted container	MFA; MDM/MAM; device encryption; remote wipe; conditional access	Access to admin consoles; downloading sensitive exports
Contractor laptop for dev work	Access to dev VDI; no direct access to prod	MFA; VDI; session recording; no split tunneling; least privilege	Local cloning of repos with regulated data; direct prod SSH
Third-party remote support	Time-boxed privileged access via PAM	MFA; PAM approval workflow; just-in-time; logging to SIEM	Persistent accounts; unmanaged remote desktop tools

This table becomes your “organization-defined parameters” in operational form ¹.

3) Align restrictions to data classification and system boundaries

Tie each approved scenario to:

• Data classification policy (what data can be handled)
• System boundary (which apps and networks are reachable)
• Identity boundary (which identities can authenticate)

If you do not have formal data classification, you can still implement “restricted categories” (customer data, federal data, HR data, secrets/keys) and treat them as higher-risk.

4) Implement technical enforcement (policy alone is weak evidence)

Pick the minimum set of enforcement points that block unapproved flows:

Identity and access

• Conditional access rules: block sign-in from unknown/unmanaged devices for sensitive apps.
• MFA and phishing-resistant methods for privileged access.
• Separate admin identities; prohibit admin actions from non-managed devices.

Endpoint controls

• MDM/MAM for mobile BYOD where permitted.
• Endpoint detection/response and disk encryption for any non-org device that is approved to handle data.
• “No local storage” patterns (VDI, browser isolation, streaming apps) for higher-risk access.

Network and session controls

• VPN posture checks or ZTNA with device trust signals.
• PAM and jump hosts for privileged sessions; session recording for third-party support.
• Segmentation so non-managed endpoints cannot reach production subnets.

Data controls

• DLP for email/web/SaaS where applicable.
• Restrictions on download, copy/paste, and printing for high-risk SaaS data where supported.

Your implementation goal: if a user attempts the prohibited scenario, the system blocks it or forces the user onto an approved path.

5) Build an exception process that does not become the default

Exceptions are normal. Untracked exceptions are control failure.

Define:

• Who can approve (system owner + security, or equivalent)
• What must be documented (business need, data type, duration, compensating controls)
• What monitoring applies (log review, session recording, DLP alerts)
• When it expires and how it is removed

Keep exceptions time-bound and review them on a recurring cadence you can sustain.

6) Monitor and test

Add at least one detective mechanism per restriction:

• Reports of blocked sign-ins from unmanaged devices
• PAM logs for third-party privileged sessions
• DLP alert summaries
• Asset inventory deltas (new unmanaged endpoints attempting access)

Then test: attempt access from a non-compliant device and capture the block as evidence.

7) Map ownership and recurring evidence (make it auditable)

Assign a control owner (often IAM, Endpoint, or GRC depending on your model) and define evidence frequency. Daydream can help here by mapping AC-20(3) to a named owner, a written procedure, and a recurring evidence checklist so you do not rebuild the story each audit.

Required evidence and artifacts to retain

Keep evidence that shows design and operation:

Design artifacts

• AC-20(3) restriction standard (definitions + allowed/prohibited matrix)
• Data classification crosswalk to restrictions (even if lightweight)
• Exception procedure and approval authority list

Operational artifacts

• Conditional access policy exports (screenshots or JSON) showing unmanaged-device restrictions
• MDM/MAM enrollment requirements and compliance policy settings
• PAM configuration evidence for third-party access (approval workflow, JIT, session logging)
• Sample tickets for approved exceptions with compensating controls
• Logs/reports demonstrating enforcement (blocked attempts, access logs, session recordings metadata)
• Inventory report showing device ownership/management status where relevant

Auditors commonly accept screenshots and exports if they clearly show scope, rule conditions, and timestamps.

Common exam/audit questions and hangups

Expect these questions:

1. “Define non-organizationally owned in your policy. Does it include contractor laptops and vendor tooling?”
   Have a definition that covers both devices and components.

2. “Show me how you technically prevent access from unmanaged devices.”
   Be ready with conditional access rules, ZTNA posture policies, or VDI-only access patterns.

3. “Where is your list of approved use cases and data types?”
   Produce the restriction matrix. If it is missing, the assessor will treat your implementation as ad hoc.

4. “How do you govern exceptions?”
   Show approval tickets, expiry, and evidence of monitoring.

5. “How do you know it’s working?”
   Show blocked access attempts or periodic tests.

Frequent implementation mistakes and how to avoid them

• Mistake: writing a BYOD policy with no enforcement.
  Fix: connect the restriction rules to conditional access, MDM/MAM, and PAM gates.

• Mistake: allowing “temporary” exceptions with no end date.
  Fix: enforce expiry dates in the ticketing workflow and require re-approval.

• Mistake: scoping only to phones and forgetting contractor laptops.
  Fix: include “ownership and management status” as the scoping attribute, not device type.

• Mistake: relying on user attestations (“I promise I encrypted my laptop”).
  Fix: require device posture signals or force access through VDI/browser isolation.

• Mistake: third-party support uses generic remote desktop tools outside your logging.
  Fix: route third-party privileged access through PAM or an approved, logged access path.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement. Practically, AC-20(3) reduces the most common operational failure modes: data sprawl onto unmanaged endpoints, inability to investigate incidents due to missing logs, and uncontrolled third-party access paths. In assessments aligned to NIST SP 800-53, weak evidence for restriction enforcement often shows up as a control design gap (“policy exists, but restrictions are not implemented”) or an operating effectiveness gap (“controls exist, but exceptions and monitoring are unmanaged”) ².

Practical execution plan (30/60/90-day)

A time-boxed plan helps, but the dates are less important than sequencing and evidence readiness.

First 30 days (Immediate)

• Name the AC-20(3) control owner and approvers.
• Publish a draft restriction matrix covering the top access paths: email/SaaS, VDI, VPN/ZTNA, privileged access, third-party support.
• Identify the top “non-org endpoints” population: BYOD users, contractors, and third-party support scenarios.
• Turn on at least one hard block for high-risk systems (for example, block admin console access from unmanaged devices).

Days 31–60 (Near-term)

• Implement posture-based access for sensitive apps (managed device required, or VDI-only).
• Stand up the exception workflow with expiry and compensating controls.
• Route third-party privileged access through a controlled path (PAM or equivalent) with logging.
• Start collecting recurring evidence artifacts in a single audit-ready folder (or in Daydream as a control evidence record).

Days 61–90 (Operationalize)

• Expand restrictions to additional systems and data types.
• Add monitoring reports and a periodic test routine (attempt prohibited access, capture the block).
• Review exception population and remove stale approvals.
• Run an internal mini-assessment: can you answer the five audit questions above in one sitting, with artifacts?

Frequently Asked Questions

Does AC-20(3) mean BYOD is prohibited?

No. It requires restricted use. You can allow BYOD for specific activities if you define the conditions and enforce them technically ¹.

Are contractor-owned laptops considered “non-organizationally owned”?

Usually yes, unless your organization owns and fully manages them. Treat contractor endpoints as non-org by default and require managed-device posture or VDI for sensitive access.

What counts as a “system component” that is non-organizationally owned?

Components include externally owned or controlled elements that can process, store, or transmit your information, such as third-party managed access tooling or externally administered infrastructure elements ².

What evidence is strongest for auditors?

Enforcement evidence beats narrative: conditional access rules, MDM compliance policies, PAM logs, blocked access reports, and approved exception tickets with expiries are typically persuasive.

How do we handle executives who insist on using personal devices?

Put executives into an approved use case with stronger controls: managed container/MAM for email, block downloads for sensitive apps, and prohibit privileged actions from non-managed devices.

If we already have AC-20, do we still need AC-20(3)?

AC-20 is broader. AC-20(3) adds specificity about restricting non-organizationally owned systems or components. Assessors will expect a distinct restriction model and evidence tied to that scope ¹.

Footnotes

1. NIST SP 800-53 Rev. 5 OSCAL JSON

2. NIST SP 800-53 Rev. 5