AC-21(2): Information Search and Retrieval

The ac-21(2): information search and retrieval requirement exists because search can bypass your intended access controls. If your systems index sensitive content and return it to users who lack permission, you have a data exposure even if the underlying repository blocks document opening. For CCOs and GRC leads, AC-21(2) is less about buying a “secure search” product and more about proving that every search experience in scope enforces the same rules you apply elsewhere: least privilege, need-to-know, controlled unclassified information handling, or mission-specific restrictions.

This control shows up in real operational places: enterprise search, SharePoint/Google Drive search, ticketing/knowledge bases, code search, data catalogs, SIEM queries, eDiscovery tools, and internal portals. It also shows up in third-party SaaS where you rely on the provider’s indexing and permissions model. The practical goal is simple: a user’s query should only return what that user is authorized to know exists, and the retrieval action should not broaden access.

Below is requirement-level guidance you can hand to engineering and system owners: scoping, design decisions, implementation steps, evidence to retain, and the audit questions that tend to stall teams.

Requirement: AC-21(2) Information Search and Retrieval

What the requirement says (and what it means)

Regulatory text

“Implement information search and retrieval services that enforce {{ insert: param, ac-21.02_odp }}.” (NIST SP 800-53 Rev. 5 OSCAL JSON)

Operator interpretation: You must ensure that any system feature that lets users search for, browse, filter, or retrieve information enforces your organization-defined access restrictions. In practice, that means your search service must apply authorization rules to:

• what gets indexed,
• what appears in results (including snippets and previews),
• what can be opened/downloaded/exported,
• what can be queried through APIs, integrations, or bulk export.

The placeholder “organization-defined parameter” is the key: your program must define the rule set (labels, clearance, roles, tenancy boundaries, legal holds, matter restrictions, export controls, etc.) and prove the search layer enforces it consistently. (NIST SP 800-53 Rev. 5)

Plain-English definition (use this with control owners)

If a user can’t access a file, they also can’t discover it via search. Search results must be “permission-trimmed,” and retrieval must enforce the same restrictions as the source system.

Who it applies to

Entity scope

AC-21(2) commonly applies to:

• Federal information systems and contractor systems handling federal data (for example, environments supporting federal contracts where NIST SP 800-53 is in scope). (NIST SP 800-53 Rev. 5)

Operational scope (where you should expect it to bite)

Include any platform where search/retrieval exists, including:

• Document repositories (SharePoint, file shares, ECM systems)
• Knowledge bases and ticketing (internal support portals)
• Code and artifact repositories (source, packages)
• Data platforms (data catalogs, BI search, SQL query interfaces, lakehouse discovery)
• Security tooling (SIEM searches, log analytics) where logs contain sensitive info
• Collaboration tools (chat search, message retention search)
• Third-party SaaS with built-in indexing, federated search, or AI “answers” that cite internal content

Third party angle: If the search function is operated by a third party (SaaS search, managed knowledge base, managed SIEM), AC-21(2) becomes a due diligence and configuration control. You still need evidence that the third party’s permission model is enforced in your tenant and that you configured it correctly.

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

Step 1: Define the “organization-defined” enforcement rules

Create a short, explicit statement that search must enforce. Examples of enforceable rules (choose what matches your environment):

• Role-based access (RBAC) and group membership
• Attribute-based access (ABAC) like classification labels or project tags
• Tenant and customer segregation boundaries
• Case/matter restrictions and ethical walls
• Need-to-know compartments for regulated programs

Deliverable: “Search Access Enforcement Standard” (one page) that names the rule inputs (identity source, groups, labels) and what must be protected (results, snippets, previews, caches, exports).

Step 2: Inventory search and retrieval services in scope

Build an inventory that answers: “Where can a user type a query and get back internal content?”

• Enterprise search portals
• Embedded search in SaaS (knowledge base, DMS, CRM)
• APIs that support query and export
• AI/RAG assistants that retrieve documents as part of answering questions

Tip: Don’t stop at the UI. Auditors will ask about API access, service accounts, and integrations that can query indexes.

Step 3: Confirm where authorization is enforced (source vs. index vs. query time)

For each search service, document:

• Indexing model: Does the index store ACLs/labels per document? Does it ingest content from multiple repositories?
• Query-time trimming: How does the service filter results to the requester?
• Snippet/preview rules: Are snippets generated from content the user can’t open? Are previews cached?
• Federated search: If searching across systems, does the aggregator enforce the strictest applicable rule?

Control intent: Authorization must not be a “best effort.” If the index can return results without enforcing restrictions, you have a design gap.

Step 4: Implement “security trimming” end-to-end

Minimum implementation expectations you can operationalize quickly:

1. Identity and authorization integration

• Tie search requests to strong identity (SSO) and authoritative group/attribute sources.
• Block anonymous search unless explicitly approved and logged.

2. Index-time controls

• Exclude content that should never be searchable (highly restricted repositories, secrets stores).
• Ingest and store access metadata (ACLs/labels) with each indexed item.

3. Query-time controls

• Filter results by the requester’s permissions and attributes.
• Ensure filters apply equally to UI, API, and bulk export endpoints.

4. Snippet, preview, and cache controls

• Disable or permission-trim snippets/previews if they can reveal restricted content.
• Control cached copies, thumbnails, and “quick view” features.

5. Service accounts and connectors

• Constrain connector accounts to least privilege. A connector that can read everything can accidentally index everything.
• Review integration scopes and rotate credentials.

Step 5: Test with negative cases (prove “cannot discover”)

Run targeted tests that attempt to find restricted information:

• Create two test users (authorized and unauthorized) in different groups/labels.
• Seed representative documents with unique keywords.
• Verify unauthorized users cannot see results, snippets, titles, metadata, or “related items.”
• Test UI search, API search, and any “recent documents” or “recommended content” widgets.

Evidence goal: Repeatable proof that the restriction is enforced, not a one-time spot check.

Step 6: Put the control on a maintenance cadence

Operationalize:

• Change control triggers: new repository connected, new index schema, new connector, new AI assistant, new sharing model.
• Periodic access review for connector accounts and search admins.
• Incident playbook for “search exposure” reports (how to disable indexing or results quickly).

Required evidence and artifacts to retain

Keep evidence that maps to design, operation, and testing:

• Control narrative / procedure for AC-21(2): scope, enforcement rules, responsibilities.
• Search services inventory with owners, data sources, and enforcement method.
• Configuration evidence (screenshots/exports) showing:
  • permission trimming enabled,
  • connector scopes,
  • snippet/preview settings,
  • API access controls.
• Test plan and test results for authorized vs unauthorized discovery (include date, test users, queries, expected/actual).
• Access reviews for privileged search admins and connector/service accounts.
• Change tickets for onboarding new data sources, updating index settings, or enabling new retrieval features.
• Third party due diligence artifacts where applicable: security documentation, tenant configuration attestations, and your configuration record.

If you track controls in Daydream, map AC-21(2) to a named owner, a repeatable procedure, and recurring evidence artifacts so assessments don’t turn into a screenshot scramble.

Common exam/audit questions and hangups

Auditors and assessors tend to focus on “bypass” paths:

• “Show me that a user without access cannot see the document title in search results.”
• “Do snippets reveal restricted content?”
• “Does the search API enforce the same controls as the UI?”
• “What permissions does the indexing connector have? Is it broader than necessary?”
• “How do you prevent cross-tenant or cross-matter discovery in federated search?”
• “What happens when a document’s permissions change? How fast does the index reflect it?”
  If you can’t answer with architecture notes and a test, you’ll stall here.

Frequent implementation mistakes (and how to avoid them)

1. Relying on ‘file-open denied’ as the control.
   Fix: require “cannot discover” testing for titles/snippets/metadata.

2. Indexing with an over-privileged service account.
   Fix: restrict connectors to scoped repositories and least privilege; document scopes.

3. Forgetting non-UI access paths.
   Fix: include API query endpoints, exports, plugins, and integrations in scope.

4. Snippets/previews leak content.
   Fix: permission-trim snippets or disable them for sensitive repositories.

5. No evidence trail.
   Fix: define a standing evidence set (config export + test results + access reviews) and collect it consistently.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement. Practically, AC-21(2) failures drive: unauthorized disclosure, cross-customer data exposure in multi-tenant tools, internal investigations, and reportable incidents depending on the data type. Treat search exposure as a real data incident path and align the control with your incident response process.

Practical execution plan (30/60/90)

You asked for speed; use phases rather than calendar promises.

First 30 days (Immediate)

• Name an owner for each search service (enterprise search, knowledge base, SIEM, data catalog).
• Publish the “Search Access Enforcement Standard” (the organization-defined rules AC-21(2) expects).
• Build the inventory of search/retrieval services, including APIs and AI assistants.
• Identify the highest-risk data sources connected to search (sensitive repositories, regulated datasets).

Next 60 days (Near-term)

• Implement or confirm permission trimming across all in-scope services.
• Review connector/service-account privileges and narrow scopes.
• Configure snippet/preview/caching behavior for sensitive sources.
• Create and run a standard negative test suite (authorized vs unauthorized discovery) and store results.

By 90 days (Operationalize)

• Add change-control gates for new connectors, new indexes, new federated search features, and AI retrieval.
• Schedule recurring access reviews for search admins and connectors.
• Build an audit-ready evidence packet per system (config + tests + reviews).
• Track AC-21(2) tasks and evidence in Daydream so control operation is continuous, not episodic.

Frequently Asked Questions

Does AC-21(2) mean we need a new enterprise search tool?

No. It requires that whatever search and retrieval you already provide enforces your defined access restrictions. Many teams meet AC-21(2) through configuration, connector hardening, and testable permission trimming rather than replacement.

If a document is permissioned correctly in SharePoint/Drive, are we automatically compliant?

Not automatically. You must verify that search results, snippets, previews, cached copies, and search APIs do not expose content or metadata to unauthorized users. Prove it with negative tests and retained evidence.

What counts as “search and retrieval services” in practice?

Any function that discovers or pulls information based on a query or filter, including enterprise search, knowledge bases, log search, data catalogs, and AI assistants that retrieve internal documents to answer prompts.

How do we handle federated search across multiple repositories?

Document where authorization is enforced and ensure the federated layer filters results based on the requester’s entitlements in each source. If you can’t prove consistent enforcement, restrict sources or disable federated results for sensitive repositories.

What evidence will an assessor accept for AC-21(2)?

A clear control procedure, an inventory of search services, configuration exports showing permission trimming and connector scopes, and test results showing unauthorized users cannot discover restricted content. Add access reviews for search admins and connector accounts.

How does AC-21(2) apply to third-party SaaS with built-in indexing?

You remain accountable for configuring the tenant correctly and retaining proof. Get the third party’s documentation, record your configuration settings, test with restricted users, and keep artifacts in your control evidence repository.