PS-9: Position Descriptions

PS-9: position descriptions requirement means you must embed security and privacy roles and responsibilities directly into job descriptions for roles that design, operate, administer, secure, or access your systems and data. Operationalize it by identifying in-scope positions, defining minimum security/privacy duties per role family, updating HR-controlled descriptions, and retaining evidence that the updates are approved, current, and used in hiring and performance management. ¹

Key takeaways:

• Treat PS-9 as an HR-controlled control: job descriptions must explicitly state security and privacy responsibilities. ¹
• Scope is broader than “security team”; include IT, engineering, product, data, and business roles with privileged or sensitive access.
• Auditors will look for consistency across job descriptions, onboarding, training, and access provisioning, plus proof the descriptions are maintained over time.

PS-9 fails in predictable ways: job descriptions say “must follow policies,” but never state which security or privacy responsibilities the role owns. That gap matters because position descriptions are where you formalize accountability before someone is hired, promoted, granted admin access, or asked to approve risk decisions. PS-9 is also deceptively cross-functional. You need HR to own the document system of record, Information Security and Privacy to define the expectations, and functional leaders to accept the duties as part of “the job,” not an afterthought.

For a CCO, GRC lead, or security compliance owner, the fastest path is to treat PS-9 like a structured documentation rollout: define role families, attach a minimum set of security/privacy responsibility statements to each family, push updates through HR’s approval workflow, and then build a small evidence pack that shows it’s live in operations. NIST’s requirement is short, but assessments are not. Your goal is to show that security and privacy responsibilities are intentionally assigned, consistently documented, and maintained as roles change. ²

Regulatory text

NIST requirement (PS-9): “Incorporate security and privacy roles and responsibilities into organizational position descriptions.” ¹

What the operator must do: ensure job descriptions (or equivalent position descriptions) explicitly include the security and privacy duties that the role is expected to perform and be accountable for. This is not a policy-only control; the requirement is anchored to the position description artifact itself. ¹

Plain-English interpretation (what PS-9 is really asking)

PS-9 asks one question: If you hire someone into a role that touches systems or data, does their job description clearly state their security and privacy responsibilities? ¹

That includes:

• Responsibilities they personally perform (example: “review access requests,” “apply secure coding practices,” “classify data,” “report incidents”).
• Responsibilities they are accountable for (example: “approve exceptions,” “ensure vendors under your management meet required controls,” “ensure system changes follow the change process”).

A strong PS-9 implementation produces two outcomes:

1. People understand what security/privacy tasks are part of their job.
2. The organization can prove accountability was defined before incidents, not written after.

Who it applies to (entity and operational context)

PS-9 is commonly assessed in:

• Federal information systems and programs using NIST SP 800-53 as the control baseline. ²
• Contractor systems handling federal data, where NIST-based control expectations are imposed by contract or inherited governance requirements. ²

Operationally, PS-9 applies wherever you maintain position descriptions, including:

• Standard HR job descriptions
• Role profiles in an HRIS
• Internal role matrices used for access provisioning
• Contractor statements of work that function as “position descriptions” for staff augmentation roles (treat these as in-scope if they perform privileged or sensitive functions)

Practical scoping rule (works in audits)

Start with roles that can:

• Administer systems (sysadmins, cloud admins, DBAs)
• Deploy or change code/infrastructure (engineers, SRE, DevOps)
• Access sensitive data (data engineers, analysts with production data access)
• Approve risk decisions (system owners, product owners for regulated products)
• Manage third parties with access to your environment (procurement, vendor managers, IT sourcing)

What you actually need to do (step-by-step)

Use this as an execution checklist. Keep it boring and repeatable.

Step 1: Assign ownership and define the “system of record”

• Control owner: usually GRC, Security Compliance, or Privacy Governance.
• Document owner: HR (because HR controls job descriptions and hiring templates).
• Approvers: Security lead + Privacy lead (or DPO equivalent) + functional leader per role family.

Define one official repository: HRIS, document management system, or controlled wiki with approvals. If descriptions live in multiple places, auditors will sample and find inconsistencies.

Step 2: Build an in-scope role inventory

Create a list of:

• Current employees in technical and data roles
• Privileged access roles (from IAM groups or admin role assignments)
• Contractors with admin access
• System owners and data owners

Output artifact: PS-9 In-Scope Role Register (role title, department, hiring manager, whether privileged access is typical, link to position description).

Step 3: Define security and privacy responsibility statements by role family

Create “responsibility blocks” you can paste into job descriptions. Keep them specific and testable.

Examples (edit to fit your environment):

• All workforce roles (baseline):
  • Follow security and privacy policies; complete required training.
  • Report suspected security incidents and privacy events through the defined channel.
• Engineering / DevOps / SRE:
  • Follow secure development practices; remediate identified security issues within agreed timelines.
  • Protect secrets and keys; avoid storing secrets in code or tickets.
  • Participate in change control and post-incident reviews for services you operate.
• System owners / product owners:
  • Ensure system risk is assessed and documented; approve exceptions per policy.
  • Ensure data handling requirements are implemented for the product’s data types.
• IT administrators:
  • Provision/deprovision access per approved requests; perform periodic access reviews when assigned.
  • Maintain secure configurations and patching responsibilities for assigned assets.
• Privacy/data roles:
  • Classify data, apply handling requirements, and validate retention/deletion practices when required.
  • Support privacy impact assessments or equivalent reviews when systems/processes change.

Make each statement map to internal procedures you already run (access request process, incident reporting, SDLC controls). PS-9 is easier to defend when responsibilities mirror operational workflows.

Step 4: Update job descriptions and run an approval workflow

For each in-scope position description:

• Add the relevant responsibility block(s)
• Confirm the description clearly indicates ownership versus participation
• Route for approvals and retain approval evidence

If you have many roles, start with templates by job family, then bulk-update individual postings.

Step 5: Operationalize: connect PS-9 to hiring, onboarding, and performance

PS-9 is stronger when you can show the job description is used, not archived.

Minimum operational hooks:

• Hiring: job postings and offer packets reference the updated description or incorporate the same responsibilities.
• Onboarding: manager confirms the employee reviewed role responsibilities (attestation or checklist).
• Performance: role expectations appear in performance goals for applicable roles (even as a standard “security & privacy responsibilities” section).

Step 6: Set maintenance triggers (how you keep it current)

Define triggers that require review/update:

• New system onboarding or major architecture changes
• New regulated data types or updated data classification approach
• Material changes in responsibilities (new admin tooling, new incident process)
• Reorgs that move system ownership

Document a simple cadence for HR and GRC to re-confirm templates remain current (tie it to your policy review cycle if you have one).

Required evidence and artifacts to retain (audit-ready)

Keep an evidence packet that makes sampling easy:

1. PS-9 procedure (1–2 pages) describing how role scoping, updates, approvals, and maintenance work.
2. In-Scope Role Register with links to current descriptions.
3. Job description templates showing embedded security/privacy responsibility blocks.
4. Approved position descriptions for a sample of high-risk roles (admins, engineers, system owners).
5. Approval records (ticket, HR workflow export, or email approval chain captured in a controlled system).
6. Change log showing when templates/descriptions were updated and by whom.
7. Onboarding acknowledgment (manager checklist, LMS acknowledgment, or HR onboarding task completion) showing the employee received role expectations.

If you use Daydream to manage control operations, map PS-9 to a control owner, a repeatable procedure, and recurring evidence artifacts so you can produce the “what changed and when” story on demand. ¹

Common exam/audit questions and hangups

Expect these, and prepare the exact artifacts listed above.

• “Show me the job description for a system administrator and where security responsibilities are defined.”
• “How do you decide which roles need security and privacy responsibilities?”
• “How do you ensure contractors and temporary staff have equivalent responsibilities?”
• “When did you last update these descriptions, and what triggered the update?”
• “Do hiring managers actually use these descriptions in recruiting and onboarding?”
• “How do privacy responsibilities differ from security responsibilities in your role templates?”

Hangup to avoid: handing over a security policy and claiming it satisfies PS-9. The control is about position descriptions, so produce those first.

Frequent implementation mistakes (and how to avoid them)

1. Mistake: One generic sentence for every role.
   Fix: keep a baseline block, but add role-specific duties for privileged and data-intensive roles.

2. Mistake: Security-only language, no privacy responsibilities.
   Fix: add data handling, incident reporting for privacy events, and privacy review participation where relevant. ¹

3. Mistake: HR templates updated, but existing employees’ descriptions unchanged.
   Fix: bulk-update current role descriptions for in-scope roles, not just future postings.

4. Mistake: No maintenance trigger, so descriptions drift.
   Fix: write down triggers and assign a reviewer; keep a lightweight change log.

5. Mistake: Contractors ignored.
   Fix: add security/privacy responsibility clauses to SOWs or onboarding checklists when HR job descriptions are not used for non-employees.

Risk implications (why PS-9 shows up in real incidents)

PS-9 gaps turn into accountability gaps:

• Incident response stalls because no role is assigned to report, triage, or escalate.
• Access reviews fail because “who owns this review” is ambiguous.
• Privacy obligations get missed because teams treat privacy as a legal review only, not an operational duty.

Assessors often treat PS-9 as a maturity signal: if responsibilities are not in job descriptions, they will probe whether other people-centric controls (training, separation of duties, access governance) are truly embedded.

Practical 30/60/90-day execution plan

First 30 days (establish control design)

• Assign control owner and HR document owner; confirm repository and approval workflow.
• Build in-scope role inventory using IAM/admin group exports plus org charts.
• Draft responsibility blocks for key role families; get Security and Privacy review.
• Pilot updates for a small set of high-risk roles (admins, SRE, system owners).

By 60 days (scale and align operations)

• Update job description templates for all in-scope families and standard job posting templates.
• Bulk-update existing job descriptions for in-scope roles; capture approvals and change log entries.
• Add onboarding acknowledgment step for new hires and role changes.
• Define maintenance triggers and assign a periodic reviewer.

By 90 days (prove operating effectiveness)

• Run an internal sampling review: pick roles across engineering, IT, data, and management; verify descriptions contain the right blocks.
• Validate operational linkage: confirm at least one hiring packet/onboarding record references updated responsibilities.
• Package evidence for assessors: procedure, register, samples, approvals, change log, onboarding proof.

Frequently Asked Questions

Which roles must have security and privacy responsibilities in their position descriptions?

Start with roles that administer systems, deploy changes, access sensitive data, or approve risk decisions. Keep a baseline statement for all staff, then add role-specific blocks for privileged and data-heavy roles. ¹

Do we need to update every historical job description, or only templates going forward?

Update templates and current in-scope roles. Auditors commonly sample current incumbents, so you need evidence the requirement applies to the active workforce, not only future hiring.

Our HR team owns job descriptions. How do we enforce consistency without slowing hiring?

Provide pre-approved responsibility blocks by role family and incorporate them into HR templates. That lets hiring managers move fast while keeping security and privacy language consistent and controlled.

How do we handle contractors if they don’t have “job descriptions” in our HRIS?

Treat the statement of work, role profile in your contractor onboarding process, or access request justification as the equivalent position description. Ensure it contains explicit security and privacy responsibilities tied to the work performed. ¹

What evidence is most persuasive in an assessment?

A role register linked to approved job descriptions, plus approval records and a change log. Add onboarding acknowledgment or performance goal linkage to show the descriptions are used in operations.

Can we satisfy PS-9 by pointing to policies and annual training?

Policies and training help, but PS-9 specifically requires incorporation into position descriptions. Keep policies and training as supporting evidence, not the primary artifact. ¹

Footnotes

1. NIST SP 800-53 Rev. 5 OSCAL JSON

2. NIST SP 800-53 Rev. 5