03.15.03 Rules of behavior: requirements and evidence

What 03.15.03 rules of behavior require before anyone touches CUI

03.15.03 requires you to write rules of behavior that tell system users what they are responsible for and how they must act when they use a system or handle CUI, then to prove each user read them and agreed before they get access. If your contract or a DFARS clause requires NIST SP 800-171, this is the requirement most organizations fail on paper: the acceptable use language often sits inside a general policy, but nobody can show a signed, dated acknowledgment from each person who has access to CUI or the systems that hold it. The requirement has three duties. You establish the rules, covering responsibilities and expected behavior for system use and for protecting CUI. You provide them to the individuals who need access. You obtain documented acknowledgment that each person has read, understood and agrees to abide by them before access to CUI and the system is authorized, and you review and update the rules at a frequency your organization defines. That review frequency is the single organization-defined parameter (ODP) for this requirement. NIST does not set the number, and if your federal sponsor does not specify one, you must choose it and be able to justify it.

Rev. 3 is the first revision to contain this requirement. Its source control, PL-4 from SP 800-53 Rev. 5, was treated as expected to be implemented by nonfederal organizations without being specified in Rev. 2, so NIST maps no Rev. 2 requirement to it. CMMC Level 2 assesses the 110 Rev. 2 requirements and therefore has no matching requirement ID. Confirm with your contracting officer which revision governs your contract before you build your evidence, because the answer determines whether 03.15.03 is in scope at all. The assessor will look for the rules, the signed acknowledgments and the review record. Start by asking who owns the rules and who signs them. Then pull the signed acknowledgments for every current user with CUI access and compare them to your account list. Gaps usually appear where contractors, temporary staff and administrators were granted access before the rules existed, and where the acknowledgment lived in an HR form that nobody can search. Confirm your review frequency is written down, that the last review happened on schedule and that the update history is preserved.

Who must sign rules of behavior for CUI systems

Under 03.15.03, the organization decides who counts as a system user and therefore who must read and acknowledge the rules before access is granted. Each decision below changes the number of people who sign, the acknowledgment records to keep, and the team that must own the answer.

Employees and full-time staff

Every employee who can log in to a system that stores, processes or transmits CUI is a system user and must sign the rules before access is authorized. Human resources usually owns the onboarding step, but the security or compliance lead should own the list of who signed. Check that the list covers people who received access through a role change, not only new hires. A signed acknowledgment is evidence only if you can match it to a named account and a date.

Contractors and third-party staff

Contractors with direct accounts on CUI systems must sign, even when their employer is a different company. Contract management should confirm this in the statement of work, and the security team should confirm that accounts are not shared with the contractor's own staff. Ask whether the contractor's firm already requires an equivalent acknowledgment, and whether that document meets the organization's own rules. Do not accept a vendor's generic policy without reading what it commits the individual to.

Managed service provider administrators

Managed service staff who administer servers, firewalls or cloud tenants that hold CUI have privileged access and should be treated as system users. IT operations usually manages these accounts, while the contracts team owns the terms that flow down the rules. Confirm which individuals at the provider hold credentials, because the provider's help desk may have access that nobody on the organization's side has listed. The list should be reviewed whenever the provider changes its staffing.

Privileged administrators and system owners

Administrators who can change access controls, configurations or logging carry responsibilities beyond ordinary use, and the rules of behavior should state those duties explicitly. Ask the system owner and the identity team to confirm that every privileged account maps to a signed acknowledgment. Where a person holds both a standard and an administrator account, decide whether one signature covers both, and record that decision in the policy.

Remote and hybrid users

People who connect from home, travel or shared offices are still system users, and the rules should address their work locations and devices. The security team should define which remote access methods are allowed, while the physical security or facilities team advises on work sites that are outside the organization's control. Confirm that remote users sign the same document as office users, and that the acknowledgment states how they must protect CUI away from the office.

Systems inside the CUI boundary

The people who must sign depend on which systems fall inside the CUI boundary, so the scope decision comes first. Compliance, with system owners, should list every system that stores, processes or transmits CUI, including email, collaboration tools and backup repositories. Anyone whose access reaches those systems, even indirectly, belongs on the signing list. Revisit the list whenever the boundary changes, because a new system brought into scope can add signers overnight.

How an assessor tests 03.15.03 and what passes

This table shows how SP 800-171A Rev. 3 approaches 03.15.03, which evidence maps to each test method, and where assessments usually fail. Read it as a preparation checklist: the organization owns the rules and their enforcement, and only the assessor records the finding.

Assessment element	What the assessor looks for	Common reason it fails
Determination statements	Five statements cover establishing the rules, describing responsibilities and expected behavior, providing them to people who need access, collecting signed acknowledgments before access, and reviewing and updating the rules. A sixth checks that the review frequency is defined.	Organization can describe the rules verbally but cannot show each element in writing.
Examine method	Written rules of behavior, the security planning policy and procedures they sit under, and the signed acknowledgment records.	Rules exist as a draft or are not dated, versioned or approved by an owner.
Interview method	Staff who write, approve, distribute and update the rules, plus those who run literacy training, can explain the process and their role in it.	Owners of the rules disagree on who approves changes or which version is current.
Test method	The process for establishing, reviewing, disseminating and updating the rules works as written, for example by sampling a recent update and tracing its distribution.	Process is documented but was not followed in the last review cycle.
Written rules covering CUI	Rules state responsibilities and expected behavior for system use and for protecting CUI, not only general acceptable use.	Generic acceptable use policy with no CUI handling, marking, transmission or incident reporting duties.
Distribution and acknowledgment record	Evidence that each person with access received the rules and signed or otherwise documented that they read, understood and agree to them before access was granted.	Acknowledgments are unsigned, missing for contractors or former staff, or collected after access was granted.
Defined review frequency	The ODP value for the review and update frequency is assigned in the rules or the policy that governs them, and a review record shows the frequency was followed.	No frequency is set, or the stated frequency has passed with no review record.

How to build rules of behavior an assessor can verify

This sequence turns 03.15.03 into a set of documents and records that an assessor can examine, interview people about and test. Each step produces an artifact, so the organization can show what the rules say, who approved them, who received them, who acknowledged them and when they will be reviewed again.

Set the review frequency as the ODP value
Start by choosing the frequency at which the rules of behavior will be reviewed and updated. 03.15.03 has one organization-defined parameter, and if the federal agency you contract with has not specified a value, your organization must assign it to complete the requirement. Record the chosen frequency in the policy or plan that governs the rules, with the name of the role accountable for it. The output is a documented ODP value that the assessor can compare against the review calendar in the final step.
Draft rules covering system use and CUI protection
Write the rules of behavior in plain language, describing the responsibilities and expected conduct for people using the system and handling CUI. Cover the activities your environment makes possible, such as acceptable use of systems, handling and sharing CUI, use of removable media, remote access, reporting suspected incidents and consequences of violations. Keep each rule tied to a system or data behavior that people can actually perform. The output is a draft rules document with a version number and an identified owner, ready for review.
Obtain management approval of the rules
Route the draft to the leaders who own the system and the CUI, such as the system owner, the security lead and the business owner who can accept the consequences of the rules. Record their approval, the date and any changes they required before the rules take effect. Approval gives the rules the authority that makes them enforceable and gives the assessor a clear chain from policy to practice. The output is an approved version of the rules with a recorded approval, and a note of who holds the document.
Distribute the rules to people who need access
Identify every population that needs access to the system or to CUI, including employees, contractors, administrators and any external users, and give each group the approved rules. Keep a distribution list that shows who received which version and when. Make sure the rules are reachable from the places people work, such as the access request workflow or the intranet, so that the distribution is traceable. The output is a distribution list tied to the approved version, which later steps compare against access grants.
Collect documented acknowledgment before granting access
Before any person is authorized to access the system or CUI, collect a documented acknowledgment that they have read, understood and agree to abide by the rules. Acknowledgment must be recorded per person and per version, with the date and a link to the rules they accepted. Block access provisioning until the record exists, so the access workflow and the acknowledgment register agree. The output is one acknowledgment record for each person with access, and a check that no account was granted before its record was created.
Schedule review and update of the rules
Enter the review frequency from the first step into a calendar or governance tracker with a named owner for each review. At each review, confirm the rules still match the system and CUI environment, update them where they do not, and reissue the approved version to the people affected. Re-collect acknowledgments when the rules change in a material way, and keep prior versions for comparison. The output is a review calendar entry with an owner, the review history and the record of any reissued version and its acknowledgments.

Evidence that proves rules of behavior are in force

An assessor testing 03.15.03 will look for a rules document, proof that it reached the people who need it, signed acknowledgments that came before access, and records showing the rules are reviewed on the frequency the organization defined. The cards below cover those artifacts and how to keep each one current between assessments, so the evidence is not rebuilt from memory when the assessor arrives.

Approved rules document with version history

This is the rules of behavior document itself, covering responsibilities and expected behavior for system use and for protecting CUI. Keep it in a wiki or document system that records every change, who made it and when, so the assessor can see the approved version in force on any given date. Check that the document names the system and the CUI it governs, and that approval is recorded by a named owner. Confirm the approval record is dated before the first access grant.

Distribution record for the rules

03.15.03 requires the rules to be provided to individuals who need access, so the organization must be able to show who received them and through which channel. A distribution log tied to the current version answers the question of whether a given user was given the rules that applied to them at the time. Record the version number sent, the recipient, and the date. Check that distribution reaches contractors and subcontractor staff who touch the system, not only employees.

Signed acknowledgment per user

The requirement calls for documented acknowledgment that individuals have read, understood and agree to abide by the rules before access to CUI and the system is authorized. Each user needs an individual record showing the version acknowledged, the date and the signed or electronically attested statement. Generic team sign-offs do not show individual agreement. Check that every active account has a matching acknowledgment for the current version, and that re-acknowledgment is triggered when the rules change.

Access provisioning record showing acknowledgment came first

Acknowledgment must precede authorization, so the assessor will compare account creation or access grant dates with acknowledgment dates. An access request ticket or identity workflow that will not complete until the acknowledgment is recorded produces this sequence automatically. Export the provisioning log for sampled users and check that each access grant date falls on or after the acknowledgment date. Any account created before the acknowledgment step needs an explanation and a remediation record.

Review and update record at the defined frequency

03.15.03 has one organization-defined parameter, the frequency at which the rules are reviewed and updated. The organization must set that value, state it in the document, and keep records showing each review happened on schedule and what changed. A review log with the reviewer, the date, the outcome and any revised version number proves the parameter is in operation. Missed reviews are the most common gap, so schedule the review as a tracked task with an owner.

Training and awareness record tied to the rules

The rules should be part of security literacy training, and assessors may interview staff who run that training to confirm the rules are taught. Keep completion records for the training module that references the current rules version, with the learner, date and any assessment score. An LMS that marks completion when a learner views or passes a module can serve as the system of record. Check that new hires and users whose roles change receive the module before they gain CUI access.

Keeping rules versions and acknowledgments with self-hosted open source

Self-hosted tools can hold the evidence that 03.15.03 asks for, but they only produce it if you configure them around the requirement. The rules of behavior themselves should live in a wiki or documentation platform that you run inside your own environment. XWiki keeps every change to a page under version control, recording what changed, when and by whom, and lets users compare any two versions and roll back to an earlier one. That history is the record an assessor will want when they ask how and when the rules were reviewed and updated, and it shows which version each user was given. Confirm with the XWiki project's documentation that the version history and comparison features match your deployment before you rely on them in an assessment.

Who can change the rules matters as much as the record of changes. BookStack assigns abilities through roles and lets you override permissions per shelf, book, chapter or page. In practice, you can give the security or compliance team edit rights on the book that holds the rules, and give everyone else view rights only. Write down that role design, because an assessor reviewing the rules and their update process will expect to see that the people who establish and update them are the people you have named. Check the role and permission model against your own access review before going live.

The acknowledgment step is where open source tooling most often falls short if it is set up loosely. Moodle activity completion can mark an activity complete when a learner views it, when they receive a grade from it, or when they tick it manually, depending on the conditions you set. A view-only completion setting records that someone opened the rules, not that they read, understood and agree to abide by them, so it is not an acknowledgment. Configure the completion condition to a deliberate action such as a manual tick combined with a quiz or signed statement, and export the completion records as evidence. Finally, have your legal team confirm the licensing terms for XWiki (LGPL-2.1-or-later), BookStack (MIT) and Moodle (GPL-3.0-or-later) against how you plan to deploy and modify them.

What meeting 03.15.03 costs in money and effort

This table breaks down the cost components of establishing, distributing, acknowledging and reviewing rules of behavior under 03.15.03, showing who is paid for each and whether it is one-time or recurring. Use it to build a quote request, since no price or duration for these components is published in the supplied facts and each one depends on your own environment.

Cost component	Who is paid	One-time or recurring	What drives it up or down
Drafting the rules of behavior	Internal policy staff or an implementation partner	One-time, then updated at each review	Number of distinct user groups, number of systems in the boundary, and how many CUI handling tasks each role performs
Legal and HR review	Counsel, HR and labor relations staff	One-time, repeated after material changes	Employment rules in each jurisdiction, union or works council obligations, and whether consent language must be reviewed by counsel
Tooling and configuration	Software vendor for licenses; implementation partner or internal engineers for setup	License cost is recurring if the tool is commercial; open-source options remove license spend but not configuration effort	Choice of wiki, document management or learning platform, integration with identity systems, and version control and permission design
Engineering time to tie acknowledgment to access provisioning	Internal identity or platform engineers, or a partner	One-time build, then ongoing maintenance	Number of account provisioning paths, whether accounts are created by hand or through automation, and how many third-party access routes exist
Acknowledgment administration	Access administrators and HR or compliance staff	Recurring with each new user, role change and rule revision	Staff turnover, contractor churn, number of users, and how many reacknowledgments a rule change triggers
Periodic review and update	Policy owner and reviewers	Recurring at the frequency the organization defines	The review frequency it sets for the ODP, the number of rule sets, and how many business changes occur between reviews
Training and literacy linkage	Training staff or learning platform administrators	Recurring if acknowledgment is tied to training completion	Size of the user population and whether training is required before access is granted
External review or testing	Independent assessor or security testing provider	Periodic, when the organization or its contracting authority requires it	Scope of the assessment, number of systems and third parties covered, and whether the review examines interviews and records
Assessor time	Independent assessor or contracting authority's assessor	Per assessment cycle	Quality of rules and signed acknowledgment records, and whether evidence is organized for examination and interview

Who owns 03.15.03 and what an outside partner can prepare

Your organization owns requirement 03.15.03 in full. The rules of behavior describe what people who use systems with CUI may and may not do, and only your organization can decide what those expectations are for your mission, your contracts and your workforce. Your team must also approve the rules, decide who receives them, decide who must sign, and set the review frequency that NIST leaves as an organization-defined parameter. The review outcome is yours to make and to record.

Content and approval: Write the rules in terms of your systems, roles and CUI handling, then approve them through a named authority.
Distribution and scope: Decide which users, administrators, contractors and third parties must receive the rules before access is granted.
Acknowledgments: Own the signed or otherwise documented acknowledgments, and decide what happens to access when an acknowledgment is missing.
Review decisions: Set the review frequency, run the reviews, and record what changed and why.
Accountable owner: Name the role that answers assessor interviews about these rules.

Before engaging any outside party, confirm that these decisions have named owners and that the review frequency is written down.

Where 03.15.03 usually fails and how to close each gap

Most 03.15.03 findings come from rules that exist on paper but do not reach the people who use the system, or from acknowledgments that cannot be proven later. The six gaps below share a root cause: the organization can describe its rules of behavior but cannot show who received which version, when, and whether they agreed before access was granted.

Rules buried in general acceptable-use policy

A general acceptable-use policy often covers email and internet use but never addresses CUI handling, remote sessions, or the specific systems in the boundary. Assessors look for rules that describe responsibilities and expected behavior for system use and protecting CUI. Fix this by writing a short, standalone rules of behavior document for the CUI system, scoped to its users, tools and data types, and linking it from the system security plan. Check that every rule can be tested against something you actually operate.

Acknowledgments collected after access

The requirement is sequential: people must acknowledge the rules before they are authorized to access CUI or the system. Many organizations grant accounts during onboarding and send the rules later, which leaves a gap an assessor will find by comparing account creation dates with signature dates. Fix this by making acknowledgment a gate in the provisioning workflow, so no account with CUI access is activated until the signed record exists.

No record linking signature, person and version

A signed PDF in a shared folder does not show which person signed, which version of the rules they accepted, or when. If the rules change, you cannot prove who agreed to the current text. Fix this by storing each acknowledgment with the user identity, the document version, and a timestamp in a system you can export, and by keeping prior versions so historical signatures stay tied to the text that was in force. XWiki and BookStack both keep page history, but confirm that your chosen tool records who changed the document and when.

Review frequency never set as a value

03.15.03 has one organization-defined parameter: how often the rules of behavior are reviewed and updated. Organizations often write 'periodically' or 'as needed', which gives an assessor nothing to test. Fix this by choosing a specific interval, recording it in the rules document and the policy set, and keeping a dated review log that shows the review happened. Since the parameter is yours to assign, confirm with the federal agency or contracting officer whether they have specified a value.

Contractors and managed service staff left out

Subcontractors, managed service providers and temporary staff often hold administrative or support access to the CUI environment but never see the organization's rules. Their accounts sit outside the normal onboarding path, so no acknowledgment exists. Fix this by inventorying every identity with access to the system, including external accounts, and requiring the same signed acknowledgment before access is granted. Put the requirement into contracts and subcontract flow-down language so the external party can produce the records on request.

Viewed training mistaken for acknowledgment

A learning platform may mark a training module complete when a user opens it, which proves exposure but not agreement. An assessor testing 03.15.03 looks for documented acknowledgment that people have read, understood and agree to abide by the rules, and a view event does not show any of those three things. Fix this by pairing training completion with a separate, explicit acceptance step, such as a required attestation after the rules are displayed. In Moodle, activity completion can be set to require a manual tick, but confirm that the record meets your evidence standard before relying on it.

Questions buyers ask about 03.15.03 rules of behavior

Is 03.15.03 rules of behavior part of CMMC Level 2?

No. NIST maps no Rev. 2 requirement to 03.15.03, so CMMC Level 2, which assesses the 110 Rev. 2 requirements, has no matching requirement ID. The requirement is new in Rev. 3, and NIST's change analysis lists it as one of 19 new requirements. Its source control, PL-4 from SP 800-53 Rev. 5, had been tailored out of Rev. 2 as a control expected to be implemented without being specified. Contracts that reference Rev. 3 may still expect you to meet it, so confirm with the contracting officer which revision applies to your agreement and whether the Rev. 2 baseline is the one being assessed.

How long does it take to write and roll out rules of behavior?

The duration depends on how many systems, user groups and access types the rules must cover, and on how many approvals the organization needs before publishing. The work needs a security or compliance lead to draft the rules, an owner who can accept them for each system, HR or legal review for wording on discipline and monitoring, and a process to collect signed acknowledgments before access is granted. No duration is set by the requirement itself, so ask any partner for a written schedule tied to a defined scope. The rules should be drafted after the system boundary is settled, because the rules describe use of that specific system and CUI.

Can we write our own rules of behavior without outside help?

Yes. The requirement does not call for an external author, and an internal team that knows its systems can write and maintain the rules. What matters for assessment is that the rules describe responsibilities and expected behavior for system use and for protecting CUI, that they reach the people who need access, and that each person's documented acknowledgment is on file before access is authorized. An assessor will examine the rules, the signed acknowledgments and the process for reviewing and updating them, and will interview the people responsible for those tasks. An outside partner can help draft and set up the process, but the organization owns the rules and the acknowledgments.

What drives the cost of meeting 03.15.03?

The cost comes mainly from people's time, not from software. The main drivers are the number of systems and user populations in scope, the number of distinct access types (for example, administrators, contractors and remote users), how many policy and legal reviews the wording needs, and how the acknowledgment process is built into onboarding and access provisioning. One-time costs include drafting the rules and designing the acknowledgment workflow. Recurring costs include reviewing and updating the rules at your chosen frequency, collecting acknowledgments from new users and changes in role, and keeping evidence ready for the assessor. Ask any quote to itemize these components and to state who performs each one.

Do rules of behavior have to be separate from the acceptable-use policy?

The requirement does not say that the rules must be a separate document, but it does require rules that describe responsibilities and expected behavior for system use and for protecting CUI, and it requires a documented acknowledgment before access is granted. Many organizations keep one acceptable-use policy for the whole enterprise and add a shorter, system-specific rules of behavior document for CUI systems. Either approach can work if the content covers the required elements and the acknowledgments are specific to those rules. Confirm with your assessor how they want the rules identified, since a combined document can make it harder to show that users agreed to the CUI-specific terms.

How often should rules of behavior be reviewed, and what is the ODP?

The review frequency is an organization-defined parameter (ODP), which is the single ODP for 03.15.03. You choose the interval and document it in your policies, and the assessor checks that a value is defined. NIST does not assign the value, and if a federal agency does not specify one in the contract or agreement, the nonfederal organization must set it to complete the requirement. Pick an interval you can keep, and review the rules sooner after a significant change such as a new system, a new type of user or a change in the CUI handled. Confirm any agency-specified value with the contracting officer before you finalize it.

What can an outside partner do for the 03.15.03 assessment, and what can't it do?

An implementation partner can help you draft the rules, design the acknowledgment and review workflow, configure the systems that hold the documents and acknowledgments, and organize the evidence that an assessor will examine. DeployOpen works this way: it prepares systems, controls and evidence for compliance assessments inside your own environment, under a fixed scope agreed in writing. It cannot issue an assessment result, report or certification. Those come only from the assessor or the body the contract requires, and the organization remains responsible for its controls. Ask your contracting officer which assessment applies to your contract before agreeing on scope.

Which tools can store rules of behavior and show who acknowledged them?

Any system that keeps versioned documents and records user actions can help. A wiki or knowledge base with version history can show each revision, who changed it and when, and let you roll back. Open-source platforms such as XWiki record every change to a page and let users compare versions. BookStack assigns abilities by role, which helps restrict editing of the rules to named owners. Moodle's activity completion can record that a learner has viewed or ticked off a module, which can support acknowledgment tracking for training, though it is not a substitute for a signed acknowledgment unless your process says so. Confirm with your assessor that the record you keep meets the evidence they expect.

How DeployOpen scopes and prepares 03.15.03 evidence

DeployOpen helps organizations put the 03.15.03 rules of behavior in place inside their own systems and document the evidence an assessor will ask for. The organization owns the rules and the acknowledgments; DeployOpen prepares the systems, documents and records that show the requirement is met. Only an independent assessor can issue an assessment result.

How we scope

Scope names the systems, user groups and CUI workflows the rules of behavior must cover, agreed in writing before work starts.
The written scope sets the review frequency for the 03.15.03 ODP, which the organization must choose and approve.
Scope lists which acknowledgment records, policies and interview roles the organization will provide for examination.

How we build

We draft rules of behavior for system use and CUI handling, tailored to the roles and tools in the client environment.
We configure the documentation platform so rule versions, approvals and reviews are recorded with who changed them and when.
We set up an acknowledgment workflow so access is not granted until each user records agreement to the current rules.

How we hand over

Handover includes the rules, a dated version history and a record of the review frequency and responsible owners.
We provide an evidence index mapping each examine, interview and test item for 03.15.03 to the artifact that answers it.
Handover includes a short runbook for onboarding, offboarding, rule updates and re-acknowledgment after changes.

How we support

Ongoing support and upgrades are available as a retainer, covering rule updates and refreshed acknowledgment records.
Retainers can include periodic checks that acknowledgments exist for every active user with CUI access.
Support scope, response expectations and fees are confirmed in writing; we do not publish a price list.