Skip to content
ControlVerdict
Sign in
AC.L2-3.1.2CMMC Level 2Level 2

Transaction & Function Control

Submit your own example

Practice statement

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

Quoted verbatim from NIST SP 800-171 Rev. 2 §3.1.2.Source

The source document’s non-normative “Discussion” section is not reproduced here. ControlVerdict quotes normative text verbatim or omits it — it never paraphrases a standard. Follow the source link above for the full context.

Assessment Objectives(2)

An assessor determines each objective separately. “Mostly implemented” is not a result — every objective below has to stand on its own.

  1. [a]

    the types of transactions and functions that authorized users are permitted to execute are defined; and

    1 example covers this

  2. [b]

    system access is limited to the defined types of transactions and functions for authorized users.

    1 example covers this

Objective text quoted verbatim from NIST SP 800-171A via the CMMC Level 2 assessment guide.

Implementation examples(1)

Submit your own example
  • addresses
    AC.L2-3.1.2Transaction & Function Control
    Limit system access to the types of transactions and functions that authorized users are permitted to execute.

    • [a]

      the types of transactions and functions that authorized users are permitted to execute are defined; and

    • [b]

      system access is limited to the defined types of transactions and functions for authorized users.

    App roles and denied APIs: users only get the transactions their job needs

    ControlVerdict Corpus@cv-corpusOSCJul 31, 2026
    Community is just starting — add yours. Only 2 verdicts so far.Last verdict Aug 2, 2026

    Implementation

    AO coverage. Addresses both Transaction & Function Control objectives.

    Function catalog. For each CUI app, security and the app owner maintain a matrix of job functions → app roles (read, contribute, admin). “Admin” roles are eligible-only and time-bounded.

    Enforcement. SSO asserts group → role mapping. Users cannot self-elevate inside the app; role changes require a ticket approved by the data owner and provisioned by IT (separate people).

    Denied by default. APIs and UI actions that export bulk CUI or change sharing are limited to the contribute/admin roles. Read-only users cannot invoke those transactions.

    Maintenance. Semi-annual review of the matrix against actual role assignments. After vendor feature releases, re-check that new privileges did not land in the default role.

    Accepted gap. One legacy web form inside a SaaS app cannot hide a “share externally” button for read-only users. DLP blocks external share of labeled files; the button remains but the action fails closed.

    What the evidence looks like

    • Job-function → app-role matrix signed by the data owner
    • IdP group-to-role mapping export
    • Sample ticket showing requester ≠ provisioner for a role change
    • Test notes showing read-only user cannot complete bulk export

    Environment

    Small OSC (~80 people); CUI in two SaaS apps behind SSO; no custom code in enclave.

    Tools

    2 ratings on this revision

    • AlignedControlVerdict Assessor@cv-assessorAug 2, 2026

      Across the finish line

      Separating standing admin from just-in-time elevation with ticket linkage is testable. Good model for a small OSC.

    • AlignedControlVerdict Consultant@cv-consultantConsultantAug 2, 2026

      Across the finish line

      Transaction-based access with explicit deny for standing privileges is a clean read of the objective. Evidence list matches what I would sample.

Discussion(0)

No discussion on this control yet

Edge cases, scoping questions, and “would this pass?” scenarios belong here.

Sign in to start a thread.