PM-16 Threat awareness program: requirements and evidence

What the PM-16 threat awareness program requires of your organization

PM-16 asks your organization to run a threat awareness program that includes a capability for sharing threat intelligence across the organization. In plain terms, the program has to exist as a defined, owned activity, and it has to move threat information between the teams that need it, not leave it sitting with whoever happened to read a vendor bulletin. An assessor will look for the policy and procedures behind the program, the risk assessment results that feed it, and proof that the sharing capability works in practice. PM-16 is a program management control. SP 800-53B places it outside the low, moderate and high baselines and outside the privacy baseline, so it is not selected per system according to impact level. You assess it once for the organization-wide program, and every system then benefits from it. Confirm this scoping with your assessor early, because teams often plan PM-16 evidence per system by mistake and then find the program-level evidence is missing.

The risk PM-16 addresses is familiar: a threat indicator reaches the security operations center, a risk analyst learns of an emerging campaign from a partner, and neither knows what the other has seen. Threat intelligence that stays inside one team cannot change risk decisions or detection rules elsewhere. The control is hard in practice because ownership is split. Security operations usually holds the feeds, risk management owns the risk assessment, and external relationships with information-sharing groups sit with someone else, often a CISO office or a legal team. Before any evidence exists, agree in writing who owns the program, who runs the cross-organization sharing, and who signs off the procedures. Then ask your team to show one recent threat item moving from intake to a risk or detection decision.

Which teams, feeds and sharing partners fall inside PM-16 scope

PM-16 is an organization-level control, so one threat awareness program document can cover many systems and teams. The scope decisions below determine who produces and consumes threat data, which sharing relationships exist, how sharing runs, and how the program connects to risk assessment and related incident and insider threat controls.

Business units that produce or consume threat data

Start by listing every unit that sees threat-relevant signals or acts on them: security operations, IT operations, fraud or payments teams, cloud platform engineering, and application owners. Each unit either produces observations worth sharing or consumes intelligence that changes its controls. Record who receives intelligence, who decides what it means for the organization, and who is accountable when a unit does not act. Confirm these owners with the organization rather than assuming the security team covers them all.

External sharing relationships and their terms

List every external party the organization exchanges threat information with, such as industry information sharing communities, sector bodies, peer organizations, government agencies and managed service providers. For each relationship, record what is shared, the classification or handling rules that apply, and any agreement that governs it. PM-16 requires a cross-organization capability, so an undocumented informal contact is a scoping gap that an assessor will ask about.

Manual versus automated sharing

Decide whether intelligence moves by people forwarding reports or by machine-readable feeds and platforms. Manual sharing is easier to start but depends on individuals remembering to act. Automated exchange requires defined formats, distribution rules and sharing groups. Open-source platforms such as MISP support granular distribution and synchronization between instances, and OpenCTI ingests feeds through connectors and TAXII. Confirm which capability the organization actually operates and document that choice, because PM-16(1) concerns automated sharing specifically.

Links to risk assessment results

Threat awareness should feed the organization's risk assessment, and risk assessment results should shape which threats the program prioritizes. Map which intelligence sources inform the RA family's risk assessment outputs and which assessment results an assessor can examine as evidence of that link. Without this connection, the program produces feeds that nobody uses to make decisions. Ask who reviews the threat program output against the risk assessment and how often that review occurs.

Incident handling under IR-4

The related control IR-4 covers incident handling, so threat intelligence that matches an observed event must reach the people who triage and contain it. Scope the handoff points between threat intelligence, security operations and the incident response team. Confirm which events trigger an incident record and whether indicators from shared feeds can be correlated against local logs. An assessor will look for a traceable path from received intelligence to an incident decision.

Insider threat links under PM-12

The related control PM-12 covers an insider threat program, and threat awareness work often surfaces signals about internal actors. Decide whether the threat awareness program's outputs are shared with the insider threat function, which handles those cases, and under what limits. Record the data handling rules that apply to personal activity information, since privacy and employment obligations may restrict what can move between teams. Confirm this boundary with legal and human resources before drafting the procedure.

How an assessor tests PM-16 under SP 800-53A

This table maps each SP 800-53A assessment method for PM-16 to the objects an assessor will look at, and notes where organizations commonly fall short. Read it as a checklist of evidence to have ready before an assessor arrives, since PM-16 is assessed through a single determination statement.

Method	Assessment objects	Evidence an assessor expects	Common findings
Examine	Threat awareness program policy, threat awareness program procedures, risk assessment results relevant to threat awareness	Approved policy naming the program owner, procedures showing how threat information is gathered and used, and risk assessment entries that cite threat sources	Policy exists but procedures do not describe how threat intelligence is shared across the organization
Interview	Personnel responsible for the threat awareness program	Program owner can explain scope, cadence of threat reviews and how findings reach risk decisions	Owner cannot describe current threat sources or who acts on them
Interview	Personnel responsible for the cross-organization information-sharing capability	Named staff can describe which external sharing channels are used, what is shared outward and inward, and how sharing is approved	Sharing relies on one individual with no documented backup or handoff
Test	Organizational processes for implementing the threat awareness program	Records of threat intelligence received, triaged, shared and acted on, such as tickets, feed logs or sharing group membership	Processes are documented but no records show they run in practice
Test	Cross-organization information-sharing workflow	Sample of shared or received indicators with timestamps, recipients and resulting control changes	Sharing happens informally by email with no record of what was shared

Steps to build a threat awareness program that passes review

This sequence turns PM-16 from a policy statement into a running program with a named owner, a documented sharing capability, links into risk and incident processes, and records an assessor can examine, interview staff about and test.

Name an accountable owner for the program
Assign one named official to own the threat awareness program and a second named role to own the cross-organization information-sharing capability. Both roles should appear in the organization's role definitions and be confirmed in writing by the accountable senior official. Assessors interview these personnel under PM-16, so the people named here must be able to explain what they do and what records they keep. The output is an appointment record or role description for each owner, with contact details and the scope of their authority.
Document the threat awareness policy and procedures
Write the threat awareness program policy and the procedures that implement it. The policy should state the purpose of collecting threat information, the sources the organization uses, who may receive and act on intelligence, and how often the program is reviewed. The procedures should describe the operational steps: intake, triage, distribution and retention. Have the accountable official approve both documents and record the version and approval date. The output is an approved policy and procedure set that an assessor can examine directly.
Define the sharing capability and its participants
Decide which external communities, peer organizations, sector groups or government channels the organization will exchange threat information with, and which internal teams receive it. Document the participants, the classification and distribution rules that govern each exchange, and the mechanism used to share, such as a platform instance, a feed or a shared mailbox. Where the organization shares with outside parties, put the terms in writing before the first exchange. The output is a sharing design record listing participants, distribution groups and handling rules.
Configure the intelligence platform and feeds
If the sharing capability runs on a self-hosted platform, configure the feeds, connectors and distribution settings to match the sharing design. Record the configuration in change-controlled documentation, including which sources are enabled, who can publish and who can read, and how indicators are correlated with internal telemetry. Open-source platforms such as MISP and OpenCTI support these functions, but the organization should confirm each capability against its own requirements before relying on it. The output is a configuration record and a test log showing that indicators reach the intended recipients.
Connect intelligence to risk assessment and incident response
Set up the handoffs that make threat intelligence useful. Relevant intelligence should feed the organization's risk assessment, which PM-16 expects the program to draw on, and it should reach incident response handlers who can act on indicators during an event. Write down the trigger for each handoff, the receiving role and the record created. Map the links to the related controls, including IR-4 and PM-12, so the assessor can trace the path. The output is a documented workflow and a sample case showing intelligence moving from intake into a risk or incident record.
Run the process and record each cycle
Operate the program as written. Collect intelligence, triage it, share it with the agreed participants and log what was received, decided and distributed. Record sightings and the actions taken on them. Keep these records in a form that can be reproduced for an assessor, because the test method under PM-16 looks at whether the processes are actually carried out. The output is a dated activity log and a set of distribution records covering the review period.
Review the program and close the findings
Review the policy, procedures, participant list and feed configuration at the interval the organization defines, and after significant changes in threat conditions or in the organization's systems. Record the review minutes, the decisions taken and any changes made to the policy or sharing design. Track open gaps as plan of action and milestones items and close them with evidence. The output is signed review minutes, a change history for the policy and a current findings register that the next assessment can examine.

When automated sharing under PM-16(1) becomes necessary

PM-16(1) is the single active enhancement under PM-16, and it covers automated sharing of threat intelligence. The base control asks for a threat awareness program with a cross-organization information-sharing capability. The enhancement moves that sharing from people passing reports along to systems exchanging data without manual handling. The researched facts do not reproduce the enhancement's exact wording, so before scoping any work, confirm the current text of PM-16(1) in the NIST CPRT catalog entry for PM-16 and read it alongside the assessment objects in SP 800-53A before deciding whether it applies to your program.

In practice, automation usually means three things: threat indicators and reports leave your environment in machine-readable formats, such as STIX or CSV, rather than as email attachments; exchanges with partner organizations or sharing communities run on defined channels, often through a platform's API or a feed protocol; and distribution is controlled, so each indicator goes only to the recipients its sharing agreement allows. Open-source platforms such as MISP and OpenCTI support these patterns, with MISP offering sharing groups and event synchronization between instances and OpenCTI ingesting and publishing data through connectors and TAXII. Whether a given platform fits your agreements is a question to confirm against its current documentation and your own requirements, not something this page establishes.

Automation changes the evidence an assessor will ask for. A threat awareness program run through meetings can be shown with agendas, minutes and a sharing policy. Once sharing is automated, the assessor will expect the configuration itself: sharing group definitions and distribution settings, synchronization logs, API access records, export histories and the rules that decide what leaves the organization. Decide early who owns those records, how long they are kept and how they connect to the policy and procedures examined under PM-16. Your organization owns the control and its decisions; an implementation partner can prepare the platform configuration and exportable logs, and an independent assessor judges whether they meet the requirement.

Evidence that satisfies PM-16 and how to keep it current

PM-16 is assessed through a small set of documents, interviews and tested processes, so the evidence is mostly governance records and system exports. Each artifact below should carry an owner, a review date and a version history so it still reflects the program when an assessor arrives.

Threat awareness program policy and procedures

The written policy states why the organization runs a threat awareness program, who owns it and how threat information enters and leaves the organization. Procedures describe the working steps: where intelligence is collected, how it is triaged and who receives it. Assessors examine both documents, so check that the procedures name current tools and roles. Set a review date, record each approval and keep superseded versions with their change notes.

Risk assessment results that cite threat data

Assessors look for evidence that threat information influences risk decisions, not just that it is collected. Risk assessment results should reference the threat sources, campaigns or indicators that informed each finding, with the date of the intelligence used. Confirm that the risk register or assessment template has a field for threat references, and that the reference links back to a stored intelligence record.

Sharing agreements and participant lists

The cross-organization capability depends on documented sharing relationships. Keep the agreements or terms under which intelligence is exchanged, a current list of participating organizations and the named contacts for each, and the distribution or sharing group each participant belongs to. Confirm the agreements define handling rules for shared data and are reviewed when a participant leaves or changes role, since stale access is a common finding.

Feed and sharing configuration exports

Configuration exports show what the platform actually does. For a MISP or OpenCTI deployment, export the sharing groups, distribution settings, feed subscriptions and connector list, and store them with a timestamp. Compare each export against the procedures so that a documented sharing rule matches the live setting. Re-export after every change to feeds, connectors or distribution levels, and retain prior exports to show history.

Records of intelligence shared and acted on

Assessors want proof that the program works in practice. Keep records of indicators or reports shared with other participants, sightings of observed indicators, and the response actions taken, such as blocking rules or hunts opened from an intelligence item. Platform audit logs and case records usually provide this, so confirm they are retained long enough to cover the assessment period.

Review cadence and version control

Evidence goes stale unless it has a schedule. Assign each artifact an owner, a review interval set by the organization, and a change log that records who approved each version and why it changed. Store documents in a controlled repository, and link each review to the matching configuration export. Confirm during an internal check that every artifact has a current review date.

What meeting PM-16 costs in money and effort

This table lists the cost components of running a PM-16 threat awareness program with cross-organization sharing, who is paid for each, whether it is one-time or recurring, and what moves it up or down. No supplied figures exist for these costs, so use it to frame the questions to ask in a written quote and in your own internal estimate.

Cost component	Who is paid or who bears effort	One-time or recurring	What drives it up or down
Defining the threat awareness program and its policy	Internal security and risk staff, possibly an outside consultant for drafting	One-time, then periodic review	Size of the organization, number of business units in scope, and how much existing risk assessment material can be reused
Staff time to run threat intelligence intake and triage	Internal analysts, or a managed service if one is contracted	Recurring	Volume of feeds, number of sources, and how much automation handles deduplication and correlation
Sharing agreement drafting and legal review	Legal counsel and privacy staff, plus partner organizations	One-time per agreement, with recurring renewals	Number of sharing partners, sector rules on shared data, and whether standard terms are reused
Intelligence platform licenses or hosting	Software vendor for commercial platforms; cloud or infrastructure provider for self-hosted systems	Recurring	Commercial licensing model versus self-hosted infrastructure, data volume, and high availability requirements
Self-hosted platform setup and upkeep	Internal platform engineers or an implementation partner under a written scope	Setup is one-time; upgrades and monitoring recur	Choice of platform, integration depth, and whether connectors and feeds need custom work
Integration with incident response (IR-4) and related controls	Incident response team and engineering staff	One-time build, recurring tuning	Number of detection tools feeding indicators, and how often playbooks are rehearsed
Evidence upkeep for assessors	Program owner and compliance staff	Recurring, usually at each assessment cycle	Number of sharing events to document, and whether logs and records are generated automatically
Assessor time	Independent assessor, paid by the organization under its own engagement	Recurring per assessment cycle	Scope of the assessment, quality of existing documentation, and number of assessment objects to examine and interview

Who owns PM-16 and what an implementation partner can take on

Your organization owns PM-16. The control asks for a threat awareness program that includes a cross-organization capability for sharing threat intelligence, and the decisions behind that program belong to you: which threat sources matter for your mission and risk profile, who receives what, which partner communities you join, and how threat information feeds back into risk assessments. Those choices reflect your mission, legal obligations and information-sharing agreements, so they cannot be delegated to a vendor.

Program ownership: Assign an accountable owner for the threat awareness program and document the policy and procedures an assessor will ask to see.
Sharing decisions: Define what intelligence is shared, with whom, under which distribution rules, and what must never leave the organization.
Risk linkage: Show how threat information informs risk assessments and related controls such as IR-4 and PM-12.
Personnel: Name the people who run the program and the people who run the cross-organization sharing capability, since an assessor will interview both.
Operating records: Keep evidence that the program runs in practice, not only that it exists on paper.

Before engaging any partner, confirm that your policy, sharing rules and named roles are settled, because a partner can configure a platform but cannot decide what your organization should share.

Where PM-16 programs usually fall short

PM-16 is short, but assessors test whether a threat awareness program actually runs: someone owns it, sharing is governed, intelligence feeds decisions and the program gets reviewed. The gaps below appear again and again, and each has a closing action the organization can assign and evidence.

Policy with no named owner

A threat awareness policy exists, but no role is accountable for running it, so procedures drift and nobody answers when the policy is tested. Assessors look for the policy, its procedures and the personnel responsible for the program, and they interview those people. Close it by naming one accountable role in the policy, documenting the responsibilities in the role description and recording who approved the appointment.

Sharing without a written agreement

Teams exchange indicators or reports with peers, partners or sector groups under informal understanding, with no statement of what may be shared, how it is handled or who may see it. This leaves the cross-organization capability hard to defend. Put each sharing relationship under a written agreement that sets scope, handling rules and distribution limits, and keep a register of those agreements.

Intelligence not tied to risk

Feeds and reports are collected and stored, yet they never reach the risk assessment or change a risk decision. PM-16 assessors check whether relevant risk assessment results inform the program, so unlinked intelligence reads as collection for its own sake. Record which threats were reviewed, which risk entries they affected and what changed, and review that link at each risk assessment cycle.

Automated feeds with no usage records

Automated ingestion and sharing run quietly, but nobody can show what was imported, matched, shared or acted on. Without records of use, the organization cannot demonstrate that the capability works. Keep sighting and match records and export logs from the threat intelligence platform, and confirm in the platform documentation which of those records it retains and for how long.

No review of the program

The threat awareness program is set up once and never re-examined, so sources, sharing partners and owners fall out of date. Assessors test whether organizational processes for the program are carried out in practice. Schedule a documented review of the policy, sources, sharing agreements and open actions, with the reviewer and outcomes recorded.

PM-16 questions buyers ask before bringing in help

How much effort does PM-16 take for a small organization?

For a small organization, PM-16 is mostly a documentation and process effort rather than a large technical build. The control asks for a threat awareness program that includes a cross-organization information-sharing capability, so the work centers on a written program, a named owner, defined sources of threat information and a way to share and receive intelligence with partners. The effort rises with the number of systems, the number of sharing relationships and how much existing risk assessment material can be reused. No effort figure is supplied for this control, so ask any provider for a written estimate that lists the policy, procedure, tooling and interview work separately. Tooling such as MISP or OpenCTI adds setup and upkeep, which is a recurring cost even when the software itself is open source.

Can a small team handle PM-16 in-house?

Yes, a small team can usually handle PM-16 in-house if it has an accountable owner, time to write and maintain the program documents, and a clear way to receive and act on threat information. The organization owns the control, so the people responsible for the threat awareness program must be able to answer assessor interviews about it. Outside help is most useful for the parts that need independent perspective, such as reviewing whether the program documents match actual practice, or setting up a self-hosted intelligence platform. Independent auditors and certification bodies, not consultants, issue any assessment report or certificate.

What does the PM-16 work need from our team?

The work needs a few distinct roles, and one person may hold more than one. Expect the following:

A program owner who can speak for the threat awareness program in interviews and approve its policy and procedures.
A person responsible for the cross-organization information-sharing capability, who manages external sharing agreements, contacts and distribution rules.
Analysts or security engineers who can review incoming intelligence, correlate it with internal indicators and record what was done with it.
Access to existing risk assessment results, since the assessment expects the program to draw on them.

The team also needs time to keep the program current as threats and partners change, because that upkeep recurs after the first implementation.

How long does PM-16 take to implement?

No implementation duration is supplied for PM-16, so no timeline should be assumed. The time depends on whether a threat awareness program already exists, how many sharing relationships must be set up, and whether a self-hosted intelligence platform must be deployed and integrated first. Ask any provider for a written timeline that states its starting assumptions, the dependencies on your approvals and data access, and which milestones produce evidence an assessor can review. Fixed-scope engagements are agreed in writing before work starts, so a timeline should appear in that written scope.

Can self-hosted tools produce the evidence PM-16 needs?

Self-hosted tools can produce supporting evidence, but they do not satisfy the control on their own. PM-16 is assessed through policy, procedures, risk assessment results, interviews with responsible personnel and tests of how the program operates. Platforms such as MISP (AGPL-3.0-only) and OpenCTI (Apache-2.0) can help show the sharing capability in action. MISP records sightings and synchronizes events with sharing groups, and OpenCTI organizes intelligence and ingests feeds through connectors and TAXII. Confirm the exact features, sharing configurations and audit logs in your own deployment before relying on them, since the software must be configured to match your program.

Why is PM-16 not in the privacy baseline?

PM-16 is not in the privacy baseline because SP 800-53B treats Program Management controls as deployed across the whole organization to support the information security program, not as controls tied to a system impact level or a privacy control set. The privacy baseline lists the controls that apply to privacy risk for PII processing, and PM-16 does not appear there. That does not remove the need for threat awareness, since the security program still depends on it. Confirm the current baseline assignments in the SP 800-53B profiles before scoping, and check whether any privacy program obligations in your environment call for threat information sharing.

Which parts of PM-16 do organizations usually outsource?

Organizations most often outsource the technical setup of the intelligence platform, the integration of feeds and sharing connections, and an independent review of the program documents before an assessment. Work that depends on the organization's own threat context, such as deciding which partners to share with and how to act on intelligence, usually stays in-house. DeployOpen plans, implements and documents self-hosted open-source platforms inside the client's own infrastructure and prepares evidence for compliance assessments, but it does not issue audit reports or certifications. Ask for a fixed-scope written proposal that separates these responsibilities.

How DeployOpen prepares PM-16 systems and evidence

DeployOpen's part in PM-16 is a fixed-scope engagement, agreed in writing before work starts, that covers the technical platforms behind the threat awareness program and the evidence an assessor will ask for. The engagement typically deploys the open-source threat intelligence platforms inside the client's own cloud accounts, data centers or air-gapped networks, configures sharing groups and distribution levels so that cross-organization sharing follows the organization's own rules, and documents the setup. The scope, deliverables and timeline are fixed in that written agreement, and the client keeps ownership of the threat awareness program, its policy and its sharing decisions. Before any work begins, confirm with the client which platforms, which sharing partners and which feeds are in scope, because each of these changes the configuration work and the evidence set.

Integration with incident response is where most of the practical value sits. Threat intelligence that is imported but never reaches the people who handle alerts does not show that the program works. DeployOpen can connect the threat intelligence platform to the incident response workflow and to the risk assessment records that PM-16 assessors examine, so that indicators, sightings and shared reports are traceable to decisions. The assembled evidence package usually includes the threat awareness program policy and procedures, configuration exports, sharing agreement records, sample sighting and sharing logs, and a mapping from each artifact to the assessment objects in SP 800-53A. Ask the client to name the personnel the assessor will interview, since they must be able to explain the cross-organization sharing capability without relying on the implementation partner.

DeployOpen prepares systems, controls and evidence. It does not issue audit reports, attestations or certifications. Only an independent assessor or the authorizing official's process can judge whether PM-16 is met in the client's environment, and that determination belongs to the organization and its assessor. Ongoing support, platform upgrades and continuous testing are available as a retainer, which suits organizations whose sharing partners, feeds or threat intelligence workflows change after the initial engagement. Ask for the written scope, the list of deliverables, and the responsibilities split between the client and DeployOpen before signing.

PM-16 Threat awareness program