Independent DIB implementation resource — not affiliated with or endorsed by the U.S. Department of WarView the official DoW campaign ↗
Brilliant at the BasicsDIB Resource Center
3.1.2OFFICIAL STATEMENT BELOWBASIC REQUIREMENTPENDING NIST SME REVIEW

3.1.2 — Transaction and function control

3.1 Access Control · NIST SP 800-171 Rev. 2 · The heading label is this site's navigational shorthand; the official language is the statement below.

Official requirement statement (verbatim)

Limit system access to the types of transactions and functions that authorized users are permitted to execute.

NIST SP 800-171 Rev. 2 — Protecting CUI in Nonfederal Systems ↗NIST SP 800-171A — Assessing Security Requirements for CUI ↗
Independent interpretation

What this requirement is after

Getting in is not the same as doing anything you like once inside. Each authorized user is limited to the transactions and functions their role actually needs — the bookkeeper cannot open engineering drawings, and the machinist cannot touch payroll.

Across revisions

Carried into Rev. 3's Access Enforcement (03.01.02), which frames the same substance as enforcing approved authorizations for all access.

Mapped practices

Brilliant at the Basics practices that support this requirement

Partial implementation supportModerate confidence

Why: Restricting engineering functions — the ability to alter control logic — to authorized staff is limiting the types of functions authorized users may execute, which is this requirement's substance applied to production systems.

What this does not claim: Applies only to OT systems inside the CUI boundary, and only to the function classes OT platforms expose; many legacy controllers cannot distinguish operator from engineer at all, leaving physical and procedural limits to carry the intent. Transaction and function limits across business applications and file systems are entirely outside this practice.

Practice-side activities
  • Restrict engineering and configuration functions to named, authorized individuals
  • Separate operator, engineering, and administrative roles where the platform allows it
Evidence this produces
  • Role or privilege configuration exports from OT platforms that support them
  • The documented list of personnel authorized for engineering functions

Where this holds: Holds only for OT systems within the organization's CUI boundary.

Review status: Pending NIST SME review · Reviewed by Brilliant at the Basics editorial — practitioner-authored; NIST SME review pending · updated 2026-08-06

Doing the work

Implementation considerations and evidence

Implementation considerationsIndependent guidance — tailor to your environment
  • Define a small set of roles and map what each may do before touching permissions; permission sprawl is easier to prevent than to unwind.
  • Enforce in the systems themselves — file share and application permissions, admin function restrictions — not just in a policy document.
  • Review the mapping when people change roles; movers accumulate access unless something takes it away.
What operating evidence looks likeRecords worth retaining, not a submission checklist
  • A role-to-permission mapping with an owner and a review date
  • Permission exports from file shares and key applications matching the mapping
  • Records of access adjusted after role changes

Suggested owners, derived from the mapped practices and artifacts: Plant / OT leader · IT leader. Ownership is a named person in your organization, not a role on a website.

Artifacts

Templates and worksheets with a mapped relationship

WORKSHEET · REVIEW QUARTERLY FOR STANDARD ACCESS; MONTHLY FOR PRIVILEGEDPeriodic Access Review Worksheet
The other revision

Where this lands in Rev. 3

Provenance

Sources and review status

Primary sourcesNIST SP 800-171 Rev. 2 — Protecting CUI in Nonfederal Systems · NIST SP 800-171A — Assessing Security Requirements for CUI
Review statusPending NIST SME review
Content version1.0
Updated