AC-16 Security and privacy attributes: requirements and evidence

What AC-16 asks for and why most teams never selected it

If a baseline, contract or overlay has pulled AC-16 into your scope, or an assessor has asked how your labels follow data, this section explains what the control requires. AC-16 Security and privacy attributes asks the organization to define the security and privacy attributes and permitted values it uses, bind those attributes to information in storage, in process and in transmission, keep the bindings with the information, audit changes to attributes and review them periodically. No SP 800-53B baseline selects AC-16, which explains why most teams never implemented it: it appears in a profile only when the organization tailors a baseline or adopts an overlay that adds it.

The risk is straightforward. Information that carries no label cannot be handled according to its sensitivity, so a system that cannot read a handling rule will store, export or transmit it like any other data. A file marked restricted in one application may arrive in a reporting tool, a mail gateway or a data lake with no indication of what it is. The difficulty lies in persistence. A label must survive copies, exports, format conversions, database joins and transfers between systems, and each of those steps is a point where the attribute is commonly dropped. Teams that label only at creation discover the gap when an assessor traces a copy.

Before committing to AC-16, confirm which attributes your organization must carry (for example, classification levels or privacy handling markers), which systems must enforce them, and which transformations must preserve them. The NIST catalog entry at the CPRT catalog for AC-16 lists the assessment objects and related controls you should map against. Make that scoping decision in writing before you select tooling, because the attribute model drives every downstream control that consumes it.

Which systems and data AC-16 reaches when you tailor it in

AC-16 is not selected in any SP 800-53B baseline, so it reaches a system only when the organization or an overlay adds it. The cards below cover the scoping choices that decide how much work it creates, from information classes and system boundaries to how labels are applied.

Information classes that need attributes

Start by deciding which information actually needs security or privacy attributes, such as a classification label, a handling caveat or a privacy marking. AC-16 asks for defined attributes and values, so every class you name becomes a definition the organization must write, maintain and review. Check whether existing classification schemes already cover the data, and whether the list is limited to a few sensitive categories or extends to all records in a system.

Systems that store, process or transmit labeled data

Attributes must stay associated with information in storage, in process and in transmission. Map every system where labeled information sits, including databases, application workflows, message queues, file shares and interfaces to external parties. A system that strips or drops attributes during transfer breaks the association, so each hop in a data flow belongs in the scope.

Manual labeling versus system-applied labels

Decide whether people apply attributes by hand, whether applications assign them from rules, or whether a combination of both applies. Manual labeling produces inconsistent values and needs training and spot checks. System-applied labels need documented rules, tested logic and logs showing which attribute was set, by whom or by which process, and when it changed.

Overlay or tailoring as the source of scope

Because no SP 800-53B baseline selects AC-16, record whether it came in through a tailoring decision in the system security and privacy plan or through an overlay from a sector or agency. The source determines who approves the scope, which parameter values apply and which assessor expectations you must meet. Confirm the source with the authorizing official or the overlay owner before design work begins.

The 10 enhancements outside every baseline

AC-16 has ten enhancements, and SP 800-53B Release 5.2.0 selects none of them for the low, moderate, high or privacy baselines. Scope each enhancement explicitly, marking it in scope, out of scope or inherited, instead of assuming that adding the base control covers them. Each one that is in scope adds its own determination statements and evidence to the assessment.

Related controls that share the same evidence

The catalog links AC-16 to 16 related controls, including AC-3, AC-4, AC-6, AU-2, MP-3 and PT-2. Attribute checks at enforcement points depend on AC-3 and AC-4, audit records of attribute changes depend on AU-2, and media marking depends on MP-3. Note which related controls already run in your environment so that one set of logs, configurations and reviews serves both.

How an assessor tests AC-16

This table maps how an SP 800-53A assessment of AC-16 proceeds, from the three assessment methods to the evidence an assessor requests and the findings that usually cause a gap. Read it as a preparation checklist: each row names what the assessor looks for and what your team should have ready before fieldwork begins.

Assessment step	What the assessor does	Evidence to have ready
Examine policy and procedures	Reads the access control policy and procedures to confirm they address associating security and privacy attributes with information in storage, in process and in transmission.	Access control policy, procedures and any data labeling or classification standard that names the attributes in use.
Define permitted attributes and values	Checks that the organization has defined which attributes and values are permitted, so that the set is bounded and not left to individual users.	Attribute definitions, approved value lists and the owner who approves changes to them.
Interview administrators	Interviews system and network administrators to learn how attributes are assigned, changed and enforced in practice, and whether staff know the rules.	Named administrator roles, documented assignment procedures and a short walkthrough of how an attribute is set on a sample object.
Test binding in storage	Selects sample objects and confirms each carries the required attribute and value at rest, with the association kept with the information.	Sample objects with their attribute metadata, plus the configuration showing how attributes are stored with the data.
Test binding in processing and transmission	Follows sample information through processing and transfer to confirm attributes are not stripped, altered or dropped at each handoff.	Test records from processing pipelines, export and transfer logs, and results from a sample export that retains attributes.
Test attribute change auditing	Changes an attribute on a test object, then checks that the change is recorded with who made it, when and the old and new values.	Change audit logs covering attribute modifications, with the log retention setting and access restrictions on those logs.
Review periodic attribute review records	Checks that attributes and values are reviewed at the frequency the organization defined, and that review results led to corrections.	Dated review records, the reviewer list, and a record of any attributes retired, added or corrected.
Common finding: labels lost on export	Attributes are present inside the system but are dropped when data is exported, converted or sent to another system.	Export tests that show attributes survive each supported format, or documented limits where they do not.
Common finding: undefined or free-text values	Attribute values are entered freely, so the set in use does not match the defined list and reviews cannot test it.	Enforced value lists in the platform, or a validation step that rejects values outside the approved set.

Implementing AC-16 in six steps

This sequence turns AC-16 from a policy statement into a working attribute scheme: defined labels, enforced bindings, audited changes, scheduled reviews and a documented record that an assessor can trace from the requirement to the system.

Define permitted attributes and values with data owners
Start by agreeing which security and privacy attributes the organization will use, such as classification labels, handling caveats or privacy categories, and which values each attribute may take. Data owners, the privacy function and the access control owner should sign off on the list, because AC-16 requires the permitted attributes and values to be defined rather than left to individual users. The output is an attribute register that lists each attribute, its permitted values, who may assign it, who may change it and the approving owner. The step is complete when the register is approved and version controlled.
Decide which systems must bind attributes
Map the information types that carry attributes to the systems that store, process or transmit them. Record which systems must keep attribute associations with the information, which can only display them and which do not need them at all. Include the system security and privacy plan owners in this review so the scope matches the authorization boundary. The output is a binding scope matrix that names each system, information type and attribute source. Confirm the matrix against the system inventory before configuration begins.
Configure attribute binding and retention
Configure the chosen systems so attributes are attached to the information, stay with it when it is stored, processed or transmitted, and are not silently dropped during export or conversion. Test this with representative files and records, including transfers to other systems, and record which mechanisms keep the association intact. Document how attributes are retained when information is copied or archived, and which components are not able to carry them. The output is a configuration record with test results showing the binding survives each defined flow.
Enable auditing of attribute changes
Turn on logging for every change to an attribute or attribute value, including who made the change, when, from which system and what the previous value was. Route these records into the same audit pipeline used for other security events, and confirm that administrators cannot alter them without leaving a trace. Test the logging by changing an attribute in a non-production copy and checking that the record contains the expected fields. The output is a test record and a sample of audit entries that an assessor can examine.
Set a review cadence for attributes
Set a schedule for reviewing the attribute register, the binding scope and the audit records of attribute changes. AC-16 requires periodic review, so the cadence must be written down and assigned to a named owner, with the chosen interval justified in the organization's own policy. Reviewers should check whether values are still correct, whether unauthorized changes appear in the logs and whether new systems need binding. The output is a review schedule and a signed review record for each cycle, kept as evidence of the periodic review.
Document decisions in the system security plan
Record the attribute register, the binding scope, the configuration and test results, the audit design and the review cadence in the system security and privacy plan, and link each element to the AC-16 implementation statement. Cross-reference related controls where the attribute scheme depends on them, such as access enforcement and audit records. Confirm which parts are inherited from an organization-wide service and which the system owner must implement. The output is an approved AC-16 implementation statement with its evidence references, ready for the independent assessor to examine.

Which evidence passes an AC-16 assessment

AC-16 asks for four things: attributes and values that are defined, bound to information, audited when changed and reviewed periodically. An assessor under SP 800-53A will look for one or more artifacts for each part, and the cards below cover the artifacts that usually satisfy them. The organization owns these records, and an independent assessor decides whether they are sufficient.

Attribute and value register

This is the authoritative list of security and privacy attributes the organization permits, such as classification labels or handling caveats, with the values each attribute may take and who may assign them. It answers the first part of AC-16, which is defining permitted attributes and values. Check that every value used in configuration appears in the register, that each entry has an owner, and that retired values are marked as such rather than deleted, so that older records remain interpretable.

Policy and procedure text

The access control policy and procedures should state which information types carry attributes, who may create or change them, and how attributes are carried through storage, processing and transmission. Assessors examine these documents first, and the AC-16 examine objects in SP 800-53A name them directly. Check that the text names the systems in scope and that the procedures match what engineers actually do, since an assessor will compare the two.

System configuration showing attribute binding

Configuration exports from the systems that bind attributes to information, such as labeling policies in a document store, metadata schemas in a data platform or security label settings in an operating system, show that the association exists in practice. Keep dated exports under change control. Check that the bindings persist after the information is copied, exported or transferred, because the requirement asks that associations stay with the information.

Sample test results across storage, processing and transmission

Test records should show that attributes survive each state the requirement names: data at rest, data in active use and data crossing a network boundary. A sample object is labeled, moved through each state and checked for intact attributes. Record the test date, the tester, the system version and any failures with their remediation. Repeat the test after significant changes, since a platform upgrade can alter how metadata is preserved.

Audit records of attribute changes

Logs of who changed an attribute or value, when, on which object and from what previous value support the requirement to audit attribute changes. Assessors sample these logs and trace a change back to an approved request. Confirm that the log source is protected from modification, that retention matches the organization's audit schedule and that the AU family controls on event content cover attribute events. Gaps here are a common reason an otherwise sound design fails.

Periodic review sign-offs

The periodic review of attributes needs dated records showing who reviewed the register and the bindings, what they found and which corrections followed. Set the review interval in the policy and keep each sign-off tied to the version of the register it covered. Assessors check that the interval is defined, that reviews happened on schedule and that findings were tracked to closure, often through the plan of action and milestones.

How attributes must travel with information through systems

The hardest engineering point in AC-16 is that an attribute is only useful if it stays attached to the information it describes. A label on a file that disappears when the file is copied, converted, indexed or sent to another system does not meet the control's intent, and label loss at system boundaries is the usual failure assessors find. The association has to survive storage, processing and transmission, so the design question is not whether a system can tag data but whether every hop preserves the tag, rejects a transfer when it cannot, and records what happened.

Several related controls meet at this point. AC-3 (access enforcement) and AC-4 (information flow enforcement) are where attributes are read and acted on, so a label that is stored but never checked protects nothing. AC-6 (least privilege) and AC-21 (information sharing) decide who may change or rely on attributes before data leaves a boundary. AU-2 is where attribute changes become auditable events, MP-3 covers marking of removable media, and PT-2 to PT-4 bring in the privacy attributes that govern authority and purpose for PII processing. The related-control list in the SP 800-53 catalog is a starting point only. Confirm each pairing against your own data flows and architecture diagrams before you assign ownership, because the catalog does not show how any particular product or pipeline behaves.

Before scoping this work, ask the system owner to trace one labeled dataset from creation through export, backup and sharing, and note each point where the label could be dropped. That trace usually shows the missing controls faster than a policy review. Confirm with the assessor whether they expect a demonstration of label persistence or only documented design, because the evidence for each route differs.

What meeting AC-16 costs in money and effort

This table breaks the cost of meeting AC-16 into its components, marks each as one-time or recurring, and names the factors that move it up or down. Use it to structure a written quote, since NIST publishes no cost or timeline figures for AC-16 and every number has to come from your own scope.

Cost component	Who is paid	One-time or recurring	What drives it
Tooling and licenses	Software vendor or open-source maintainers, plus your team for hosting	Recurring for commercial labeling or data classification products; removable for self-hosted open-source tools, which still carry hosting and staffing costs	Number of systems that must enforce labels, number of users, and whether labels must be enforced across storage, processing and transmission
Attribute design and policy definition	Implementation partner or internal security architect	One-time, with periodic revision	Number of attribute types, number of permitted values, and how many information classes the organization already recognizes
Engineering to bind and retain attributes	Internal engineers or implementation partner	One-time for initial build, recurring for new systems and integrations	Number of applications, data stores and transfer paths that must carry labels through processing and transmission
Audit logging of attribute changes	Internal platform team or implementation partner	One-time configuration, recurring log storage and review	Volume of attribute changes, retention period set by your policy, and integration with existing logging systems
Periodic attribute reviews	Internal control owners, sometimes supported by a partner	Recurring	Review frequency your organization defines, number of attribute types, and how many systems depend on them
Evidence upkeep	Internal compliance staff or implementation partner	Recurring	Number of systems in scope, change frequency of labels and policies, and how evidence is collected (manual or automated)
External testing or review	Independent testing firm or assessor, paid by the organization	Recurring at each assessment cycle	Scope of testing, number of enforcement points, and whether label bypass paths are tested
Independent assessor sampling	Independent assessor or certification body	Recurring at each assessment	Number of samples the assessor selects, the number of systems in scope, and how cleanly evidence is organized

Who owns AC-16 and who can help

AC-16 starts with decisions about information, not technology. The organization must decide which security and privacy attributes matter in its environment, what values each attribute may take, which information carries them and who may change them. Those choices reflect the organization's classification scheme, legal obligations and risk appetite, so they stay in-house even when outside help is involved. The organization also accepts the residual risk of any gap and signs off on the policy that governs attribute use.

Attribute model: defining which attributes exist, their permitted values and the information types they apply to.
Assignment rules: deciding who may assign, change or remove attributes and under what conditions.
Review cadence: setting how often attributes are reviewed and who owns that review.
Risk acceptance: recording decisions on any control that is not implemented or not selected in the chosen baseline.
Policy approval: keeping the access control policy and its procedures current and approved by accountable leaders.

Before engaging anyone, confirm that your attribute model is written down and approved, because an assessor will examine that document first.

Where AC-16 implementations usually fall short

AC-16 asks for more than a list of labels. The gaps below tend to appear after the attribute scheme is written down, when systems, integrations and staff practices drift from it. Each card names one gap and the closing action an assessor would expect to see.

Attributes defined but not bound

Many organizations write an attribute scheme but never attach the attributes to the information itself. Labels exist in a policy document or a classification spreadsheet, while files, database records and messages carry no marking that a system can read. Check whether a sample of stored, processed and transmitted objects actually carries the defined attribute and value. Close the gap by testing a sample of real objects in each system against the scheme, not the scheme alone.

Labels lost in exports and integrations

Attributes often survive inside one application and disappear when data moves. Exports to spreadsheets, API calls, message queues and backup restores can strip or rewrite metadata without any error. AC-16 expects the association to stay with the information as it moves, so integration tests should include the label as a required field. Close the gap by adding attribute preservation tests to every export, interface and restore path.

Value lists that drift from policy

Attribute values tend to multiply over time. Teams add local values such as project codes or abbreviations, and older values remain in systems after the policy retires them. Two systems may then describe the same sensitivity level in different words, which breaks access decisions that depend on the value. Close the gap by making the policy-approved value list the single source that systems read from, with a named owner for changes.

No audit trail of attribute changes

Assessors look for a record of who changed an attribute, when, and to what value. Many platforms overwrite labels silently, so a downgraded or removed marking leaves no trace. Without that record, an investigation cannot tell whether information was relabeled legitimately. Close the gap by confirming that every attribute change writes an audit event with actor, time, old value and new value, and that those events reach the central log store.

No periodic review of attributes

Attribute schemes age. Sensitivity categories change, projects close, and the people who set the original labels leave. AC-16 calls for periodic review of the attributes themselves, which is separate from reviewing access. Without a dated review, stale labels keep controlling access long after they stopped reflecting the data. Close the gap by scheduling a documented review of the attribute list and its values, with the reviewer, date and changes recorded.

How much work and cost does AC-16 add?

Is AC-16 required by default under NIST SP 800-53?

No. SP 800-53B Release 5.2.0 does not select AC-16 for the low, moderate or high security control baselines or for the privacy baseline, so it applies only when an organization adds it. Teams usually add it by tailoring a baseline, by adopting an overlay, or because a contract, agency or internal policy requires labeled information. Confirm the exact baseline selection in the current OSCAL profiles before scoping, because the work it creates depends entirely on that decision.

How much effort does implementing AC-16 take?

The effort depends on how many attribute types you define and how many systems must carry them. AC-16 asks for defined attributes and values, a way to bind them to information in storage, processing and transmission, a way to keep those bindings with the information, auditing of attribute changes, and periodic review. Each of these is a separate piece of design, configuration and evidence work. A narrow scheme applied to one application is a small exercise. A scheme spanning several platforms, data stores and integrations is a program with its own owners and review cycle.

What drives the cost of AC-16 up or down?

Four factors move the cost most:

The number of systems and data stores that must carry labels.
Whether the platforms natively support labels, or whether the labels must be enforced by an added component.
How many attribute values and downstream policies depend on them.
How much existing access control logic (AC-3, AC-4, AC-6) must be changed to read the attributes.

Costs rise sharply when labels must survive transfers between systems, because each handoff is a place where the association can be lost and must be tested.

How long does it take to implement AC-16?

NIST does not set implementation timelines for SP 800-53, and no researched duration applies to AC-16, so treat any figure you see as unverified. The schedule follows the same drivers as effort: the attribute model must be agreed first, then platforms are configured, then change auditing and periodic reviews are proven to run. Ask any partner to split the timeline into design, build, testing and first review cycle, and to tie each phase to a named system.

What must the organization supply before work starts?

Most of the decisions belong to the organization, not the implementer. You need to supply:

An approved list of security and privacy attributes and their permitted values.
The systems and data flows in scope, with owners who can confirm where information is stored, processed and transmitted.
The access control policy and procedures that define how attributes are used.
Named reviewers for the periodic attribute review and access to the audit logs that record attribute changes.

Without these, any implementation partner can only build a technical prototype that the organization cannot defend in an assessment.

Can we implement AC-16 in-house?

Yes, if you have engineers who understand your platforms and an owner who controls the attribute policy. The work sits between access control engineering, data classification and audit logging, so the in-house team needs skills in all three. Outside help is most useful for the design and for configuring platforms you have not run before. The organization keeps ownership of the controls and their evidence either way. An independent assessor, not the implementer, tests whether the control works.

What should we ask a partner for in a fixed-scope quote?

Ask for a written scope that lists each system, each attribute type and each data flow covered, plus the deliverables. A fixed-scope quote should state:

The attribute model and permitted values, as a document you approve.
The platforms configured to bind and retain attributes, and how each was tested.
Audit logging for attribute changes, with a sample record set.
The periodic review procedure and a first review run.
What is excluded, such as data classification, legacy systems and assessment support.

DeployOpen plans, implements and documents self-hosted open-source platforms in your own infrastructure and prepares evidence for assessment. It does not issue audit reports or certifications, and it does not publish a price list, so the quote follows from the written scope.

Does AC-16 create ongoing costs after implementation?

Yes. Labels need periodic review, so the review itself recurs, and each new system or data type that adopts labels adds work to the review and to audit log checks. Attribute changes must keep being logged, which means the logging pipeline and its retention must keep running. Confirm with your partner whether the engagement includes a first review cycle only, or whether ongoing support is a separate retainer, since that decision determines the recurring cost.

How DeployOpen prepares AC-16 evidence

DeployOpen's part of AC-16 work starts with a written scope that names the systems, data types and attribute schemes in play, the assessment objects the client's assessor will examine, and the deliverables and timelines both sides agree before any work begins. Within that scope, DeployOpen plans and implements the self-hosted open-source platforms that carry the labels, deploys them inside the client's own cloud accounts, data centers or air-gapped networks, and configures the attribute handling so the association of attributes with information is enforced where the data is stored, processed and transmitted. The client keeps ownership of the control itself, including the decision on which attributes and values are permitted.

For the assessor, the evidence is mostly a set of records rather than a single screen. DeployOpen prepares an attribute register listing each permitted attribute, its allowed values, the owner who approves changes and the review cadence the client defines, along with configuration exports showing how those attributes are bound to data objects and how the platform logs attribute changes. It also prepares test records that show attributes staying attached to information through storage, processing and transmission, and an audit log extract that demonstrates changes are captured. Ask the partner to confirm in writing which of these artifacts the platform can export natively and which need scripted collection.

DeployOpen does not issue audit reports, attestations or certifications. Those come only from an independent assessor or certification body that the client engages, and it is the client who decides whether AC-16 is selected at all, since no SP 800-53B baseline includes it. Before engaging anyone, confirm with the assessor which assessment objects they will sample, how they expect the register to be versioned and whether the evidence package should follow the procedures in SP 800-53A. Clarify these points in the statement of work so that preparation work is aimed at what will actually be tested.