SA-16: Developer-provided Training

Quick-reference card

What this control requires

SA-16 requires organizations to ensure that system developers deliver training on the correct use and operation of implemented security and privacy functions. This control targets a gap most teams overlook, the assumption that deploying a security capability means people know how to use it correctly. Without structured, developer-led instruction, even well-designed controls can be misconfigured, bypassed, or left partially implemented. You can find SA-16 within the broader NIST SP 800-53 framework, which defines security and privacy controls for federal information systems and organizations.

In practice, you need to establish contractual requirements that obligate developers to provide training covering the security and privacy mechanisms built into any system, component, or service they deliver. This training obligation applies to both external vendors and internal development teams. The System and Services Acquisition family groups SA-16 alongside controls that govern how organizations procure, build, and maintain secure systems.

The training itself can take many forms, including web-based modules, classroom instruction, hands-on workshops, and micro-training sessions. You aren’t limited to one format. Organizations define the training scope and type based on the complexity and criticality of the security functions involved. The key requirement is that developers don’t just hand over a system and walk away; they provide the knowledge transfer necessary for your team to operate it securely from day one.

Why it matters

Most compliance failures tied to SA-16 don’t stem from malicious intent. They stem from operational blind spots where teams inherit systems they were never taught to configure or maintain. NIST SP 800-53 categorizes this control under the HIGH baseline because untrained operators represent a structural weakness in any security program, regardless of how robust the underlying technology might be.

Auditors evaluating your compliance posture will look for documented evidence that developer-provided training was both required and delivered. Gaps here don’t just create audit findings. They signal a broader governance failure in your acquisition process, one that raises questions about whether your organization can demonstrate due diligence across its vendor relationships.

Specifically, when training is absent, security and privacy controls may function as intended on paper but fail under real-world conditions. Operators may not understand alerting thresholds, access control configurations, or privacy-preserving defaults. The result is a compliance gap that compounds over time as personnel rotate and institutional knowledge erodes.

What attackers exploit

Threat actors take advantage of undertrained operators in several predictable ways:

• Misconfigured access controls where operators don’t understand the system’s role-based access model, leaving default permissions in place or granting excessive privileges
• Disabled or ignored security features that operators weren’t trained to monitor or maintain, creating undetected gaps in coverage
• Delayed incident response because staff lack the operational knowledge to recognize anomalous behavior generated by the system’s privacy and security functions
• Social engineering success against operators who weren’t trained on the system’s legitimate communication patterns, making them more susceptible to impersonation attacks targeting third-party risk requirements under NIST 800-53

How to implement

For your vendors

The core challenge with SA-16 in a third-party context is verification. Vendors will often claim they provide training, but the quality, relevance, and completeness of that training varies widely. Your job is to build assessment criteria that distinguish substantive knowledge transfer from checkbox compliance.

What to include in your security questionnaire:

• Does your organization provide training materials covering the security and privacy functions implemented in the delivered system or service?
• What formats does this training take (for example, web-based, classroom, hands-on, micro-training)?
• How frequently is training updated to reflect changes in security functions, controls, or mechanisms?
• Can you provide a sample training curriculum or module outline for review?
• Do you track training completion and comprehension metrics for the personnel who will operate the system?

Evidence to request from the vendor:

You should require vendors to provide developer-provided training materials, completion records, and documentation that maps training content to the specific security and privacy functions implemented in the system. Request copies of acquisition contracts or service level agreements that explicitly reference training obligations. Ask for the vendor’s organizational security and privacy training policy to confirm that developer-provided training is a formal requirement, not an informal courtesy.

Red flags to watch for:

Generic training content that doesn’t reference the specific security functions in the delivered system is a significant warning sign. Other red flags include training materials that haven’t been updated in over 12 months, no documented training completion records, and vendors who offer only self-service documentation with no structured instruction. A vendor security review should flag any of these gaps as material findings.

How to verify beyond self-attestation:

Don’t rely solely on a vendor’s word. Request a walkthrough of the training curriculum alongside the system’s security architecture documentation. Compare the training topics against the system’s implemented security and privacy functions to identify coverage gaps. You can also interview your own operators post-training to assess whether they can articulate how the system’s controls work and what their responsibilities are. The UpGuard Vendor Risk platform helps you centralize this evidence collection and track vendor compliance against SA-16 requirements over time.

Evidence examples

Cross-framework mapping

No cross-framework mappings are currently configured for SA-16.

Related controls

• AT-02 — Literacy Training and Awareness: establishes the broader organizational training baseline that developer-provided training supplements with system-specific instruction
• AT-03 — Role-based Training: complements SA-16 by ensuring personnel receive training tailored to their specific security roles and responsibilities beyond developer-provided content
• PE-03 — Physical Access Control: intersects with SA-16 when developers must train operators on physical security mechanisms integrated into the delivered system
• SA-04 — Acquisition Process: defines the procurement framework where developer training requirements are contractually established before system delivery
• SA-05 — System Documentation: works alongside SA-16 by ensuring developers provide the reference documentation that supports and reinforces training content

Frequently asked questions

What is NIST SP 800-53 SA-16

SA-16 is a NIST SP 800-53 control that requires developers to provide training on the correct use and operation of a system’s implemented security and privacy functions, controls, and mechanisms. This requirement applies to both external and internal developers, covering any system, component, or service delivered to your organization. The goal is to ensure that the people operating a system understand how its security features work in practice, not just in theory. SA-16 falls within the System and Services Acquisition family and is included in the HIGH baseline.

What happens if SA-16 is not implemented

Failure to implement SA-16 creates a documented compliance gap that auditors will flag during any assessment against the NIST SP 800-53 HIGH baseline. Without developer-provided training materials and completion records, your organization cannot demonstrate that operators are qualified to manage the security and privacy functions they’re responsible for. This gap weakens your overall compliance posture and raises questions about the effectiveness of related controls in the NIST SP 800-53 framework. Over time, the absence of structured training leads to configuration drift, misused controls, and increased exposure to preventable security incidents.

How do you audit SA-16

Auditing SA-16 starts with verifying that acquisition contracts and service level agreements explicitly require developers to deliver training on implemented security and privacy functions. You then review developer-provided training materials to confirm they map to the specific controls and mechanisms in the delivered system. Auditors also examine training completion records and may interview operators to assess whether they can describe how the system’s security features function and what their operational responsibilities are. The assessment objective focuses on confirming that the developer was required to provide, and actually delivered, training on the correct use and operation of the implemented security and privacy functions.

What types of training can developers provide under SA-16

Developers can deliver training through multiple formats, including web-based and computer-based modules, classroom instruction, hands-on workshops, and micro-training sessions tailored to specific security functions. Organizations determine which training type is appropriate based on the complexity of the implemented controls and mechanisms. Vendors may also provide training materials that your organization uses to conduct in-house instruction or self-paced learning. The key requirement is that the training covers the correct operation of the specific security and privacy functions built into the delivered system, not generic security awareness content.