AC-21 Information sharing: requirements and evidence

What AC-21 information sharing asks before data leaves your hands

AC-21 asks that authorized people check, in defined circumstances, whether a sharing partner's access authorizations match the access and use restrictions on the information, and that defined automated mechanisms support those sharing and collaboration decisions. If your team shares files, records or datasets with partners, the control expects a named decision-maker to confirm the partner is allowed to see and use what you are about to send, and expects the check to happen in a repeatable way rather than from memory. The risk the control targets is over-sharing: information leaves with a partner whose access does not match the restrictions attached to it, such as a contractor cleared for less sensitive records or an outside group that is not covered by the agreement governing the data.

What makes AC-21 hard in practice is usually not the technology but the ambiguity around it. Teams often cannot list the circumstances that require user discretion, so decisions get made informally by email or chat, and nobody can later show who decided, on what basis, or against which restriction. The assessment procedure for AC-21 looks for a list of the users authorized to make these decisions, a list of the circumstances that need that discretion, and the agreements that support them, including non-disclosure agreements, contracts and any privacy impact assessment. Start by writing down those three lists before you configure anything. Ask your compliance lead which sharing scenarios the organization has already defined.

AC-21 is selected in the moderate and high SP 800-53B baselines but not in the low or privacy baselines, and none of its two enhancements is selected in any baseline. Confirm the baseline for your system against the SP 800-53B Release 5.2.0 profiles before you scope the work, because a low-impact system may not need the control at all. Where it does apply, the automated part can be supported by tooling. For example, Nextcloud's File Access Control app can deny upload, download, sync and other actions based on rules such as user group, IP address or file tags, which can serve as one of the defined mechanisms if your sharing rules are written down and tested. Confirm with the vendor and your own environment whether those rules meet the restrictions you have defined.

Which sharing relationships and systems put AC-21 in scope

AC-21 applies to information with access and use restrictions that people may share with partners, so scope starts with which systems hold that information and who sits on the other side of each sharing relationship. The organization defines the circumstances that require user discretion, which means the scope is only as clear as that definition.

Systems holding restricted information

Start with the systems that store or process information carrying access or use restrictions, such as contract terms, personal data, controlled technical data or internal-only reports. A file share, collaboration platform or document repository that holds this material is in scope even when no one has yet shared anything from it. Ask data owners to label which repositories carry restrictions, because the scope cannot be drawn from the system inventory alone.

External sharing partners

External partners are the main source of AC-21 work. Customers, suppliers, auditors, regulators and joint-venture members each hold different authorizations, and their own controls may not match yours. Record each partner relationship, the agreement that governs it and the kinds of information it may receive, so that the decision about matching authorizations has a defined counterpart on the other side.

Internal sharing across groups

Internal sharing still counts when it crosses a boundary that carries different access rights, such as a research group sharing with a commercial team or a business unit sharing with a subsidiary. Map the internal groups and the restrictions attached to their data. Where internal groups already share freely under one set of rules, document that boundary so assessors can see why it falls outside the circumstances you defined.

Sharing circumstances that need user discretion

Define the specific circumstances in which an authorized user must decide whether a partner's authorizations match the restrictions, for example sharing outside a defined partner class or sharing a particular data category. Assessors examine this list directly, so a vague definition leaves the scope open to dispute. Each circumstance should name who decides and what they check.

Baseline selection and privacy scope

AC-21 is selected in the moderate and high baselines but not in the privacy baseline. Confirm the system's impact level and baseline before scoping, and check whether any tailoring removes or adds the control. A privacy-only system may still share personal data, so review its sharing practices against the privacy controls and the rest of the control set rather than relying on this baseline choice alone.

Automated sharing mechanisms

Systems that automate sharing, such as sync clients, external links and shared folders, make decisions at volume, so they need to be inside scope even when people trigger them. Inventory the features that move restricted information outside its boundary and confirm which of them rely on automated mechanisms to check partner authorizations. Open-source platforms vary in what they enforce natively, so confirm each feature against the platform's documentation.

How to implement AC-21 sharing decisions in order

This sequence turns AC-21 into a working decision process: it defines when people must weigh a sharing partner's access authorizations against information restrictions, who makes those calls, and how the decision is supported and tested. Each step produces a record an assessor can examine.

Define the sharing circumstances that need user discretion
Start by listing the situations in which a user must decide whether a partner's access authorizations match the restrictions on the information. Typical entries include sharing outside the organization, sharing with a partner under a collaboration agreement, and sharing content that carries restrictive labels. Your AC-21 assessment is organization-defined, so the list must be written down and approved by the system owner and the information owner. The output is a circumstance list with a named owner and a review date, which the assessor examines first. If a circumstance is not on the list, users will have no documented basis for deciding, so ask the owners to confirm the list covers every sharing path the system supports.
Name the users authorized to make sharing decisions
Identify the individuals or roles allowed to decide whether a partner may receive information in each circumstance. Keep the group small and tie each role to a job function, not to a general user group. Record who approved the assignment and how it is removed when someone changes roles. The output is an authorized-user list that matches the circumstance list one to one. Assessors interview the people named here to confirm they know their responsibility, so the list should be checked against current staff before each assessment cycle.
Document the restrictions attached to each information class
For each information class in scope, write down the access and use restrictions that a sharing partner must satisfy. Restrictions often come from contracts, privacy obligations, classification markings or regulatory rules, so draw them from the source document rather than from memory. Link each class to the circumstances in step one. The output is a restriction register that a decision-maker can read without asking the information owner. Where a restriction depends on a privacy impact assessment or a non-disclosure agreement, record that dependency explicitly so the decision aid can reflect it.
Set up the decision aid for sharing requests
Choose how the decision is supported. Automated access rules can deny or hold a transfer when the request matches a restricted pattern, for example by user group, network address, collaborative tag or file type. Nextcloud's File Access Control app, which is AGPL-3.0-only, can apply rules on user group, IP address, collaborative tags, MIME type, file name, request time and user agent, but you must confirm that it fits your sharing paths and restriction register. Where automation cannot cover a case, write a manual check with a checklist that the authorized user completes and retains. The output is the configured rule set or the signed-off manual procedure, plus a mapping from each rule to a restriction in step three.
Write and sign the agreements that govern partners
Put the sharing terms in writing before any information moves. Non-disclosure agreements, contractual terms and, where applicable, a privacy impact assessment should state the permitted use, the onward sharing limits and the security expectations the partner must meet. Have legal or contract owners confirm the wording matches the restriction register. The output is a signed agreement for each partner in scope, stored where assessors can examine it. Note that agreements describe the partner's commitments, so they support the decision but do not replace the decision-maker's check.
Test the mechanism with sample requests
Run sample sharing requests through the decision aid and the manual procedure. Include requests that should be allowed, requests that should be denied and requests that fall into a circumstance with no rule. Compare each outcome with the expected result from the restriction register, and record any mismatch and the fix applied. Assessors use the SP 800-53A test methods to check that the mechanism implements the authorizations, so keep the test inputs, outputs and tester names. The output is a dated test record with pass, fail and corrective action entries. Repeat the tests after rule changes and after any change to partners or information classes.

How an assessor tests AC-21 information sharing

This table compares the three SP 800-53A assessment methods for AC-21 against the two determination statements, showing what the assessor asks for, the evidence they expect and the findings that usually come up. Read each row as a question the assessor will put to your team before the assessment starts.

Method	What the assessor asks for	Evidence requested	Common findings
Examine	The list of users authorized to make information-sharing or collaboration decisions, the list of circumstances that require user discretion, and the agreements that govern sharing with partners	Current authorized-user list with approval dates, written circumstance definitions, signed non-disclosure agreements, contracts or acquisition terms covering shared data, and a privacy impact assessment where personal information is involved	Circumstances are described only in general terms, the authorized-user list is outdated or unapproved, and agreements do not mention the access restrictions that apply to the shared information
Interview	The personnel responsible for information-sharing and collaboration decisions, and how they judge whether a partner's access authorizations match the restrictions on the information	Named role holders, a walkthrough of a recent sharing decision, and the criteria or checklist the decision-maker applied	Staff describe a practice that differs from the written procedure, or they cannot say who approves a sharing decision outside normal business hours
Test	The automated mechanisms or manual process that enforce access authorizations to support sharing and collaboration decisions	Configuration exports or policy rules for the sharing mechanism, sample decision records, and test results showing that a partner without matching authorizations is refused or escalated	Rules exist but were never tested against a realistic partner case, manual steps are undocumented, or the mechanism applies rules the written policy does not describe
Determination statement 1	That the organization enables authorized users to determine whether a sharing partner's access authorizations match the access and use restrictions, in the defined circumstances	Linked evidence from the examine and interview rows showing the defined circumstances and the decision step for each	Circumstances are not defined, so the assessor cannot tell which sharing cases the control covers
Determination statement 2	That the organization uses defined automated mechanisms to support sharing and collaboration decisions	Documented mechanism scope, the set of decisions it supports, and proof that it runs in production	The mechanism is defined only as a plan or a pilot, or the organization cannot show which decisions it actually supports
Scope check	Whether the sharing paths in the system are the same as the ones described in the control evidence	Data flow diagram or inventory of external sharing channels, matched against the authorized-user list and circumstance list	Sharing happens through a channel that was never assessed, such as a file link or an email export

Evidence that passes an AC-21 review and how to keep it current

An assessor testing AC-21 looks for a short, dated set of records showing who decides, under which circumstances, against which restrictions, and what the mechanism actually did. Each artifact below goes stale for a different reason, so each needs its own review trigger between audits.

Signed list of authorized decision makers

This is the list of users your organization has authorized to make information-sharing and collaboration decisions, the examine object an assessor starts with. Check that every name maps to a current role, that the approver is someone with authority over the information, and that the list is signed by that approver with a date. Review it whenever a named decision maker changes role or leaves, and reconcile it against your identity provider group membership so the list and the access it grants agree.

Documented sharing circumstances

This artifact defines the circumstances in which a sharing decision must be made by a person rather than applied automatically, such as sharing with a new partner, sharing a new information class, or sharing outside a contracted scope. Write each circumstance as a testable condition, not a general principle. Revisit the list at every new partner onboarding and after any change to the information classes it covers, and record the reviewer and date on each revision.

Restriction mapping for information classes

The mapping ties each information class to its access and use restrictions and to the partner attributes that may receive it. Assessors use it to judge whether a sharing partner's authorizations match the restrictions, so gaps here undermine every decision record. Confirm that the mapping uses the same labels your access enforcement and labeling controls apply. Recheck the mapping whenever a classification is changed or a new partner type is added, since a stale label can let a decision look valid when it is not.

Partner agreements and non-disclosure terms

Non-disclosure agreements, contracts and acquisition terms show what each partner has committed to do with shared information. The SP 800-53A examine objects name these agreements directly, and an assessor will compare their terms with the restrictions in your mapping. Confirm that the agreement covers the same information classes and use limits that the decision record cites. Track expiry and renewal dates for every partner agreement in a register, and flag any sharing that continues after an agreement lapses.

Sample decision records

Decision records show a sample of real sharing actions, including the requesting partner, the information class, the authorization check, the approver, and the outcome. If an automated mechanism makes some decisions, keep its logs and the rules that produced them alongside manual records. Choose samples across the period so the assessor sees the process working over time, not only at one moment. Refresh the sample set on a fixed schedule and after any change to the mechanism's rules, and confirm that each record can be traced back to the mechanism version that made it.

Test records for the mechanism or process

Test records show that the automated mechanism or manual process actually enforces the authorizations it is meant to enforce. For a rule-based tool, this means test cases that match partner attributes against restrictions, including cases that should be denied, with the results and the reviewer's sign-off. Keep the test cases under version control so each run can be compared with the last. Rerun the test set after every rule change, upgrade or partner-type addition, and record which version of the rules was tested.

Who decides, who builds and who assesses AC-21

Your organization owns AC-21. Authority to decide whether a sharing partner's access authorizations match the restrictions on a piece of information sits with named people, and those people must be identified, trained and accountable. The organization also defines the circumstances in which that user discretion applies, because the assessment expects a written list of them, and it signs off on the agreements that govern sharing. An implementation partner can draft these materials, but the decisions and approvals must come from inside the organization.

Authorized decision makers: Name the users or roles allowed to make information-sharing and collaboration decisions, and keep that list current as people change jobs.
Sharing circumstances: Define the situations that require user discretion, such as sharing with a partner organization or an external collaborator.
Agreements and approvals: Own the non-disclosure agreements, contracts and privacy impact assessment that the assessment examines as supporting evidence.
Operating records: Keep decision records that show who decided, what partner was involved and which restrictions applied.
Policy alignment: Confirm that the sharing rules match the information classification scheme already in use.

Before any assessment, confirm with your assessor which of these artifacts they will request and in what format.

What AC-21 information sharing costs to meet

This table breaks AC-21 cost into its components, showing who is paid, whether each cost is one-time or recurring, what pushes it up or down, and how self-hosted open source affects license spend. Use it to build a quote request, because no price or duration is supplied for this control and the real figures depend on the partners, information classes and automation in your environment.

Cost component	One-time or recurring, and who is paid	What drives it up or down	How to reduce it
Tooling or licenses	Recurring if commercial; open-source tooling removes license spend but not hosting or support. Paid to vendors or to the hosting team.	Number of sharing partners and whether the decision aid is a commercial product or a self-hosted tool such as a file access control app.	Prefer self-hosted open-source enforcement where it covers the required rules, and confirm feature coverage before committing.
Engineering time to configure the decision aid	One-time build, then recurring changes. Paid to the internal team or an implementation partner under a written scope.	Number of rule types needed (user group, IP, tags, file type) and how many systems must be integrated.	Start with a narrow set of sharing circumstances and expand only where the scope is written down.
Policy and circumstance design	One-time design, with periodic review. Paid to internal governance, legal or compliance staff.	Number of information classes and the number of distinct circumstances that require user discretion.	Group information into a small set of classes with shared sharing rules before writing per-partner conditions.
Agreement drafting and legal review	One-time per partner type, recurring for new partners. Paid to counsel or internal legal.	Number of partners, whether non-disclosure agreements and acquisition or contract terms must be reviewed, and whether a privacy impact assessment is needed.	Use standard agreement templates and ask counsel to review deviations rather than each agreement from scratch.
Evidence upkeep	Recurring. Paid to internal staff who export rule sets, access lists and approval records.	Frequency of partner changes, rule changes and reviews of the list of authorized decision makers.	Automate exports of rule configuration and approval logs, and version them with change tickets.
External testing or review	Recurring or periodic. Paid to a testing firm under a written scope.	Degree of automation in the sharing path and the exposure of the systems that enforce the decisions.	Scope tests to the decision aid and the sharing paths it controls, and retest after material rule changes.
Assessor effort	Recurring per assessment cycle. Paid to the independent assessor, who alone issues findings.	Number of examine, interview and test objects in scope and how well evidence is organized before the assessment starts.	Prepare a single evidence pack that maps each object in SP 800-53A to a stored artifact before the assessor begins.

Using Nextcloud file access rules as an automated decision aid

The Nextcloud File Access Control app can serve as an automated decision aid for AC-21 by turning some sharing restrictions into rules the server applies before a file moves. Administrators can configure rules that deny upload, modification, deletion, download and sync of files when a rule matches on user group, IP address, collaborative tags, MIME type, file name, request time or user agent. For example, a rule might block download of files tagged with a restricted classification by users outside a given group, or block sync clients from a particular user agent. Each rule expresses a restriction as a check the system performs on every matching request, which gives authorized users a consistent mechanism rather than relying only on individual judgment.

The rules enforce restrictions but do not make the sharing decision. The organization still has to define the circumstances in which users must decide whether a partner's access authorizations match the information's restrictions, name the users authorized to make those decisions, and decide which restrictions the rules must reflect. A rule set that blocks a file type or a group is only as good as the classification behind it, so the classification scheme, the tags applied to files and the group structure need to be documented and reviewed together. Assessors will look for the list of circumstances and the authorized decision makers, and they will test whether the mechanism implements the decisions those people make.

Before relying on these rules, confirm with your Nextcloud administrators and security team which rule types fit your restrictions. Test each rule against sample files from every information class you handle, including edge cases such as renamed files, mixed group memberships and sync clients, and record the results as test evidence. Because Nextcloud is licensed under the AGPL-3.0-only license, confirm with your legal team what that license means for your deployment and any modifications you make to the app. Review the official Nextcloud admin manual on files access control for the current behavior of each rule type before you finalize your configuration.

Where AC-21 implementations usually fall short

AC-21 only works when the organization can show who decides, under which circumstances, against which written restrictions, and with what record. The gaps below tend to appear together: a sharing practice that depends on individual judgment with no list, no rules and no trail is hard to test and easy to get wrong.

Sharing circumstances never written down

AC-21 asks the organization to define the circumstances in which an authorized user must decide whether a partner's access matches the restrictions on the information. Many teams share informally, so no document lists those situations. Check that the organization has a written list of sharing circumstances, that each entry names the information types involved, and that the list is approved and reviewed. Without it, an assessor has nothing to compare actual sharing against.

Decisions made by people not authorized

The control requires a defined list of users authorized to make information-sharing decisions. In practice, account owners, project leads or help desk staff often approve shares because they hold the data or the relationship. Compare recent sharing approvals with the authorized list and look for names that are missing. The fix is to name the roles or individuals in writing, tie them to a delegation process, and remove approval rights when people change roles.

Restrictions not turned into checkable rules

Access and use restrictions often live in contracts, classification labels or policy text that no system reads. A decision aid can only support the decision if the restriction is expressed as a condition, such as a group, label, file type or domain that a tool can evaluate. Confirm that each restriction in scope maps to a rule, and that the rule can be tested with sample files and partner identities. Access control tools such as the File Access Control app in Nextcloud can express rules on user group, IP address, tags, MIME type and file name, but the organization must still decide which restriction each rule represents.

Partner agreements missing access terms

Before information is shared, the organization should confirm that the partner's own access authorizations fit the restrictions on the data. Agreements that only cover confidentiality often say nothing about who at the partner may see the data, which systems they may use or whether onward sharing is allowed. Check that each agreement states the partner's access terms, the permitted users or roles, and the conditions for onward disclosure, and that the agreement is reviewed when a partner's staffing or systems change. Confirm the required clauses with legal counsel.

No record of sharing decisions

An assessor will ask who decided to share, what restrictions were checked, what the partner was authorized to access and when the decision was made. If those answers exist only in email or memory, the control cannot be evidenced. Set up a decision log that records the requester, the approver, the information, the partner, the restrictions checked, the outcome and any exception. Keep the log in a system the sharing team cannot edit after the fact, and sample it regularly to confirm that entries match actual transfers.

Mechanisms never tested

When automated mechanisms support sharing decisions, assessors test whether they work as documented. Teams often deploy a filter, sharing rule or approval workflow and never try it against a partner account that should be blocked. Build test cases for each rule, including a denied partner, a restricted file type and an allowed case, and repeat them after upgrades or rule changes. Record the results with the configuration version so the test can be shown later. Where the process is manual, test a sample of past decisions the same way.

Questions buyers ask about AC-21 cost, effort and outside help

How much effort does AC-21 take, and what drives it?

The effort depends on how many sharing circumstances the organization defines and how many systems hold information that carries access and use restrictions. AC-21 asks the organization to define the circumstances in which authorized users decide whether a sharing partner's access authorizations match the restrictions on the information, and to define the automated mechanisms that support those decisions. Effort rises with the number of sharing partners, the number of restriction types (for example, legal, contractual or classification-based), and whether decisions are made by hand or supported by tooling. Assessors examine the list of circumstances, the list of authorized decision makers, and the agreements in place, so the documentation effort starts before any technical work. Ask any provider to break its estimate into definition, documentation, tooling and evidence collection.

Can a small team meet AC-21 without outside help?

A small team can often meet AC-21 internally if it has clear ownership of information sharing and access authorizations. The work is mostly decision-making and documentation: defining circumstances, naming decision makers, writing the sharing rules and keeping the records current. Outside help is most useful where the team lacks experience with access enforcement tooling, needs an automated decision aid built or configured, or must prepare evidence for an assessment. Whether to bring in a partner is a judgment for the organization. Any partner can prepare systems and evidence, but the organization keeps ownership of the control and the independent assessor issues any assessment result.

What does AC-21 need from our staff?

AC-21 needs named people, not only tools. The organization must identify the users authorized to make information-sharing and collaboration decisions, and assessors interview the personnel responsible for those decisions. Typical roles include a system owner for each information set, a data or records owner, legal or contracts review for non-disclosure agreements and sharing agreements, and a privacy contact where a privacy impact assessment applies. Plan for each role's time to define circumstances, review proposed sharing with partners and approve rule changes. Confirm with your assessor which roles they expect to interview and which documents they will request.

How long does AC-21 take, and what sets the timing?

NIST does not set implementation timelines for SP 800-53 controls, and it leaves timing to OMB Circular A-130 for federal systems. For any other program, the timing is set by your authorizing body, contract or regulator, along with your own change calendar. The main drivers are how many information sets and sharing partners are in scope, whether existing agreements need revision, how many decision makers must approve the circumstances, and whether automated mechanisms are new or already in place. Ask your authorizing body what deadline applies, then build a plan that reflects your own environment. A written fixed scope with agreed deliverables is the most reliable basis for a schedule.

Can an implementation partner issue an AC-21 assessment result?

No. An implementation partner prepares systems, controls and evidence, but it does not issue audit reports, attestations or assessment results. Under the SP 800-53 program, the assessment is performed by an independent assessor, and the authorizing official decides whether to accept the risk. Your partner can help you define circumstances, configure access controls and organize the evidence the assessor will examine, such as decision-maker lists, sharing agreements and mechanism test records. Ask any provider to state its role in writing so there is no confusion about who issues the result.

Is AC-21 required in the privacy baseline?

No. SP 800-53B selects AC-21 for the moderate and high security control baselines but not for the privacy baseline. None of the two current AC-21 enhancements is selected in the low, moderate, high or privacy baselines. If your program relies on the privacy baseline, you should still review how personally identifiable information is shared, because related controls such as PT-2 and PT-7 and the privacy impact assessment may apply. Confirm the baseline selection with your authorizing body, since it determines which controls are assessed.

What are the recurring costs after AC-21 is in place?

After the initial definition, AC-21 has recurring work that is easy to underestimate. Decision makers must review circumstances when partners, data types or contracts change. Mechanism rules, such as file access rules in a self-hosted collaboration platform, need periodic testing to confirm they still deny what they should. Agreements need renewal, and evidence must be refreshed for each assessment cycle. Ask any quote to separate one-time setup from ongoing review, testing and support, and to state whether ongoing support is a fixed-scope item or a retainer.

How DeployOpen works on this

DeployOpen approaches AC-21 Information sharing as an engineering and documentation task inside your own infrastructure. We prepare the systems, decision workflows and evidence that let your authorized users check a sharing partner's access authorizations against the restrictions on the information, while your organization keeps ownership of the control.

How we scope

We confirm which information-sharing circumstances your organization has defined and which of them require user discretion.
We list the users authorized to make sharing and collaboration decisions and the systems where those decisions take place.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work starts, and a quote follows from that scope.

How we build

We configure or integrate self-hosted platforms so that sharing and collaboration decisions follow your defined access restrictions.
Where a platform supports rule-based controls, such as Nextcloud's File Access Control app, we set rules by group, tag or file attribute and test them.
We test the automated mechanisms and any manual process against the access authorizations they are meant to support.

How we hand over

We document the sharing circumstances, decision roles, rule configurations and test results in a form your assessor can examine.
We collect supporting artifacts such as NDAs, agreements and privacy impact assessment references where your program holds them.
Your organization owns the control and the final evidence package, and an independent assessor is the party that tests and reports on it.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
We can revisit rule sets and decision workflows when sharing partners, classifications or platform versions change.
Confirm with us in writing which support and testing activities sit inside the retainer before you sign.