PM-13: Security and Privacy Workforce

PM-13 requires you to establish and run a security and privacy workforce development and improvement program: defined roles, required skills, training paths, and a way to measure and improve capability over time. To operationalize it fast, assign an owner, build a role-to-training matrix, track completion and proficiency, and retain evidence that the program is active and improving. ¹

Key takeaways:

• PM-13 is a program requirement: you need governance, defined scope, and an improvement loop, not a one-time training event. ¹
• Auditors look for role-based coverage (security and privacy), proof of execution, and proof you remediate skill gaps. ²
• The fastest path is mapping roles to required competencies and recurring evidence artifacts, then running it on a predictable cadence. ¹

PM-13: security and privacy workforce requirement sits in the “Program Management” control family for NIST SP 800-53 and is aimed at a durable capability: staffing, training, and continuous improvement for the people who design, build, run, and oversee your systems. The control is short, which is exactly why it causes findings. Teams treat “workforce” as an HR topic or treat “training” as annual awareness, then struggle to prove they have a workforce development program that covers both security and privacy roles with measurable improvement.

For a CCO, GRC lead, or security compliance owner, the operational goal is simple: you need a repeatable program that (1) defines the workforce scope, (2) sets expectations per role, (3) closes skill gaps through training or other development actions, and (4) produces audit-ready evidence without heroics. PM-13 applies cleanly across regulated environments that use NIST SP 800-53 as a baseline (including federal information systems and contractor systems handling federal data). ²

The guidance below is written to help you stand up PM-13 quickly, align it to other workforce-related controls you already run, and avoid the most common “we trained people” but “we don’t have a program” audit outcome.

Regulatory text

Requirement (verbatim): “Establish a security and privacy workforce development and improvement program.” ¹

What the operator must do

PM-13 expects an organizational program, not a slide deck. “Establish” means you can point to a defined program owner, documented approach, and consistent execution. “Workforce development and improvement” means you identify security and privacy roles and skills, develop them through training and other methods (mentoring, labs, certifications, exercises, on-the-job learning), and improve the program based on outcomes (gaps, incidents, assessment results, turnover, technology changes). ²

A practical way to read the control is: show that the right people exist, they are prepared for their responsibilities, and you have a mechanism to keep them prepared as requirements and systems change. ²

Plain-English interpretation (what PM-13 really requires)

You need a documented, operating system for security-and-privacy capability:

• Workforce scope: which roles count as your security and privacy workforce (not just the security team).
• Role expectations: what each role must know and do (baseline skills + role-specific skills).
• Development paths: how those skills are built and maintained.
• Improvement loop: how you measure effectiveness and update the program.

If you can’t answer “who needs which skills” and “how do we know we improved,” you will struggle to defend PM-13 during assessment.

Who it applies to (entity + operational context)

PM-13 applies when you are expected to align to NIST SP 800-53 controls, including:

• Federal information systems (agency-operated systems). ²
• Contractor systems handling federal data (service providers and other organizations operating systems in scope for federal requirements). ¹

Operationally, PM-13 is relevant anywhere security and privacy outcomes depend on people making good decisions repeatedly:

• Engineering (secure SDLC, code review, dependency management)
• IT operations (patching, backups, identity, logging)
• Privacy operations (data mapping, DSARs, retention)
• Risk and compliance (control operation, evidence, exceptions)
• Procurement / third-party risk (security/privacy due diligence requirements)

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

Use this as an implementation checklist you can assign and track.

Step 1: Assign ownership and define the program boundary

1. Name a PM-13 program owner (often GRC, security governance, or a joint security-privacy owner).
2. Define “security and privacy workforce” for your organization: list the job families/roles in scope, including “non-security” roles with material impact (e.g., developers, DBAs, system owners, helpdesk with privileged access, privacy analysts).
3. Define which systems and environments are in scope (for example, federal systems or contracts where NIST SP 800-53 is required). ²

Deliverable: PM-13 program charter (one to two pages) with scope, owner, stakeholders, cadence, and reporting path.

Step 2: Build a role-to-competency map (security and privacy)

1. Create a role inventory: roles, teams, and headcount identifiers (you don’t need to store sensitive HR data in the control evidence set; use role IDs where possible).
2. For each role, define:
   • Required security competencies (e.g., incident handling basics for system owners, secure coding for engineers).
   • Required privacy competencies (e.g., data classification/handling, minimization, consent concepts as relevant to the role).
3. Set proficiency expectations (basic/intermediate/advanced) and tie them to responsibilities that exist in your environment (on-call, approvals, architecture reviews, vendor reviews).

Deliverable: a role-to-competency matrix that explicitly covers both security and privacy responsibilities. ¹

Step 3: Define development paths and delivery mechanisms

1. For each competency, define how people meet it:
   • Training modules (internal or third-party)
   • Tabletop exercises
   • Secure design reviews or labs
   • Mentorship/apprenticeship
   • Required reading with attestation (use carefully; auditors prefer objective completion evidence)
2. Identify mandatory vs. elective development items by role.
3. Define new hire and role-change onboarding requirements (promotions into privileged roles are a common gap).

Deliverable: training/development catalog mapped back to the role-to-competency matrix.

Step 4: Implement tracking, exceptions, and corrective actions

1. Choose a system of record for completion and status (LMS, GRC platform, ticketing, HRIS export). The tool matters less than consistent records.
2. Define an exception process: how you handle contractors, temporary staff, or role coverage gaps; who can approve exceptions; what compensating controls apply.
3. Create corrective actions for gaps:
   • Individuals missing required training
   • Teams lacking role coverage (no trained backup for key functions)
   • Patterns from incidents or audit findings that imply skill gaps

Deliverable: workforce development register (or equivalent) with role coverage, completion status, and open remediation items.

Step 5: Prove “improvement” with a lightweight measurement loop

PM-13 includes “improvement,” so add program-level measures that are defensible without inventing metrics:

• Trend training completion by role (pass/fail, completion, overdue list)
• Reduction in repeat findings tied to human error categories (qualitative linkage is acceptable; don’t force a numeric claim)
• Post-incident lessons learned mapped to new training or exercises
• Annual review notes: what changed in the program and why

Deliverable: periodic PM-13 review memo or dashboard export showing decisions and updates over time. ²

Step 6: Map PM-13 to a control owner, procedure, and recurring evidence

This is the fastest way to become assessment-ready:

• Owner: accountable person
• Procedure: what happens, by whom, and when
• Evidence: what you retain each cycle

This aligns to the recommended implementation approach in your control guidance: “Map PM-13 to control owner, implementation procedure, and recurring evidence artifacts.” ¹

If you manage controls in Daydream, implement PM-13 as a control with scheduled evidence requests (role matrix, LMS exports, review memo) so you are not rebuilding proof during an audit.

Required evidence and artifacts to retain

Keep evidence minimal but decisive. Aim for artifacts that show design + operation + improvement.

Core artifacts (most audits):

• PM-13 program charter (scope, ownership, cadence)
• Role inventory and role-to-competency matrix (security + privacy)
• Training/development catalog mapped to competencies
• LMS or tracking exports showing completion status by role/team
• New hire / role-change onboarding requirements and sample completion
• Exception register with approvals and compensating controls
• Periodic program review notes and resulting updates (the “improvement” proof)

Nice-to-have artifacts (helps close debates fast):

• Tabletop exercise schedules and attendee lists
• Secure coding standards training completion tied to engineering repos
• Privacy training tailored to data-handling roles (customer support, analytics, marketing ops)

Common exam/audit questions and hangups

Expect these lines of questioning:

• “Show me your security and privacy workforce development program. Where is it documented?” ¹
• “Which roles are in scope, and how did you decide?”
• “How do you ensure developers (or system owners) have role-based training, not only annual awareness?”
• “How do you track contractors and third parties with privileged access?”
• “What changed in the program since last review? What triggered the change?” ²

Hangups that cause findings:

• No explicit privacy component (security-only program presented for a security-and-privacy requirement). ¹
• Training exists, but there is no role-to-skill mapping, so coverage can’t be demonstrated.
• Completion records are ad hoc (emails, screenshots) and not reproducible.

Frequent implementation mistakes (and how to avoid them)

1. Mistake: Treating PM-13 as “annual awareness training.”
   Fix: Keep awareness training, but add role-based competencies, tracking, and a review cycle tied to job responsibilities. ²

2. Mistake: Limiting scope to the security team.
   Fix: Include roles that create or process sensitive data, administer systems, approve access, or ship code.

3. Mistake: No improvement mechanism.
   Fix: Add a periodic review with documented changes (new modules, updated competencies after incidents, updated onboarding for new platforms). ¹

4. Mistake: No evidence strategy.
   Fix: Predefine recurring evidence artifacts and store them centrally. The control guidance explicitly points you toward mapping owner, procedure, and evidence. ¹

Risk implications (why operators get burned)

PM-13 failures rarely fail alone. Weak workforce programs show up downstream as:

• repeat audit findings across access control, change management, and incident response
• inconsistent privacy handling (misrouting requests, over-collecting data, mishandling retention)
• dependency on a small set of “heroes” who hold institutional knowledge

Even without public enforcement examples in your source pack, the operational risk is straightforward: if you can’t demonstrate a functioning security and privacy workforce program, assessors can reasonably question whether the rest of the control set is sustainable.

A practical 30/60/90-day execution plan

No sourced enforcement timelines are provided, so treat this as operator guidance you can tailor.

First 30 days (stand up the skeleton)

• Assign PM-13 owner and publish a short charter.
• Define in-scope roles and systems.
• Draft the initial role-to-competency matrix (start with critical roles).
• Identify system of record for training status and evidence storage.

Days 31–60 (make it real and measurable)

• Map existing training to the competency matrix; fill obvious gaps.
• Launch role-based assignments for priority roles (engineering, system owners, IAM admins, privacy ops).
• Implement exception workflow for contractors and role changes.
• Produce the first status report: completion snapshot + gap list + corrective actions.

Days 61–90 (prove improvement)

• Run a program review with stakeholders (security, privacy, HR/L&D, IT, engineering leadership).
• Update the matrix and catalog based on findings (incidents, audit results, new technology).
• Capture “before/after” evidence: what changed, who approved it, and when.
• Convert PM-13 into a steady-state control with recurring evidence requests (Daydream can automate evidence collection reminders and keep artifacts linked to the control record).

Frequently Asked Questions

Does PM-13 require a dedicated training team or new headcount?

PM-13 requires a workforce development and improvement program, not a specific org design. You can meet it with clear ownership, role-based requirements, and reliable execution records. ¹

Who counts as the “security and privacy workforce”?

Include any role with material security or privacy responsibilities, including engineering, IT ops, system owners, and privacy operations. Define and document your scope so an auditor can follow the logic. ²

What’s the minimum evidence set to avoid a PM-13 finding?

Keep a charter, a role-to-competency matrix, training mappings, completion tracking, and proof of periodic review updates. Missing implementation evidence is a known risk factor for PM-13. ¹

How do we handle contractors or third parties who support in-scope systems?

Put them into the same role-based requirements where they perform equivalent functions, or document exceptions with compensating controls and approvals. Track completion in a system of record or maintain attestations tied to access approvals.

Our privacy team is separate from security. Do we need one combined program?

You need one program that covers both security and privacy workforce development, but it can be administered jointly with clear interfaces. The evidence should show privacy is not an afterthought. ¹

How do we demonstrate “improvement” without complicated metrics?

Use simple, reviewable artifacts: periodic review notes, updated matrices, and documented changes to training paths triggered by incidents, findings, or platform changes. Improvement is visible when the program changes based on identified gaps. ²

Footnotes

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

2. NIST SP 800-53 Rev. 5