AC-23: Data Mining Protection

To meet the ac-23: data mining protection requirement, you must implement technical and procedural mechanisms that detect and protect against unauthorized data mining across the systems, datasets, and interfaces in scope. Operationally, that means defining what “unauthorized mining” looks like for your environment, instrumenting monitoring and controls to spot it, and keeping evidence that the controls run and generate actionable outcomes. ¹

Key takeaways:

• AC-23 expects detect + protect outcomes against unauthorized data mining, not a policy-only response. ¹
• Scope must include data access paths (apps, APIs, analytics platforms, exports) where mining can happen, including third-party tooling. ¹
• Audit readiness depends on repeatable evidence: data access telemetry, alert/runbook records, and periodic reviews tied to an accountable owner. ¹

AC-23 is easy to misunderstand because “data mining” can sound like a niche research activity. In audits, it usually translates to a more concrete risk: someone (internal user, compromised account, malicious insider, or third party) repeatedly queries, exports, correlates, or scrapes data in a way that exceeds their authorization or business purpose. The control requires you to employ organization-defined mechanisms for organization-defined data mining activities to detect and protect against that unauthorized behavior. ¹

For a CCO, GRC lead, or compliance officer, the fastest path to operationalizing AC-23 is to treat it as an access control and monitoring requirement focused on patterns, not single events. A single query may be legitimate; a burst of queries over time, cross-dataset joins, bulk exports, or unusual API pagination often signals mining. Your job is to (1) define what “unauthorized data mining” means for your environment, (2) place controls where data leaves or is enumerated, and (3) retain evidence that detection and protective responses occur as designed. ¹

Regulatory text

NIST SP 800-53 Rev. 5 AC-23 excerpt: “Employ {{ insert: param, ac-23_odp.01 }} for {{ insert: param, ac-23_odp.02 }} to detect and protect against unauthorized data mining.” ¹

What the operator must do with this text

AC-23 is intentionally parameterized. You must fill in two blanks in your implementation:

1. What mechanisms you employ (tools, logging, analytics, rate limits, approvals, DLP, query monitoring, etc.).
2. What “data mining” activities are in scope for your system (data lake queries, BI dashboards, API enumeration, bulk exports, model training pulls, privileged database reads, partner feeds).
   Then you must show those mechanisms detect and protect against unauthorized mining (blocked, throttled, alerted, investigated, or otherwise contained). ¹

Plain-English interpretation

AC-23 requires a defensible answer to three questions:

• What does unauthorized data mining look like here? Define it in operational terms: unusual query volume, broad table scans, repeated searches for sensitive attributes, systematic enumeration, large exports, or cross-tenant pulls.
• How will we detect it? You need telemetry and analytics that surface mining patterns across the main access paths.
• How will we protect against it? Detection without a protective control is incomplete. Protection can mean prevention (block/throttle), containment (reduce permissions, segment access), and response (incident workflow). ¹

Who it applies to (entity and operational context)

AC-23 applies wherever you implement NIST SP 800-53 as a control baseline, including:

• Federal information systems. ¹
• Contractor systems handling federal data, including systems operated by third parties on your behalf. ¹

Operationally, prioritize AC-23 in environments with:

• Centralized analytics platforms (data warehouses, data lakes, BI tools)
• High-value datasets (regulated data, proprietary R&D, credentials/secrets, identity data)
• Broad internal access (support, operations, engineering) and service accounts
• Externally exposed data interfaces (APIs, partner portals, export endpoints)
• Third-party ingestion, enrichment, or analytics services with direct data access

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

1) Assign ownership and define scope (system + data paths)

• Name a control owner (often Security Engineering, IAM, or Data Platform Security) and a GRC owner for evidence collection.
• Document in-scope systems and in-scope access paths: application UI, API gateway, database access, BI tools, ETL jobs, file exports, object storage access, and admin consoles.
• Identify third-party access paths (support tooling, managed services, analytics vendors) as part of the same control boundary where applicable. ¹

2) Define “unauthorized data mining” for your environment (the ODP fill-in)

Write a short standard that security, engineering, and audit can all use. Include:

• Unauthorized actors: non-privileged users, compromised accounts, insiders outside job role, third parties outside contract scope.
• Unauthorized behaviors (examples you can tune):
  • Bulk extraction inconsistent with role
  • Automated enumeration (high-frequency queries; systematic ID scanning)
  • Cross-dataset correlation outside approved analytics workspace
  • Queries for sensitive fields outside ticket/approval context
• Authorized exceptions: approved data science jobs, sanctioned reporting, legal holds, eDiscovery, incident response pulls.
• Approval mechanism for exceptions (ticket, JIT access, data access request workflow). ¹

3) Implement detection mechanisms where mining happens

Detection must be feasible across your actual tooling. Common control points:

• Identity/IAM telemetry: who accessed what, from where, using which auth method.
• Database and query telemetry: query logs, table access logs, result size indicators, long-running scans.
• API telemetry: endpoint usage, pagination patterns, error rates, token identity, IP/device signals.
• Export and egress telemetry: downloads, object storage GET/LIST patterns, file generation jobs, outbound transfers.

Turn telemetry into signals:

• Alert on unusual query volume for a user/service account relative to their baseline.
• Alert on access to unusually broad sets of records or many distinct identifiers in sequence.
• Alert on sensitive attribute access outside approved contexts.
• Alert on new automation patterns (scripts, new user agents, new IP ranges) against data endpoints.

Your auditor will care less about the exact algorithm and more about whether you can show the system detects behavior that matches your definition. ¹

4) Implement protective responses (not just alerts)

Pick protections aligned to your risk tolerance and business operations:

• Preventive: query rate limiting, API throttling, pagination caps, row-level security, deny-by-default on sensitive tables, token scopes.
• Detective + containment: automatic session termination, forced re-authentication, step-up MFA for bulk actions, temporary access suspension.
• Administrative: JIT access with expiration, break-glass controls with enhanced logging, mandatory ticket linkage for privileged pulls.

Tie protections to a runbook:

• Triage steps (confirm identity, validate business purpose, check ticket/approval)
• Containment options (disable token, rotate keys, revoke role, isolate workload)
• Escalation criteria (security incident vs HR/insider risk vs operational anomaly)
• Post-incident review requirements (tuning thresholds, closing access gaps) ¹

5) Operationalize: reviews, tuning, and coverage checks

• Establish a recurring review to confirm:
  • Logging remains enabled after platform changes
  • Alert logic still matches current data architecture
  • Known exceptions remain justified and time-bounded
  • Third-party integrations have not expanded data access

Daydream note (where it fits naturally): many teams fail AC-23 because evidence is scattered across SIEM, IAM, and data platform teams. Daydream can be the system of record that maps AC-23 to an owner, an implementation procedure, and the recurring evidence artifacts you expect to collect each cycle. ¹

Required evidence and artifacts to retain

Keep artifacts that prove definition, implementation, and operation:

Control definition (design evidence)

• AC-23 control narrative with your filled-in parameters (mechanisms + in-scope mining activities) ¹
• Data access architecture diagram (systems, interfaces, and data flows relevant to mining)
• Data classification and “sensitive datasets” register (if you have one)
• Exception/approval standard for high-volume analytics and bulk extraction

Control operation (run evidence)

• Samples of logs showing:
  • User identity + dataset/object accessed
  • Query/API activity metadata sufficient to detect mining patterns
• Alert records (SIEM tickets/cases) showing detection events and outcomes
• Runbook and incident response records for at least one exercised scenario (tabletop or live event), if available
• Access reviews for privileged analytics roles and service accounts tied to high-volume data access

Control oversight (governance evidence)

• Named control owner and RACI
• Periodic review notes, tuning changes, and sign-offs
• Third-party access reviews for tools that can extract/aggregate data

Common exam/audit questions and hangups

Expect assessors to press on these points:

• “What are your organization-defined mechanisms and activities?” If you cannot clearly state the two filled-in parameters, the control reads as incomplete. ¹
• “Show me detection in action.” They may ask for a recent alert, a test alert, or evidence that rules run against logs.
• “How do you protect, not just detect?” A queue of alerts with no containment options looks weak.
• “Where are the gaps?” If your data lake is monitored but your export endpoint is not, document compensating controls or remediation work.
• “How do third parties factor in?” If a third-party platform has direct dataset access, assessors often expect equivalent monitoring and contractual constraints.

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails AC-23	Fix
Writing a policy that bans “data mining” without defining it	Auditors need testable criteria	Define mining behaviors and exceptions in operational terms 1
Monitoring only the database, not the API/exports	Mining often occurs via APIs and bulk downloads	Instrument all major access paths and egress points
Alerts with no response path	Detection alone does not “protect”	Add rate limits, step-up auth, containment runbooks 1
Ignoring service accounts and automation	Automation can mine at scale	Apply scopes, rotation, and anomaly detection to service identities
No recurring evidence package	Control cannot be re-performed or assessed	Define a monthly/quarterly evidence bundle and store it in your GRC system 1

Enforcement context and risk implications

No public enforcement cases were provided in the supplied sources for AC-23 specifically, so this page focuses on assessment expectations under NIST SP 800-53. ¹ Practically, AC-23 failures raise breach and insider risk because mining is a common precursor to exfiltration: attackers and malicious insiders often enumerate, correlate, and stage data before removal. Treat AC-23 as a control that reduces dwell time and limits blast radius by detecting abnormal aggregation early and applying containment quickly. ²

Practical 30/60/90-day execution plan

First 30 days (define + inventory + minimum telemetry)

• Assign AC-23 owner and publish a one-page control narrative with your filled-in parameters. ¹
• Inventory in-scope datasets and data access paths, including third-party platforms.
• Confirm logging is enabled for: IAM events, data platform access, API gateway access, and export/download events.
• Draft the unauthorized mining definition and exception process, then get sign-off from Security + Data owners.

By 60 days (detection rules + runbooks + initial evidence)

• Implement initial detection rules for your top mining risks (bulk export, high-rate API enumeration, broad table scans).
• Create triage and containment runbooks; align to incident response intake.
• Run a test: simulate a mining pattern in a non-production dataset and capture evidence (alerts + ticket + response notes).
• Start an evidence folder (or Daydream control record) with a recurring checklist of what to retain each cycle. ¹

By 90 days (protection hardening + coverage confirmation)

• Add protective controls where you only had alerts: throttles, step-up auth, tighter scopes, JIT access for high-risk roles.
• Validate coverage against the original access-path inventory; document compensating controls for any gaps.
• Operationalize a recurring review cadence: alert tuning, exceptions review, third-party access review, and artifact capture.

Frequently Asked Questions

What counts as “data mining” for AC-23?

AC-23 leaves it to you to define the in-scope data mining activities and the mechanisms you will employ. Define mining as observable patterns like systematic enumeration, bulk extraction, or cross-dataset correlation that exceed a user’s authorization. ¹

Do we need a specific tool for AC-23 compliance?

The requirement is outcome-based: employ mechanisms that detect and protect against unauthorized data mining. If your current SIEM, data platform logs, and API monitoring can reliably detect patterns and trigger protective actions, that can satisfy AC-23 with good evidence. ¹

How do we show “protect” instead of just “detect”?

Document and demonstrate at least one containment or prevention path tied to a detection event, such as rate limiting, access revocation, step-up authentication, or session termination. Keep tickets or incident records showing the action taken. ¹

Does AC-23 apply to third-party analytics providers?

If a third party operates systems handling federal data or has direct access to your datasets in-scope, include that access path in your AC-23 scope. Contract terms and monitoring should support detection and protective response for that third-party channel. ¹

What evidence do auditors ask for most often?

They typically ask for the AC-23 control narrative with defined parameters, proof that logs exist for key access paths, and examples of alerts or cases that demonstrate detection and response. A mapped control owner and recurring evidence list reduces back-and-forth. ¹

We have approved data science workflows that look like “mining.” How do we avoid false positives?

Treat approved workflows as exceptions with explicit approvals, scoped access, and enhanced logging, then tune detection rules to recognize those job identities while still flagging anomalous behavior outside the approved pattern. Keep the approval artifacts and periodic exception reviews. ¹

Footnotes

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

2. NIST SP 800-53 Rev. 5