- Keep the rules short and specific to CUI handling — where it may be stored, how it may be shared, what is prohibited — rather than duplicating the entire acceptable-use policy.
- Automate the acknowledgment at onboarding and again when the rules change; an access population larger than the signed population is the first thing an assessor reconciles.
- Cover non-employee access: contractors, vendor technicians, and partner users who reach the system are 'individuals requiring access' too.
03.15.03OFFICIAL TITLEPENDING NIST SME REVIEW
03.15.03 — Rules of Behavior
03.15 Planning · NIST SP 800-171 Rev. 3
Independent summary of the official requirement
Establish rules describing responsibilities and expected behavior for handling CUI and for system usage, provide the rules to individuals requiring access, obtain a documented acknowledgment before authorizing access, and review and update the rules at an organization-defined frequency.
Rev. 3 requirement text is multi-part and parameterized with organization-defined values, so this site summarizes rather than reproduces it. The summary is independent — read the official publication for the binding wording.
NIST SP 800-171 Rev. 3 — Protecting CUI in Nonfederal Systems ↗NIST SP 800-171A Rev. 3 — Assessing Security Requirements for CUI ↗Independent interpretation
What this requirement is after
Before someone touches CUI, they read the rules for handling it and sign. Not because a signature stops misuse, but because expectations that were never stated cannot be enforced — and terminations, disputes, and insider-risk cases all eventually turn on whether the person was told.
Across revisions
New in Rev. 3 with no Rev. 2 counterpart requirement; it formalizes the signed-acknowledgment discipline many organizations already ran informally under acceptable-use policies.
Mapped practices
Brilliant at the Basics practices that support this requirement
No practice maps to this requirement — deliberately.
The campaign’s twenty practices are a priority list, not a control catalog, and none of them works this requirement’s substance directly. It still applies to you if it is in your contract’s scope: address it through your own implementation and the related artifacts below, and treat the absence of a mapping here as honesty, not permission to skip it.
Doing the work
Implementation considerations and evidence
- The current rules of behavior with version history
- Signed or system-recorded acknowledgments reconciled against everyone holding access
Artifacts
Templates and worksheets with a mapped relationship
No artifact in the library names this requirement yet. The library index groups everything by category and practice.
The other revision
Where this came from in Rev. 2
No direct Rev. 2 counterpart — this requirement is new in Rev. 3. Open the transition crosswalk →
Provenance
Sources and review status
| Primary sources | NIST SP 800-171 Rev. 3 — Protecting CUI in Nonfederal Systems · NIST SP 800-171A Rev. 3 — Assessing Security Requirements for CUI |
|---|---|
| Review status | Pending NIST SME review |
| Content version | 1.0 |
| Updated |