AC-21: Information Sharing

AC-21 requires you to make information sharing safe by giving authorized users a reliable way to confirm that a sharing partner’s access authorizations match the data’s access and use restrictions before data is shared. Operationalize it by defining shareable data types, tagging restrictions, mapping partner entitlements, and enforcing a pre-share authorization check with retained evidence. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Key takeaways:

• AC-21 is a “pre-share authorization compatibility check” between data restrictions and partner permissions. (NIST SP 800-53 Rev. 5 OSCAL JSON)
• You need a repeatable workflow (people + tooling) that blocks or routes exceptions when restrictions and partner authorizations do not match.
• Evidence is the product: auditors will expect records of restriction labeling, partner authorization baselines, and completed checks.

The ac-21: information sharing requirement shows up when your system exchanges data with a third party, another agency/business unit, a joint program, or an integrated platform. The control is not asking you to “share more securely” in the abstract. It asks for a specific operator capability: authorized users must be able to determine whether a sharing partner’s access authorizations match the information’s access and use restrictions. (NIST SP 800-53 Rev. 5 OSCAL JSON)

For a Compliance Officer, CCO, or GRC lead, the fastest path to implementation is to translate AC-21 into a gating decision that happens before data moves: (1) classify the information and record its sharing restrictions, (2) define the sharing partner and record what they are authorized to access/use, and (3) require a check that those two line up, with an outcome you can prove later. You do not need perfect tooling on day one, but you do need a consistent method, a control owner, and retained artifacts that survive staff changes and audits.

Regulatory text

Control requirement (excerpt): “Enable authorized users to determine whether access authorizations assigned to a sharing partner match the information’s access and use restrictions for [organization-defined parameter]; and” (NIST SP 800-53 Rev. 5 OSCAL JSON)

Operator meaning: before you share information with a partner, an authorized user must be able to check, using your defined method, that the partner’s access approvals/entitlements allow the exact access and allowed uses the information permits. If the match is unknown, you treat it as “no match” until validated.

What “organization-defined parameter” means in practice: you must define the scope that triggers AC-21 checks (for example: specific data types, systems, interconnections, sharing mechanisms, or sensitivity labels). AC-21 does not pick the scope for you; your governance does. (NIST SP 800-53 Rev. 5)

Plain-English interpretation

AC-21 is a compatibility test:

• Side A: the data’s restrictions (who can access it, what they can do with it, and any onward-sharing limits).
• Side B: the sharing partner’s authorizations (contractual terms, account entitlements, role approvals, connection-level permissions).
• Decision: share only when A and B match; otherwise block, reduce scope, or obtain an explicit exception.

This is an “information sharing” control, but it lives operationally in identity/access management, data governance, third-party risk management, and integration change management.

Who it applies to

Entity scope: federal information systems and contractor systems handling federal data. (NIST SP 800-53 Rev. 5)

Operational scope (where AC-21 is triggered):

• System-to-system data exchanges (APIs, ETL feeds, EDI, SFTP drops)
• Cross-tenant sharing in SaaS (shared workspaces, external collaboration)
• Direct user sharing to external recipients (emailing exports, shared links, file shares)
• Contractor-operated environments where the contractor shares data with another third party or supporting provider
• Interconnections and data-sharing agreements (formal or informal)

If your organization has “partners” that receive data but are not treated as third parties in your inventory, AC-21 still applies. The control is about the act of sharing and the partner’s authorization state.

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

1) Assign ownership and define AC-21 scope

• Name a control owner (commonly IAM, data governance, or security engineering) and a process owner (commonly GRC or TPRM).
• Define the AC-21 trigger conditions: which systems, datasets, and sharing channels require the check.
• Define what counts as a “sharing partner” (third party org, external tenant, affiliate, another agency, or internal enclave).
  Recommended: document this mapping to owners, procedures, and recurring evidence so the control is assessable. (NIST SP 800-53 Rev. 5 OSCAL JSON)

2) Define “access and use restrictions” in a format people can apply

You need a restriction model that can be checked consistently. Use a simple structure first:

• Access restriction: allowed roles/groups/clearances; allowed locations/devices if relevant
• Use restriction: allowed purposes (view-only vs download; analytics vs operational use); storage limits; onward sharing prohibitions; retention requirements
• Handling requirement: encryption, marking, logging, approved tools/channels

Implementation tip: if your current data classification policy is high-level, add a “sharing rules” appendix for the categories that are actually shared.

3) Tag information with those restrictions (labeling)

Operational requirement: the check cannot happen if restrictions are not knowable.

• For structured datasets: maintain a data catalog entry with classification and sharing restrictions.
• For documents/files: apply metadata tags or a repository label; if tooling is limited, use a controlled template header/footer plus a registry entry.
• For API data: document the data elements and the applicable restriction set in an interface control document.

Your goal is not perfect tagging everywhere. Your goal is that in-scope shared information has recorded restrictions that a reviewer can retrieve later.

4) Establish a “partner authorization baseline”

For each sharing partner, you need a current record of what they are authorized to access and how. Minimum baseline:

• Partner legal identity and points of contact
• Data sharing mechanism(s): connection, tenant, accounts, API client, service principal
• Authorized roles/groups and approval authority
• Contractual/data-sharing agreement constraints that affect use

Where this typically lives:

• Third-party inventory + contract repository
• IAM role mappings for external accounts
• Interconnection security agreement (ISA) or equivalent

5) Implement the pre-share check (the core of AC-21)

Pick a workflow pattern that matches how sharing happens:

Pattern A: Human-approved sharing (tickets/requests)

• Requestor identifies dataset + partner + purpose.
• System owner or data owner verifies restrictions vs partner baseline.
• Approval recorded; sharing executed by IT or automated job.

Pattern B: Automated gating (preferred where feasible)

• Data labels/restrictions are enforced by a policy engine (DLP/CASB/data access governance) and identity controls.
• If partner entitlements do not satisfy restrictions, the system blocks the share or requires an exception workflow.

Pattern C: Contract-first controls (common early-stage)

• Sharing permitted only under standardized agreement terms and predefined datasets.
• Any deviation requires a ticketed exception with data owner sign-off.

Whatever pattern you choose, AC-21 expects that an authorized user can determine the match between partner authorizations and data restrictions. If the check is tribal knowledge, auditors will treat it as not implemented. (NIST SP 800-53 Rev. 5 OSCAL JSON)

6) Add exception handling (because mismatches will happen)

Define:

• Who can approve exceptions (data owner + security)
• Required compensating controls (redaction, aggregation, time-limited access, additional logging)
• When exceptions expire and must be revalidated

7) Monitor and revalidate

AC-21 fails silently if partner access drifts.

• Revalidate partner authorization baselines when: contracts change, integration changes, identities change, data restrictions change, or a security event occurs.
• Add AC-21 checks to change management for integrations and access provisioning.

Required evidence and artifacts to retain

Auditors will ask for proof the check exists and is performed. Retain:

• AC-21 procedure (how to do the check, who performs it, what tools/records are used) mapped to the control owner. (NIST SP 800-53 Rev. 5 OSCAL JSON)
• Scope definition for AC-21 triggers (systems/datasets/channels in scope).
• Restriction records for shared datasets (catalog entries, labels, templates, data handling requirements).
• Partner authorization baselines (entitlement listings, role mappings, contract clauses that constrain use).
• Completed check records (tickets, approval logs, automated policy decision logs).
• Exception approvals with rationale and expiry.
• Change management linkage (evidence that new/changed shares go through the check).

Daydream note (earned, not decorative): teams often lose time proving the control is operating. A Daydream-style control mapping that ties AC-21 to owners, procedures, and recurring evidence artifacts reduces “audit archaeology” and makes renewals and reassessments faster. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Common exam/audit questions and hangups

Expect questions like:

• “Show me how a user determines whether Partner X is authorized for Dataset Y.”
• “Where are the use restrictions defined, and how do you keep them current?”
• “Is there a technical control that prevents sharing when permissions don’t match?”
• “How do you handle downstream sharing by the partner?”
• “Give examples of a share that was denied or modified due to a mismatch.”

Typical hangups:

• Restrictions exist in policy prose but are not attached to the data.
• Partner authorization is assumed based on a contract, but not translated into actual account entitlements.
• Shares happen through informal channels (exports, emailed reports) outside the controlled workflow.

Frequent implementation mistakes (and how to avoid them)

1. Mistake: Treating AC-21 as a one-time due diligence task.
   Fix: make it an operational gate in the sharing workflow with revalidation triggers.

2. Mistake: Defining restrictions without a decisionable format.
   Fix: convert restrictions into a checklist or policy rules that yield a clear yes/no/exception outcome.

3. Mistake: No single source of truth for partner authorizations.
   Fix: maintain a partner authorization baseline and tie it to identity objects (accounts, roles, API clients).

4. Mistake: Evidence is scattered across tools with no retrieval path.
   Fix: standardize where artifacts live and index them per partner and per dataset.

5. Mistake: Ignoring “use restrictions” and checking only “access.”
   Fix: require requestors to state purpose and confirm allowed uses (e.g., analytics-only, no onward sharing) during approval.

Risk implications and why operators care

AC-21 gaps typically surface as:

• Data shared with a third party whose actual entitlements exceed what the data restrictions allow
• Purpose drift (data used for a different purpose than approved)
• Uncontrolled onward sharing because restrictions were not communicated or enforced

Even without a quantified penalty model in NIST, these failures commonly drive incident response, contract disputes, and audit findings because they combine access control breakdowns with third-party exposure. (NIST SP 800-53 Rev. 5)

Practical 30/60/90-day execution plan

First 30 days (get to a working gate)

• Appoint control/process owners and publish an AC-21 procedure. (NIST SP 800-53 Rev. 5 OSCAL JSON)
• Define scope: which systems/datasets/sharing channels trigger the check.
• Create a restriction template for in-scope information (access + use restrictions).
• Stand up a basic request-and-approve workflow (ticket form) that captures dataset, partner, purpose, and restriction match decision.
• Start a partner authorization baseline for the highest-risk sharing partners.

Days 31–60 (make it repeatable and auditable)

• Expand restriction tagging for all in-scope shared datasets (catalog entries and/or labels).
• Standardize partner baselines: identity objects, contract terms, approved sharing mechanisms.
• Add exception workflow with expirations and compensating controls.
• Build an evidence register: where logs/tickets/approvals are stored and how to retrieve them per share.

Days 61–90 (reduce manual burden; close the side channels)

• Integrate AC-21 into change management for new/changed data exchanges.
• Add technical enforcement where feasible (repository sharing controls, DLP rules, conditional access, API gateway policy checks).
• Run a tabletop audit: pick a sample of shares and prove the restriction/authorization match with retained evidence.
• Use Daydream (or your GRC system) to keep the AC-21 mapping current: owner, procedure, evidence cadence, and test steps. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Frequently Asked Questions

Does AC-21 apply to sharing with internal business units?

It can. If the “sharing partner” is a separate environment, enclave, or tenant with distinct authorizations, the same mismatch risk exists. Define this explicitly in your AC-21 scope. (NIST SP 800-53 Rev. 5)

What counts as “use restrictions” versus “access restrictions”?

Access restrictions define who can get the data. Use restrictions define what the recipient is allowed to do with it (purpose, onward sharing, storage/retention). Your process should check both before approving a share. (NIST SP 800-53 Rev. 5 OSCAL JSON)

We only have contracts, not technical enforcement. Can we still meet AC-21?

Yes, if authorized users can reliably determine the partner’s authorizations and confirm they match the data’s restrictions before sharing, and you retain evidence of that determination. Over time, add technical gates to reduce human error. (NIST SP 800-53 Rev. 5 OSCAL JSON)

How do we handle dynamic partner access that changes frequently?

Maintain a partner authorization baseline tied to identity objects (accounts, roles, API clients) and require revalidation when access changes. If you cannot keep up, narrow sharing to fixed datasets and fixed mechanisms until the baseline stabilizes. (NIST SP 800-53 Rev. 5)

What evidence is most persuasive in an audit?

A complete thread that starts with the data restrictions, shows the partner authorization baseline, and ends with a recorded approval or policy decision for the specific sharing event. A written procedure alone rarely closes the loop. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Where does Daydream fit without turning this into a tooling project?

Use Daydream to map AC-21 to a named owner, a concrete procedure, and a recurring evidence set so you can answer auditor sampling requests quickly. Keep the enforcement in your IAM/data-sharing stack; keep the proof and workflow indexing in Daydream. (NIST SP 800-53 Rev. 5 OSCAL JSON)