- The current account and access population (the access review worksheet or identity-provider export)
- Your data-handling decisions: what people may and may not do with CUI, AI tools, personal devices, and removable media
- Knowledge of every non-employee population with access — contractors, vendor technicians, partner users
ATL-031RECORDEDITORIAL REVIEW COMPLETE
Rules of Behavior Template
A one-page-when-finished set of signed rules for everyone who touches systems handling sensitive contract information — starter language by topic area, an acknowledgment register that reconciles signers against the access population, and the renewal discipline that keeps signatures meaningful.
Using this artifact
Purpose, inputs, and completion
Purpose. Rules of behavior are the shortest governance document with a requirement number behind it (03.15.03 in Rev. 3): the plain statements each person accepts before touching systems that handle sensitive contract information. This template provides starter language to adapt, the acknowledgment register that makes the signatures auditable, and the renewal wiring that keeps them current. The signature is the easy half — the reconciliation of who signed against who has access is what a reviewer actually checks.
When to use it. Adapt the starter rules to your environment and enforcement reality, cut to one page, and route every person with access — employee or not — through signing at onboarding and at each material change. Keep the register beside the identity provider's account list and reconcile the two on a cadence. Nothing here should restate your full policies; the rules summarize behavior, the policies stay separate and referenced.
- Adapt the starter rules to what you actually enforce — a rule your systems permit and your culture ignores trains people that the signature is theater.
- Cut until it fits on one page. Rules of behavior are read at signing time or never; length is the enemy of the only reading you get.
- Collect acknowledgments from everyone holding access — including non-employees — and record them in the register, not in a drawer.
- Reconcile the register against the access population on a cadence: the gap between people-with-access and people-who-signed is the finding.
- When a rule materially changes, version the document and re-acknowledge; date-range the superseded version.
Keeping it honest
Evidence, validation, and failure modes
- A versioned, dated rules-of-behavior document with an owner
- Signed acknowledgments reconciled against the access population
- Re-acknowledgment records tied to rule changes and renewals
- Pull five names from the identity provider at random and find their current-version acknowledgment in the register; a miss is the gap an assessor will find the same way.
- Ask the most recent hire what the rules said — if signing left no memory, the document is too long or the signing moment is a formality to fix.
What looks done but is not
- The signed population is the employee roster while the access population includes contractors and vendor technicians nobody asked to sign.
- Rules written as policy prose — three pages of 'users shall' that nobody reads — instead of a dozen plain statements a person can actually follow.
- The rules changed (a new AI clause, a device rule) but acknowledgments were never refreshed, so everyone is signed to a document that no longer exists.
Mapped relationships
Practices and requirements this artifact relates to
Brilliant at the Basics practices
NIST SP 800-171 Rev. 2
NIST SP 800-171 Rev. 3
Relationships are mapped support, not equivalence: completing this artifact documents work relevant to these requirements and does not by itself address any of them. Retention: Retain every signed acknowledgment for the person's access lifetime plus your record-retention period, and every superseded rules version with its date range — an assessor reconciles who signed which version, when.
Full document
Preview — exactly what prints
RECORD · GOVERNANCE & PROGRAM MANAGEMENTv1.0 · REVIEWED 2026-08-07
Rules of Behavior Template
Brilliant at the Basics Resource Center · brilliantatthebasics.us · published by inDirectIT, Inc.
Independent educational material. Not affiliated with, sponsored by, approved by, or endorsed by the U.S. Department of War. Does not establish compliance, certification, or contractual standing.
Purpose
Rules of behavior are the shortest governance document with a requirement number behind it (03.15.03 in Rev. 3): the plain statements each person accepts before touching systems that handle sensitive contract information. This template provides starter language to adapt, the acknowledgment register that makes the signatures auditable, and the renewal wiring that keeps them current. The signature is the easy half — the reconciliation of who signed against who has access is what a reviewer actually checks.
How to use it
Adapt the starter rules to your environment and enforcement reality, cut to one page, and route every person with access — employee or not — through signing at onboarding and at each material change. Keep the register beside the identity provider's account list and reconcile the two on a cadence. Nothing here should restate your full policies; the rules summarize behavior, the policies stay separate and referenced.
Scope and definitions
Who must sign, what systems the rules cover, and the handful of terms the rules use. Signing populations fail at the edges — name the edges.
Scope
| Organization and environment covered | Who must acknowledge (employees / contractors / vendor technicians / partner users) | Rules version and effective date | Where the full policies live |
|---|---|---|---|
Non-employees sign too
If a contractor, vendor technician, or service-provider engineer holds an account, they are an individual requiring access — their acknowledgment belongs in the same register, and an engagement letter saying 'vendor will follow policies' is not a signature. Where a provider's staff rotate, have the provider maintain and furnish its per-technician acknowledgments as part of the service.
The rules — starter language to adapt
Twelve starter statements by topic area. Keep the ones you enforce, adapt the bracketed choices, delete what does not apply, and resist adding more — every added rule dilutes the twelve that matter.
Starter language, not policy: each row is one plain statement a person can follow. Adapt or strike every row deliberately.
| Topic | Starter rule language | Keep / adapt / strike |
|---|---|---|
| Sensitive information | I will handle CUI and other sensitive contract information only in the systems approved for it, and I will not move it to personal accounts, personal devices, or unapproved tools. | |
| Marking and sharing | I will preserve markings on information I handle and share it only with people authorized to receive it. | |
| Credentials | I will keep my credentials to myself, use the MFA methods issued to me, and never share, write down, or reuse passwords across systems. | |
| AI tools | I will not enter CUI, export-controlled data, credentials, or customer-sensitive information into any AI tool that is not on the approved list. | |
| Devices | I will do company work only on managed devices, and I will report a lost or stolen device immediately — [name the number/channel]. | |
| Removable media | I will use removable storage only when approved, and never a device with no identifiable owner. | |
| Remote work | When working away from the office I will use the approved remote-access path and keep sensitive information out of sight of others. | |
| Software | I will install only approved software and will not disable or work around security tools. | |
| Reporting | I will report suspected security incidents, phishing, and mistakes — including my own — immediately, and I understand that fast reporting of an honest mistake is valued, not punished. | |
| Monitoring notice | I understand activity on these systems may be logged and reviewed. | |
| Physical | I will lock my screen when away and will not let anyone through controlled doors on my badge. | |
| Consequences | I understand that violating these rules may result in loss of access and disciplinary action per [policy reference]. |
Acknowledgment statement and register
The statement each person signs, and the register that turns signatures into a reconcilable record.
Acknowledgment statement to adapt
I have read and understand the rules of behavior, version [X.X], and I agree to follow them as a condition of my access to [organization] systems. I understand the rules may change and that I will be asked to re-acknowledge when they do.
Rows beginning EXAMPLE: show the expected shape — replace them with your own.
| Name | Population | Role | Rules version signed | Date | Method | Renewal due |
|---|---|---|---|---|---|---|
| EXAMPLE: J. Rivera | Employee | CNC programmer | 1.2 | 2026-08-01 | Onboarding packet, wet signature | 2027-08-01 |
| EXAMPLE: M. Chen (Acme Controls) | Vendor technician | Integrator engineer | 1.2 | 2026-08-04 | E-sign, engagement onboarding | 2027-08-04 |
Register reconciliation
| Date reconciled against access population | Accounts with access | Current-version acknowledgments | Gap (names) | Reconciled by |
|---|---|---|---|---|
Renewal, change, and onboarding wiring
Signatures decay. This section is the small machinery that keeps them current without anyone heroically remembering.
- Onboarding: acknowledgment happens before first access is granted, as a checklist step in the joiner process — not in the first week, before.
- Annual renewal: re-acknowledgment rides an existing rhythm (training completion, access review) rather than a standalone campaign.
- Change-driven renewal: a material rule change bumps the version, and access-holders re-acknowledge within a defined window; the superseded version is retained with its date range.
- Offboarding: the acknowledgment record is retained per the retention rule when access ends — it is evidence, not clutter.
- Provider staff: the ESP furnishes current per-technician acknowledgments at a defined cadence, and its roster changes trigger new signatures.
Document control, version history, and approval
An artifact without an owner, a review date, and an approval trail is a snapshot, not a record. Complete this section before the document is used, and update it at every review.
| Field | Entry |
|---|---|
| Document owner (named person) | |
| Suggested owner role | IT leader or compliance lead |
| Approval authority | Executive sponsor |
| Review frequency | Annual, and at every material change to the rules — a changed rule nobody re-acknowledged is unsigned |
| Next scheduled review | |
| Storage location of the completed document | |
| Retention | Retain every signed acknowledgment for the person's access lifetime plus your record-retention period, and every superseded rules version with its date range — an assessor reconciles who signed which version, when. |
Version history
| Version | Date | Author | Summary of change | Approved by |
|---|---|---|---|---|
Review and approval
| Reviewed by | Role | Date | Signature / initials |
|---|---|---|---|
Complete this offline — and mind what you write down
Fill this in inside your own environment, not on any public website or unapproved cloud tool. A completed copy may reveal your security posture: never include CUI, export-controlled data, credentials or keys, unremediated vulnerability details, network diagrams, or customer-sensitive information beyond what the artifact strictly needs, and store the completed document with the same care as the systems it describes.
What completing this artifact does and does not do
This is independent educational material. Completing it documents your work and produces records a reviewer can examine — it does not, by itself, implement a safeguard, satisfy any NIST SP 800-171 requirement, establish compliance with DFARS or CMMC, or replace your own analysis within your defined system boundary. Requirement references are mapped relationships, not equivalence claims. Tailor every section to your technical, operational, contractual, regulatory, and safety requirements.