AC-16(2): Attribute Value Changes by Authorized Individuals

AC-16(2) requires you to ensure only authorized individuals (or approved automated processes acting for them) can define or change security and privacy attribute values used in access decisions. Operationalize it by tightly scoping who can change attributes, enforcing approved change paths, logging every change, and routinely reviewing changes for appropriateness. ¹

Key takeaways:

• Treat attribute changes as privileged actions with explicit authorization, workflow, and auditability. ¹
• Control both “who can change attributes” and “how attributes get changed” across IdP, IAM, apps, data platforms, and cloud policy engines.
• Evidence must show capability + restriction + traceable change history, not just policy statements.

Security and privacy attributes (department, role, clearance, data classification, purpose of use, residency, consent flags) drive real access outcomes in modern systems: ABAC, RBAC with tags, cloud IAM conditions, and data lake row-level security. AC-16(2) focuses on a narrow but high-impact requirement: attribute values must be definable and changeable only by authorized individuals, including authorized processes acting on their behalf. ¹

For a CCO or GRC lead, the fastest path is to map where attributes live, designate attribute owners, and lock down write access plus change paths. Then you prove it with logs, approvals, and periodic review. If you cannot answer “who can change ‘classification=restricted’ in the data catalog?” or “what stops an admin from setting their own ‘role=superuser’ attribute?”, you have an AC-16(2) gap.

This page is written as implementation guidance: what the requirement means, who it applies to, how to implement it step-by-step, what evidence auditors ask for, and how to avoid common failures that show up during federal assessments and customer due diligence.

Regulatory text

Requirement (verbatim): “Provide authorized individuals (or processes acting on behalf of individuals) the capability to define or change the value of associated security and privacy attributes.” ¹

Operator interpretation (what you must do):

1. Identify the security and privacy attributes your environment uses to make access, authorization, or privacy enforcement decisions.
2. Ensure there is a defined, controlled capability to create/change attribute values (you can actually administer them).
3. Restrict that capability to authorized individuals (and approved automation tied to those individuals), so attribute values cannot be changed arbitrarily. ¹

This is not a “write a policy” control. You must demonstrate that attribute write operations are technically and procedurally constrained.

Plain-English requirement meaning (AC-16(2))

Attributes are inputs into access control and privacy decisions. If the wrong person can change attribute values, they can often grant themselves access without triggering your normal access request process.

AC-16(2) expects:

• A short list of who is allowed to set/change specific attributes (by attribute type).
• A controlled mechanism to make changes (admin console with MFA, privileged workflow, HR feed, ticket-to-change automation, API with service account controls).
• A record that shows what changed, who changed it (or which process), when, and why.

Who it applies to

Organizations / systems:

• Federal information systems and programs using NIST SP 800-53 as the control baseline.
• Contractor systems handling federal data (including environments aligned to NIST 800-53 through contracts and flowdowns). ¹

Operational contexts where AC-16(2) is most “real”:

• Centralized identity and access management: IdP/IAM directories, HR-driven identity lifecycle.
• Cloud IAM using tags/attributes and conditional policies (for example, environment tags, project tags, data sensitivity labels).
• Data platforms: data catalogs, lakehouses, DLP tools, row/column-level security based on classifications.
• Privacy enforcement: consent flags, processing purpose, residency tags, retention/hold flags.

If you use attributes only informally (spreadsheets, wikis), you still have risk. Auditors will push for governance and authoritative sources.

What you actually need to do (step-by-step)

Step 1: Build an attribute inventory (authoritative map)

Create a simple register with:

• Attribute name (e.g., role, department, data_classification, geo_residency, consent_status)
• Where it is stored (IdP directory, HR system, app database, cloud tag store, data catalog)
• What it controls (app access, privileged access, data access, privacy rule)
• Source of truth (HR feed, manager attestation, privacy office, data owner)
• Change method (UI, API, SCIM, ETL job)
• Owner (role title, not a person)

Deliverable: “Security & Privacy Attribute Register” (version-controlled).

Step 2: Assign “attribute owners” and “attribute custodians”

Separate governance from operations:

• Owner approves semantics and who is allowed to change (often HR, Security, Privacy, Data Governance).
• Custodian operates the mechanism (IAM team, platform team, app admin team).

Document owner/custodian per attribute in the register. This becomes your “authorized individuals” roster by function.

Step 3: Define authorization rules for attribute changes

For each attribute, define:

• Who can request a change (manager, HR, data owner, privacy office)
• Who can approve the change (owner or delegate)
• Who can execute the change (custodian or automation)
• What evidence is required (HR event, ticket, data owner approval)
• Segregation of duties requirements for high-risk attributes (example: no self-approval, no self-execution)

Keep the rules short and implementable. A table works best:

Attribute	Risk level	Approver	Executor	Allowed trigger
role=Privileged	High	Security	IAM Ops	Approved access request
data_classification	High	Data Owner	Data Gov Ops	Data onboarding/change ticket
department	Medium	HR	HRIS feed	HR job change

Step 4: Lock down the technical write paths

Auditors will test whether a user (or admin) can bypass your workflow.

Minimum technical expectations:

• Restrict write permissions to attribute stores (directory attributes, cloud tags, app tables, catalog fields).
• Require strong authentication for administrators and operators (commonly MFA plus privileged access controls).
• Disable ad-hoc backdoors (shared admin accounts, direct DB writes, “break glass” without logging).
• Constrain automation:
  • Service accounts must be uniquely identified.
  • Limit scopes to only the attributes they manage.
  • Tie runs to a change request, HR event, or job ID where possible.

Practical example: If HR is the source of truth for department, the only system allowed to change it should be the HRIS-to-IdP provisioning process (with a controlled service account), not helpdesk admins manually editing user profiles.

Step 5: Implement change logging and reviewability

AC-16(2) is about capability and authorization, but you will struggle to prove it without audit trails.

Put in place:

• Attribute change logs from the systems of record (IdP audit logs, cloud audit logs, app audit logs, data catalog audit events).
• Central retention (SIEM or log archive) with searchable fields: who/process, attribute, old value, new value, timestamp, target object.
• Periodic review of changes for high-risk attributes (privileged roles, classifications, privacy flags). Review sampling is acceptable if volume is high; define your sampling method and keep it consistent.

Step 6: Write the “control card” operators can run

Create a one-page control card:

• Objective: only authorized individuals/processes can change attribute values.
• Scope: list attribute systems and high-risk attributes.
• Trigger events: onboarding, role change, data onboarding, reclassification, privacy request.
• Execution steps: request → approval → change → verification → logging.
• Exceptions: emergency changes, incident response (define who approves after the fact and what evidence is required).

This is the artifact auditors and customers can read in minutes.

Step 7: Prove it with a repeatable evidence bundle

Define and standardize the minimum evidence bundle per cycle (monthly/quarterly, or per significant change type):

• Role-based access list for attribute admin functions
• Sample attribute change tickets with approvals
• System audit logs showing the executed change
• Review sign-off for the change review activity
• Exception log (if any) and closure evidence

If you use Daydream to manage your control operations, store the control card, attribute register, evidence bundle checklist, and review tasks in one place so you can produce audit-ready evidence quickly and consistently.

Required evidence and artifacts to retain

Retain evidence that demonstrates design (rules) and operation (real changes occurred through authorized paths):

1. Security & Privacy Attribute Register (current and prior versions)
2. Role/permission mappings for each attribute store (screenshots/exports of admin roles/groups)
3. Procedure / runbook (the control card)
4. Change records:
   • tickets/requests
   • approvals (manager, data owner, privacy office, security)
   • implementation confirmation
5. Audit logs proving the change event (who/process, old/new values if available)
6. Periodic change review records (sampling list, reviewer, findings, remediation tickets)
7. Exception documentation (emergency change rationale, compensating approvals, post-change review)

Common exam/audit questions and hangups

Expect these questions, and prepare crisp answers plus evidence:

• “Which attributes are used for authorization decisions, and where are they mastered?”
• “Who can change privileged role attributes? Can they change their own?”
• “Show me a recent attribute change end-to-end: request, approval, implementation, log entry.”
• “What automated processes change attributes? How are service accounts governed?”
• “How do you detect unauthorized attribute changes or drift?”
• “How do you ensure attributes remain accurate over time (especially for contractors and third parties)?”

Hangup pattern: teams can show access request workflows for application roles, but not for “attributes” that live inside the IdP, cloud tags, or data catalog. AC-16(2) covers those.

Frequent implementation mistakes (and how to avoid them)

1. No attribute inventory. You cannot control what you cannot name. Fix: create the register and keep it current with your onboarding/change processes.
2. Over-broad admin roles. “Directory Admin” can change everything, including high-risk attributes. Fix: split roles; restrict write permissions by attribute where your platform allows it; add compensating approvals and monitoring where it does not.
3. Self-service edits without governance. Allowing users to edit fields that influence access (title, department, group) creates an escalation path. Fix: clearly separate “profile fields” from “authorization attributes.”
4. Automation with unlimited scope. Provisioning scripts that can write any attribute become a hidden super-admin. Fix: least-privilege scopes, code ownership, change control, and audit logs.
5. Logging exists but is not reviewable. Logs that are not retained, searchable, or reviewed fail under examination. Fix: define your evidence bundle and review cadence; test retrieval during control health checks.
6. Policy-only compliance. A policy that states “only authorized users can change attributes” will not survive an assessor walkthrough. Fix: show enforced permissions plus real change records.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not list specific actions.

Risk still matters and is easy to explain to executives: attribute changes can become a quiet privilege escalation route. If an attacker (or internal admin) changes role, group, classification, or a privacy flag, they can bypass approval workflows and gain access to regulated data or disable controls. That drives confidentiality incidents, audit findings, and contract noncompliance risk in federal contexts aligned to NIST SP 800-53. ²

Practical execution plan (30/60/90)

First 30 days (stabilize and scope)

• Build the attribute register for your top systems (IdP/IAM, cloud IAM, data platform, key apps).
• Identify high-risk attributes (privileged roles, data classifications, privacy/consent flags).
• Export current admin role memberships for each attribute store and confirm owners.
• Turn on and validate audit logging for attribute changes where possible; confirm retention location.

Next 60 days (control the change paths)

• Implement role restriction and least privilege for attribute write access.
• Standardize the request/approval workflow for high-risk attribute changes (tickets + approvals).
• Govern automated processes (service account scope, ownership, change control, logging).
• Write the control card and define the minimum evidence bundle.

By 90 days (prove operation, close gaps)

• Run the first attribute change review and document results plus remediation items.
• Test an auditor walkthrough: select a change and produce the end-to-end evidence in one sitting.
• Add control health checks (permission drift checks, admin group review, logging verification).
• Track remediation to closure with dated evidence.

Frequently Asked Questions

What counts as a “security or privacy attribute” for AC-16(2)?

Any value your systems use to make access or privacy decisions, such as roles/groups, clearance, data classification tags, residency, or consent flags. Start with attributes referenced in policies (cloud IAM conditions, ABAC rules, row-level security rules).

Do automated provisioning jobs satisfy “processes acting on behalf of individuals”?

Yes, if the process is authorized, scoped, and traceable to a legitimate trigger (for example, an HR event or approved ticket). You still need to restrict the service account and retain logs showing what it changed. ¹

If our IdP admins can edit any directory attribute, are we noncompliant?

It depends on whether those admins are the “authorized individuals” for each attribute and whether you can justify the breadth of access. For high-risk attributes, reduce scope where possible and add compensating approvals and monitoring where platform limits exist.

How do we handle emergency attribute changes (break glass)?

Define an exception path with who can approve, how you document rationale, and how you review after the fact. Keep an exception log and attach the audit log event for the actual change.

What evidence do auditors usually want first?

They typically start with your attribute inventory, the list of admins who can change key attributes, and one or two real attribute changes with approvals and system audit logs. A clean control card speeds up the walkthrough.

How does this relate to customer/vendor due diligence?

Enterprise and federal customers often test whether privilege and data classification controls can be bypassed through attribute manipulation. Showing restricted admin roles, controlled workflows, and change logs reduces friction in security reviews.

Footnotes

1. NIST SP 800-53 Rev. 5 OSCAL JSON

2. NIST SP 800-53 Rev. 5