AC-3(11): Restrict Access to Specific Information Types

The ac-3(11): restrict access to specific information types requirement is an access control enhancement that forces clarity about what data matters most and where it lives. Many programs have “least privilege” statements, but AC-3(11) is evaluated where it hurts: actual repositories containing defined sensitive information types. If you cannot name the information types, list the repositories that contain them, and show the technical and procedural controls that restrict access, you will struggle in an assessment.

This requirement is especially operational for CCOs, GRC leads, and security compliance owners supporting federal information systems or contractor systems handling federal data. It pushes cross-functional alignment between data governance (classification and labeling), IT operations (identity, access, network), and system owners (applications, databases, file stores, object storage, SaaS repositories).

The fastest path to “assessment-ready” is to treat AC-3(11) as a mapping exercise plus a control enforcement exercise: (1) define the information types, (2) find every repository that contains them, (3) restrict access at the repository boundary, and (4) continuously prove it through reviews, logging, and tests. The control is short; the operational work is not.

Regulatory text

Requirement (verbatim): “Restrict access to data repositories containing {{ insert: param, ac-03.11_odp }}.” ¹

Operator interpretation: You must (a) define what “specific information types” are for your system or environment, (b) identify the repositories that contain those types, and (c) implement and maintain access restrictions so only authorized identities (users, admins, services) can access those repositories. Document what you chose, how you enforce it, and how you verify it over time. ²

Plain-English meaning

• “Specific information types” are categories of information you explicitly call out as requiring tighter control than general system data (for example: regulated data, mission-sensitive data, high-impact internal data).
• “Data repositories” include any store where the data resides: databases, data warehouses, file shares, object storage buckets, document management systems, collaboration platforms, backup repositories, logging platforms that ingest sensitive payloads, and analytics lakes.
• “Restrict access” must be real access enforcement at the repository boundary (permissions, roles, network paths, conditional access, service-to-service authentication), not just a policy statement or an app screen that hides a menu item.

Who it applies to

Entity scope

• Federal information systems and contractor systems handling federal data ²

Operational scope (where you feel it)

• Systems with multiple data types mixed across environments (prod/non-prod), teams (engineering, finance, HR), or third parties (managed services, SaaS).
• Environments with shared repositories (one warehouse for “everything,” one file share for “all projects,” one bucket for “all exports”) where sensitive datasets are not separated.
• Programs with data classification defined on paper but not implemented in IAM, database permissions, or storage policies.

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

Step 1: Define the specific information types (make them assessable)

1. Pick the authoritative taxonomy you will use (your data classification standard, contract-defined categories, system security plan boundaries).
2. Write an in-scope list of “specific information types” for this control that is short, explicit, and testable (examples: “CUI,” “PHI,” “cardholder data,” “payroll and compensation,” “source code for regulated systems”).
3. Assign a business owner for each information type (data owner who approves access criteria and exceptions).

Output you need: a one-page “AC-3(11) Information Types in Scope” statement with owners and high-level access principles.

Step 2: Inventory repositories that contain those types (don’t guess)

1. List repositories by platform and environment: databases, buckets, shared drives, SaaS workspaces, backup vaults, ETL staging areas.
2. Map each information type to each repository where it is stored, processed, or exported.
3. Identify “shadow repositories”: ad hoc exports, analyst sandboxes, shared spreadsheet locations, ticket attachments, email archives, and logs capturing sensitive fields.
4. Confirm with sampling: pull a small sample of records/files (or metadata) to validate the mapping, and document the method.

Practical tip: if you cannot prove the data location, you cannot prove the restriction. Treat “unknown location” as a finding until closed.

Step 3: Define access rules that match real operating needs

For each repository containing in-scope information types, define:

• Allowed roles and attributes (job functions, privileged admin groups, break-glass admins, service accounts).
• Access methods (VPN-only, private endpoint-only, managed devices only, approved IP ranges, conditional access).
• Separation expectations (prod vs non-prod; analytics vs operational; human vs service access).
• Exception process with expiry and compensating controls.

Use a table like this:

Repository	Information types	Who may access	How access is granted	How access is restricted	Review cadence
Data warehouse (prod)	CUI	Data engineering, approved analysts	IAM group + ticket approval	RBAC + network boundary + MFA/conditional access	Periodic

(Your cadence can be risk-based; auditors will look for consistency and evidence.)

Step 4: Implement restrictions at the repository boundary (technical enforcement)

Prioritize controls that are difficult to bypass:

• Repository IAM/RBAC: database roles, bucket policies, share permissions, workspace admin roles.
• Network segmentation: private subnets, private endpoints, firewall rules, deny-by-default ingress.
• Strong authentication: MFA/conditional access for admins; workload identity for services.
• Service account governance: no shared credentials; scoped permissions; rotation where applicable.
• Encryption keys as a control point (where relevant): access to key usage can function as an access gate, but only if it is tied to identity and monitored.

Validation test: attempt access with a user who should not have access. Capture the deny event (screenshot/log) and the configuration that caused it.

Step 5: Operationalize approvals, reviews, and change control

1. Access request workflow: ticket with business justification, data owner approval, and scope (repo + role + duration).
2. Periodic access reviews: reviewers must be able to see who has access to each sensitive repository and attest to appropriateness.
3. Joiner/mover/leaver linkage: ensure role changes remove access promptly through IAM automation or a documented offboarding process.
4. Change management: repository policy changes require peer review and documented approval, especially for “allow” rules that broaden access.

Step 6: Monitor and prove ongoing restriction

• Logging: enable access logs for repositories that store in-scope types; ensure logs capture identity, action, target, result.
• Alerting: detect anomalous access (new principals, access from unexpected networks, mass export patterns).
• Drift checks: periodic configuration review to detect policy drift (permissions broadened, public access toggled, new integrations).

Where Daydream fits (without adding process overhead)

Most teams fail AC-3(11) on evidence, not intent. Daydream can act as the system-of-record for the control mapping: information types → repositories → control owner → operating procedure → recurring evidence checklist. That structure reduces scramble during audits and helps you detect “new repository introduced” gaps before an assessor does.

Required evidence and artifacts to retain

Keep evidence that ties requirement text to real enforcement:

• In-scope information types list with owners and definitions.
• Repository inventory showing which repositories contain each information type.
• Access control configuration exports (RBAC/IAM policy snapshots, group membership lists, database role grants, bucket/share policies).
• Access request tickets with approvals and timestamps.
• Access review records with reviewer attestation and remediation actions.
• Testing evidence (deny tests, control validation scripts, screenshots/log extracts).
• Change records for policy updates (who approved, what changed, why).
• Exceptions register with expiry dates and compensating controls.

Auditor comfort comes from traceability: each sensitive repository has a named owner, explicit allowed access population, and proof that the system enforces it.

Common exam/audit questions and hangups

• “What are the ‘specific information types’ for this system?” If you answer with a broad category like “confidential data” and cannot show a definition, expect follow-ups.
• “Show me every repository that stores that type.” They will test whether you missed backups, exports, or SaaS mirrors.
• “Is restriction enforced at the repository, or only in the app?” UI-only controls are a common failure mode.
• “How do you prevent access through alternate paths?” Example: direct database connections, shared service credentials, or overly permissive network routes.
• “How do you detect and remove access when roles change?” They want to see an operational loop, not a one-time cleanup.

Frequent implementation mistakes (and how to avoid them)

1. Mistake: Defining information types but not mapping to repositories.
   Fix: maintain a living repository map tied to data discovery and onboarding checklists.

2. Mistake: Relying on shared folders or broad analyst groups.
   Fix: create narrowly-scoped groups per repository and per access level; require data owner approval.

3. Mistake: Forgetting non-production and staging areas.
   Fix: treat non-prod repositories as in-scope when they contain copies of sensitive types; restrict and justify any masking exceptions.

4. Mistake: Service accounts with “admin” permissions for convenience.
   Fix: enforce least privilege for workloads; document each permission to a function; rotate and monitor.

5. Mistake: No durable evidence.
   Fix: define recurring evidence artifacts (policy exports, review sign-offs, test results) and store them in a controlled audit repository with retention rules.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement. Practically, AC-3(11) is assessed as a high-signal control because it targets the repositories that concentrate sensitive information. Failures typically translate into broader findings: excessive privileges, weak segmentation, uncontrolled data sprawl, and inability to demonstrate that your data governance model is real.

A practical 30/60/90-day execution plan

First 30 days (stabilize scope and visibility)

• Name the in-scope “specific information types” and assign owners.
• Build the initial repository inventory and map types to repositories.
• Identify the worst exposures: broad groups, public links, shared admin accounts, unmanaged service credentials.
• Define evidence standards (what you will export, where stored, who signs).

By 60 days (enforce restrictions and close bypass paths)

• Implement repository-level RBAC/IAM restrictions for all mapped repositories.
• Add network controls for sensitive repositories (private access paths where feasible).
• Stand up an access request and approval workflow tied to data owner sign-off.
• Run deny tests and document results for each repository class.

By 90 days (operate the control like a program)

• Start periodic access reviews for each sensitive repository.
• Establish drift detection (policy change monitoring) and exception handling with expirations.
• Confirm logging coverage and review samples of access logs for appropriateness.
• Package the evidence set so an auditor can trace: information type → repository → restriction → approvals → review → monitoring.

Frequently Asked Questions

How do we decide what counts as “specific information types” for AC-3(11)?

Define a short list that reflects what would cause material harm if accessed improperly, and make it testable. Tie each information type to a data owner who can approve access rules and exceptions.

Does AC-3(11) require data classification tooling?

No tool is mandated by the requirement text. You do need a defensible definition of in-scope information types and a reliable way to identify which repositories contain them.

Are application-level permissions enough?

Usually not. Assessors commonly expect repository-level enforcement so a user cannot bypass the application and access the underlying database, bucket, or file share directly.

What repositories do teams most often miss?

Backups, data exports/staging locations, analytics sandboxes, collaboration platforms storing extracts, and logs that ingest sensitive fields. Add these to your inventory checklist.

How do we handle third-party managed services that host our repositories?

Treat the third party’s platform as the repository boundary and require evidence of access restriction (roles, groups, admin access controls, and logs). Contract terms should support timely access reporting and access removal.

What evidence is strongest for auditors?

A repository-by-repository packet: the access policy configuration export, the list of principals/groups with access, approval records for grants, access review sign-off, and a simple negative test showing denied access.

Footnotes

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

2. NIST SP 800-53 Rev. 5