What AC.L2-3.1.9 privacy and security notices requires for CUI systems
If a CMMC Level 2 assessment is coming, the logon screen on every system that handles CUI must display a privacy and security notice that matches the handling rules for the CUI the system holds. AC.L2-3.1.9 asks the organization to provide that notice, and the assessor will look for two things: the approved wording and proof that users see it. The requirement comes from NIST SP 800-171 Rev. 2 requirement 3.1.9 and is a derived requirement in the Access Control family. It addresses a simple risk: users who are unaware that a system is monitored, or unaware of their obligations for CUI, cannot be held to those obligations. The mapping in NIST SP 800-171 Rev. 2 points to the system use notification control in SP 800-53, which is a useful reference when the notice wording is drafted.
The work is mostly about approval and proof rather than technology. Legal or contracting staff should confirm which CUI rules apply, and the organization should document the approved notice text, who approved it, and the systems where it appears. NIST SP 800-171A lists the potential evidence: documented approval of the messages, the messages themselves, and user acknowledgements. The CMMC Assessment Guide Level 2 describes a banner that users must accept at each logon as one way to meet the requirement. Technology only enters at the point of display, through a login banner or a configuration setting on the platform, and an implementation partner can help configure that setting and capture screenshots and configuration exports as evidence.
AC.L2-3.1.9 is worth 1 point under 32 CFR 170.24, and because it is not on the exclusion list in 32 CFR 170.21, it can be placed on a POA&M for Conditional Level 2 status if the score is at least 88 of 110. The Department of War suspended CMMC Phase II on 13 July 2026, so certification assessments are not currently required for applicable contracts. Phase I self-assessments, SPRS postings, annual affirmations and DFARS 252.204-7012 obligations remain in place, so the notice must still be accurate and provable. Confirm the current status with the contracting officer and the DoW CIO About CMMC page before planning the assessment schedule.
Which systems, logon points and users the notice must cover
The notice requirement applies wherever CUI is reachable, not only on the core system. Scoping decisions about logon points, hosted services and the people who approve the wording determine how much work the banner and its evidence will take.
Every system that handles CUI
Start with the system boundary: every component that stores, processes or transmits CUI, including file servers, email, collaboration tools, databases and build systems. Each one that a user can log on to needs a notice, or a documented reason why a notice does not apply. Compare the boundary diagram in your system security plan against the list of logon points you actually inventory. Gaps usually appear in older servers and appliances that were never added to the boundary.
Remote and cloud portals
Remote access gateways, VPN portals, virtual desktop brokers and cloud administration consoles are common logon points that teams forget to treat as in scope. A user who reaches CUI through a browser portal sees a logon screen, so that screen is where the notice belongs. Check that each portal shows the approved wording before authentication, not only after the user signs in to the desktop behind it.
VDI and shared sessions
Virtual desktop infrastructure often presents one logon at the broker and another inside each session, and a notice may appear on one layer but not the other. Decide which layer the notice must cover for your architecture, and test it from a thin client, a personal device and a managed workstation. Persistent and non-persistent desktops may need different configuration, so confirm the setting on each golden image.
Administrative consoles and mobile access
Administrators using privileged consoles, hypervisor managers and security tools often bypass the standard user path, and mobile apps that reach CUI may show no logon banner at all. List these entry points separately, record how each one displays the notice, and confirm that mobile applications meet the same requirement as desktop logons. Where a console cannot display a banner, document the compensating approach and discuss it with your assessor before you rely on it.
Third-party hosted services
A hosted email, collaboration or ticketing service that stores or processes CUI sits inside your assessment boundary whether or not you run its servers. Ask each provider whether its logon pages can show your approved notice, or whether it offers a configurable banner for your tenant. If a provider cannot display the wording, the gap belongs in your risk record and your contract review, not in an assumption.
Owners of the approval wording
Three teams should sign the notice text before anyone configures it: legal, which confirms the wording matches the CUI rules and any monitoring disclosures that apply; contracts, which checks obligations flowed down from the prime contract; and security, which owns the configuration and the evidence of approval and display. Record each approval with a date and version, because assessors look for documented approval of the messages themselves.
How to build and approve the notice in five steps
This sequence turns a general requirement for a privacy and security notice into a banner that matches the CUI rules your contracts apply, is approved through a documented change, appears at every logon point, and leaves records an assessor can test.
Identify the CUI categories and contract rules
Start by listing which CUI categories the system stores, processes or transmits, and which contract clauses, agency markings or handling instructions govern them. Record the rules that require particular notice wording or a particular acknowledgement. The owner is the system owner with the compliance lead, and the output is a short scope note tying each CUI category to its governing rules. You know this step is done when every notice requirement in the note traces to a named source.
Have counsel draft the banner text
Ask legal counsel to draft the notice text from the rules identified in the first step, covering monitoring, consent to use, the consequences of misuse and the handling of CUI. Keep the wording consistent across the messages used on each system. The output is a draft notice document with a version number and the name of the reviewing attorney. The draft is complete when counsel has signed off on the text and the CUI category it applies to.
Approve the notice through a documented change
Route the final text through your change control process so the approval is recorded with the approver, the date and the version. Assessors look for documented approval of the notification messages, so an email thread alone is weak evidence. The output is an approved notice document and a change record that links to it. The step is complete when the approved version is the only one authorized for deployment.
Deploy the notice at every logon point
Configure the approved text on each logon point in scope, including workstations, servers, remote access gateways, virtual desktops and cloud administration consoles where users sign in. Where a platform supports it, require users to accept the banner at each logon rather than displaying it once. The output is a configuration change record listing each system, the setting used and the version deployed. Check the result by logging on to a sample of systems and confirming the banner appears unchanged.
Capture and retain user acknowledgements
Set the acceptance mechanism so that each acknowledgement is logged with the user identifier, the notice version and the time. Retain these records for as long as your assessment evidence policy requires. The output is an acknowledgement log that can be filtered by user and by notice version. Test the log by pulling acknowledgements for a sample of users and confirming each one matches the approved text in force at that time.
Review the notice when rules change
Set a trigger for review whenever a CUI category, contract clause or agency rule changes, and whenever the notice text is revised. A revision starts again at the approval step and produces a new change record and a new acknowledgement cycle. The output is a review log showing each trigger, the decision and the resulting version. Ask your assessor early which evidence they will expect for a revised notice so that the history stays easy to present.
How an assessor tests AC.L2-3.1.9 and what they ask to see
This table maps how an assessor tests AC.L2-3.1.9 against the two NIST SP 800-171A objectives, from the approved notice text through to the display on each logon path. Read it as a checklist of the records to have ready and the gaps assessors most often write up.
| Assessment step | What the assessor checks | Evidence to have ready |
|---|---|---|
| Objective 1: identify the notices | Confirm the organization identified which privacy and security notices its CUI rules require, and that the notice text matches the CUI categories the system handles. | Mapping from CUI categories and applicable rules to the notice text, dated and owned by the accountable official. |
| Documented approval | Check that the notice messages were formally approved for use, and that the approved version is the one displayed. | Signed or recorded approval of each notice, with version number, approver and date. |
| Message text | Review whether the wording is specific to the system and its CUI, not a generic warning copied from elsewhere. | Final notice text as deployed, including any banner variants for different systems or user groups. |
| Objective 2: display the notices | Test that each notice is shown to users before they gain access, consistently and tied to the CUI category. | Screenshots or captures of the logon screen, plus configuration exports for the banner mechanism. |
| Coverage across logon paths | Verify the banner appears on every path to the system, such as console, remote desktop, web portal, VPN and API or service logons where users authenticate. | Test results for each logon path, with the same notice text shown on each path. |
| User acknowledgement | Confirm users must accept the notice at logon where the organization requires it, and that acceptance is recorded. | Acknowledgement logs or records, retention settings, and a sample of user records tied to accounts. |
| Interviews | Assessors may interview personnel who provide legal advice to confirm the notice text reflects current obligations. | Named owner for the notice, legal review records and a short account of how changes are reviewed. |
| Common findings | Generic banners not tied to CUI, drafts presented as final, and banners present on some logon paths but not others. | Before the assessment, test every path, remove draft text from production and confirm the approved version is live. |
Evidence that passes AC.L2-3.1.9 and how to keep it current
Assessors test AC.L2-3.1.9 by following the notice from approval to what a user actually sees at logon. The cards below cover each artifact that shows this chain, and the routine checks that keep it accurate between assessments. Evidence must be in final form, so every item should be dated, approved and retained as a finished record.
Signed approval of notice text
Keep a written approval of the exact notice wording, signed by the person accountable for the system and, where the organization has one, reviewed by counsel or a privacy lead. Assessors look for approval of the system use notification messages themselves, so a general policy statement is not enough. Check that the approved text matches the banner text shown on each system in scope. Store the approval with its date and the CUI categories it covers.
Versioned notice documents
Maintain the notice as a controlled document with a version number, revision history and a named owner. Each version should record what changed, why it changed and which systems adopted it. Versioning lets you show which wording was live on a given date, which matters when an assessor asks what users saw during a period under review. Keep superseded versions rather than overwriting them.
Display screenshots and configuration exports
Capture screenshots of the logon banner on each system type, such as workstations, servers, VPN gateways and cloud consoles, and export the configuration that controls it. Examples include a Group Policy setting, an SSH banner file or an identity provider login page setting. Dated captures tied to a system name let an assessor confirm the notice is displayed, not just approved. Recapture whenever the platform, template or identity provider changes.
User acknowledgement logs
Where the notice requires acceptance at each logon, retain logs that record user acknowledgement with a timestamp and account identifier. Confirm the log captures acceptance rather than only page display, and check that logons cannot proceed without acceptance. Review the retention period with your records policy and any contract terms. Ask your assessor early whether their approach to acknowledgement logs matches your design.
Configuration drift checks
Banner settings can be overwritten by image rebuilds, patches or new deployments. Schedule a recurring check that confirms each in-scope system still displays the approved text, using configuration scanning or a documented manual test. Wazuh's Security Configuration Assessment can check files and settings against policies you define, which helps detect a changed banner file. Record the results and the remediation for any system that drifted.
Change records for CUI rule updates
Review the notice wording whenever CUI handling rules, contract clauses or customer requirements change, and record the review even when no edit is needed. Link each change record to the new version, the approval and the systems redeployed. Ask your contracting team to flag new CUI categories or flowdown terms, since these can require different notice language. A dated review with a decision is stronger evidence than an updated banner with no explanation.
Where open-source tooling supports the notice evidence
AC.L2-3.1.9 has evidence in several layers. Some of it is documentary, such as the approved notice text and the decision to approve it. Some of it is behavioral, such as whether the banner appears at logon and whether users acknowledge it. Open-source endpoint tooling can contribute to the configuration layer only. It can show that a system is set up the way your documented configuration says it should be, and it can keep that state visible over time. It cannot show who approved the wording, when a legal reviewer signed off, or that a person actually read and accepted the notice.
- Configuration state: Endpoint checks can confirm that a banner setting exists and matches the approved content on the systems in scope.
- Drift over time: Scheduled results show when a setting changed, which matters if an assessor asks how you keep the notice in place between reviews.
- Approval and acknowledgement: Signed approval records, change tickets and acknowledgement logs must come from your governance process and identity platform.
- Assessment objectives: NIST SP 800-171A treats the approved notice and the user acknowledgement as separate potential objects, so tool output supports only part of the picture.
- Scope boundary: Results apply only to devices the tool actually monitors, so unmanaged endpoints need their own evidence.
Confirm with your assessor which artifacts they expect for approval and acknowledgement before you decide what the tooling must produce.
Wazuh's Security Configuration Assessment scans monitored endpoints against YAML policies. The shipped policies are mostly based on CIS benchmarks, and organizations can extend them with custom policies. Checks can cover files, directories, registry keys and running processes, and the module recommends remediation for failed items. For a banner requirement, the practical question is whether a custom policy can read the file or registry value where your logon notice is stored and compare it with the approved text. Whether the shipped policies already include a banner check on your operating system is something to confirm in your environment, not assume.
- Custom policy: Write a policy that checks the banner file or registry value against the approved configuration, then test it on a known-good and a known-bad system.
- Scope of checks: Confirm which operating systems and versions the agent and policies cover in your fleet.
- Remediation output: Review whether the recommended fix is acceptable under your change control process before enabling automated actions.
- Result retention: Keep scan results and policy versions so you can show the state at a past date.
- Licensing: Wazuh is licensed under GPL-2.0-only. Review what that license requires if you modify or distribute the software, and get legal advice on how it applies to your deployment.
Test one custom banner policy on a sample of systems and confirm the output matches what an assessor would expect to see.
Fleet policies ask each device a yes or no question written as an osquery query, and the policies page shows which devices in each fleet pass or fail each policy. A banner-related policy can ask whether the configured notice exists on the device, which gives a current pass or fail view across a fleet. Because Fleet reports the state of each device, it can help identify the systems that need correction before an assessment. The exact queries that are possible depend on the operating system and what osquery exposes there, so confirm them against your own images.
- Yes or no queries: Write a query that returns a result only when the banner configuration matches the approved text, then review the pass and fail results.
- Fleet-level view: Group devices into fleets that match your CUI boundary so the failing list maps to in-scope systems.
- Failure follow-up: Record each failing device, the fix applied and the date it passed again.
- Query stability: Test queries after operating system updates, since file locations and registry paths can change.
- Licensing: Fleet is licensed under MIT. Confirm that the license terms fit how you plan to use and distribute any custom queries.
Run a banner policy against a small test fleet, then confirm that a deliberately misconfigured device shows as failing.
Assessors look for a package of evidence rather than a single screenshot. Tool output is most useful when it sits alongside the documents that prove the notice was approved and that users see it. A workable package links the approved notice text, the approval record, the configuration policy that checks it, the scan or query results over time, and the logon or acknowledgement records from your identity platform. Each item should be in final form when the assessor reviews it, since 32 CFR 170 counts a requirement as met only when evidence is final rather than draft.
- Approved text: Keep the notice wording, its version and the approval record with the date and approver.
- Policy artifacts: Store the Wazuh policy or Fleet query, its version and the change record that introduced it.
- Recurring results: Retain periodic scan or query output that shows the pass state across the in-scope fleet.
- Acknowledgement records: Pull logon acknowledgement records from the identity or access platform, which the open-source checks do not produce.
- Gaps: Document any system where the banner cannot be checked and how it is handled.
Before the assessment, walk through the package with the people who will answer questions about it and confirm which items the assessor expects in final form.
The tooling discussed here is a starting point, not a commitment that either product will check your specific banner on your specific systems. Capability depends on the operating system, the banner mechanism you use, the agent version and the policy language available at the time you deploy. DeployOpen's role in an engagement is to plan, implement and document these checks in your environment and to prepare the evidence, while your organization owns the controls and an independent assessor reviews them. Scope and deliverables are set in writing before work starts.
- Banner mechanism: Identify where the notice is stored on each platform, such as a file, a registry value or a policy setting.
- Tool test: Build a proof-of-concept check on one system per operating system and record whether the tool reads the value correctly.
- Version pinning: Record the Wazuh and Fleet versions used in testing, since results can differ between releases.
- Licensing review: Have counsel confirm the GPL-2.0-only and MIT obligations for your intended use.
- Assessor agreement: Confirm with your assessor that tool output is an acceptable form of configuration evidence.
Write down the result of each test before you rely on a check in an assessment, and treat any operating system where the check does not work as a manual evidence item.
Gaps that cause AC.L2-3.1.9 findings and how to close them
Most AC.L2-3.1.9 findings come from notices that exist on paper but fail in practice: the wrong text, the wrong channel, or no record that anyone approved or users saw them. The cards below cover the gaps assessors meet most often and the fix for each, so the notice works as a control and leaves evidence behind.
Generic consumer-style banners
A welcome message or a generic "unauthorized use prohibited" line may read well, but it rarely reflects the rules for the CUI the system handles. Assessors look for notice wording tied to the applicable CUI requirements, so a banner copied from a commercial login page is a likely finding. Fix it by drafting the text with legal or contracting staff against the CUI categories and markings the system actually processes, then recording which version is live.
Banners not tied to CUI
NIST SP 800-171A expects the notices to be consistent with, and tied to, the specific CUI category. A single banner that never names the CUI handled, or that contradicts the marking rules used on documents, leaves the assessor unable to connect the notice to the data it protects. Map each system to its CUI categories and confirm that the banner language and the marking guidance agree. Keep the mapping in the system security plan.
Inconsistent display across access paths
A banner that appears on the web portal but not on the VPN client or the RDP session leaves a gap that is easy to miss in a test. Each remote entry point, jump host, and administrative console needs the same approved notice shown before access is granted. Inventory every logon path, test each one from a clean session, and capture a screenshot of each for the evidence file.
No approval record
Assessors expect documented approval of the system use notification messages, so a banner with no sign-off record is hard to defend even when it displays correctly. Keep a dated approval for each version, naming the approver and the change reason. Store it with the change control records so the approval history is traceable.
No acknowledgement evidence
Where the notice requires users to accept it at each logon, the system should record that acceptance. Without logs or stored acknowledgements, the assessor cannot confirm that users saw the notice. Configure the platform to require an explicit acceptance action, log each acceptance with user identifier and timestamp, and check sample records during internal reviews. Confirm with your assessor which acknowledgement form they will accept.
Notices without configuration tests
A banner that was once configured may later be overwritten by an upgrade, a new reverse proxy, or a changed VPN gateway. Scheduled checks that confirm the notice still appears on every path catch this drift before an assessment does. Record the test date, the tester, and the result. Compliance and platform teams should agree on who owns that check and how often it runs.
What meeting AC.L2-3.1.9 costs in money and effort
Most of the cost of AC.L2-3.1.9 is labor, not software. The organization pays its own legal or policy staff to decide which notice text applies, engineers to put that text on every logon path, and someone to keep the approval and acknowledgement records current. Outside help is optional and usually limited to a partner preparing the configuration and evidence, or an assessor's fees if you go through a certification assessment. Ask any quote to split these lines so you can see who is paid for what.
Setup is the one-time part: drafting or reviewing the notice wording against your CUI handling rules, getting it formally approved, and configuring its display on each logon point. Recurring work is smaller but never zero: re-reviewing the text when CUI categories or contract terms change, re-testing banners after operating system or application upgrades, and collecting fresh user acknowledgements where your process requires them. Ask the quote to show the one-time and recurring effort as separate line items, with the number of review cycles the partner assumes for legal sign-off.
Cost rises with the number of logon paths (workstations, servers, VPN gateways, web consoles, cloud tenants, and remote desktop entry points), the number of CUI categories that need different notice wording, and the number of legal review rounds. It falls when one approved banner is applied through centralized configuration and when configuration is checked by repeatable scripts or open-source policy tools rather than manual screenshots. Request an inventory of logon points from the scope, a list of CUI categories the notices must reflect, and the assumed review cycles, then compare quotes against those same inputs.
Cost components for AC.L2-3.1.9 by one-time and recurring effort
This table breaks down the cost components of meeting AC.L2-3.1.9 and marks each as one-time, recurring or set by someone else. Read it as a list of what to ask a quote to separate, since the cost of a banner is mostly legal and evidence work rather than software. The main takeaway is that the notice text and its approval record drive most of the recurring effort, while the display itself is usually inexpensive to configure.
| Cost component | One-time or recurring | What drives it and how to keep it down |
|---|---|---|
| Legal drafting and approval | One-time, with periodic review | Drives: number of CUI categories, contract-specific markings and the counsel hours needed. Keep down: draft one reviewed notice template and tie variants to each CUI category in a single approval record. |
| Configuration across systems | One-time, plus change effort | Drives: how many logon paths exist (workstations, servers, VPN, cloud consoles, mobile). Keep down: centralize the banner in directory or group policy so one change propagates. |
| Tooling | Often one-time setup, plus licensing if any | Open-source tools can remove license spend, but configuration and testing still take staff time. Confirm which platforms support the banner natively in your environment. |
| Evidence upkeep | Recurring | Drives: how often banners change and how many systems must show current screenshots, configuration exports and acknowledgement records. Keep down: automate exports and store them with the approval record. |
| User acknowledgement tracking | Recurring | Drives: user count, turnover and whether acceptance is required at each logon. Keep down: use systems that log acceptance automatically rather than manual sign-off sheets. |
| External review or testing | Optional, scoped in writing | Drives: whether counsel or a third-party tester reviews wording or validates the banner. Ask for a fixed scope and deliverables before work starts. |
| Auditor effort | Set by the assessor, not the organization | Drives: how many systems the assessor samples and how complete the evidence is in final form. Ask your assessor about their expected evidence before preparing it. |
Questions about AC.L2-3.1.9 that buyers ask before hiring help
Is a logon banner alone enough to meet AC.L2-3.1.9?
No. A logon banner is one common way to display a system use notification, and the CMMC Assessment Guide Level 2 describes a banner that users must accept at each logon as one possible approach. The assessor still checks whether the notice wording was approved for the CUI rules that apply, whether it is consistent across the systems that handle CUI, whether it is actually displayed, and whether users acknowledge it. Evidence of approval, screenshots or configuration exports, and acknowledgement records all need to exist in final form. A banner with no approval record or no acknowledgement trail will not satisfy the requirement.
Can a consultant or implementation partner write the legal text of the notice?
A partner can help structure the notice, configure where it appears and collect the approval trail, but the wording should be approved by your legal counsel. The requirement ties the notice to the rules for the CUI categories you handle, and that interpretation belongs to your organization. Ask the partner to show how the approved text is version-controlled and linked to each system that displays it. Your counsel's approval should be recorded with a date and the text it covers, so the assessor can see that the content was reviewed by the right people.
How long does this work take, and what drives the duration?
Duration depends mostly on how many systems display notices and how many distinct CUI rules apply. The main drivers are the number of login points (domain logon, VPN, web portals, remote desktop gateways, mobile management), whether the wording already exists and has been approved, and how long counsel review takes. Configuration of a single banner across one identity provider is usually the shortest part. Ask any partner for a written schedule tied to the agreed scope, and confirm which steps depend on your legal and HR teams so that delays on your side are visible in the plan.
What must our team provide before a partner can start?
Expect to provide a list of systems that handle CUI, the login paths for each, the current notice text if one exists, the CUI categories and handling rules that your contracts require, and a named approver from legal or compliance. You will also need administrator access to the identity provider, endpoint management and any remote access gateways, plus a place to store signed approvals and acknowledgement records. The partner can prepare configuration and evidence, but your organization owns the controls and the decision on what the notice says.
Does self-assessment still apply given the Phase II suspension?
Yes, you should plan on it. The Department of War suspended CMMC Phase II on 13 July 2026, which had required Level 2 certification assessments by C3PAOs for applicable contracts, and started a 60-day review by a CMMC Reform Task Force. Phase I self-assessments, SPRS postings, annual affirmations and DFARS 252.204-7012 obligations remain in place. As of 17 October 2026, the DoW CIO page says implementation is paused in Phase 1 and may only require self-assessments at Levels 1 and 2, while the eCFR still shows the original schedule. Confirm your current obligations with your contracting officer and counsel, and check the official About CMMC page before you set a timeline.
Can AC.L2-3.1.9 be placed on a POA&M, and how long is closeout?
Yes, AC.L2-3.1.9 is a 1-point requirement that is not on the list of requirements that cannot go on a plan of action and milestones, so it may be placed on a POA&M for Conditional Level 2 status if your score is at least 88 of 110 (0.8). Under 32 CFR 170.21, closeout is due within 180 days. Treat that as a short window: the banner, approval and acknowledgement work is usually quicker to finish than the broader access control work, but the approval step depends on counsel. Track the closeout date from the day the POA&M is recorded, and do not rely on a POA&M for a notice that is already simple to deploy.
How do we choose a partner for this work?
Ask for a written, fixed scope that lists each system, login path and deliverable, along with who approves the notice text and who keeps the acknowledgement records. A credible partner will say plainly that it prepares configuration and evidence and does not issue assessment results, and that only an independent assessor or certification body issues reports or certificates. Ask how the partner tests the banner on each login path before handover, how evidence is packaged in final form, and what support is available after the work ends. Compare written quotes against that scope rather than against a headline figure.
How DeployOpen configures and documents the notice for CMMC
This sequence takes the logon points of a self-hosted platform from scoping through configuration, verification and evidence packaging, so the organization can show assessors a consistent notice that it approved, displayed and users acknowledged. DeployOpen prepares the configuration and evidence; the organization owns its controls and the legal wording.
Scope every logon point and CUI boundary
DeployOpen works with the organization to list each place users reach the system that handles CUI, including web consoles, SSH or remote desktop entry points, VPN and remote access gateways, and administrative portals. The output is a written inventory that ties each entry point to the system security plan boundary, so the notice coverage can be checked against it later. The organization confirms the list, since it knows which access paths are actually in use.
Obtain approved notice wording from the organization
The organization's legal, privacy or contracts function drafts or approves the notice text, reflecting the CUI handling rules that apply to its contracts and data. DeployOpen does not write or certify the legal language. The output is a signed or recorded approval of the final wording, with version and approval date, which becomes the first item in the evidence set.
Configure the notice on each self-hosted platform
DeployOpen configures the approved banner inside the client's own environment on each platform in scope, using the native login banner or pre-authentication message setting that the platform supports. Where a platform cannot show a banner before logon, the team documents the gap and the compensating method. The output is a change record with configuration file names, settings and the target systems, placed under the organization's change control process.
Require acknowledgement at each logon where supported
Where the platform supports it, DeployOpen enables an acceptance step so users must acknowledge the notice at each logon before the session continues. The team confirms the behavior with a test account and records the result. Where the platform cannot require acknowledgement, the organization decides on an alternative, such as a signed user agreement, and the decision is recorded in the system security plan.
Build automated configuration checks
DeployOpen writes checks that confirm the banner text is present and unchanged on each endpoint or platform, using tools such as Wazuh Security Configuration Assessment with custom YAML policies that inspect the relevant configuration files, or Fleet policies written as osquery questions that report which devices pass or fail. The checks run on a schedule the organization sets. The output is a passing report and a documented procedure for handling failures.
Test display and acknowledgement end to end
DeployOpen runs a documented test from each logon point, capturing screenshots or logs that show the notice displayed before access and the acknowledgement recorded. Test results are compared against the scope inventory, and any gaps are logged as findings with owners. The output is a dated test record that shows the mechanism works as the configuration describes.
Package the evidence for the assessor
DeployOpen assembles the evidence set: the scope inventory, approved wording with its approval record, change records, configuration files, check reports, acknowledgement logs and test results, all in final form. The organization reviews the package and keeps it current when platforms or wording change. DeployOpen does not issue reports or certifications. An independent assessor reviews the evidence and reaches the MET or NOT MET determination, and the organization remains responsible for its controls.
