SI.L2-3.14.7 Identify unauthorized use: evidence

What SI.L2-3.14.7 requires for identifying unauthorized use

If your organization holds CUI, an assessor will expect you to show that you can tell when a user, administrator or technician acts outside the role they were given. SI.L2-3.14.7 asks for exactly that: a defined standard of authorized use for your systems and a working way to identify unauthorized use. The requirement has two parts that must both be true. First, you must define what authorized use looks like, by role. Second, you must have a monitoring capability that can detect when activity departs from that definition. Assessors test each part separately, so a strong monitoring stack cannot compensate for a missing acceptable use definition, and a good policy cannot compensate for logs that nobody reviews.

The hard part is usually the baseline. Many contractors have an acceptable use policy that says little about what a technician may do on a server, what an administrator may change, or which tasks belong to a standard user. Without that role-level definition, there is nothing to measure activity against. The second common gap is the opposite: logs are enabled, retained and never read. Assessors ask who reviews them, how often, what they look for, and what happened the last time something was flagged. Confirm with your assessor which artifacts they expect for each objective, since the assessment objectives in NIST SP 800-171A and the CMMC Assessment Guide shape what they will sample.

Scoring makes this decision concrete. SI.L2-3.14.7 is a 3-point requirement that must be MET. If it is NOT MET, 3 points come off the maximum score of 110, and because the requirement is worth more than 1 point, it cannot be placed on a POA&M. Plan this one as a gating item rather than a later fix. Start by writing the role definitions for user, administrator and technician, then confirm that your logging and alerting cover the systems those roles touch. Evidence must be in final form when the assessor reviews it, so a draft policy or an undated review log will not count.

Which systems, roles and logs fall under identifying unauthorized use

Before any monitoring tool is configured, the organization has to decide what sits inside the assessment boundary, who counts as an authorized user, and which records prove that unauthorized use would be noticed. Each decision below changes the evidence an assessor will ask to see for SI.L2-3.14.7, and each one is easier to settle in writing before the logs start flowing.

CUI systems and their protection assets

Start by listing every system that processes, stores or transmits CUI, then add the security protection assets that watch over them, such as firewalls, identity providers, endpoint agents and jump hosts. Monitoring that only covers the CUI application server leaves the path into it unobserved. Record each asset in the system security plan so the assessor can trace the monitored scope back to the CUI boundary. Ask the team to confirm that nothing outside this list handles CUI through file shares, email or exports.

Written authorized use by role

The assessor will look for an acceptable use policy that states what a user, administrator and technician may do on the system, and what each role may not do. Without that baseline, an alert about an administrator changing settings cannot be judged as authorized or unauthorized. Keep the definitions short, tie each role to the accounts and privileges the identity system actually grants, and have the policy approved and signed off as final before the assessment.

Log sources that feed monitoring

Decide which logs reach the monitoring platform: operating system and endpoint logs from hosts, authentication and configuration events from network devices, audit trails from cloud services, and application logs such as admin actions in collaboration or document tools. Each source that is missing is a blind spot an assessor can name. Document the source, the log type and the collection method for each one, and confirm that clocks are synchronized so events from different sources can be correlated.

Detection rules tied to role definitions

Collecting logs does not identify unauthorized use on its own. The rules that compare events against the authorized use policy do that work, such as an administrator account signing in from an unregistered location or a technician account reading data outside its assigned scope. Map each rule to a role definition so the alert can be explained in the assessment. Review the rule set when roles change, and keep the mapping as evidence.

Third-party monitoring and cloud tenants

When a managed security provider or a cloud service runs part of the monitoring, decide where that provider sits relative to the assessment boundary. If the provider stores or can access CUI or its logs, it is in scope and its controls need evidence. Confirm in writing which logs the provider holds, how long they are kept, who can read them and how the organization gets them back for review. Cloud tenants that hold CUI follow the same rule, and the agreement should say so.

Ownership of log review

Name the person or team who reviews alerts and logs, the schedule for that review and the record kept when an alert is closed. Assessors test whether monitoring is operated, not just installed, so a dashboard that nobody reviews will not show that unauthorized use was identified. Write the review steps into the procedures for the security team, and link any alert that leads to an incident to the incident response process.

How an assessor tests unauthorized use monitoring

This table compares the two NIST SP 800-171A assessment objectives for SI.L2-3.14.7 with the assessment objects an assessor examines for each. Read each row as a test the assessor runs, the evidence they ask for and the gap that most often causes a requirement to fail. A requirement is MET only when every applicable objective is satisfied with final evidence.

Assessment element	How the assessor tests it	Evidence requested	Common finding
Objective: define authorized use	Reads the acceptable use policy and checks that it describes permitted activity for each role, such as user, administrator and technician, and that the organization's system configuration reflects those roles.	Approved acceptable use policy with version and approval date, role definitions, and account listings mapped to those roles.	Policy exists but does not distinguish roles, or administrators have no documented permitted activity.
Objective: identify unauthorized use	Tests whether the organization detects activity that falls outside the defined use, by reviewing alert rules and sampling events against the policy.	Monitoring rules or detectors, sample alerts with disposition, and records showing review and follow-up.	Logs are collected but no rule or review process flags out-of-role activity.
Assessment object: continuous monitoring strategy	Reads the strategy to confirm it covers what is monitored, how often, who reviews results and how gaps are escalated.	Written monitoring strategy tied to the system security plan, with owners and review cadence.	Strategy is generic, not linked to the system boundary, or was not updated after system changes.
Assessment object: monitoring tools and techniques documentation	Checks that documented tools, such as log management, intrusion detection or host agents, match what is actually deployed and configured.	Tool inventory, configuration exports, rule sets and version records.	Documentation names a tool that is not running, or describes capabilities the configuration does not enable.
Assessment object: deployment locations of monitoring devices	Compares the documented placement of sensors and log sources with the system boundary and network diagrams to find unmonitored segments.	Network and data flow diagrams marked with monitoring points, list of log sources per system.	Cloud workloads, remote endpoints or administrator workstations are outside the documented monitoring scope.
Test of monitoring process	Walks through the process from event to review to ticket, checking that roles and steps in the documentation are followed in practice.	Review logs, shift or review schedules, ticket samples showing triage and closure.	Reviews are documented on paper but not performed, or no one is named to review alerts.
Test of monitoring capability	Generates or observes a controlled out-of-role event and checks whether the monitoring detects and records it.	Test records showing the event, the resulting alert and the reviewer's action, typically set up by the organization.	Alerts fire in a lab but not in production, or log sources silently stop sending events.

How to implement unauthorized use identification step by step

This sequence turns SI.L2-3.14.7 into working evidence: a documented definition of authorized use by role, a source inventory for each in-scope system, detection that flags role violations, and a review record showing what happened to each alert.

Define authorized use by role
Write an acceptable use policy that describes what each role may do on in-scope systems, such as user, administrator and technician, and what counts as a violation for each role. Name the systems the policy covers and have an accountable executive approve it. The step is done when the signed policy exists, is version controlled, and every in-scope role has a stated boundary that a monitoring rule could test against.
Inventory log sources for each system
List every in-scope system and the log sources it produces, including operating systems, identity providers, applications, network devices and cloud services. Record where each log is stored, who can read it, and how long it is kept. The output is a source inventory that maps each system to its logs. Assessors will compare this list against the system security plan and the system boundary, so gaps here show up later as untested systems.
Set up collection and detection
Forward logs from the inventory to a central point and choose the detection method: manual review of logs, an intrusion detection system, a SIEM, or a combination. Open-source options include Wazuh, which compares events against a ruleset and writes alerts to files, and OpenSearch Security Analytics, which runs detectors against ingested logs. Confirm each platform's current capabilities in your environment before committing. The step is complete when test events from each source arrive and appear in the detection tool.
Write and tune role violation rules
Translate the role definitions from step one into detection rules, such as an administrative action performed by an account without an administrator role, or access to CUI repositories outside a role's permitted hours or systems. Test each rule with known-good and known-bad events, then adjust thresholds to cut false positives. Keep the rule set under change control and record who changed each rule and why. The output is a versioned rule set with test results attached.
Run the review cadence and record dispositions
Assign analysts to review alerts and log summaries on a schedule the organization defines in its procedures. For each alert, record a disposition: confirmed unauthorized use, authorized activity, or false positive, with the reviewer, the date and the follow-up taken. Confirmed cases feed the incident response process. The step is done when a sample of alerts shows a complete trail from event to disposition, because assessors test whether monitoring actually operates, not only whether tools exist.

Evidence that passes for unauthorized use monitoring

An assessor testing SI.L2-3.14.7 looks for two things: a documented definition of authorized use and proof that unauthorized use is actually detected and handled. The six artifacts below connect those two halves, and each one must be final, dated and traceable to the system it describes before the assessment starts.

Signed acceptable use policy by role

The acceptable use policy is the first objective of 3.14.7: it defines what authorized use looks like for each role, such as user, administrator and technician. Confirm that every role in your system security plan appears in the policy, that each role has its permitted actions and prohibited actions written out, and that staff have signed the current version. An unsigned or unversioned policy weakens every other artifact, because the monitoring rules are only as good as the definition they test against.

Monitoring strategy and tool documentation

This document describes how system monitoring works: what is monitored, which tools perform it, how alerts are routed and who reviews them. Assessors use it as the reference point for the monitoring tests, so it must match what the tools actually do in production. Check that tool versions, log sources and alert paths in the document are current, and that the approval date and owner are recorded. A strategy that names a tool you no longer run will fail on its own.

Log source inventory with device locations

The inventory lists every host, network device, cloud service and application that sends logs to the monitoring platform, along with where each one sits in the environment. The assessment objectives expect evidence of where monitoring devices are deployed, so the inventory should show coverage across the boundary and internal segments. Reconcile it against the asset inventory each quarter so that new systems are added and retired ones removed. Gaps in this list are the most common reason monitoring evidence looks incomplete.

Detection rules with change history

Detection rules define what counts as unauthorized use, such as logins outside approved hours, privilege changes by non-administrators or access to restricted data. Keep the rule set under version control, with a record of who changed each rule, when, and why. Tools such as OpenSearch Security Analytics match ingested logs against Sigma rules, and Wazuh compares events against its ruleset plus custom rules, so the exported rule files and their history are the evidence. Confirm that rules trace back to the acceptable use definitions in the policy.

Alert samples with triage and closure

Samples of real alerts show the monitoring process working from detection to disposition. For each sample, keep the alert, the triage notes, the decision (confirmed unauthorized use, false positive or tuned rule) and the closure record with the person who closed it. Assessors test whether alerts are identified and acted on, so an alert log with no closure entries shows a gap. Include at least one case where a rule was tuned after a false positive, since it shows the rule set is maintained rather than left alone.

Periodic review logs

Periodic review logs show that someone examines audit and monitoring data on a schedule and records the result. Reviews should cover administrator activity, failed and unusual logins, and changes to monitoring configuration itself. Each entry needs a date, the reviewer, the scope reviewed and any findings. Confirm the review frequency in your own documented process, since the assessment checks that the schedule was followed. Missed review cycles are easier to explain when the log records the reason and the catch-up review.

What meeting unauthorized use monitoring costs

This table breaks down the cost components of meeting SI.L2-3.14.7 by who is paid, whether each cost is one-time or recurring, and what pushes it up or down. Use it to structure a quote request so that every component is priced separately. The main takeaway is that licence spend is only one part of the cost, and staff time for defining roles, tuning rules and reviewing alerts usually makes up most of the effort.

Cost component	One-time or recurring	What drives it up	How to keep it down
Monitoring tooling or licenses	Recurring for commercial SIEM subscriptions, one-time for setup	Number of log sources, cloud footprint, data retention and ingest volume	Self-hosted open-source tools such as OpenSearch Security Analytics or Wazuh remove most license spend, but infrastructure and support remain
Engineering time to define roles and tune rules	One-time, with periodic revisits	Number of user roles, number of distinct systems and custom log formats	Document the acceptable use policy by role first, then write rules against it so tuning is limited to real gaps
Analyst time for alert review	Recurring	Alert volume, staffing model (in-house, shared or outsourced), hours of coverage	Tune noisy detectors, route alerts to defined owners and record the review outcome for each alert
Log source onboarding and integration	One-time per source, plus recurring when systems change	Count of hosts, network devices, cloud services and applications that must be monitored	Prioritize systems that hold CUI or administer the boundary, and confirm the monitoring location list against the system security plan
Evidence upkeep	Recurring	Frequency of evidence collection, number of systems in scope, and how often roles change	Automate exports of rule sets, alert records and review logs into a single evidence location with dates
External testing or review	Recurring or periodic, scoped per engagement	Number of systems tested and whether detection is tested with simulated attacks	Agree the scope in writing before work starts, and ask whether the quote covers a review of rules as well as a test
Assessor sampling and review	Set by the assessor, recurring at each assessment	Number of monitoring records the assessor samples and the completeness of final-form evidence	Keep final, dated records of role definitions and reviews so samples can be produced without rework

Open-source tools that produce unauthorized use evidence

SI.L2-3.14.7 is met with two things: a written definition of authorized use by role and a working way to spot departures from it. The four tools below each produce a different kind of record, from rule-matched findings to application audit trails, and an assessor will expect you to show how those records are reviewed, not just that they exist.

OpenSearch Security Analytics

Security Analytics (Apache-2.0) runs detectors that match ingested logs from hosts, network devices and cloud services against prepackaged or custom Sigma rules. Each match becomes a finding with its rule, log type and severity, and alerts can go to channels such as Slack or email. The correlation engine links findings across log types in a correlation graph, which helps show a sequence of unauthorized activity rather than isolated events. Confirm that your log sources are supported, that the rule set covers the roles you defined, and that someone owns triage of the findings.

Wazuh alerts and ATT&CK mapping

Wazuh (GPL-2.0-only) decodes collected logs and compares each event against a ruleset of over 3,000 built-in rules and decoders, plus any custom rules you write. Matching events are written to alerts.log and alerts.json and forwarded to the Wazuh indexer for review in the dashboard. Alerts are mapped to MITRE ATT&CK, which helps you explain to an assessor which techniques your monitoring covers. Keep the rule set under change control, because an assessor will ask who approved each rule and when it was tuned. Confirm that the GPL-2.0-only terms fit how you distribute or modify the software.

Nextcloud admin_audit logging

The admin_audit app in Nextcloud (AGPL-3.0-only) records additional event information to audit.log in the data directory, or to a path set with logfile_audit. This gives you a record of administrative and user actions on file-sharing and collaboration data, which is where unauthorized use often shows up. Decide where the log is written, who can read it, and whether it is forwarded to a central collector, because a log that sits on the same host it describes is weaker evidence. The AGPL-3.0-only license applies to the server software, so review its obligations if you modify and offer it to others over a network.

OpenBao audit devices

OpenBao (MPL-2.0) audit devices write a detailed JSON log of every API request and response, including errors, with most sensitive values hashed using HMAC-SHA256. For unauthorized use, this log answers who requested which secret or policy and when, including failed attempts. Hashing means you can correlate events without storing secret values in clear text, but you must confirm which fields are hashed in your version and that the audit device cannot be disabled by the users it monitors. Plan where the JSON output is shipped and retained. The MPL-2.0 license is file-level copyleft, so confirm what it requires for any modifications you make.

Who owns the monitoring, who builds it and who assesses it

Your organization owns the control. The assessment looks for a defined standard for authorized use and evidence that someone acts on what monitoring finds, and neither can be delegated to a vendor. Your team writes the acceptable use policy, defines authorized use for each role such as user, administrator and technician, approves which log sources are in scope, and decides how alerts are dispositioned.

Policy and role definitions: Authorized activities for each role, approved by a named owner and reviewed on a schedule you set.
Log source scope: Which systems, identity services, endpoints and cloud accounts feed monitoring, recorded in the system security plan.
Alert disposition: Who triages alerts, what counts as unauthorized, when an event becomes an incident, and how false positives are closed with a reason.
Sign-off and records: Periodic review of alert trends and rule changes, with dated approvals that show the monitoring is in use.
Personnel: Staff with enough knowledge of the system to judge whether activity is authorized.

Before any assessment, confirm that the policy, role definitions and disposition records exist in final form, because drafts do not count toward a MET result.

Where unauthorized use monitoring usually fails an assessment

Assessors test SI.L2-3.14.7 by checking two things: whether the organization defined authorized use, and whether it can show it identified unauthorized use. The gaps below usually break one or both, and most of them can be closed with written definitions, tuned detections and retained records before the assessment starts.

No written definition of authorized use

Monitoring has nothing to measure against if the organization never defined what authorized use looks like for each role. Write an acceptable use policy that separates user, administrator and technician activity, and list the systems, data and actions each role may perform. Confirm that the policy is approved, dated and distributed, because the first objective of the requirement depends on it.

Logs collected but never reviewed

Many environments forward logs to a central store and never look at them. An assessor will ask who reviews the logs, how often, and what a reviewer does when something looks wrong. Assign a named owner, set a review cadence, and keep dated review records or ticket trails that show the review happened. Automated alerts count only when someone acts on them.

Detection rules never tuned to the environment

Default rulesets flag generic activity and miss the unauthorized use that matters for your systems, such as an administrator account logging in outside its usual hours. Review the rules against your documented roles, suppress known benign noise with a recorded reason, and add custom rules for your critical systems. Keep the change history so the assessor can see the rules evolved with the environment.

Monitoring that skips cloud and remote paths

Monitoring often covers on-premises servers while cloud consoles, SaaS applications and remote access through VPN or virtual desktops go unobserved. Map every path a user or administrator can take into the system boundary, then confirm each one produces logs that reach your monitoring platform. Document any path that is not monitored, along with the compensating control.

No records of alert dispositions

An alert that is opened and silently closed leaves the assessor with nothing to test. For every alert, record the triage result, whether it was authorized use or unauthorized use, the analyst, the date and any escalation to incident response. Consistent dispositions also show that the organization identifies unauthorized use and does not just generate alerts.

Draft evidence presented as final

A requirement is MET only when the evidence is in final form, so a draft acceptable use policy or an unsigned monitoring procedure will not satisfy the assessor. Before the assessment, version each document, record approval and effective dates, and remove superseded drafts from the evidence folder. Ask your assessor early which format and approval record they expect.

How much effort and cost does unauthorized use monitoring take

What drives the cost of meeting SI.L2-3.14.7?

The cost depends mostly on how many systems are in scope, how many log sources they produce, and how much of the monitoring is automated versus reviewed by hand. The requirement itself is short, but the work behind it is not. An organization has to write an acceptable use policy that defines authorized use by role, deploy a logging and detection stack, tune it so alerts are meaningful, and keep records showing that someone reviews them. Costs fall into people time (policy writing, engineering, analyst review), infrastructure (storage and compute for logs, which grows with retention and volume), and any external help. Ask any provider for a quote that lists the in-scope systems, log sources, retention period, and whether the review process is staffed internally or outsourced. Software licensing is only one line, and open-source components remove most of it.

Can a team meet SI.L2-3.14.7 without an outside partner?

Yes, an internal team can meet the requirement without an implementation partner, provided it has the skills and time to do the work. The assessment objectives are straightforward: define authorized use of the system, and identify unauthorized use. The harder part is producing evidence that an assessor will accept, including a policy that defines roles, monitoring tools and their documentation, the locations where monitoring devices are deployed, and records that show monitoring operates as described. Teams with security engineers who already run a SIEM or log pipeline usually need less outside help. Teams without that experience often bring in a partner to prepare systems and evidence. In either case, the organization owns its controls, and only an independent assessor can issue the assessment result.

How long does it take to put unauthorized use monitoring in place?

The timeline depends on the size of the environment, the state of existing logging, and how quickly the organization can agree on roles and policy. No duration is set by the requirement, so the reader should confirm expectations in writing with any provider. Planning usually runs in parallel with work on the acceptable use policy, since the role definitions feed the detection rules. Deployment work covers collecting logs from hosts, network devices and cloud services, then tuning detection rules so that normal activity does not flood reviewers. Evidence collection needs enough operating history for an assessor to see monitoring working over time, so organizations should not plan to start monitoring the week before an assessment. Ask for a fixed-scope plan with milestones and dependencies before committing to a date.

What does the work require from our own staff?

Staff are needed for four kinds of work: policy and role definition, system and log source owners, detection tuning, and regular review of alerts. Policy work involves security, HR and system owners agreeing on what authorized use means for users, administrators and technicians. System owners confirm which logs exist and where they are stored. Engineers who run the monitoring stack handle deployment, access control to the monitoring data and maintenance of rules. Analysts review alerts and document what they did with each one, which is the evidence that makes monitoring count. Small teams often underestimate the review workload, so they should decide early who triages alerts, how often, and how escalations are recorded. Any partner engagement should name which of these tasks it covers and which stay with the organization.

Does open-source monitoring avoid license spend for this requirement?

Open-source tools can remove most software license fees for the monitoring stack, but they do not remove the cost of running it. OpenSearch Security Analytics is licensed under Apache-2.0, Wazuh under GPL-2.0-only, and the Nextcloud admin_audit app and OpenBao audit devices are also open source. Each still needs hosting, storage for logs, configuration, updates, and staff who understand them. Licensing terms also differ, so legal teams should review the specific license and any commercial support or add-on offering before relying on the no-fee assumption. When comparing options, ask for total cost over the planned retention period, including infrastructure, staffing and any support retainer, not only the license line.

Is monitoring alone enough to satisfy SI.L2-3.14.7?

No, monitoring alone is not enough, because the requirement has two parts that an assessor will test: a definition of authorized use, and a way to identify unauthorized use. A dashboard with logs and no policy gives no basis for deciding what counts as unauthorized, and a policy with no monitoring gives no way to detect it. Assessors look for the acceptable use policy defining authorized use by role, the monitoring tools and their documentation, the continuous monitoring strategy, and evidence that alerts are reviewed and acted on. Missing any one of these parts can leave the requirement unmet. Because this requirement is worth 3 points, it cannot go on a plan of action and milestones, so it must be fully met to reach Conditional or Final Level 2 status.

How DeployOpen scopes and prepares unauthorized use monitoring

DeployOpen plans, implements and documents the monitoring setup that supports SI.L2-3.14.7 Identify unauthorized use inside your own infrastructure, using self-hosted open-source platforms. We prepare the systems and evidence; your organization owns the policy and the monitoring decisions, and an independent assessor makes the determination.

How we scope

We agree in writing which systems, log sources and user roles fall inside the monitoring scope before work starts.
The scope records the acceptable use definitions by role, such as user, administrator and technician, that we will help you document.
Engagements are fixed-scope, and the written scope sets the deliverables, timelines and any quote basis.

How we build

We deploy and configure log collection and detection tooling, such as Wazuh or OpenSearch Security Analytics, within your environment.
We tune detection rules and alerting for the authorized use definitions, and test that matching events produce findings and alerts.
We configure audit logging on supporting platforms, such as Nextcloud audit logs and OpenBao audit devices, so their events reach the monitoring stack.

How we hand over

We document monitoring tools, deployment locations, rule sets and the review procedure your staff will follow.
We deliver test records showing monitoring tools detected simulated unauthorized use, so your team can present them in a self-assessment.
We transfer administration to your staff and confirm which evidence should be retained, and where, for the assessor.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
We can review alert volumes, rule changes and log source coverage as your systems and user roles change.
Ask any provider which final-form evidence they will produce and confirm with your assessor which artifacts they will accept.