AC-16(10): Attribute Configuration by Authorized Individuals

AC-16(10) requires you to ensure only explicitly authorized individuals can define or change the types and values of security and privacy attributes used by your systems to label subjects (users, services) and objects (files, records, resources). Operationalize it by centralizing attribute governance, limiting who can modify attribute schemas, and keeping auditable change records. ¹

Key takeaways:

• Treat attribute schema changes (new attribute types, allowed values) as high-risk configuration changes with strict access control.
• Assign a single accountable control owner and implement a formal attribute change workflow with approvals and logging.
• Retain concrete evidence: role assignments, configuration baselines, change tickets, and system logs showing who changed what and when.

The ac-16(10): attribute configuration by authorized individuals requirement is easy to misunderstand because many teams focus on “who can edit a user profile” rather than “who can change the attribute system itself.” AC-16(10) is about governance over the attribute catalog your environment relies on for access decisions, data labeling, privacy restrictions, and downstream enforcement. If someone can add a new sensitivity label, redefine what “Privileged” means, or expand allowed values for “Data Residency,” they can quietly bypass controls that depend on those attributes.

This requirement shows up in real operations wherever you use ABAC (attribute-based access control), policy engines, directory groups mapped to attributes, data classification labels, or privacy tags. It also shows up in third-party and federal data handling contexts where NIST SP 800-53 Rev. 5 is the baseline. Your goal is straightforward: limit attribute definition and modification authority to named roles, enforce that limitation technically, and prove it with durable evidence. ²

Regulatory text

Requirement (verbatim): “Provide authorized individuals the capability to define or change the type and value of security and privacy attributes available for association with subjects and objects.” ¹

What the operator must do:
You must (1) identify where security/privacy attributes are defined (schemas, catalogs, label taxonomies, directory attribute definitions, policy-engine attribute sets), (2) ensure only authorized individuals can modify those definitions, and (3) ensure the system actually supports those authorized individuals in performing the work (so changes don’t happen via informal backdoors). The focus is on attribute configuration authority and control over the “allowed set” of attribute types/values, not merely day-to-day assignment of an existing value to a user or file. ¹

Plain-English interpretation

AC-16(10) means: “Only the right people can change what attributes exist and what values are allowed, because those definitions drive access and handling rules.” If attribute definitions can be edited by anyone with broad admin access, you have a control gap even if your policies look correct on paper.

Think of attributes as the vocabulary your controls use. If someone can add new words or redefine them without oversight, they can change outcomes across access control, DLP, classification, privacy filtering, and audit reporting.

Who it applies to

Entity scope

• Federal information systems and contractors handling federal data that implement NIST SP 800-53 Rev. 5 controls. ²

Operational scope (where you will find this control in practice)

• Identity platforms: directory attributes, IdP claim mappings, HR-driven identity attributes, privileged access attributes.
• Authorization services / policy engines: ABAC policies, attribute dictionaries, policy bundles.
• Data systems: classification labels, database row-level security tags, object metadata used for access decisions.
• Privacy tooling: tags that drive masking/redaction, purpose limitation, consent-based access.
• DevOps / infrastructure: IaC modules that define tag keys/values used by guardrails (e.g., “environment=prod”, “data_class=restricted”).

If a third party hosts any of these components (SaaS IdP, policy engine, data platform), your obligation shifts to contract controls and due diligence: you still need to ensure authorized individuals have the capability and that change control is constrained and auditable.

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

1) Establish attribute governance boundaries (define “attribute configuration”)

Create a short scoping statement that distinguishes:

• Attribute configuration (AC-16(10) scope): creating/deleting attribute types (keys), changing allowed values, changing semantics/definitions, changing mappings (e.g., HR field → IdP claim), changing default values, changing inheritance/precedence.
• Attribute assignment (usually separate control coverage): setting a user’s department, assigning a label to a file, tagging a record with an existing value.

This boundary prevents audit confusion and stops teams from presenting the wrong evidence.

2) Build an authoritative inventory of attribute sources

Document every system where attribute types/values are defined or controlled, such as:

• Directory schema and custom attributes
• IdP/OIDC/SAML claim configuration
• Policy engine attribute dictionary
• Data classification taxonomy
• Privacy tags and rule dictionaries

For each source, capture: system owner, admin roles, where changes are made (UI/API/IaC), and where logs live.

3) Name the “authorized individuals” (roles, not people) and set least privilege

Define who is allowed to modify attribute types and values:

• Typical roles: IAM engineering, security architecture, data governance, privacy office, platform owners.
• Avoid broad “global admin” as the only answer; you need a narrower, reviewed admin role or a controlled “break-glass” path.

Then implement technical restrictions:

• RBAC roles that specifically allow schema/dictionary edits
• Separate admin consoles or projects for policy/schema management
• Conditional access for admin actions (strong auth, managed devices) where supported

4) Implement a formal attribute change workflow (request → review → approve → deploy)

Minimum workflow requirements:

• Intake: a ticket/request with business justification, attribute definition, allowed values, and expected impact.
• Review: security review for access-control impact; privacy review if privacy attributes change.
• Approval: a designated approver separate from the requester for high-impact attribute changes.
• Deployment: controlled release path (prefer IaC/PRs for policy dictionaries and schema-like configs).
• Validation: confirm downstream enforcement still behaves as intended.

If you run a GRC platform like Daydream, map AC-16(10) to a control owner, embed the workflow as the implementation procedure, and schedule recurring evidence collection so you are not reconstructing decisions during an assessment.

5) Log, monitor, and reconcile attribute configuration changes

Configure logging to capture:

• Actor identity (who)
• Action (create/update/delete attribute type/value)
• Target (which attribute, which value set)
• Timestamp
• Source IP / session metadata, if available

Add a lightweight reconciliation step: periodically compare current attribute catalogs against an approved baseline to detect drift.

6) Extend to third parties and managed services

Where a third party controls attribute configuration (common in SaaS):

• Contractually require role-based admin restriction, change logs, and access review support.
• Obtain evidence during due diligence (admin role definitions, audit logs, change records).
• Ensure your internal team still controls attribute taxonomy decisions, even if the third party operates the platform.

Required evidence and artifacts to retain

Keep evidence that proves both design (the control exists) and operation (it runs consistently).

Core artifacts (high value in audits)

• Attribute governance standard / procedure defining attribute configuration vs assignment
• Attribute catalog inventory (systems, owners, change paths)
• Role/permission matrix showing who can change attribute types/values in each system
• Access approvals for attribute-admin roles (joiner/mover/leaver records)
• Change tickets/PRs for attribute schema or allowed-value updates, with approvals
• Configuration baseline snapshots (before/after) or exported attribute dictionaries
• Audit logs showing actual attribute configuration changes and the responsible actor

Nice-to-have artifacts

• Risk assessment notes for major taxonomy changes
• Test results or validation notes showing policy outcomes after changes

Common exam/audit questions and hangups

Auditors and assessors tend to get stuck on a few points:

1. “Show me who is authorized.”
   Expect to produce a list of roles, the approval basis, and evidence that only those roles can perform attribute definition changes.

2. “Where are attributes defined?”
   If you miss one system (IdP claim mapping, DLP label dictionary, policy engine), the control looks incomplete.

3. “Prove it’s enforced technically, not just policy.”
   They will ask for screenshots/config exports and logs demonstrating denied access for non-authorized users, or at least role membership proof plus change logs.

4. “Differentiate configuration from assignment.”
   If you show user attribute edits (assignment) instead of attribute type/value changes (configuration), you will burn time and credibility.

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails	Avoid it by doing this
Treating “global admin” as the authorized individual set	Overbroad access creates easy bypass paths	Create a narrow “Attribute Schema Admin” role and time-bound elevation for exceptions
No inventory of attribute-definition systems	Changes happen outside your workflow	Maintain a living inventory and tie it to system onboarding/offboarding
Making changes only in a UI with no record	You can’t reconstruct intent or approval	Require tickets/PRs and store exports/snapshots
Confusing attribute assignment with configuration	Wrong evidence; control not met	Document the boundary and train assessable teams
No downstream impact review	A “harmless” attribute change can break access controls	Add mandatory security/privacy review steps for taxonomy changes

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so you should treat AC-16(10) as an assessment and assurance expectation rather than a commonly cited enforcement hook.

Operationally, the risk is concrete: attribute schemas and allowed values drive authorization and handling decisions. Weak control over attribute configuration can enable privilege escalation (by redefining privileged attributes), data overexposure (by downgrading classification values), or privacy violations (by altering privacy tags or their allowed states). ²

Practical 30/60/90-day execution plan

First 30 days (Immediate stabilization)

• Assign a control owner for AC-16(10) and name backup owners.
• Write a one-page “Attribute Configuration Standard” defining scope and approval expectations. ¹
• Inventory attribute-definition locations across IAM, policy engines, and data platforms.
• Identify who currently has the ability to change attribute types/values; freeze expansion of access until reviewed.

By 60 days (Control implementation and workflow)

• Implement or tighten RBAC so only approved roles can modify attribute schemas/dictionaries.
• Stand up a change workflow: ticket template, approvers, and required review steps.
• Turn on and validate audit logs for schema/dictionary changes; confirm retention location and access controls.
• Start collecting recurring evidence in Daydream (role membership exports, recent change tickets, sample logs).

By 90 days (Assurance and drift control)

• Baseline the attribute catalog(s) and store approved snapshots.
• Add periodic reconciliation against baseline and investigate drift.
• Run a tabletop: simulate a proposed new attribute type and ensure the workflow captures review, approval, and validated deployment.
• Prepare an assessor-ready evidence packet: inventory, roles, last changes, and representative logs.

Frequently Asked Questions

Does AC-16(10) mean only authorized people can edit user attributes in the directory?

No. AC-16(10) focuses on who can define or change the types and values of attributes available for association, like adding a new attribute or changing allowed values. Editing a user’s existing attribute value is typically “assignment,” which you should control, but it is not the enhancement’s main point. ¹

What counts as a “security and privacy attribute” in practice?

Any attribute that drives access decisions or handling rules qualifies, including role/entitlement attributes, data classification labels, residency tags, and privacy tags used for masking or purpose limitation. If a policy references it, treat it as in scope. ¹

We use SaaS tools. How do we meet AC-16(10) if we can’t control the backend?

Control what you can: restrict admin roles in the SaaS, require MFA/strong admin access, and enforce a documented change workflow with approvals. For what you can’t control, obtain vendor-provided logs and admin role documentation during due diligence and keep them as evidence.

Is an approval ticket enough evidence without system logs?

A ticket shows intent and approval, but auditors usually expect proof the change happened under authorized credentials. Keep both: the ticket/PR plus the system’s audit log or configuration change history showing the actor and the change.

How do we handle emergency attribute schema changes?

Use a break-glass role with time-bound access and mandatory after-the-fact review. Require an incident-style record: reason for emergency, exact changes made, and validation that access/privacy policies still behave correctly.

What’s the fastest way to become assessment-ready for AC-16(10)?

Create the inventory, lock down who can change attribute types/values, and produce a small set of evidence from the last few changes (approval record + config export + audit log). Then automate recurring evidence collection in Daydream so readiness doesn’t depend on heroics.

Footnotes

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

2. NIST SP 800-53 Rev. 5