SA-16 Developer-provided training: requirements and evidence

What SA-16 developer-provided training requires in the high baseline

SA-16 requires the developer to provide defined training on the correct use and operation of the security and privacy functions, controls and mechanisms it implemented. In a high-baseline system, that means the people who run the security functions after go-live, such as administrators who configure authentication, logging and encryption, and users who depend on functions like access approval or data handling, need training from the developer that matches what the developer actually built. The control is a base control in the System and Services Acquisition family, and SP 800-53B selects it only in the high baseline. Your organization owns the control, but the developer is the party expected to deliver the training content.

The control has one organization-defined parameter, which you set when you tailor the control, and no control enhancements in Release 5.2.0. That parameter is where you decide what the training must cover and who must receive it, so it is the first thing to settle in the acquisition contract. SA-16 is related to AT-2 and AT-3, which govern your own security and role-based training, and to SA-4 and SA-5, which carry training and documentation requirements into the acquisition and system documentation. Appendix C of SP 800-53 lists SA-16 as implemented by the organization and marks it as assurance-related, so an assessor will look for proof that the training was delivered and that it was tied to the functions the developer implemented.

The assessment in SP 800-53A Release 5.2.0 uses one determination statement and the examine and interview methods. An assessor will ask for developer-provided training materials, training records, and privacy impact assessment and privacy risk assessment documentation, then interview administrators and users about whether the training matched their duties. Confirm early whether your acquisition contract requires the developer to supply training content, delivery records and updates after changes, because retrofitting those obligations after award is harder. FedRAMP's Rev5 baselines also require SA-16 at Class D, so cloud providers should check that rule before drafting training scope.

Which systems, developers and training audiences SA-16 reaches

SA-16 only applies where the high baseline selects it, and its reach depends on four decisions: which systems fall in scope, who counts as the developer, which security and privacy functions were built versus configured, and who needs training. Each card below is a decision an assessor will expect you to have documented and defended.

High-baseline systems in scope

SP 800-53B assigns SA-16 only to the high baseline, so the first check is the system's security categorization. A system categorized moderate or low does not carry SA-16 unless the organization selects it through tailoring or an overlay, and that choice must be recorded in the security plan. For a high-impact system, confirm that the boundary in the plan matches the boundary the developer trained against, including any shared services the system inherits. Ask whether the categorization was reviewed after the last significant change.

Internal teams as the developer

When an internal platform or engineering team builds the security functions, that team is the developer for SA-16 purposes, and the training obligation falls on it even though the same organization owns the system. Name the internal team in the control narrative, identify the people who build authentication, logging or access functions, and confirm that training covers the administrators who will run those functions after handover. Internal developers still need a documented training package, not an informal walkthrough.

Contractors and vendors as developers

A contractor or software vendor that builds or configures a security function is a developer, and SA-16 requires that developer to provide the training. The acquisition contract, which SA-4 covers, should name the training deliverable, its audience and its format. Ask vendors for their existing administrator training materials and check whether those materials describe the configuration you actually deployed, not the product in general. Open-source projects with no commercial developer raise a different question: the organization or its implementation partner may have to write the training itself.

Built versus configured functions

SA-16 reaches the security and privacy functions the developer implemented. A function written from scratch, such as custom access logic or a bespoke audit exporter, clearly needs training. A function that is only configured from an existing product sits in a grey area, so document which settings the developer chose and which defaults the administrator inherits. For example, an illustrative case: a team that enables a logging feature but changes its retention and forwarding rules has built part of the function and should train on those changes.

Administrator and user roles

The control asks that people who operate the functions, and the users who depend on them, can do so correctly. List each role separately: system administrators, security operations staff, privileged application administrators, and end users whose workflow depends on a control such as multi-factor enrollment or data handling rules. Each role needs a training scope that matches its tasks. A single generic course rarely covers an administrator who must change a key or review an alert queue, so record which tasks each role must perform.

Privacy functions and PIA documentation

When the developer built privacy functions, such as consent capture, data minimization or retention deletion, the privacy side of the control applies too. The SP 800-53A examine method for SA-16 references developer-provided training materials, training records, and privacy impact assessment and privacy risk assessment documentation. Check that the PIA and privacy risk assessment describe the same functions the training covers, and that privacy staff reviewed the training content before it was issued to users.

How an assessor tests SA-16

This table maps the single SP 800-53A determination statement for SA-16 to the methods an assessor uses, the objects they examine and the findings they commonly raise. Read it as a checklist of what to have ready before an assessor arrives, since the test is document-heavy and turns on whether training is tied to the functions actually built.

Assessment element	What the assessor does	What to have ready	Common finding
Determination statement	Confirms the developer provides the defined training on correct use and operation of the security and privacy functions it implemented	Written statement of the training scope, mapped to the functions the developer built and the organization-defined parameter value	Scope lists generic platform features rather than the specific security functions delivered
Examine: training materials	Reads the course content and checks it covers secure operation of each in-scope function	Materials for administrators and users, with the function, configuration steps and misuse risks each module addresses	Materials cover generic product features and omit secure configuration or the controls the developer added
Examine: training records	Checks who completed the training, when, and whether completion covers the roles that operate the functions	Completion records tied to named roles, dates and the version of the material delivered	No records exist, or records do not link completion to administrators and users who operate the functions
Examine: privacy impact assessment documentation	Checks whether the functions with privacy effects are described in the training and the PIA	PIA sections that name privacy functions and the training that explains their correct use	PIA identifies privacy functions that the training never addresses
Examine: privacy risk assessment documentation	Checks that privacy risks linked to the functions are reflected in what the training teaches	Privacy risk assessment entries cross-referenced to training modules	Privacy risks are recorded but no training content addresses them
Interview: developer and training owners	Asks how training content is decided, updated after changes, and delivered to operators and users	Named owners, update triggers such as major releases, and the delivery method	Staff describe training as a one-time onboarding event with no update process
Interview: administrators and users	Asks whether they received the training and can explain how to operate the functions correctly	Staff who can describe their role-specific functions and where the training is kept	Operators say they learned the functions from peers or vendor documentation, not the developer training

Implementing SA-16 step by step

This sequence turns SA-16 from a line in a control narrative into a documented training program: which developer-built functions need training, who receives it, what the contract obliges the developer to deliver, and how the results are recorded and fed back into the system security plan.

Inventory the developer-built security and privacy functions
Start by listing every security and privacy function, control and mechanism the developer built or configured into the system, such as authentication flows, role assignments, audit settings, encryption configuration and privacy consent handling. Record which of these administrators or users must operate correctly, and which team owns each function on the organization side. The output is a function inventory that maps each item to the audience that needs training. Confirm the list with the system owner and the security team so that nothing built by the developer is left out of scope.
Define the organization-defined parameter for training
SA-16 carries one organization-defined parameter, which the organization sets to specify the content and the frequency of the developer-provided training. Decide what the training must cover for each audience, such as administrators who configure the functions and users who rely on them, and set how often it is repeated, including after major releases. Document the parameter values in the system security plan. The output is a written parameter statement that an assessor can compare against the training actually delivered. Confirm the values with your assessor before they are finalized.
Write the training obligation into the acquisition contract
Because the developer must provide the training, the obligation has to exist in the contract or agreement that governs the build. Work with procurement and legal to add training requirements under the acquisition requirements that SA-4 covers, including content tied to the function inventory, the audience, the delivery format and the parameter values. For an internal development team, record the same obligation in a formal internal work order or statement of responsibilities. The output is a signed contract clause or internal agreement that names the training deliverables and the acceptance criteria.
Build or obtain role-based training materials
Using the function inventory and the parameter values, the developer prepares training materials for each audience. Administrator material should cover configuration, privileged operations, logging and recovery steps. User material should cover normal use of the functions and the actions users must avoid. Materials should be versioned so that each release can be traced to the training that accompanied it. Where a learning management system is used, an open-source option such as Moodle can host the courses, but confirm that the platform's activity completion settings reflect the way your organization records attendance. The output is a set of versioned training materials mapped to the function inventory.
Deliver the training and record completion
Run the training for each defined audience and keep records that show who attended, when, which version of the material they received and whether they passed any assessment you require. Verify that completion is recorded by the method you chose, whether a system-generated completion status or a manual sign-off by a trainer. The output is a training record set that identifies each learner, the material version and the completion date, which an assessor can examine for the SA-16 determination statement.
Feed the results back into the system security plan
Review training outcomes with the system owner and security team to find gaps, such as functions that administrators misconfigure or features users misunderstand. Update the function inventory, the parameter values and the training materials to close those gaps, and reflect the program in the system security plan and the related documentation. Record any open items in the plan of action and milestones. The output is an updated system security plan entry for SA-16 that describes the training, its audiences, its frequency and its evidence location, ready for the assessor's examine and interview activities.

How to tie training to the functions the developer built

Start with a function-to-role matrix that lists every security and privacy mechanism the developer built into the system, then names the audience for each one and a learning objective the audience must reach. A mechanism such as a privileged access approval workflow, a log review dashboard, or a PII redaction setting usually has two or three distinct audiences: the administrators who configure it, the operators who monitor it, and the end users who must follow its rules. Write one row per mechanism and one row per audience, and state the objective in terms an assessor can check, such as "configures the account lockout threshold according to the approved baseline" rather than "understands authentication." The matrix is the document an assessor will ask for first, because it shows how the training content maps back to the components the developer delivered.

Generic vendor courses rarely satisfy SA-16 on their own. They teach the product in general, not the configuration choices your organization made, the custom functions a developer added, or the settings your baseline requires. An assessor testing the determination statement will look for developer-provided training materials that reference the implemented functions and training records showing that the right people completed them. Ask any vendor or integrator to show which functions their material covers and how it is tied to your deployment. Confirm the exact training content, delivery format and record-keeping with the developer during scoping, because those details are what an examiner will sample.

The broader literacy and role-based training baseline sits in AT-2 and AT-3. AT-2 covers security and privacy awareness for all users, and AT-3 covers role-based training for personnel with defined security responsibilities. SA-16 extends that baseline to the specific functions the developer built, so the training you run under AT-3 for administrators should reference the matrix rows for those functions. Use the same role definitions and training records for both controls to avoid duplicate tracking. Platforms such as the learning management system Moodle can record completion, but completion is marked by viewing, grading or manual ticking depending on how each activity is configured, so decide which condition counts as evidence before you rely on it.

Evidence that passes an SA-16 review

An assessor testing SA-16 looks for training materials, proof of who was trained, and a contract that obligates the developer to deliver the training. The cards below cover each artifact and how to keep it accurate between assessments, since a training record that describes a previous version of a function fails the same test as no record at all.

Developer-provided training materials

These are the courses, guides, and walkthroughs the developer delivers on the security and privacy functions it built, such as configuring authentication, role assignment, audit logging, or encryption key handling. Check that each module names the function, the release it applies to, and the administrator or user action it teaches. Tie every revision to a change record so the materials match the deployed system. Re-issue them after significant changes to any function covered.

Function-to-audience matrix

This matrix maps each security or privacy function the developer implemented to the roles that must operate it, such as system administrators, security operators, and end users. It shows which audience gets which training and makes gaps visible before an assessor finds them. Review it whenever a function is added, changed, or retired, and confirm every administrative function has at least one trained owner.

Attendance and completion records

Records show who received the training, when, and which version of the material they saw. Keep them in a system that can export per-person history on request. For self-hosted learning platforms, confirm that completion is recorded when the learner views the activity, receives a grade, or ticks it manually, and set the activity conditions to match the evidence you need. Store records long enough to cover the assessment period and every re-training trigger.

Assessment and quiz results

Attendance alone does not show that administrators can operate a function correctly. Short assessments tied to tasks, such as configuring a role or reviewing an audit record, produce results that show competence. Keep the question bank versioned with the materials, record the pass threshold, and retain failed attempts with the retake outcome. A low pass rate on one function is a signal to fix the training or the function's usability.

PIA and privacy risk assessment references

The examine objects for SA-16 include privacy impact assessment and privacy risk assessment documentation, so training on privacy functions should be traceable to those assessments. Reference the specific PIA or risk assessment section that each privacy function addresses, and confirm the training covers the handling steps the assessment requires. When an assessment is updated, check whether the training still describes the function accurately.

Contract clause obligating the developer

The acquisition contract or internal development agreement should require the developer to deliver the training, define its content and audience, and set delivery timing. Without this clause, the organization may have no right to demand training materials from an external developer. Ask counsel and procurement to confirm the clause names the functions in scope, the delivery format, and the obligation to re-train after significant changes, and keep the signed copy with the SA-4 acquisition file.

What meeting SA-16 costs in money and effort

This table breaks SA-16 cost into components, showing who is paid, whether each item is one-time or recurring, and what drives it up. NIST does not estimate compliance costs, so use the rows to structure written quotes from your developer and any implementation partner rather than to forecast a budget.

Cost component	Who is paid or who does the work	One-time or recurring	What drives it
Developer training production	The developer, often under a contract clause written to SA-4	One-time, then updated	Number of security and privacy functions the developer built and the depth of material needed
Training delivery	The developer, or a partner the developer uses	Recurring per cohort or per intake	Number of administrators and users, and how often new staff need training
Internal mapping of functions to roles	Your security, IT and privacy staff	One-time, then reviewed	Count of functions, administrator and user roles, and how much of the system is customized
Training records and tracking	Your compliance or LMS administrators	Recurring	Learning platform choice, reporting needs and how many people must be tracked
Learning platform hosting and licensing	Your organization or a hosting partner, plus any licensing vendor	Recurring	Whether an existing LMS is reused and whether it runs inside your own infrastructure
Refresher updates after releases	The developer for content, your staff for rollout	Recurring with each significant change	Release frequency, changes to security functions and staff turnover
Assessor review of materials and records	Independent assessor, billed by the engagement	Recurring at each assessment	How many training materials and records the assessor samples, and how well they are indexed

Using self-hosted open source to produce training records

Moodle is a GPL-3.0-or-later learning management system, and its activity completion feature is the part most relevant to SA-16 evidence. According to the Moodle developer documentation, an activity is marked complete for each learner in one of three ways: when the learner views it, when the learner receives a grade from it, or when the learner ticks it manually. The condition used depends on how the activity is configured. Completion is tracked per learner, which is the granularity an assessor expects when checking whether the people operating a developer-built security function were actually trained on it.

Per-learner status: Each enrolled user has their own completion state for each activity, not a shared course-level flag.
View condition: The activity completes when the learner opens it, which records access but not comprehension.
Grade condition: The activity completes when a grade is issued, which ties completion to an assessment result.
Manual condition: A learner or instructor ticks the activity, which needs a clear rule for who may tick it and when.
Course-level roll-up: Individual activity states can be combined into a course completion view for reporting.

Confirm which condition your training design requires before go-live, because a view-based record cannot show what a learner understood.

Common SA-16 gaps and how to close them

Assessors testing SA-16 tend to find the same handful of gaps: training that describes a product rather than the functions an organization configured, training that ignores who operates those functions, and no record that anyone completed it. The cards below pair each gap with a closure action you can check before an assessment starts.

Training written for the product

Vendor training often explains the platform in general terms. SA-16 asks about the security and privacy functions the developer implemented in your deployment, so the material should name the configured access roles, logging settings, encryption options and privacy controls you actually use. Closure: map each training module to a function in your system security plan, and drop modules that describe features you have switched off.

Training not tied to roles

Administrators configure and maintain security functions, while users rely on them day to day, and the two groups need different content. A single generic session often leaves administrators without procedures for changing settings safely. Closure: split training into administrator and user tracks, and confirm in writing which roles each track covers, including contractors who hold privileged access.

No training records

An assessor testing the examine method will ask for training materials and proof that people took them. Without attendance logs, completion dates and versions of the material, the control cannot be shown as met. Closure: store each completion with the learner, role, date and material version in a system you control, and keep records for the period your authorization requires.

Training not updated after significant change

When a developer patches a security function, adds an encryption option or changes how access is granted, older training describes behavior that no longer exists. Staff then operate the system from outdated instructions. Closure: tie training revisions to your change control process, so any change that alters a security or privacy function triggers a review of the affected modules.

No contract obligation for the developer

If the contract does not require the developer to deliver training, you may have no right to it and no defined content to test against. This gap is common when a product is bought off a standard license. Closure: write the training obligation, its scope, format, audience and delivery timing into the acquisition or support agreement, and confirm the vendor's commitment before purchase.

Privacy functions left out

Where a system processes personally identifiable information, training on access and handling of that data is part of what SA-16 covers, and the examine objects include privacy impact assessment and privacy risk assessment documentation. Training that skips these functions often exists because the PIA was never linked to the training scope. Closure: add a step to the PIA process that lists the privacy functions and carries them into the training plan.

SA-16 questions buyers ask before hiring help

How much effort does SA-16 take to meet in-house?

The effort depends mainly on how many security and privacy functions the developer built, how many distinct audiences use them, and whether training material already exists. SA-16 asks for defined training on the correct use and operation of those functions, so the work is less about writing new security content and more about inventorying what the system does, mapping each function to the people who operate or use it, and producing material that matches the delivered configuration. Start by counting functions and audiences, then compare that list with existing guides. Ask your team to estimate hours for each audience, and confirm the scope with your assessor before committing resources, because neither NIST nor FedRAMP publishes a standard effort figure for this control.

Do we need an outside partner to meet SA-16?

Not necessarily. The organization owns its controls, and nothing in SP 800-53 requires an outside firm to write or deliver training. A partner is worth considering when the internal team lacks people who understand the implemented security functions well enough to teach them, when the system was built by an external developer whose training you must obtain, or when the schedule for an assessment is tight. An implementation partner can prepare the training material, configure the learning platform and collect completion records. Only an independent assessor can test whether the control is met and report on it. Confirm that split of roles in writing before any work starts.

What does the internal team have to provide for SA-16?

The internal team has to supply the knowledge and the decisions that the training depends on. Expect to provide:

A list of the security and privacy functions, controls and mechanisms in the system, with their configuration owners.
Named audiences, such as administrators, operators and general users, and the actions each group performs.
Access to the developer or engineers who know how each function behaves under failure or misconfiguration.
Sign-off from a control owner who accepts the material as accurate for the live environment.

The assessor will look for training materials, training records and privacy-related documentation, so the team should also decide where those records are kept and who maintains them.

How long does SA-16 preparation take?

No preparation duration is set by NIST for this control, and no reliable figure can be given without knowing the system. The timeline depends on how many functions need training, how many audiences exist, how quickly subject matter experts can review drafts, and whether the training must be rebuilt after each significant change. Ask your partner or internal lead for a schedule with milestones for inventory, drafting, review, delivery and record keeping. Confirm the expected assessment date with your assessor and work backward from it, because the assessor's evidence requirements shape which materials must exist before the review.

Must the developer or the organization deliver SA-16 training?

SA-16 places the duty on the developer to provide the training, so the question is usually whether the developer is internal or external. When an internal team built the functions, the organization is the developer and must train its own administrators and users. When a vendor built the functions, the acquisition contract should require the vendor to provide the training and its materials, and the organization should confirm what it receives. In both cases the organization is responsible for showing that the training happened and that the people trained are the ones who operate the functions. Check the defined parameter for the training scope in your system's control documentation, and confirm with your assessor how they will treat vendor-provided material.

Which SA-16 evidence will an assessor ask to see?

The assessment procedure for SA-16 uses examine and interview methods, so the assessor will review documents and speak with staff. Typical evidence includes the developer-provided training materials, training records showing who completed which course and when, and privacy impact assessment and privacy risk assessment documentation where those functions handle personal information. Interviews will test whether administrators can describe how the functions work in practice. Keep materials version controlled, tie each version to a system release, and retain completion records in a system the assessor can access. A learning platform such as Moodle can record completion, although its activity completion rules depend on how each activity is configured, so confirm those settings before relying on them as evidence.

What should a quote for SA-16 work include?

A quote should follow from a written scope, so ask for the scope first. It should list the security and privacy functions in scope, the audiences to be trained, the deliverables (training material, delivery method, completion records and a maintenance plan), and the systems or environments covered. It should state which tasks the partner performs and which remain with your staff, including review and sign-off. Ask whether the work is one-time or recurring, such as refresher training after each significant change, and what triggers a new engagement. Confirm how the partner will hand over materials and records so the organization can maintain them. DeployOpen does not publish a price list; a quote follows from the written scope.

Does SA-16 apply to every baseline?

No. SP 800-53B assigns SA-16 to the high security control baseline only, so systems categorized at low or moderate impact are not required to meet it under that baseline. Organizations still need to confirm the baseline that applies to their system, because contracts, agency requirements or FedRAMP rules can impose controls beyond the baseline selection. FedRAMP's Rev5 baselines require SA-16 at Class D, so a system within that program should plan for it regardless of how the general baseline reads. Verify the applicable baseline and any contractual overlay with your authorizing official before scoping the work.

How DeployOpen prepares SA-16 evidence

DeployOpen scopes SA-16 work through a written, fixed-scope agreement signed before any work starts. The agreement names the systems in scope, the security and privacy functions the developer built or configured, the audiences that need training (administrators, operators and end users), and the deliverables. Before drafting, confirm with the organization's control owner who is the developer for each function. For a platform built in-house, that is the internal engineering team. For a vendor-built or customized open-source platform, the organization must confirm what the vendor will provide under the acquisition contract, because SA-16 expects the developer to deliver the training. Where the developer cannot, the agreement should say who fills the gap and how the organization will document that decision.

Once scope is fixed, DeployOpen maps each developer-built function to the training it needs. A typical map lists the function, the operator task it supports (for example, configuring authentication, reviewing audit records or rotating keys), the role that performs it, and the materials that explain it. Training materials, attendance or completion records, and the assessment or feedback records that show learners understood the content are then prepared inside the client's own infrastructure. Where the client uses Moodle (GPL-3.0-or-later), activity completion can record when a learner views a module, receives a grade or is marked complete manually, so the client should decide in advance which condition counts as evidence of training. The privacy elements of SA-16, including privacy impact assessment and privacy risk assessment documentation, are prepared alongside the security material. Records of the work are handed over in formats the client's assessor can examine.

Platforms change, so training goes stale. DeployOpen offers retainers that cover refresher cycles, updates to materials when functions change and re-checks of training records before an assessment. The retainer scope, cadence and deliverables are set in writing, and the client decides how often refresher training must occur under its own policy. DeployOpen prepares systems, training materials and evidence only. It does not issue findings, ratings or authorizations. Those come from the independent assessor the organization engages, who will test SA-16 against the procedure in SP 800-53A and decide whether the evidence is sufficient. Ask any prospective assessor early which training records they expect to see, and ask for the outcome in writing.

SA-16 Developer-provided training