Position Descriptions

To meet the FedRAMP Moderate “Position Descriptions” requirement, you must embed security and privacy roles and responsibilities directly into the job/position descriptions for relevant roles, then keep those descriptions current and provable. The goal is simple: examiners should be able to trace who is responsible for security/privacy work, and see that responsibility formally assigned in HR-controlled documents. ¹

Key takeaways:

• Update position descriptions (not just policies) to include specific security and privacy responsibilities. ¹
• Cover both technical and business roles that touch the FedRAMP boundary, third parties, or sensitive data flows. ¹
• Keep evidence: approved job descriptions, a role-to-control responsibility map, and a repeatable review workflow. ¹

“Position descriptions requirement” sounds like HR hygiene, but PS-9 is an accountability control. FedRAMP assessors and agency security reviewers want to see that security and privacy work is not informal or dependent on tribal knowledge. The requirement is narrow: incorporate security and privacy roles and responsibilities into organizational position descriptions. ¹

For a CCO, CISO, or GRC lead, the fastest path is to treat this like a controlled documentation problem with HR as the system of record. You identify roles that influence security or privacy outcomes, define the responsibilities in plain, auditable language, and push those responsibilities into the official job/position description templates. Then you create a lightweight maintenance process so job descriptions track reality as your system, staffing model, and third-party footprint change.

This page gives you requirement-level implementation guidance: who to include, what to write, how to evidence it, and what auditors tend to challenge. It also includes a practical execution plan you can run without waiting for a full org redesign.

Regulatory text

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

Operator interpretation: Your job descriptions must explicitly state relevant security and privacy responsibilities for the roles that perform, approve, administer, or oversee security/privacy activities. A standalone RACI chart or security policy helps, but does not satisfy PS-9 by itself because PS-9 is specifically about position descriptions. ¹

Plain-English interpretation (what “good” looks like)

You pass PS-9 when:

• A reviewer can pick a role (for example, cloud ops engineer, IAM admin, product manager, privacy lead) and read the official position description to find concrete security/privacy responsibilities that match what the person actually does.
• Those responsibilities align with how your security and privacy programs operate (access control, incident response, change management, vulnerability management, data handling, third-party oversight, etc.).
• Updates to responsibilities follow a controlled change process (versioning, approvals, effective dates), not ad hoc edits in a shared drive.

This is accountability in writing. If a breach or incident happens, PS-9 reduces the “nobody owned it” failure mode by making ownership part of the employment role.

Who it applies to

Entities

• Cloud Service Providers (CSPs) operating under FedRAMP Moderate expectations. ¹
• Federal Agencies implementing the same control baseline for internal systems or shared services. ¹

Operational context (which roles to cover) Focus on roles that:

• Administer or design systems in the FedRAMP boundary.
• Handle customer or government data, including logs and support artifacts.
• Approve changes, exceptions, or risk decisions.
• Manage third parties with access to systems/data (support vendors, MSPs, SOC providers).
• Own security/privacy governance, compliance, audit response, and incident response.

Do not limit this to the security team. Many PS-9 gaps happen because engineering, IT, support, and product roles are excluded even though they materially affect security and privacy outcomes.

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

Step 1: Inventory roles that need security/privacy responsibilities

Build a list from three sources:

1. Org chart and team rosters (engineering, IT, security, privacy, support, HR, compliance).
2. System access reality (admin roles, privileged access groups, on-call roles).
3. Control ownership reality (who performs key control activities, who approves, who reviews).

Deliverable: a “PS-9 in-scope roles list” with a clear rationale for each role.

Step 2: Define the minimum responsibility statements per role

For each role, write responsibilities that are:

• Actionable: “Review and approve access requests for privileged roles” beats “Responsible for security.”
• Bounded: mention scope (FedRAMP boundary systems, production environment, customer data).
• Aligned to process: reference the activity, not a tool name (tools change; responsibilities remain).
• Dual-lens: include security and privacy where applicable, even if the role leans technical.

A practical pattern is 3–6 bullets per role covering:

• Access control and privileged operations (if applicable)
• Secure change practices
• Incident reporting and participation
• Data handling and privacy expectations
• Third-party access handling (if applicable)
• Compliance obligations (training, policy adherence, evidence support)

Step 3: Embed responsibilities into HR-controlled position descriptions

This is where many teams fail: they draft a nice RACI but never update HR’s official job description.

Implementation options that usually work:

• Add a dedicated section: “Security and Privacy Responsibilities” to your standard job description template.
• If HR templates are rigid, add responsibilities under “Essential Functions” or “Duties.”

Control point: Ensure position descriptions live in the HR system (or other controlled repository) and follow document control basics: owner, version, approval, effective date.

Step 4: Map responsibilities to program ownership (so it’s auditable)

Create a lightweight mapping artifact:

• Role → responsibilities → related control/process area Examples of process areas: access management, logging/monitoring, vulnerability management, incident response, configuration management, data retention, third-party access.

This mapping is what lets you answer examiner questions quickly without over-explaining.

If you maintain a GRC control ownership matrix, link roles in that matrix back to the position descriptions as authoritative sources.

Step 5: Operationalize ongoing updates (the maintenance loop)

Build PS-9 into existing change points:

• New role creation: HR requires security/privacy bullets before posting.
• Role change / promotion: job description updated with effective date.
• Program change: when you change a security/privacy process, update impacted roles.
• Access model change: new privileged functions trigger role description updates.

Assign two owners:

• Business owner (HR or People Ops): controls templates and job description repository.
• Control owner (GRC/Security): ensures required responsibilities exist and remain accurate.

Step 6: Validate in practice (spot checks)

Do targeted checks:

• Pick roles with privileged access.
• Compare: job description responsibilities vs. actual runbooks/on-call duties vs. access rights.
• Fix mismatches. Auditors notice “paper roles” that don’t match reality.

Step 7: Package evidence for assessment

Your objective is fast retrieval. Store evidence in a single PS-9 folder or GRC evidence object with consistent naming.

If you use Daydream to run audit prep, treat PS-9 like a recurring evidence request with a checklist: in-scope roles list, role-to-responsibility map, approved position descriptions, and last review proof. Daydream’s value is keeping the evidence thread tight so you are not re-assembling HR docs during an assessment.

Required evidence and artifacts to retain

Keep artifacts that prove both content and control:

1. Position descriptions (approved copies) for in-scope roles with visible security/privacy responsibilities. ¹
2. PS-9 in-scope roles list with date and owner.
3. Role-to-control/process mapping (table or matrix) showing how responsibilities connect to your program.
4. Document control evidence: version history, approvals, effective dates, and where the system of record is.
5. Maintenance workflow evidence: screenshot/export of HR workflow, ticketing workflow, or SOP showing how updates happen.
6. Spot check results (optional but strong): a short memo or checklist showing periodic validation.

Common exam/audit questions and hangups

Auditors typically ask:

• “Show me the job description for your ISSO/ISSM/security lead and where responsibilities are documented.” ¹
• “How do you ensure engineers with production access understand privacy requirements?” ¹
• “What triggers updates to job descriptions when your security processes change?” ¹
• “Which roles are responsible for incident reporting and participation?” ¹
• “Are third parties covered if they perform operational duties?” (PS-9 focuses on organizational position descriptions, but your operating model should still document third-party responsibilities contractually and in onboarding artifacts.)

Hangups that slow assessments:

• HR refuses to change templates, so teams keep responsibilities elsewhere.
• Responsibilities are vague (“ensure security”) and not testable.
• Position descriptions exist, but nobody can show approvals/version control.

Frequent implementation mistakes (and how to avoid them)

1. Mistake: Only updating security team job descriptions.
   Fix: Include operations, engineering, IT, support, and any role with privileged access or control approvals.

2. Mistake: Writing generic, non-verifiable bullets.
   Fix: Use responsibility verbs tied to activities: review, approve, report, implement, maintain, participate.

3. Mistake: RACI charts without HR-backed job descriptions.
   Fix: Keep RACI, but treat it as supporting evidence. PS-9 wants responsibilities embedded in position descriptions. ¹

4. Mistake: No update trigger.
   Fix: Add PS-9 checks to role creation, access model changes, and security process changes.

5. Mistake: “Privacy is handled by legal, so engineers don’t need it.”
   Fix: Engineers and support still need privacy responsibilities when they handle personal data, logs, or support tickets that contain sensitive information.

Enforcement context and risk implications

No public enforcement cases were provided for this requirement in the source catalog, so tie risk to operational outcomes rather than case law.

PS-9 failures show up in two ways:

• Assessment friction: you lose time proving ownership because responsibilities are scattered across policies, wikis, and tribal knowledge.
• Control failure risk: incident response, access governance, and data handling break down when responsibilities are implied rather than assigned.

Treat PS-9 as a control that supports clear accountability, clean handoffs, and defensible governance.

A practical 30/60/90-day execution plan

First 30 days (Immediate: establish scope and templates)

• Identify in-scope roles across security, privacy, IT, engineering, ops, support, and compliance.
• Pull current position descriptions from HR for those roles and mark gaps.
• Draft a standard “Security and Privacy Responsibilities” section with approved language patterns.
• Agree with HR on the change mechanism (template update vs. per-role edits) and document owner.

Days 31–60 (Near-term: rewrite, approve, and map)

• Update each in-scope position description with specific responsibilities.
• Route through HR approval workflow and capture approved versions.
• Build the role-to-process/control mapping table.
• Run spot checks on a few high-risk roles (privileged access, on-call responders, IAM admins) and resolve mismatches.

Days 61–90 (Stabilize: maintenance and audit packaging)

• Publish an SOP for job description updates and define triggers (new role, process change, access change).
• Add PS-9 to onboarding/offboarding checklists where role changes occur.
• Package evidence for FedRAMP assessment: in-scope list, approved job descriptions, mapping, and workflow proof.
• Schedule periodic re-validation tied to org changes and major security program updates.

Frequently Asked Questions

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

Start with any role that administers systems, approves risk decisions, handles sensitive data, or participates in incident response for the FedRAMP boundary. Expand to business roles that influence security/privacy outcomes, such as product and support, when they access production data or logs. ¹

Do we need to update position descriptions for contractors or third-party staff?

PS-9 is about organizational position descriptions, which usually means employee roles. For third parties, mirror the same responsibilities in contracts, SOWs, and onboarding requirements, and document who internally owns oversight of that third party’s access and activities. ¹

Are policies and a RACI matrix enough if HR won’t change job descriptions?

They help, but PS-9 explicitly requires incorporating responsibilities into position descriptions. If HR templates are constrained, add an approved addendum that is attached to the official position description and controlled through the same workflow. ¹

How detailed should the security/privacy bullets be?

Detailed enough to be testable in an interview and traceable to a process (access approvals, incident reporting, change participation, data handling). Avoid tool names and vague statements; focus on actions and scope.

How do we prove job descriptions are “controlled” documents?

Keep evidence of approvals, effective dates, and version history from your HR system or document control workflow. Store the exported, approved copies with consistent naming so you can produce them quickly during assessment.

What’s the fastest way to operationalize PS-9 without rewriting every job description from scratch?

Add a standardized “Security and Privacy Responsibilities” section to the job description template, then update only in-scope roles first. Maintain a mapping table so you can show coverage without over-editing roles that have no security/privacy touchpoints. ¹

Footnotes

1. NIST Special Publication 800-53 Revision 5