AC-23 Data mining protection: requirements and evidence

What AC-23 data mining protection asks for and why it is easy to miss

An assessor or contract clause asks about AC-23, and the team has never scoped it. The reason is structural: no SP 800-53B baseline selects AC-23 at the low, moderate or high level, or for the privacy baseline. Nothing in a standard baseline prompts a team to think about it, so the control tends to surface only when a customer questionnaire, a sector regulator or an assessor's scoping exercise asks for it. The control asks the organization to pick the data storage objects it cares about, such as database tables, records or specific fields holding sensitive information, and to employ defined techniques that detect and protect against unauthorized data mining against them. Data mining here means systematic extraction or pattern-finding across large volumes of stored data, often by someone with legitimate access who is pulling far more than their job requires.

The risk is mostly insider and bulk extraction. An authorized user, a service account or a compromised credential can run queries that return sensitive fields in volume, and each individual query may look routine. Two organization-defined parameters, AC-23_ODP[01] and AC-23_ODP[02] in SP 800-53A, make the control specific to the organization. Your team must decide which data storage objects are in scope and which detection and protection techniques apply to them, such as alerting on atypical queries or accesses and limiting bulk retrieval. Confirm both parameters with the control owner before any assessment, because an assessor will test the mechanisms against whatever values you recorded.

The work is hard for two reasons. First, defining the objects and techniques requires a data inventory that many organizations do not maintain at field level, and it requires agreement between data owners, application owners and security staff on what counts as atypical. Second, proving that the mechanisms run is harder than deploying them. SP 800-53A expects examination of audit logs and notifications of atypical queries, interviews with the people who operate detection, and testing of the mechanisms themselves, so the evidence must show alerts actually firing and being handled. Ask your assessor early which evidence they will accept for the examine, interview and test methods, and plan the logging needed to support them.

Which data stores and teams fall under AC-23 once you select it

AC-23 only works once the organization names the data storage objects it protects and the people and systems that reach them. Selecting the control is a scoping decision first: it changes which databases, fields and query paths must produce detection and protection evidence.

Defining the data storage objects

AC-23 requires the organization to define which data storage objects are covered, such as specific database tables, record sets or sensitive fields. Scope them by data classification, not by server. A broad definition means more detection rules and more evidence to keep, while a narrow one may leave sensitive fields outside the control. Write the list in the system security plan so an assessor can trace each object to its monitoring.

Application query paths

Applications that read protected records are the most predictable source of bulk access. Map which services, APIs and batch jobs query each defined object and how often they run. Automated jobs produce large, expected query volumes, so detection rules must separate them from atypical patterns. Confirm that each application's access path is logged at the database or proxy layer.

Analyst and administrator access

Analysts, database administrators and support staff often run ad hoc queries that fall outside application logic. These users create the highest-risk mining patterns, including large exports and repeated field-level reads. Identify which named roles can query protected objects directly, and record how their queries reach the audit trail. Administrators also need coverage, since they can alter logging itself.

Reporting tools and data extracts

Business intelligence platforms, reporting servers and scheduled exports read data in bulk and may cache it outside the original store. Inventory each reporting connection, its service account and any extract destinations. Decide whether detection applies at the source database or at the reporting layer, because a gap between the two can hide data leaving the organization.

Third-party integrations

Vendors, data processors and integration partners that connect to protected stores extend the boundary of AC-23. Each integration needs a documented account, a defined access scope and logs that the organization can review. Confirm contractually who receives alerts about atypical queries from a partner and how quickly partner access can be suspended.

Tailored baseline or overlay

AC-23 is not selected in any SP 800-53B baseline, so it enters a system only by tailoring a baseline or through an overlay. The decision determines where the requirement is documented, who approves it and whether it applies to one system or to a family of systems. Record the chosen path, the two organization-defined parameters and the rationale in the security plan before collecting evidence.

How an assessor tests AC-23 under SP 800-53A

This table breaks down the single SP 800-53A determination statement for AC-23 and the examine, interview and test methods that support it, with the objects each method uses. Read it as a checklist of what to prepare before an assessor arrives, and note that the common findings often trace back to parameters the organization never defined.

Assessment method	Assessment objects	What the assessor asks for	Common findings
Examine	System audit logs, notifications of atypical database queries or accesses, documentation or reports of the insider threat program	Records showing the defined data storage objects, the detection and protection techniques in use, and alerts raised for unusual queries or bulk access over a sample period	Alert rules exist but no records show anyone reviewed or acted on the notifications
Interview	Organizational personnel responsible for implementing data mining detection and prevention for data storage objects	How staff choose which database records and fields are covered, how alerts reach them, and what they do when a pattern looks like data mining	Owners cannot name the protected objects or describe the response steps
Test	Mechanisms implementing data mining prevention and detection	Evidence that the mechanisms fire on a controlled test, such as a bulk query against a protected table, and that the resulting alert is recorded	Detection is configured on paper but never triggered in testing, or thresholds are too broad to flag bulk extraction
Determination statement	The two organization-defined parameters, AC-23_ODP[01] and AC-23_ODP[02]	Documented values for the data storage objects and the techniques, approved by the control owner and traceable to the system security plan	Parameters left blank or set to generic wording, so the assessor cannot tell what was meant to be detected

Implementing AC-23 detection and protection for your data stores

This sequence turns AC-23 from a policy statement into working detection and protection on the data stores that matter, with each step producing a record an assessor can examine and test.

Define the data storage objects in scope
The control applies to defined data storage objects, so the first step is a written inventory of the database records, tables, fields and document stores that hold data worth protecting from bulk extraction. The data owner and the security team agree the list, and each object is tied to the system it belongs to. The output is a scoped inventory that names each object, its owner and its system boundary. You know the step is done when every object an assessor could ask about appears on the list with an owner.
Set the two organization-defined parameters
AC-23 has two organization-defined parameters that the organization assigns when it implements the control, and the assessment procedure expects them to be stated. The security owner chooses which data storage objects the techniques cover and which detection and protection techniques apply to them, then records those values in the system security plan. The output is a parameter record that matches the scoped inventory. The step is complete when an assessor reading the plan can see exactly what was chosen and why.
Choose detection and protection techniques
Select the detection techniques, such as monitoring query volume, unusual access patterns and atypical bulk reads, and the protection techniques, such as restricting who can run broad queries, applying row or field limits and rate limits on exports. Security engineering and the database owners decide together, weighing operational impact on legitimate reporting and analytics. The output is a documented technique set linked to each object from the previous step. The step is done when every object has at least one detection and one protection technique recorded against it.
Instrument the data stores to produce logs
Detection depends on evidence, so the data stores and their access paths must write logs that show who queried what, when and how much was returned. Platform engineering enables query and access logging on the databases and applications, and forwards those logs to a central collector. The output is a log source list with confirmed sample events. Confirm the capability and log fields with each vendor or in your own environment, because logging depth varies by product.
Route alerts to a reviewer with a response procedure
Detection without review does not satisfy the control in practice, so matches must reach a named reviewer. Configure detection rules in a self-hosted SIEM or analytics platform to raise alerts on the chosen patterns, send them to a monitored channel, and link each alert type to a written response procedure that covers triage, escalation and evidence capture. Open-source options such as OpenSearch Security Analytics, which runs detectors against ingested logs using Sigma rules and sends alerts to channels such as Slack or email, or Wazuh, which writes matching alerts for review in its dashboard, can carry this step. The output is a tested alert path with a documented procedure.
Test the mechanisms against defined scenarios
Assessors test whether the mechanisms work, so run controlled test cases against the data stores. Using a non-production copy or an approved test account, simulate bulk extraction, unusual query patterns and access outside normal roles, then confirm that the expected alerts fire and that protection limits block or slow the activity. The output is a test plan, the raw results and a list of gaps with owners. The step is done when each technique has a recorded pass or a tracked remediation.
Document results and maintain the evidence
Close the loop by recording the implementation and test results in the documents an assessor will examine: the system security plan entries, the parameter record, the detection rule inventory, sample alerts, the response procedure, test reports and any insider threat program documentation the organization references. The organization owns the control and signs off these records. An implementation partner can prepare the packages, but only an independent assessor issues an assessment result. The output is an assessment-ready evidence set that is reviewed on a schedule the organization sets.

Open-source tools that can produce AC-23 detection evidence

AC-23 asks for detection and protection against data mining on defined data storage objects, so the evidence has to come from the systems that hold that data. The four tools below each record a different layer of access activity, from log-based detection to audit trails of secret access. None of them decides on its own whether a pattern of queries is data mining, so each should be tested against your own data stores before it is named in a control narrative.

OpenSearch Security Analytics

Security Analytics runs detectors that match ingested logs from hosts, network devices and cloud services against prepackaged or custom Sigma rules. Matches are stored as findings with the rule, log type and severity, and alerts can go to Slack or email. The correlation engine links findings across log types in a correlation graph, which can show a sequence of unusual queries followed by bulk reads. Confirm that your database and application logs reach the cluster in a form the Sigma rules can match, and write your own rules for the object types you define in AC-23.

Wazuh ruleset and alerts

Wazuh decodes collected logs and compares each event against a ruleset of over 3,000 built-in rules and decoders, plus any custom rules you add. Matching events are written to alerts.log and alerts.json and forwarded to the Wazuh indexer for review in the dashboard. Each alert can be mapped to MITRE ATT&CK techniques, which helps assessors trace a detection to a threat category. Built-in rules were not written for your data model, so you must test that rules fire on queries against your own database fields before relying on them.

Nextcloud admin_audit logging

For organizations that store regulated records in Nextcloud, the admin_audit app writes additional event information to audit.log in the data directory, or to a path set with logfile_audit. This gives a record of administrative and file-related events that can support investigation of bulk access. The app does not profile query volume or flag mining patterns on its own, so detection logic must run in a separate system. Confirm that the events you need for AC-23 are captured at the verbosity you configure, and that the log file is protected from modification. Nextcloud is licensed under AGPL-3.0-only, so review obligations if you modify and distribute it.

OpenBao audit device records

OpenBao audit devices keep a detailed JSON log of every API request and response, including errors, which lets you show who requested which secret or credential and when. Most sensitive values are hashed with HMAC-SHA256, so the log itself does not expose the data it records. This is useful evidence that access to database credentials is logged, but it does not show what a user did with data after retrieving it. Confirm that audit devices are enabled and that the log is forwarded to a store that your detection tooling can query. OpenBao is licensed under MPL-2.0, which is a file-level copyleft license.

What evidence passes an AC-23 assessment

An assessor testing AC-23 Data mining protection looks for proof that the organization decided what it protects and then built and ran detection and protection against it. The first artifact is a written definition of the data storage objects in scope, such as specific database tables, record sets or sensitive fields, together with the two organization-defined parameter values that SP 800-53A labels AC-23_ODP[01] and AC-23_ODP[02]. Keep these as a signed, dated document in the system security plan or the access control procedures, and make sure the values match what the detection rules and database settings actually cover. A mismatch between the written scope and the configured scope is one of the faster ways to fail the examine step.

Next, the assessor will examine the configuration of detection rules and protection settings. For a self-hosted stack this usually means exported detector or rule definitions (for example, Sigma rules in OpenSearch Security Analytics or custom rules in Wazuh), database audit or query-logging settings, and the access restrictions applied to the in-scope objects. Samples of the audit logs and alerts then show the mechanism ran: entries from the Wazuh alerts.json output or OpenSearch findings, Nextcloud audit.log entries where that app holds the data, and OpenBao audit device records for secrets access. Pair each sample with the rule that produced it. Records of alert review and response, such as triage tickets showing who looked at an atypical query and what was decided, are often the artifact that separates a configured control from an operating one. Where the organization runs an insider threat program, its documentation and reports support the interview step, since the assessor will ask the personnel responsible how detection is handled. Finally, keep test results for the mechanisms, such as a dated test where a bulk export from an in-scope object raises an alert.

To stay ready between assessments, schedule rule reviews, record their dates and approvers, and take dated exports of rule sets, settings and alert samples into the evidence repository rather than relying on live screenshots. Confirm the retention period for these logs with your own policy and the platform documentation. Some of this material can be reused: PM-12 (insider threat program) and PT-2 (authority to process personally identifiable information) are listed as related controls, so an insider threat program document or PII processing record may serve both. That reuse has limits, though, because AC-23 requires evidence of technical detection and protection against data mining, which a policy document alone does not provide. Ask your assessor early which of these artifacts they will accept for each control.

What meeting AC-23 costs in money and effort

This table lists the cost components of building and evidencing AC-23 data mining protection, who is paid for each, whether it is one-time or recurring, and what to ask for in a quote. NIST does not estimate compliance costs, so no figures appear here; use the rows to build a scope and to compare written quotes line by line.

Cost component	One-time or recurring, and who is paid	What drives it up or down	What to ask for in a quote
Tooling and licenses	Recurring infrastructure cost. The named open-source tools (OpenSearch Security Analytics, Wazuh, Nextcloud, OpenBao) carry no license fee for the software itself, so spend goes to hosting, storage and support.	Number of hosts and data stores in scope, cluster sizing, and whether you use a managed service or self-host. Confirm current licensing terms with each vendor.	A bill of materials listing each component, its version, hosting model and any paid add-ons or support tiers.
Engineering time to define objects and tune detections	One-time for initial design, then recurring for tuning. Paid to your staff or to an implementation partner under a fixed-scope agreement.	How many AC-23 data storage objects you define (for example, customer tables or sensitive fields), how many query patterns count as atypical, and how noisy the first detections are.	A list of defined data storage objects, the detection rules to be built, the tuning window included, and the acceptance criteria for each rule.
Log storage and retention	Recurring. Paid to your cloud provider or data center for storage of database query and access logs, plus the indexer capacity that searches them.	Query volume against sensitive stores, retention period set by your policy, and whether logs are kept hot or archived. Set retention with your legal and records owners.	Expected daily log volume per source, retention periods per log type, and storage tiers with their recurring charges.
Evidence upkeep	Recurring. Paid to your staff or partner to keep detection configuration, alert records, insider threat documentation and reviews current.	Frequency of rule changes, number of personnel who review alerts, and how often data stores or schemas change.	The evidence list per review cycle, the owner of each artifact and the change-control steps for rule updates.
External testing or review	Recurring or periodic. Paid to a security testing firm or reviewer to test whether data mining detections fire on realistic query patterns.	Scope of the database estate, number of test scenarios and whether testing is repeated after major schema changes.	Test objectives, scenarios covered, the deliverable format and whether retesting after fixes is included.
Auditor sampling and assessment	Recurring with each assessment cycle. Paid to the independent assessor, who tests the mechanisms and the alert records. Only the assessor issues findings.	Number of systems and data stores sampled, quality of evidence on hand, and how many detections the assessor must trace end to end.	A written statement of the assessment scope, sample method and evidence requests before fieldwork begins.
Organization-defined parameters and policy work	One-time to set the two organization-defined parameters, then recurring when they are reviewed. Paid to your risk, legal and security owners.	Number of stakeholders who must agree on which techniques and objects apply, and how often the risk decision is revisited.	Confirmation of who approves the parameter values and the review cycle written into the system security plan.
Baseline tailoring decision	One-time. AC-23 is not in any SP 800-53B baseline, so adding it is a tailoring decision that consumes review time from your authorizing official or risk owner.	Whether the system is already in scope for a regulator or contract that requires data mining protection, and how many baselines or overlays must be updated.	A documented tailoring rationale and the list of systems where AC-23 is added, reviewed by the authorizing official.

Who does what for AC-23: your team, a partner and the auditor

Your organization owns AC-23 in full. The control asks you to employ defined techniques against defined data storage objects to detect and protect against unauthorized data mining, so the decisions about what counts as a sensitive store, what counts as suspicious querying and how the risk is accepted belong to you. No partner or auditor can make those calls on your behalf.

Data store definitions: Name the database records and fields in scope, and record why each one is covered.
Parameter values: Set the two organization-defined parameters (AC-23_ODP[01] and AC-23_ODP[02]) and document the rationale in your system security documentation.
Alert review: Assign named people to review alerts about atypical database queries or accesses, with a defined response path and records of each decision.
Risk acceptance: Decide which residual risk is accepted, by whom, and for how long, and keep that approval on file.
Insider threat linkage: Confirm how data mining signals feed your insider threat program, since assessors may examine its documentation.

Before any assessment, confirm that every one of these decisions has an owner and a dated record.

Common questions about AC-23 cost, effort and scope

Is AC-23 data mining protection required by default under NIST SP 800-53?

No. AC-23 is not selected in any SP 800-53B baseline, so it does not apply to a low, moderate or high system or to the privacy baseline unless someone selects it. It usually enters scope in one of three ways: the organization tailors its baseline and adds the control, an overlay selects it, or a contract, agency requirement or internal risk decision calls for it. The first step is to read the governing requirement and the system security plan to see whether AC-23 is listed. If it is not, the control is outside the assessed set, and the team should document that decision rather than assume it. If it is selected, the organization must also set the two organization-defined parameters that define the data storage objects and the techniques in use.

How much effort does AC-23 take to implement and assess?

Effort depends on how many data storage objects fall under the control and how many detection and protection techniques the organization defines. AC-23 has one determination statement in SP 800-53A, but meeting it means choosing sensible objects, such as sensitive database tables or fields, and then configuring monitoring that can recognize unusual query or access patterns against them. The largest effort is usually the design work: identifying which records are worth protecting, deciding what counts as atypical behavior, and connecting logs to a review process with an accountable owner. Effort rises with the number of database platforms, the volume of queries, and the number of insider threat or analytics tools already in place.

Can our own team implement AC-23 without an outside partner?

Often yes, if the team already runs database auditing, log management and access reviews, and if it has a clear owner for insider threat monitoring. The practical gaps tend to be defining the two parameters with business owners, writing the procedure that explains how alerts are triaged, and producing evidence that an assessor can reproduce. An outside implementation partner can help with the technical setup and documentation, but the organization still owns the control, its parameters and its decisions. Only an independent assessor can issue an assessment result, so the team should plan for that separately.

How long does it take to implement AC-23?

Timelines depend on scope, and NIST does not set implementation timelines for SP 800-53 controls. Under FISMA, timing for federal systems is left to OMB Circular A-130, so a contract or internal program sets its own schedule. The main variables are the number of data storage objects in scope, the maturity of existing logging, the complexity of the database estate, and how long the business takes to agree on parameter values. A fixed-scope engagement starts with a written scope and timeline agreed before work begins, so ask any provider to state the phases, dependencies and deliverables in that document.

What does the organization need to provide for AC-23 work?

The organization must supply the decisions and the access that make the control real. It should name the data storage objects, such as the customer records or regulated fields, and confirm the two organization-defined parameters. It must provide read access to database audit logs, administrative access to the systems where detection rules run, and a named owner who receives alerts. Business and privacy stakeholders need to review which queries count as atypical. Expect to provide the existing system security plan, insider threat program documents if they exist, and access review records, because assessors will examine them alongside the control's mechanisms.

Do open-source tools remove the need for a partner on AC-23?

Open-source tools can produce much of the evidence, but they do not decide the control. OpenSearch Security Analytics (Apache-2.0) can run detectors against ingested logs with Sigma rules and record findings with severity. Wazuh (GPL-2.0-only) can decode logs, match them against its ruleset and write alerts for review. OpenBao (MPL-2.0) audit devices keep detailed JSON logs of API requests, which can support evidence for secrets access. Each tool needs data sources, tuning, retention and a documented review process, and you must confirm whether a given database or platform log type is supported. Whether a partner is needed depends on your internal capacity, not on the tools alone.

What drives the cost of AC-23 up or down?

Costs fall into one-time work and recurring work. One-time costs include scoping the data storage objects, defining parameters, configuring detection, and writing procedures and evidence. Recurring costs include reviewing alerts, tuning rules as query patterns change, keeping logs retained, and refreshing the analysis when systems change. Costs rise with more databases, more sensitive fields, more log sources and stricter response expectations. They fall when data classification is already mature and logging is centralized. When requesting a quote, ask for the written scope, the list of assumed systems, which costs are one-time and which recur, and who is responsible for each deliverable and for supplying access.

How DeployOpen scopes and prepares AC-23 evidence

DeployOpen approaches AC-23 Data mining protection as a fixed-scope piece of work inside your own infrastructure. We prepare the detection and protection mechanisms, the records they produce and the documentation an assessor needs, while your organization owns the control decisions and an independent assessor reaches the conclusion.

How we scope

Agree in writing which data storage objects, such as specific database tables or sensitive fields, fall under AC-23.
Record the two organization-defined parameters, covering the techniques and the storage objects, as decisions your organization approves.
Confirm whether AC-23 is added by baseline tailoring or an overlay, since no SP 800-53B baseline selects it.

How we build

Configure log ingestion from database, application and access layers so that query and access events reach the detection platform.
Deploy detection rules for atypical queries or bulk access, such as Sigma rules in OpenSearch Security Analytics or custom rules in Wazuh.
Test each detection path with controlled, labeled queries to show that alerts fire and that the protection mechanism behaves as documented.

How we hand over

Deliver a mapping of AC-23 assessment objects to the audit logs, alert records, configuration files and interview roles that satisfy them.
Provide runbooks for triaging data mining alerts, including who receives them and how insider threat referrals are documented.
Hand over the test results and configuration baseline so your assessor can examine and reproduce the evidence without DeployOpen involvement.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Retainers can cover rule tuning as data volumes and query patterns change over time.
Your organization decides whether to engage an independent assessor, which issues any report or certification, and DeployOpen prepares the evidence for that review.

AC-23 Data mining protection