What this is: a complete, copy-paste AI acceptable-use policy for organizations handling CUI, with each section mapped to the NIST 800-171 Rev 2 requirement it supports. A policy alone is not a control — the enforcement section below is what turns it into one — but assessors do expect the written artifact, and this saves you writing it from scratch.
How to use this template
- Replace bracketed placeholders with your organization's specifics.
- Have leadership and counsel review — especially the incident-response section against your actual DFARS contracts.
- Publish it, train on it, and wire the technical enforcement so the policy describes reality.
The template
1. Purpose and scope
[Organization] permits the use of generative AI tools to improve productivity, subject to the controls in this policy. This policy applies to all employees, contractors, and systems that access [Organization]'s network or handle Controlled Unclassified Information (CUI). It supports [Organization]'s obligations under DFARS 252.204-7012 and NIST SP 800-171.
2. Approved AI tools and pathway (maps to 3.1.20 — external connections)
AI tools may be used only through [Organization]'s approved AI gateway at [proxy address]. Direct access to AI services that bypasses the gateway is prohibited on organizational systems. The approved tool list is maintained by [role] and reviewed quarterly.
3. Prohibited content (maps to 3.1.3 — CUI flow control)
The following must never be entered into any AI tool, regardless of pathway: CUI in any form (including contract numbers, CAGE codes, technical data, and program details); ITAR/EAR-controlled technical data; personnel or clearance information; customer data governed by contract; authentication secrets. When in doubt, treat content as CUI and do not submit it.
4. Technical enforcement (maps to 3.13.1 — boundary protection)
All AI traffic is routed through a locally hosted scanning proxy that inspects prompts on [Organization]'s own infrastructure before transmission. Prompts matching CUI, export-control, or PII patterns are blocked automatically. The scanning system runs within [Organization]'s network boundary; prompt content is not transmitted to any third party for inspection.
5. Logging and audit (maps to 3.3.1, 3.3.2, 3.3.8)
Every AI prompt event — allowed or blocked — is recorded in a tamper-evident, hash-chained audit log attributing the event to an individual user. Audit records are retained for [retention period, e.g. 3 years] and are protected from modification. Logs are reviewed [weekly/monthly] by [role].
6. Incident response (maps to 3.6.1, 3.6.2)
Suspected submission of CUI to an AI tool must be reported to [security contact] immediately. [Organization] will assess scope, preserve evidence, and where required report through DIBNet within 72 hours of discovery per DFARS 252.204-7012. See [incident-response plan reference].
7. Training and acknowledgment
All personnel complete AI-use training at onboarding and annually. Each employee acknowledges this policy in writing. Violations are handled under [disciplinary policy].
8. Review
This policy is reviewed [annually] by [owner] and after any AI-related security incident.
Making it real
Section 4 is the one assessors probe: a policy that says "employees must not paste CUI" with no enforcement is an honor system, and honor systems fail audits. The enforcement architecture — local scanning, blocking, hash-chained logs — is exactly what HoundShield deploys in minutes as self-hosted Docker. If an incident has already happened, start with the incident-response playbook; to baseline what your team is actually sending to AI tools today, run the $499 assessment and attach its PDF to this policy as evidence.