PS-9 Position descriptions: requirements and evidence

What PS-9 position descriptions ask for and why they matter

PS-9 requires that security and privacy roles and responsibilities be written into the organization's position descriptions. In practice, this means the job documents that define what each role does should say what security and privacy duties come with it, so that the person in the role, their manager and the people who train and provision them all work from the same statement. The control is short, but its purpose is practical: it ties each role's duties to the role-based training that person needs and to the access that person should hold. When a position description is silent on security, the organization tends to discover the gap later, through an access request that nobody can approve, a training course that was never assigned, or an incident where nobody was clearly accountable.

The gaps usually have a common cause. Position descriptions are often owned by human resources and written for recruiting, pay grading and general duties, so security responsibilities are missing or generic. Security duties are then added late, through a new tool rollout or a policy update, and they live in a runbook or an email rather than in the role record. Nothing links the position description to training records, so an assessor who asks how a database administrator's privacy duties translate into completed training finds two systems that do not talk to each other. Under SP 800-53A, the assessment examines the personnel security policy, the procedures for position descriptions and the position descriptions themselves, and it interviews the people who manage personnel security and human capital. Each of those is a place where the organization must show a consistent chain from duty to training to access.

Before engaging an implementation partner or auditor, the reader should confirm three things in their own environment: which position descriptions exist for roles with system or data access, who has the authority to change them, and whether the training assignment process reads from the role or from a manual list. A useful first check is to take five roles with privileged access, read their position descriptions, and ask whether a new hire could tell from the document alone which security and privacy duties apply. If the answer is no, the fix belongs in the HR template and the approval workflow, not only in the training catalog.

Which position descriptions fall under PS-9 in the low, moderate and high baselines

PS-9 applies at the low, moderate and high baselines in SP 800-53B and is absent from the privacy baseline, so scope starts with which systems carry security impact. Within those systems, the roles that matter are the ones whose duties touch security, not just the people who hold a system account.

Privacy-only systems fall outside PS-9

SP 800-53B allocates PS-9 to the low, moderate and high security baselines and does not place it in the privacy baseline. A system scoped only to the privacy baseline does not trigger PS-9 on its own. Confirm the baseline selection in the system security and privacy plan before deciding that position descriptions are out of scope, because a system that also carries security impact will bring PS-9 back in.

System owners and security-relevant managers

System owners, authorizing officials' delegates and managers who approve access or accept risk need their security responsibilities written into their position descriptions. Check whether each description names the decisions the role makes, such as approving access requests, accepting risk or owning the security plan, and whether those duties drive role-based training assigned to the role.

Administrators, developers and help desk staff

Privileged administrators, developers with production access and help desk staff who reset credentials carry day-to-day security duties that are easy to leave unwritten. For each group, confirm the description covers the security tasks performed, such as change approval, secure configuration, identity verification and incident escalation, so that the training needs follow from the documented duties.

HR and human capital ownership

Human resources and human capital teams usually own the position description templates, job families and approval workflow. Scope work with them early, because a security duty added to a single role will not persist unless the template and the review cycle carry it forward. Ask who approves template changes and how often descriptions are reviewed against the system inventory.

Contractors and external roles through PS-7

Contractors and service provider staff who perform security duties are not covered by internal position descriptions. Their security responsibilities are set through the PS-7 external personnel requirements and the contract, so confirm that each external role with security duties has written requirements that match the internal role it mirrors. Ask the provider how it maps its staff to those requirements.

System scope determines which roles matter

The roles in scope depend on the system boundary, its data and the functions it performs. An illustrative example: a payroll application with no connection to security services may need fewer security-tasked roles than a shared identity platform that issues credentials for many systems. Document the role list per system in the security plan so the position description review follows the boundary rather than the org chart.

How an assessor tests PS-9 position descriptions

This table compares the three SP 800-53A assessment methods for PS-9, the examine, interview and test steps an assessor uses to check the two determination statements. Read each row as the evidence the assessor will ask to see, what they will look for in it, and where organizations usually fall short. The assessment objects are suggestions, and your own system boundary and organizational scope determine the actual sample.

Method	What the assessor looks at	Evidence requested	Common findings
Examine: personnel security policy and procedures	Whether the policy and procedures address position descriptions and assign who keeps them current	Current PS policy and procedures, approval records, review dates	Policy mentions screening but never mentions security or privacy duties in position descriptions
Examine: procedures addressing position descriptions	A documented step that adds or updates security and privacy responsibilities when a description changes	Written procedure, workflow or ticket template showing the step	Procedure exists only as informal practice held by HR staff
Examine: security and privacy position descriptions	Whether sampled role descriptions state security and privacy duties that match the role's system access	Sample of position descriptions for in-scope roles, with version history	Descriptions for administrators and privileged users omit security duties entirely
Examine: privacy program plan	Whether the plan assigns privacy responsibilities to roles and links them to position descriptions	Current privacy program plan and the roles it names	Plan names privacy roles that do not appear in any HR position description
Interview: personnel security responsibilities	Whether the people who own screening and role changes can explain how security duties reach position descriptions	Interview notes, named owners, RACI or responsibility matrix	Owners describe duties from memory and cannot point to the current document
Interview: human capital management responsibilities	Whether HR staff know when a role change requires a security update and how training needs are triggered	Interview notes, HR change triggers, job architecture or role catalog	HR updates titles and pay bands but not the security content of descriptions
Test: processes for managing position descriptions	Whether the process runs in practice, from role creation through review and approval, with security and privacy input	Sample of recent role changes with approvals, review records and linked training assignments	Changes are approved without a security reviewer, or training is never tied to the revised role

How to write security and privacy duties into position descriptions

This sequence turns the PS-9 requirement into working documents: a role inventory, a duty matrix, approved position descriptions and a training linkage that HR, security and privacy owners can maintain together. Each step names the artifact it produces so an assessor can trace it.

Inventory roles that touch the system
Start by listing every position that operates, administers, uses, supports or oversees the system in scope, including contractors who fill organizational roles. Pull the list from HR position records, the system security and privacy plan, access provisioning records and the personnel security risk designations already assigned under PS-2. Security or compliance staff should confirm that no privileged or privacy-relevant role is missing. The output is a role inventory that names each position, its HR title, its reporting line and the systems it touches. The step is complete when every account holder with elevated or sensitive access maps to a listed position.
Map each role to security and privacy duties
For each inventoried role, write the security and privacy responsibilities that the person is expected to carry out, such as applying configuration baselines, reviewing audit records, handling incident escalation, protecting personally identifiable information or approving access requests. Keep duties specific enough to test, and separate duties that conflict within one position. The output is a duty matrix that links each role to its duties and to the control families those duties support. Ask the system owner and the privacy office to review the matrix, and record their sign-off on the version used.
Agree ownership with HR and human capital management
Position descriptions belong to HR and human capital management, so the security and privacy language has to be agreed with them before it is added. Hold a working session where security, privacy and HR leads confirm which office drafts each duty, who approves changes to the wording and how job evaluation or grading is affected. Document the agreed owner for each position description and the escalation path when a duty is disputed. The output is a short ownership record that names the approvers for each role family. Confirm the process with your own HR policies, since local employment rules may shape how descriptions are changed.
Update and approve position description templates
Insert the approved duty language into the standard position description templates for each role family, rather than editing individual documents one at a time. Keep the wording aligned with the policies and procedures already maintained under PS-1, and avoid restating control text verbatim. Route the revised templates through the approval chain the ownership record defines. The output is a set of approved position descriptions, each with a version number, effective date and approver. An assessor will look for these approved documents, so confirm that the versions in use match the approved ones.
Link each role to role-based training requirements
For each approved position description, identify the role-based training that the duties imply, such as privileged user training, incident handling exercises or privacy training for staff who process personally identifiable information. Record the training requirement next to the role in the duty matrix so the training owner can schedule and track it. This linkage is what makes the responsibilities testable under the training family. The output is a training linkage table that lists each role, its duties and its required role-based training. Confirm the table with the training owner and check that it matches the training records the organization already keeps.
Set a review trigger when roles or systems change
Define the events that require the position descriptions and training linkage to be reviewed, such as a new system, a changed authorization boundary, a reorganization, a new privacy processing activity or a significant change in duties. Assign an owner to watch for these triggers, usually the system owner working with HR. Also set a periodic review cadence that your policy sets, so descriptions do not drift from the system. The output is a documented review trigger procedure and a log of completed reviews. Ask your auditor or assessor which evidence they expect for the periodic review, since expectations vary by program.

Evidence that passes PS-9 position descriptions review

An assessor testing PS-9 looks for a chain of records: the position descriptions themselves, the policy and procedures that require them, the training that follows from them, and the change and sign-off history that proves they stay current. Each card below is one link in that chain, with the upkeep that keeps it defensible between assessments.

Approved position descriptions with security duties

These are the position descriptions for roles that touch systems, data or access, each containing the security and privacy responsibilities assigned to that role. Check that every role with system access has a description that names its duties, not only a generic line about following policy. Keep a review date, a named owner in HR or the business unit, and a version number on each document, so the assessor can see which version was in force on a given date. Confirm with HR which system is the record of truth for these documents.

Personnel security policy and procedures

The PS-1 policy and procedures are the documents that require security and privacy duties to appear in position descriptions. Assessors read them first to confirm the requirement exists and who enforces it. Record the review cycle, the approving official and the date of the last update, and tie any change to the position description process back to this document. Without this link, the position descriptions look like local practice rather than an organizational requirement.

Role-to-training matrix

This matrix maps each role named in the position descriptions to the security and privacy training that role must complete. It is the evidence that the NIST discussion for PS-9 is met in practice: the duties are clear enough to drive role-based training. Keep it under version control, review it when a position description changes, and link each row to the training records the people in that role have completed. Confirm that the matrix and the training platform use the same role identifiers.

HR change records for updated descriptions

When a role's duties change, HR should record what changed, why, who approved it and when the new version took effect. Assessors sample these records to test whether position descriptions are updated after reorganizations, new system ownership or policy revisions. Keep the change log in the HR system or a controlled repository with timestamps, and check that each change triggers a review of the matching training requirements. Ask the organization how it handles changes that arrive from managers rather than HR.

Privacy program plan references and sign-off

Where a position carries privacy responsibilities, the position description should match what the privacy program plan assigns to that role. Assessors examine the privacy program plan for those assignments and interview personnel with human capital management responsibilities to confirm the two agree. Keep a sign-off record from the privacy official and the HR owner showing the plan and the descriptions were reviewed together, with the date and the version each one reflects.

What PS-9 position descriptions cost to meet

This table lists the cost components of writing security and privacy duties into position descriptions, who usually does the work, and whether each cost is one-time or recurring. Use it to shape a request for quote, since NIST does not estimate compliance costs and DeployOpen does not publish a price list, so every figure must come from your own role count and written scope.

Cost component	Who does the work	One-time or recurring	What drives it up or down
HR and human capital review and rewrite of descriptions	HR and human capital staff, with hiring managers	One-time for the initial rewrite, recurring for updates	Number of distinct roles and how many descriptions already exist in usable form
Security and compliance definition of duties	CISO office, security engineers, privacy staff	One-time for the baseline duties, recurring as systems change	Number of systems each role touches and how many privacy duties apply to each role
Role-based training design linked to duties	Training owners and security awareness staff	One-time for initial mapping, recurring when duties change	Number of role families and whether training content already exists for them
Template and standard text maintenance	HR policy owners and compliance leads	Recurring	Number of templates across business units and regional employment rules
Periodic review of descriptions	HR, managers and security leads	Recurring at the review cycle the organization sets	Frequency of role change, reorganizations and new system onboarding
Evidence collection for assessors	Compliance lead and HR records team	Recurring at each assessment	Sample size the assessor selects and whether signed or versioned copies are easy to retrieve
Independent assessor testing	Independent assessor (not DeployOpen)	Recurring at each assessment cycle	Number of organizational processes for managing descriptions and how many interviews the assessor schedules

Where position descriptions fall short and how to close each gap

PS-9 is satisfied only when security and privacy duties appear in the position descriptions people actually work from, and when those descriptions stay current and traceable. The gaps below recur across regulated organizations, and each one is usually visible to an assessor within a single interview or document request.

Security duties missing from HR templates

Standard HR position description templates describe job function, reporting lines and qualifications, but often omit security and privacy responsibilities entirely. Check whether templates for engineering, administration, customer support and finance roles include a section for duties such as protecting authenticators, reporting suspected incidents and handling personal data. Fix this by adding a role-specific security and privacy section to each template, drafted with the security office and reviewed by HR. Evidence that closes the gap is the revised template with version history and a sample of populated descriptions.

Duties written but never approved

A description drafted by a security team member and stored in a shared drive does not show that the organization adopted it. Confirm that each security and privacy addition has a named approver in HR and in the business unit, and that the approval date is recorded. Assessors commonly ask who approved the wording and when it took effect, so an unsigned draft is a weak answer. Evidence includes the approval record, the approver's role and the effective date on each description.

No link to role-based training

PS-9 exists in part because security responsibilities define which role-based training people need. If a description lists a duty, such as administering privileged accounts or handling regulated data, there should be a matching training requirement in the training program. Map each security duty in the descriptions to the training courses assigned to that role, and flag any duty with no course. Evidence is the mapping table, the training assignment records and completion reports for the affected roles.

Descriptions not updated after changes

Position descriptions often lag behind changes in systems, tools and responsibilities. A role that gains administrator access to a new cloud platform, or an analyst who begins handling a new category of personal data, may still carry the old description. Set a trigger list that requires review when systems, regulatory scope or reporting lines change, and record each review even when no edit is needed. Evidence is the review log, the change history of each description and the trigger list itself.

Contractors and external roles left out

Position descriptions govern employees, but many privileged operators in a self-hosted environment are contractors, managed service staff or vendor engineers. Their security duties are set through external personnel requirements rather than internal descriptions. Inventory external roles with privileged access and confirm that each one has a documented set of security duties in its contract or statement of work, as PS-7 requires. Evidence is the contract clause, the vendor role list and the monitoring records for those roles.

No evidence trail for assessors

Even well-written descriptions fail an assessment if the organization cannot show how they were produced, approved, distributed and used. Assessors test PS-9 through policy, procedures, the descriptions themselves and interviews with people who handle human capital management and personnel security. Keep a single register that links each role to its current description, approval record, training mapping and review date, and confirm with the assessor which format they expect. Evidence is that register, exported on request, with the underlying documents attached.

Who writes, approves and tests position descriptions

The organization owns PS-9. Human resources, system owners, and security and compliance leads decide which security and privacy responsibilities belong in each position description, and they approve the wording. The organization also owns the training that follows from those duties, because the NIST discussion ties position descriptions to role-based training requirements. Accountability cannot be delegated to a vendor, so the internal owners must be named in the personnel security policy and procedures.

Role ownership: HR and the business owner of each function agree which duties in each position description are security or privacy duties.
Approval record: Approved descriptions carry a version, an approver and an effective date that an assessor can trace.
Training linkage: Security and privacy duties feed the role-based training assignments for each position.
Periodic review: Descriptions change when roles change, so the organization sets a review trigger and records each review.
Staff sign-off: Confirm how employees and managers receive the updated descriptions and where acknowledgments are kept.

Check that the named HR and security owners can produce the current approved descriptions and the training assignments that match them without help from outside parties.

Questions buyers ask about PS-9 position descriptions

How much effort does PS-9 position descriptions take?

Effort depends on how many position descriptions exist and how much security and privacy content they already contain. PS-9 asks that security and privacy roles and responsibilities be written into organizational position descriptions, so the work is mostly a review and drafting exercise across HR documents, followed by agreeing the wording with the people who own each role. Organizations with a small number of technical roles and recent, well-maintained job descriptions usually have less to change than those with many legacy or generic descriptions. The effort is largely one-time, with recurring effort when roles change, new systems are added or descriptions are reviewed on the organization's normal cycle. Ask any partner to size the work from a list of position descriptions and the systems each role touches, not from a generic estimate.

Can our organization write PS-9 position descriptions in-house?

Yes. PS-9 is a documentation and governance control, and the organization owns it, so internal HR, security and system owners can do the work without outside help. Outside help is most useful when the team needs a structured inventory of roles and systems, a consistent set of security and privacy responsibility statements, or evidence prepared for an assessor. An implementation partner can prepare drafts and the evidence trail, but the organization must approve the final wording and keep the descriptions current. An independent assessor reviews the result and issues no report on the partner's work alone.

How long does rewriting position descriptions take for a typical system?

The duration depends on the drivers, not on a fixed figure. The main ones are the number of roles tied to the system, how many HR approval steps each description needs, whether security and privacy duties must be added to existing descriptions or new ones are created, and how quickly system owners respond to drafts. Parallel review by HR and security shortens the cycle, while unclear role ownership lengthens it. Ask the organization's HR team to confirm its approval workflow before setting any timeline, and ask any partner to tie the schedule to a written scope.

What does the work need from HR and system owners?

HR needs to provide the current position descriptions, the approval workflow and the template they use, and to confirm which roles carry security or privacy duties. System owners need to state which duties each role performs on their systems, such as account approval, access reviews, incident reporting or handling personal data. Both groups should review drafts together so that the wording matches real responsibilities and feeds the role-based training that NIST links to these roles. Without this input, descriptions tend to be generic and hard to test during assessment.

Does PS-9 apply at the privacy baseline?

No. SP 800-53B allocates PS-9 to the low, moderate and high security control baselines and does not include it in the privacy control baseline. Organizations with a privacy-only scope should confirm this against the current SP 800-53B baseline profiles in NIST's OSCAL content, because their own contract or regulator may still ask for privacy responsibilities to appear in role documentation. Where a contract requires it, the organization can address privacy duties in position descriptions even though the baseline does not select PS-9.

How does PS-9 map to the CSF 2.0 subcategories?

NIST's OLIR crosswalk from CSF 2.0 to SP 800-53 Release 5.2.0 lists PS-9 as an informative reference for one CSF 2.0 subcategory, GV.RR-04. NIST marks that crosswalk as not comprehensive, so it should be read as a starting point rather than a complete mapping. Organizations should confirm the mapping in the crosswalk itself and document any additional links they rely on, rather than assuming that meeting GV.RR-04 covers everything PS-9 requires. Teams using CSF profiles can record the mapping in their control evidence.

What should we ask for in a quote for PS-9 work?

Ask for a written scope that lists the position descriptions in scope, the systems and roles they cover, the review and approval steps, the deliverables and the evidence format. Request a breakdown of who does each step, including HR, security and system owner time, and which items are one-time versus recurring, such as annual reviews. Confirm what the partner will not do, including final approval of wording and any statement about assessment outcomes. Also ask how changes to scope are priced and who keeps the final versions. DeployOpen provides a quote from the written scope; it does not publish a price list.

Who issues the assessment result for PS-9?

An independent assessor issues any assessment result or report. The organization owns its personnel security controls, and an implementation partner such as DeployOpen can prepare position descriptions, the role inventory and supporting evidence, but cannot issue an audit report or attestation. Ask the assessor which SP 800-53A assessment objects they will examine for PS-9, typically the personnel security policy, procedures, the position descriptions and interviews with personnel and human capital staff, so the evidence is ready before fieldwork begins.

How DeployOpen prepares PS-9 position descriptions and evidence

DeployOpen helps organizations write security and privacy responsibilities into the position descriptions that PS-9 expects, then prepares the documents and records an assessor would examine. The organization owns its roles, its HR process and its control decisions, while an independent assessor decides whether the control is met.

How we scope

Engagements are fixed-scope, with the PS-9 deliverables and timelines agreed in writing before work starts.
The written scope lists which position descriptions, HR systems and role families are in scope for PS-9.
Scope confirms which baseline applies, since PS-9 is allocated to the low, moderate and high baselines.
We confirm who in HR, security and privacy owns each description and approves changes.

How we build

We map security and privacy duties to each role family in the organization's existing position description templates.
We align the role-based training needs that follow from each description with the training program owners.
We check that privacy responsibilities appear where personnel handle personally identifiable information.
We prepare the personnel security policy and procedure language that governs how descriptions are updated.

How we hand over

We deliver the revised position descriptions, a role responsibility matrix and a change log for review.
We provide an evidence package mapping each PS-9 assessment objective to the document or record that shows it.
We walk through the package with the people an assessor would interview, including personnel security and human capital staff.
The organization approves and issues the final documents. Only an independent assessor issues assessment results.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after the initial scope is delivered.
Retainers can cover periodic reviews of position descriptions when roles, systems or regulatory duties change.
Ask any provider to confirm in writing who maintains the descriptions after handover and how changes are recorded.