AC-21(1): Automated Decision Support

AC-21(1) requires you to use an automated decision support capability to enforce information-sharing decisions so authorized users can only share information with partners who are authorized to receive it, and only under the information’s sharing restrictions. To operationalize it, implement policy-driven sharing controls (labels, rules, and enforcement points) plus logging and reviewable evidence that the automation, not user discretion alone, governs sharing. ¹

Key takeaways:

• Build machine-enforceable sharing rules that evaluate both the recipient’s authorization and the data’s sharing restrictions. ¹
• Put enforcement at the sharing “choke points” (email, file sharing, collaboration, APIs, cross-domain transfers), not only in policy docs.
• Retain evidence that shows rules, authorization sources, enforcement decisions, and exceptions were controlled and reviewable.

The ac-21(1): automated decision support requirement is about making information-sharing controls enforceable by systems, not just by training and good intentions. Many programs already have access controls for “who can read what,” but AC-21(1) targets a different failure mode: an authorized user who can access data may still share it incorrectly to an unauthorized partner, or share it without honoring restrictions attached to the data.

Operationally, this requirement pushes you toward consistent tagging (or other metadata), an authoritative source of “sharing partner” authorizations, and an automated decision engine that can approve, block, or require additional approvals before information leaves its boundary. Your assessors will look for proof that the automation is real, centrally managed, and consistently applied across common sharing channels.

This page gives requirement-level implementation guidance you can hand to control owners: what systems need to exist, where to put enforcement, what evidence to retain, what auditors ask, and how to avoid common traps.

Regulatory text

“Employ {{ insert: param, ac-21.01_odp }} to enforce information-sharing decisions by authorized users based on access authorizations of sharing partners and access restrictions on information to be shared.” ¹

Operator interpretation (what you must do)

You must implement an automated mechanism (the “automated decision support” capability) that evaluates information-sharing decisions using two inputs:

1. Access authorizations of sharing partners
   The system needs a reliable way to know whether the intended recipient (person, organization, system, tenant, domain, third party) is authorized to receive the category of information being shared.

2. Access restrictions on the information to be shared
   The system needs a reliable way to know the information’s restrictions (classification, dissemination limits, contractual handling terms, export controls, CUI categories, internal confidentiality tiers, “no external sharing,” etc.).

Then the system must enforce the decision. “Enforce” means the system blocks, gates, or conditions sharing, rather than leaving the outcome to user judgment alone. ¹

Plain-English requirement (for busy operators)

If a user tries to share data, your environment must automatically check: “Is this recipient authorized for this kind of data?” and “Is this data allowed to be shared under its restrictions?” Then it must stop or control the share when the answer is no.

Who it applies to

Entity scope

• Federal information systems and contractor systems handling federal data implementing NIST SP 800-53 controls. ¹

Operational context (where AC-21(1) shows up)

This control matters anywhere information can move across boundaries, including:

• Email and outbound attachments
• File sharing (managed file transfer, SFTP, shared drives, cloud storage links)
• Collaboration tools (chat, channels, wikis)
• APIs and system-to-system exchanges
• Cross-domain transfers or data exports from governed repositories
• Third party portals and support ticket uploads

If you have third parties (vendors, partners, contractors, customers) receiving information, you need the automation to understand partner authorization and apply data restrictions consistently.

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

1) Define “sharing partner authorization” as a machine-checkable attribute

Goal: a system can answer “is recipient X authorized for data type Y?”

Concrete actions:

• Create a sharing partner register: internal domains/tenants, approved third parties, external agencies, and system accounts.
• For each partner, record authorization attributes: allowed data categories, contract constraints, security requirements, and any scope limits.
• Identify the system of record (often IAM, GRC, vendor management system, or a dedicated registry) and make it queryable.

Practical note: if authorization lives only in PDFs (contracts, MOUs), you have policy but not decision support. Convert key constraints into structured fields.

2) Standardize information “access restrictions” in a usable schema

Goal: a system can answer “what restrictions apply to this information?”

Concrete actions:

• Define a data classification and dissemination schema with values your tooling can enforce (examples: Public / Internal / Confidential / Restricted; plus tags like “CUI,” “Export-controlled,” “No external sharing”).
• Decide how restrictions attach to information:
  • Persistent labels in documents and files
  • Metadata in repositories
  • Database row/column tags for exports
  • API response labeling (when feasible)

Make one owner accountable for the schema (typically Security Governance + Data Governance).

3) Choose the enforcement points (“choke points”) and implement rules

Goal: sharing attempts are evaluated and controlled automatically.

Concrete actions:

• Inventory outbound channels and select where to enforce first:
  • Email gateway / DLP
  • Cloud access security broker (CASB) controls for SaaS sharing
  • File transfer gateways
  • API gateways and integration platforms
• Implement policy rules that combine partner authorization + data restriction. Example rule statements:
  • “Restricted data cannot be shared externally.”
  • “CUI may only be shared with partners marked ‘CUI-authorized’.”
  • “Confidential data shared externally requires encryption and an approved partner domain.”

AC-21(1) expects the automated mechanism to enforce the decision outcome, not just display a warning. ¹

4) Build the “decision support” workflow for ambiguous cases

Not all sharing can be decided purely by rules. You still need automation to control the workflow.

Concrete actions:

• Define decision outcomes:
  • Allow
  • Block
  • Allow with conditions (encryption, watermarking, expiration, view-only)
  • Route for approval (data owner, security, legal, program office)
• Configure a standard exception/override path with:
  • Required justification
  • Time-bound approval
  • Logging and post-review

5) Log and review decisions, overrides, and policy drift

Goal: you can prove the automation operated and detect misuse.

Concrete actions:

• Centralize logs for:
  • Sharing attempt details (user, data label, recipient/partner, channel)
  • Rule evaluated and decision outcome (allow/block/approve)
  • Overrides and approver identity
• Implement recurring reviews:
  • High-risk share attempts
  • Repeated blocked attempts (possible insider risk or training gaps)
  • Stale partner authorizations and expired contracts

6) Map ownership and evidence cadence (make it assessable)

AC-21(1) commonly fails during audits because no one “owns” it across tools and data governance. Assign a control owner, document procedures, and define recurring evidence artifacts. ¹

If you use Daydream for control operations, map AC-21(1) to a single accountable owner, link the implementation procedure, and schedule recurring evidence collection so you can answer assessor requests fast.

Required evidence and artifacts to retain

Keep artifacts that show design and operating effectiveness:

Policy and design

• Information sharing policy that references partner authorization and data restrictions
• Data classification / dissemination standard and label definitions
• Sharing partner register (or exported report) with authorization attributes
• Data flow diagrams highlighting sharing channels and enforcement points
• Rule library or configuration export from enforcement tools (DLP/CASB/email gateway/API gateway)

Operating evidence

• Sample decision logs showing:
  • labeled data + recipient authorization check
  • enforced outcomes (blocked/approved/conditioned)
• Exception tickets/approvals with justification and expiration
• Periodic review records (meeting notes, sign-offs, dashboards) for blocked shares, overrides, partner authorization updates
• Training or user guidance is supportive, but auditors will still expect automated enforcement aligned to the control text. ¹

Common exam/audit questions and hangups

Expect these lines of questioning:

• “Show me how the system determines a partner is authorized for this data type.”
• “Where are the information-sharing restrictions stored, and how do they follow the data?”
• “Demonstrate enforcement: what happens if an authorized user tries to share Restricted data to an unauthorized third party?”
• “Which channels are covered? What channels are out of scope, and why?”
• “Who can override a block, and how do you review overrides?”
• “How do you ensure partner authorization data stays current?”

Hangup assessors often fixate on: warnings vs enforcement. If your mechanism only pops up a banner, you may not satisfy “enforce information-sharing decisions.” ¹

Frequent implementation mistakes (and how to avoid them)

1. Treating this as a policy-only control
   Fix: implement technical enforcement at real sharing points and retain logs.

2. No authoritative partner authorization source
   Fix: build a register with structured authorization attributes; tie updates to third-party onboarding/offboarding.

3. Labels exist, but are inconsistent or optional
   Fix: require labeling at creation or before external sharing; add defaults and validation in key repositories.

4. Exceptions become the normal path
   Fix: time-box exceptions, require justification, and review exceptions for pattern-based remediation.

5. Coverage gaps (shadow channels)
   Fix: document out-of-scope channels, add compensating controls, and prioritize expansion based on where data actually exits.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not cite specific actions.

Risk-wise, AC-21(1) is a common control gap behind data leakage events: a legitimate user shares information to an unauthorized recipient or violates handling limits. The operational impact includes incident response workload, contractual breach with third parties, loss of federal data protections, and audit findings that force corrective action plans.

Practical 30/60/90-day execution plan

Use phases so you can start without guessing dates.

First 30 days (Immediate)

• Assign a control owner and name technical owners for each enforcement point.
• Inventory sharing channels and pick initial enforcement scope (usually email + primary file sharing).
• Define the minimum viable restriction schema (a small set of labels you can enforce consistently).
• Stand up (or extract) a partner authorization register with a few critical attributes.

Days 31–60 (Near-term build)

• Configure automated rules in the selected enforcement points that evaluate restrictions + partner authorization.
• Implement an exception workflow with approvals, expirations, and required fields.
• Start centralized logging for decisions and overrides.
• Run tabletop tests: attempt shares that should be blocked and capture evidence.

Days 61–90 (Operationalize)

• Expand coverage to additional channels (collaboration, MFT, priority APIs) based on actual data egress.
• Begin recurring reviews: blocked attempts, overrides, partner authorization drift.
• Package your assessor-ready evidence set: rules, logs, partner register extracts, and review records.
• In Daydream, connect the procedure, owners, and evidence schedule so evidence stays current between audits.

Frequently Asked Questions

Do we need to block every unauthorized share, or are warnings enough for AC-21(1)?

The text says “enforce information-sharing decisions,” which implies the system must control the outcome, not only advise the user. Warnings can support behavior change, but keep enforcement (block, conditional allow, or approval gating) as the default for restricted data. ¹

What counts as a “sharing partner”?

Treat any external recipient as a sharing partner: third parties, other agencies, customer tenants, external domains, and external system accounts. If data crosses a trust boundary, you need a way to evaluate that recipient’s authorization.

We don’t have consistent data labels. Can we still meet AC-21(1)?

You can start with a limited set of restrictions applied at key repositories or before external sharing, then expand. Document the schema, make it enforceable, and show that the decision support checks restrictions that are reliably attached to the data. ¹

How do we prove “automated decision support” to an auditor?

Provide rule/config exports from the enforcement tools and sample logs showing the rule evaluation and enforced outcome. Pair that with the partner authorization source and evidence of exception handling and periodic review.

What if a partner is authorized, but only for a specific project or contract?

Encode that constraint as structured authorization attributes (project, contract, program) and require the automated check to include those attributes when deciding. Where automation cannot check the nuance, gate sharing through an approval workflow tied to that contract scope.

Who should own AC-21(1) operationally?

Assign a single accountable owner in Security/GRC, then delegate implementation to messaging, endpoint, cloud, and data platform owners. Central ownership matters because the requirement spans multiple sharing channels and depends on both partner authorization and data restriction governance. ¹

Footnotes

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