| Field | Value |
|---|---|
| Control ID | AC-16 |
| Control Name | Security and Privacy Attributes |
| Framework | NIST SP 800-53 Revision 5 |
| Control Family | Access Control |
| Baselines | — |
| Relevance | Organization — First Party and Third Party |
| Risk Severity | Medium |
What this control requires
AC-16 requires organizations to assign and maintain metadata attributes that describe the security and privacy properties of all information they store, process, or transmit. You aren’t just classifying data at rest. You’re ensuring that attributes travel with information throughout its entire life cycle, so access decisions and information flow enforcement remain consistent.
In practice, this requirement means your organization needs five distinct capabilities. First, you must provide a mechanism to associate defined attribute types with defined attribute values for all information states. Second, those associations must persist with the information itself, not just in a separate lookup table.
Specifically, you must also formally establish which attributes and which value ranges are permitted for each system in scope. Your organization must audit every change to attribute values and review the full set of attributes for continued applicability on a recurring schedule. The review cycle catches drift that occurs when systems evolve, data classification policies change, or regulatory requirements shift.
Why it matters
Most organizations treat data classification as a one-time labeling exercise during onboarding. The result is a growing gap between that initial label and the ongoing enforcement decisions that depend on it. When attribute associations break down, access controls that reference those attributes stop working correctly, and you lose the ability to demonstrate consistent information flow governance across your environment.
In practice, this gap means audit risk and potential certification withdrawal or regulatory findings. Assessors specifically look for evidence that attribute values are bound to information objects and that changes to those bindings are logged. Without that evidence trail, your organization can’t prove that its access policies are enforced as designed.
The consequence extends to privacy compliance as well. Privacy attributes govern how personally identifiable information (PII) is processed, retained, and shared, and frameworks like ISO 27002 reinforce the need for structured attribute management. If those attributes are missing or stale, your data handling practices may violate the processing permissions you’ve documented in your privacy plan.
But the problem goes deeper than compliance gaps alone. Systems that rely on attribute-based access control (ABAC) will make incorrect authorization decisions when the underlying metadata is incomplete or outdated.
Attackers and auditors alike exploit weaknesses in attribute management through the following vectors:
- Stale or missing classification labels that allow sensitive information to flow through unprotected channels
- Attribute associations that don’t persist across system boundaries, creating gaps where data moves between environments without its security context
- Unaudited attribute changes that let privilege escalation go undetected
- Overly broad attribute value ranges that grant access beyond the intended scope
- PII processing attributes that fall out of sync with published privacy notices, exposing the organization to regulatory action
How to implement
Attribute management fails most often when organizations treat it as a documentation exercise rather than an operational capability. The challenge is building a system that assigns, binds, and maintains attributes at the speed your data actually moves, not just at the speed your compliance team reviews spreadsheets.
For your organization
In practice, that means building your attribute taxonomy first. Inventory every security and privacy attribute type your access control policies require, such as classification level, impact level, data life cycle stage, PII processing permissions, and access authorization tier. For each type, define the permitted values or value ranges.
Take classification as an example: permitted values might include “public,” “internal,” “confidential,” and “restricted.” A PII processing permission attribute might allow “consent-based,” “contract-based,” or “legal-obligation.”
The consequence of defining attributes without binding them is that your policies exist only on paper. Implement binding mechanisms in each system that stores or processes controlled information, so the attribute value is associated directly with the information object. In databases, this binding often takes the form of metadata columns or tagging schemas.
Specifically, in file systems, extended attributes or dedicated metadata stores serve the same purpose. The critical requirement is that the association persists when information moves between systems or changes state.
The result of all this binding work needs to be auditable. Your security information and event management (SIEM) system or logging platform should capture every attribute modification event, recording who changed the attribute, the previous value, the new value, and the timestamp.
Where this process breaks down is in environments without a defined review schedule. AC-16 requires periodic review of attribute applicability, so define the frequency in your access control policy. Quarterly reviews work for most environments, but high-change environments may need monthly cycles.
Specifically, during each review, verify that the attribute taxonomy still reflects current policy, that value ranges haven’t drifted, and that deprecated attributes are retired.
The result of all this work must be captured in writing. Your system security plan should describe the attribute types, permitted values, binding mechanisms, and review schedule. Assessors will cross-reference this documentation against your technical implementation and audit logs.
For your vendors
When evaluating a vendor’s AC-16 posture, focus on whether they can demonstrate a functioning attribute management capability, not just a written policy.
In practice, this assessment starts with the vendor’s data classification policy. Confirm it defines specific attribute types and permitted values. A policy that says “data will be classified” without listing the actual classification levels and their definitions is insufficient.
Specifically, probe how attributes are bound to information objects within their systems. Vendors using attribute-based access control should be able to describe how their systems associate metadata with data objects and how that metadata survives data movement or transformation.
The result of poor attribute management is usually visible in the audit logs. Request sample audit records that show attribute modification events with timestamps, actor identification, and before-and-after values. If the vendor can’t produce these records, their attribute management is likely manual and inconsistent.
But logging alone isn’t sufficient without a review cycle. Ask when the vendor last reviewed their attribute taxonomy for applicability and request evidence of that review, such as meeting minutes or updated policy documents. A vendor that hasn’t reviewed their attributes in over a year represents a compliance gap.
Where this process breaks down most visibly is in vendors who conflate data classification with monitoring alone, whose attribute values don’t align with the data types they actually handle, or who can’t demonstrate that attribute associations persist across their internal systems.
Evidence examples
Assessors verify AC-16 by examining artifacts that demonstrate your organization’s attribute management capability across the full life cycle, from policy definition through ongoing monitoring.
| Evidence Type | Example Artifact |
|---|---|
| Access control policy | Policy document defining attribute types (classification levels, PII processing permissions), permitted values, binding requirements, and review frequency |
| Attribute association procedures | Documented procedures describing how security and privacy attributes are assigned to information in storage, in process, and in transmission |
| System design documentation | Architecture diagrams and data flow models showing where and how attribute bindings are implemented across systems |
| System configuration settings | Screenshots or exports of metadata schemas, tagging configurations, and ABAC policy rules that enforce attribute-based decisions |
| Audit records | SIEM or log entries showing attribute creation, modification, and deletion events with actor, timestamp, and before-and-after values |
| System security plan and privacy plan | Plan sections describing the attribute taxonomy, permitted value ranges, binding mechanisms, and the defined review schedule |
Cross-framework mapping
No cross-framework mappings are currently configured for this control.
Related controls
- AC-03, Access Enforcement. Access enforcement mechanisms rely on the attribute associations that AC-16 establishes to make authorization decisions.
- AC-04, Information Flow Enforcement. Information flow policies reference security and privacy attributes to determine whether data can move between systems or domains.
- AC-06, Least Privilege. Attribute values help define the boundaries of least-privilege access by linking users and processes to specific authorization tiers.
- AC-21, Information Sharing. Sharing decisions depend on attribute values that indicate whether information can be released to external parties.
- AC-25, Reference Monitor. The reference monitor validates attribute associations as part of mediating every access request.
- AU-02, Event Logging. AC-16 requires auditing attribute changes, and AU-02 defines what events the organization must log.
- AU-10, Non-repudiation. Non-repudiation mechanisms protect the integrity of attribute audit trails by preventing actors from denying modifications.
- MP-03, Media Marking. Media marking is the human-readable counterpart to internal attribute labels, ensuring physical media reflects the correct classification.
- PE-22, Component Marking. Component marking extends attribute visibility to physical system components, supporting consistent classification awareness.
- PT-02, Authority to Process Personally Identifiable Information. Privacy attributes defined under AC-16 must align with the processing authorities documented under PT-02.
Frequently asked questions
What is NIST SP 800-53 AC-16?
AC-16 is the NIST SP 800-53 control that requires organizations to associate security and privacy attribute values with information in storage, in process, and in transmission. The control covers the full attribute life cycle, from defining permitted attribute types and value ranges to binding those values to information objects and auditing every change.
It ensures that access enforcement and information flow decisions operate on reliable, current metadata rather than assumptions about data sensitivity. Organizations must also review their attribute taxonomy on a defined schedule to confirm it still reflects operational and regulatory requirements.
What happens if AC-16 is not implemented?
Without AC-16, your organization loses the metadata foundation that attribute-based access controls depend on. Access enforcement systems can’t reliably distinguish between classification levels or PII processing permissions when attribute associations are missing or inconsistent.
Assessors will flag the absence of attribute binding evidence and audit records as a finding, which may jeopardize your authorization to operate. The gap also undermines your ability to demonstrate compliance with privacy regulations that require documented data processing controls, as described in your privacy plan.
How do you audit AC-16?
Auditing AC-16 starts with verifying that your organization has defined the permitted security and privacy attribute types and their value ranges for each system in scope. Assessors will review your access control policy, system security plan, and system configuration settings to confirm that binding mechanisms exist and function as documented.
They’ll also examine audit records for evidence that attribute changes are captured with actor identification, timestamps, and before-and-after values. Finally, auditors verify that your organization conducts periodic reviews of attribute applicability at the frequency defined in your policy, using documented review artifacts as proof.
What is the difference between security labels and security markings?
Security labels are the internal, machine-readable associations between attribute values and information objects within a system. Labels enable automated policy enforcement by allowing systems to evaluate classification levels, impact categories, or processing permissions during access decisions.
Security markings, by contrast, are the human-readable representations of those same attributes displayed on physical or digital media. A label might exist as a metadata tag in a database, while the corresponding marking appears as a banner on a printed document or a visual indicator in a user interface. AC-16 addresses the establishment and management of the underlying attribute associations that both labels and markings represent.