PM-3: Information Security and Privacy Resources

PM-3 requires you to budget and request the people, tools, and services needed to run your information security and privacy programs through your formal capital planning and investment process, and to document every exception. To operationalize it fast, define “required resources,” embed them into funding workflows, and maintain an exceptions register with approval and rationale. ¹

Key takeaways:

• Tie security and privacy program resourcing directly to capital planning and investment requests, not informal side agreements. ¹
• Maintain a documented, approved exception process for any missed or deferred resource needs. ¹
• Evidence wins audits: budgeting artifacts, investment request records, and an exceptions register must be review-ready. ¹

The pm-3: information security and privacy resources requirement is a governance control with an operational “teeth” problem: most teams can describe what they need, but they can’t prove those needs were built into the organization’s funding mechanics. PM-3 closes that gap by forcing security and privacy resourcing into the same capital planning and investment request channels used for other enterprise priorities, and by requiring documented exceptions when that doesn’t happen. ¹

For a Compliance Officer, CCO, or GRC lead, the fastest path is to treat PM-3 like a workflow design and evidence design exercise. You are not just writing a policy. You are (1) defining what counts as “resources,” (2) mapping those resource needs to a repeatable request method that finance and portfolio teams already respect, and (3) building an exceptions register that makes shortfalls visible, owned, and time-bound. ¹

This page gives requirement-level guidance you can implement immediately: who must do what, where it fits in budgeting and portfolio management, the artifacts to retain, common audit traps, and a practical execution plan.

Regulatory text

Control requirement (verbatim excerpt): “Include the resources needed to implement the information security and privacy programs in capital planning and investment requests and document all exceptions to this requirement;” ¹

Operator interpretation:
You must be able to show, with records, that your information security program and privacy program are funded through your organization’s formal capital planning and investment request mechanisms. If any needed security/privacy resources are not included (or are deferred, cut, or funded outside the normal process), you must document those exceptions, including what was excepted and who approved the deviation. ¹

This is not a “have a budget” control. It is a “prove the resourcing went through the official machinery, and track deviations” control.

Plain-English interpretation (what PM-3 is really testing)

PM-3 tests whether security and privacy are treated as first-class portfolio items. Auditors look for two things:

1. Integration: Security and privacy resource needs appear in capital plans and investment requests the same way other programs do (staffing, tooling, managed services, assessments, training, and lifecycle costs). ¹

2. Exception discipline: If you did not include a needed resource, you can point to a controlled exception record with rationale and approval, not a hallway conversation or a buried email thread. ¹

A mature PM-3 implementation makes underfunding visible early, assigns ownership, and creates a clean audit trail.

Who it applies to

PM-3 is commonly applied in these contexts:

• Federal information systems implementing NIST SP 800-53 controls as part of their program requirements. ¹
• Contractor systems handling federal data where NIST SP 800-53 is contractually flowed down or used to demonstrate program alignment. ¹

Operationally, it applies anywhere your organization makes spending decisions through structured processes such as annual budgeting, capital planning, portfolio governance, investment committees, IT project intake, procurement planning, or strategic planning cycles.

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

Step 1: Define “resources needed” in a way finance accepts

Create a scoped definition for PM-3 resources that is practical and auditable. Include categories such as:

• People (security engineering, GRC, privacy, IAM, incident response)
• Technology (security tooling, privacy tooling, monitoring, asset inventory support)
• Services (penetration testing, audits/assessments, managed detection, privacy counsel support where applicable)
• Program overhead (training delivery, third-party assessments, tabletop exercises)
• Lifecycle costs (renewals, maintenance, decommissioning)

Keep it as a one-page “PM-3 Resource Taxonomy” so teams can tag items consistently in requests.

Step 2: Map the security and privacy program roadmap to resource line items

Take your program plan (initiatives, control gaps, risk treatment items) and translate it into funding requests:

• For each initiative, document: objective, owner, dependency, required resourcing, timing, and whether it is CapEx/OpEx based on your internal accounting rules.
• Link each line item to the security/privacy outcome it supports (for example, “SIEM logging expansion supports detection and response program objectives”).

This is where most teams fail: they keep the roadmap in a GRC tool and the budget in spreadsheets with no traceability.

Step 3: Embed PM-3 into capital planning and investment request workflows

Decide how requests enter your formal pipeline, then hardwire PM-3 checks:

• For project intake: Add mandatory fields or attachments: “Security/Privacy Resource Impact,” “Incremental run cost,” and “Security/Privacy tooling dependency.”
• For annual planning: Require the CISO and privacy lead (or equivalent) to submit a consolidated “Security & Privacy Program Investment Request” package.
• For procurement planning: Require that significant third-party purchases include security and privacy program resourcing impacts (implementation effort, ongoing admin effort, monitoring and assurance costs).

If you can’t modify the intake system quickly, implement a compensating control: a standardized PM-3 addendum template attached to every investment request.

Step 4: Establish an exception process with a real register

PM-3 explicitly requires documented exceptions. Build an exceptions process that is not performative:

Minimum fields for the PM-3 Exceptions Register:

• Exception ID
• Date opened
• Resource not funded / not included in request
• Impact statement (what control objective is delayed or what risk increases)
• Compensating measures (if any)
• Decision (approved/denied/deferred)
• Approver (name/role)
• Expiration/next review trigger
• Closure evidence (funded later, risk accepted, scope changed)

Set ownership: GRC maintains the register; finance/portfolio governance retains authority to approve exceptions with security/privacy concurrence.

Step 5: Build review cadence into existing governance

PM-3 becomes sustainable when it is reviewed in forums that already exist:

• Portfolio review: open exceptions, aging exceptions, and top unfunded requirements.
• Quarterly security/privacy steering: validate new resource needs and confirm exceptions remain valid.
• Annual budget closeout: reconcile what was requested vs funded; roll forward exceptions.

Step 6: Make evidence “audit-ready by default”

Treat evidence capture as part of the workflow, not a scavenger hunt:

• Save investment request packages in a controlled repository.
• Require final approvals to be attached or referenced.
• Export exceptions register snapshots on a regular basis (or keep immutable change history in your system of record).

Daydream can help here by mapping PM-3 to a named control owner, a documented procedure, and a recurring evidence set so you can answer audits with a consistent packet instead of assembling artifacts under pressure. ¹

Required evidence and artifacts to retain

Keep artifacts that prove both integration and exception discipline:

Capital planning / investment artifacts

• Security & privacy program budget submission package
• Investment request forms/tickets with security/privacy resource components
• Portfolio committee minutes or approval records referencing security/privacy funding decisions
• Procurement plans that reflect security/privacy program run-cost impacts

Program traceability artifacts

• Crosswalk: program initiatives → resource line items → investment requests
• Resource plan for security and privacy functions (roles, tools, services)

Exceptions artifacts

• PM-3 Exceptions Register with approvals and rationale
• Supporting risk acceptance documentation where exceptions increase risk
• Evidence of periodic review and closure decisions

Common exam/audit questions and hangups

Expect reviewers to ask:

• “Show me where security and privacy program resourcing appears in the capital plan or investment request system.” ¹
• “How do you determine what resources are ‘needed’?” ¹
• “What happens when funding is denied or deferred?” (They want the exception record.) ¹
• “Who can approve an exception, and how is it tracked to closure?” ¹
• “Prove this is repeatable year over year, not a one-time exercise.” ¹

Hangups that stall audits:

• Budget data exists, but is not tied to the security/privacy program scope.
• Exceptions exist in email, not a register with approvals.
• Resource needs are described as “security improvements” with no specific people/tools/services.

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails PM-3	How to fix it
Security has a budget, but not tied to capital planning/investment requests	PM-3 is about inclusion in formal mechanisms	Require a traceable investment request ID for each material resource item
Privacy is treated as “policy-only” and not resourced	PM-3 explicitly covers privacy program resources	Build a privacy resource plan (people, tooling, assessments) and submit through the same process
Exceptions are verbal or buried in meeting notes	PM-3 requires documented exceptions	Create a dedicated exceptions register with required fields and approvals
Only new spend is captured; run costs are ignored	Program implementation depends on sustaining resources	Include renewals, staffing backfill, and managed service costs in requests
Control owners can’t produce evidence quickly	Audit risk increases and confidence drops	Pre-package evidence quarterly; assign a single PM-3 evidence owner in GRC

Enforcement context and risk implications

No public enforcement cases were provided in the supplied sources for PM-3. ¹

Practically, PM-3 failures show up as program fragility: delayed control implementations, under-scoped monitoring, and privacy gaps that persist because nobody funded the fix. In assessments, PM-3 weakness often correlates with repeat findings elsewhere because teams cannot staff or tool their way out of known issues.

A practical execution plan (30/60/90-day)

Use this as an operator’s rollout sequence; tailor to your budgeting calendar.

Days 1–30: Establish the minimum viable PM-3 control

• Name the PM-3 control owner (usually GRC) and accountable executives (CISO and privacy lead).
• Publish the one-page PM-3 Resource Taxonomy and the PM-3 Addendum template for investment requests.
• Stand up the PM-3 Exceptions Register and define who can approve exceptions.
• Collect current-year artifacts: existing security/privacy budgets, current investment requests, and any denied funding decisions.

Days 31–60: Integrate into intake and portfolio governance

• Update project intake or investment request workflows to require the PM-3 addendum fields/attachment.
• Build a crosswalk from the security and privacy program roadmap to specific resource line items.
• Pilot the exception process: log every unfunded resource item and route it for approval with rationale.

Days 61–90: Make it durable and audit-ready

• Convert the pilot into steady state: routine exception reviews in portfolio governance meetings.
• Produce an “audit packet” folder structure with: latest budget request package, sample investment requests, and the current exceptions register export.
• Run an internal tabletop audit: ask a non-GRC leader to locate and explain evidence from request to approval to exception.

Daydream fits naturally at this stage by maintaining the PM-3 mapping to owners, procedures, and recurring evidence, so the control runs continuously instead of being rebuilt during audits. ¹

Frequently Asked Questions

What counts as “capital planning and investment requests” for PM-3?

PM-3 expects security and privacy resource needs to appear in the same formal funding channels used by the business, such as portfolio intake, annual budget submissions, and investment committee requests. If your organization uses multiple channels, pick the authoritative ones and document the mapping. ¹

Do I need a separate budget for privacy to satisfy PM-3?

You need demonstrable privacy program resourcing, not necessarily a standalone cost center. If privacy is funded through shared functions, keep clear traceability from privacy needs to funded line items and document any gaps as exceptions. ¹

What is a PM-3 “exception,” exactly?

An exception is any case where needed security/privacy resources were not included in capital planning or investment requests, or were not funded through that process. PM-3 requires you to document each exception with approval and rationale. ¹

Who should approve PM-3 exceptions?

Use your existing governance, but make it explicit: portfolio/finance leadership typically approves funding deviations, with security and privacy leadership concurring on the risk. Record the approver and decision in the exceptions register. ¹

What evidence do auditors ask for most often?

They ask for investment request records showing security/privacy resources were requested, plus a controlled exceptions register for unfunded or deferred needs. They also look for traceability from program plans to funded items. ¹

How do I operationalize PM-3 if my finance team won’t change their tooling?

Treat the PM-3 addendum as a required attachment and enforce it through your security governance gate (for example, security review required before portfolio approval). Store addenda and approvals in a controlled repository and link them to the investment request record. ¹

Footnotes

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