PM-15 Security and privacy groups and associations: evidence

What PM-15 requires and why an assessor will ask for proof of contact

If you need to show that PM-15 is met, the short answer is that PM-15 requires institutionalized contact with selected security and privacy groups and associations. The control is not satisfied by individuals who happen to read advisories or attend conferences. The organization must select the groups it will engage with, establish the contact as a formal, repeatable practice, and be able to show that it runs. The control has three stated purposes: supporting ongoing education and training, keeping current with recommended practices and technologies, and sharing current threat, vulnerability and incident information. An assessor will test each purpose separately, so your evidence should show that the contacts feed each one.

PM-15 is a program management control. SP 800-53B places the Program Management family at the organization level, supporting the information security program and independent of any system impact level. For that reason PM-15 is not allocated to the low, moderate or high baseline, and it is not in the privacy baseline either. In practice this means you will not find PM-15 in a system security plan's control list. It belongs in the organization-wide program documentation, and the assessment is run against the organization's processes rather than against each system. Confirm this allocation against the current SP 800-53B profiles before you build your control matrix, since your scoping decisions depend on it.

The difficulty is almost always the same: the contacts exist only in people's heads. A senior engineer subscribes to a sector information sharing body, a security lead joins a regional working group, and nobody records who the organization is a member of, who is responsible for monitoring it, or what was shared back. When the assessor asks for the procedures that establish and institutionalize these contacts, and for the people responsible for them, there is nothing to hand over. Start by asking for a written list of groups and associations, named owners, membership or subscription records, and a log of threat or incident information received and passed on. Those records are the evidence that turns an informal habit into a control.

Which groups, people and information flows fall under PM-15

PM-15 is an organization-level control, so its scope is the enterprise security and privacy program rather than any single system. The cards below cover the decisions an organization makes about which groups it joins, who owns those relationships, where shared information lands internally, and how outward sharing fits existing handling rules.

Selecting the groups and associations

The organization decides which security and privacy groups or associations it will maintain contact with, based on its sector, technology stack and threat profile. Document the selection criteria and the reason each group was chosen, so an assessor can see that contact is institutionalized rather than ad hoc. Review the list periodically, since the reason for joining one group may lapse while a new one becomes more relevant.

Assigning relationship owners

Name the role, not just a person, that owns each relationship and the alternate who takes over when that person leaves. The owner is responsible for membership, attending meetings, and tracking what the group produces. Interview evidence from assessors often focuses on whether the personnel responsible for these contacts can explain how they were established and maintained.

Routing information to the SOC

Threat and incident information received from groups should reach the security operations center in a defined form, with priority and triage rules. Confirm that the SOC can tell which indicators were externally sourced, so that detections and alerts built on shared material can be traced back to their origin during review.

Feeding vulnerability management

Vulnerability and advisory information from groups should flow into the vulnerability management process and be compared against the asset inventory. Define who decides whether an advisory applies to the environment and how that decision is recorded. Related evidence for this flow may come from SI-5, which covers security alerts, advisories and directives, and from SA-11 for developer testing and flaw information.

Engaging the privacy office

Privacy-focused associations publish guidance that the privacy office needs to track, such as changes to practices and enforcement trends. Decide which privacy items are routed to the privacy office, how they are logged, and how they feed the privacy program. Confirm that privacy staff, not only security staff, are named in the contact arrangements.

Limiting outward sharing

Sharing threat or incident information with a group can expose personal data, customer details or controlled information. Before any outbound sharing, check the organization's handling rules, classification labels and any contractual or legal limits on disclosure. Document who may approve a release and what is stripped from the content first, so the sharing practice matches the rules that already govern the data.

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

This table maps each SP 800-53A assessment method used for PM-15 to its assessment object, the evidence an assessor will ask for and the findings that most often come up. The procedure contains 6 determination statements, so read each row as the question an assessor is trying to answer.

Method	Assessment object	Evidence requested and common findings
Examine	Procedures for establishing and institutionalizing contacts with security and privacy groups and associations	Evidence: a written procedure naming the groups, the purpose of each membership and who may join them. Common finding: no procedure exists, so contacts depend on individual habits.
Interview	Organizational personnel responsible for establishing and institutionalizing contact with security and privacy groups and associations	Evidence: named owners and their explanation of how they choose groups, receive advisories and pass information on. Common finding: staff describe memberships that nobody else in the organization knows about.
Test	Organizational processes for establishing and institutionalizing contact with security and privacy groups and associations	Evidence: a sample of real contacts with records of what was received, who reviewed it and what action followed. Common finding: contacts happen, but no record shows what was learned or shared.
Examine (sharing)	Procedures for sharing threat, vulnerability and incident information received from these contacts	Evidence: documented routes for passing advisories to system owners, the security operations team and, where relevant, incident response. Common finding: advisories stay in one person's inbox.
Interview (currency)	Personnel who keep staff current with recommended practices and technologies	Evidence: examples of training, briefings or updated standards traced back to a group or association. Common finding: no link between the external source and the internal update.
Test (education)	Processes that carry information from groups into staff education and training	Evidence: training content or briefing notes that cite the external source and their dates. Common finding: education material is generic and not tied to the groups the organization joined.
Records review	Membership, subscription and participation records for each selected group or association	Evidence: a current list of memberships with owners and review dates, plus a note of any lapsed membership. Common finding: the list is out of date or missing entirely.

How to institutionalize contact with security and privacy groups

This sequence turns PM-15 from an informal habit into a documented, owned and reviewed program, so that contact with security and privacy groups produces staff learning, current practice and shared threat information that can be shown to an assessor.

Select groups aligned to the risk strategy
Start from the organization's risk management strategy and its list of critical systems, then shortlist the security and privacy groups and associations that cover those technologies, sectors and regulators. Record why each group was chosen, including the threat areas it covers and whether it shares information publicly or only with members. The output is a shortlist with a one-line rationale per group, approved by the owner of the security program. The step is done when every selected group maps to a stated risk or technology in the strategy.
Assign named owners for each group
Give each selected group a named owner who is accountable for the relationship, and a backup who can cover when the owner leaves. Separate the roles of receiving learning (for staff education) from the roles of receiving and sharing threat and vulnerability information, because these usually need different people and different handling rules. The output is an ownership table recording the owner, backup and purpose for each group. Confirm the table with the people named in it, since an assessor will interview them about their role.
Write the contact procedure
Document how the organization joins a group, who may sign up or accept terms on its behalf, how contacts are established and how the relationship is kept active. Include rules for what may and may not be shared outward, and who approves any sharing of information about the organization's own systems. The output is a procedure document that is version controlled and approved by the accountable senior official. The step is done when someone outside the program could follow the procedure to establish a new contact without asking the owner.
Route learning and threat information to staff
Define how material from each group reaches the people who need it: which bulletins go to the security operations team, which advisories go to system owners, and which learning items feed the awareness and role-based training programs. Decide which channel is used for each type of information and how urgent items are escalated. The output is a routing matrix that maps information types to recipients and channels. Test the matrix once by sending a sample item through it and confirming the right people received it.
Set up the threat and vulnerability sharing log
Record threat, vulnerability and incident information received from or shared with groups in a sharing log that captures the date, source group, indicator or advisory, the systems or business areas affected, the action taken and the person who approved any outward sharing. Where the organization runs a threat intelligence platform such as MISP or OpenCTI, the log can be kept as platform events with sharing groups and tags, so the handling rules are enforced by the tool. Confirm that the platform's distribution settings match the approved sharing rules before any event is shared externally.
Set a review cadence for the relationships
Agree how often the program reviews the group list, ownership, routing matrix and sharing log against the risk management strategy and against changes in the organization's systems or regulators. Ask the accountable official to approve the cadence in writing, since NIST does not set a fixed interval for PM-15 in the supplied facts. The output is a review record showing what changed, why and who approved it. The step is done when at least one review has been completed and recorded.
Log participation and evidence for assessment
Keep a membership and participation register that shows which staff attended events, completed learning, or contributed to information sharing, and link each entry to the relevant training record and sharing log entry. Collect the procedure, ownership table, routing matrix, sharing log and review records in one evidence folder that maps to the six determination statements in SP 800-53A. The output is an assessment-ready evidence set, and the step is done when an internal reviewer can trace each claim in the set to a dated record.

How threat sharing platforms can hold the evidence trail

Evidence that passes a PM-15 review

PM-15 is tested through procedures, people and records rather than a single system setting. An assessor will look for a documented contact process, a current register of groups, and proof that the contacts produced education, practice updates and shared threat information. Each artifact below should be dated, owned and reviewed on a cadence the organization sets for itself.

Documented contact procedure

This is the written procedure for establishing and institutionalizing contact with security and privacy groups and associations, which is the first thing an assessor examines. It should name who may join or withdraw from a group, which information may be shared outward, how threat material is triaged, and how staff are told to use what they learn. Check that the procedure matches what staff actually do. Review it on the organization's own policy cycle and after any change to the security or privacy program leadership.

Register of selected groups

A register lists each group or association the organization has chosen, the business reason for it, a named internal owner, the topics covered, and the date of last review. Assessors use it to confirm contacts are deliberate rather than accidental. Ask the owner of each entry to confirm the group still fits the threats and technologies in scope, and remove entries where the owner no longer participates. Tie the register review to the organization's own planning schedule so entries do not go stale between audits.

Membership and participation records

These records show that the organization actually joined or engaged with each listed group, such as membership confirmations, invitations accepted, working group enrollment or mailing list subscriptions. They answer the question of whether the contact is institutionalized or only planned. Keep dates and the named participant for each entry. Reconcile the records against the register at each review so that lapsed memberships are noticed and renewed or retired.

Staff education records from contacts

PM-15 exists in part to support ongoing education, so an assessor will expect evidence that knowledge from these contacts reached staff. Examples include briefing notes circulated after a conference, training modules updated from a group's guidance, or a short internal session on a recommended practice. Record the source group, the date and the audience. Confirm with the training owner that these records are kept alongside the organization's broader awareness and training evidence.

Sharing logs and sightings

When the organization shares or receives threat, vulnerability or incident information through a platform, the platform's own logs become evidence. For example, MISP records sightings and synchronizes events between instances under sharing groups, and OpenCTI keeps threat knowledge as connected entities with ingestion and export history. Export or retain the audit trail for shared events, note who approved external distribution, and confirm that sharing rules match the classification of the information. Check the retention settings in your own deployment rather than assuming a default.

Meeting and briefing minutes

Minutes from internal reviews of group contacts show that someone reviewed what was received and decided what to act on. Useful minutes record the attendees, the group or source discussed, the decisions taken, the owners assigned and the follow-up dates. Assessors often sample a few meetings across the review period, so keep them consistent in format. Ask the reviewing body to confirm that minutes are approved and stored in the program's document repository.

What meeting PM-15 costs in money and staff time

This table breaks down the cost components of running PM-15 contacts with security and privacy groups, who is paid for each, whether it is one-time or recurring, and what moves it up or down. Use it to build a quote request, since NIST does not publish cost figures for PM-15 and no supplied source gives a price or duration.

Cost component	Who is paid or who bears it	One-time or recurring	What drives it up or down
Staff time to select and establish group contacts	Internal owner, often the security or privacy office; or a consultant if scoped in writing	One-time, then periodic review	Number of groups selected, whether the selection criteria are documented, and how many people must be onboarded
Membership, subscription or event fees	Each group or association sets its own fees; confirm with each group	Recurring, usually annual or per event	Tier of membership, number of attendees, and whether free or sponsored options exist for your sector
Staff time for education and training follow-up	Internal staff attending meetings, conferences or working groups	Recurring	Number of roles that must stay current, and whether attendance is tracked and fed into training records
MISP or OpenCTI licensing	Both are open source (MISP under AGPL-3.0-only, OpenCTI under Apache-2.0), so no license fee applies to the software itself	Not applicable to licensing	Removing license spend does not remove hosting, storage, upgrades or administration costs, which remain yours or your implementation partner's
Hosting and administration of self-hosted sharing platforms	Your infrastructure team, or an implementation partner under a written scope	One-time setup, then recurring operations	Data volume, number of sharing communities, backup and access control requirements, and upgrade frequency
Time to triage shared threat and vulnerability information	Internal analysts or security operations staff	Recurring	Volume of incoming indicators, the quality of feed filtering, and whether correlation and sightings are automated
External review of the PM-15 process	Independent assessor or consultant, if engaged	Periodic, tied to assessment cycles	Whether assessment procedures are examined and tested in one cycle, and how much documentation exists before the assessment

What makes PM-15 effort grow or shrink

The main driver of PM-15 effort is how many security and privacy groups the organization has chosen to engage and how much each one asks of staff. Each group adds its own mailing lists, meetings, membership obligations and information flows that someone must monitor and record. The PM-15 assessment looks for institutionalized contact, meaning documented procedures and named personnel responsible for establishing and maintaining those relationships, so a short, deliberately chosen list of groups tied to the organization's sector, technology stack and risk profile is far easier to sustain than broad membership that nobody reviews. Before quoting, ask the vendor or auditor how they expect the selection rationale to be documented, because that rationale is what keeps the list from growing by accident.

Whether information flows outward matters as much as how much flows inward. An organization that only consumes advisories from groups carries a light obligation, while one that shares threat, vulnerability or incident information must decide what leaves the building, who approves it, and what gets redacted. Sharing also depends on how many teams consume threat intelligence. Security operations, vulnerability management, incident response and engineering teams each need different slices of the same feed, and every extra consumer multiplies the questions about relevance, ownership and follow-up. Sharing that must follow distribution rules, such as traffic-light labels or sharing groups agreed with a partner, adds review steps and access restrictions that recur for every item, not once at setup.

Tooling is the lever that most often shrinks the workload. Manual intake from email, portals and spreadsheets scales poorly and makes the evidence trail hard to reconstruct during assessment. Self-hosted platforms such as MISP can synchronize events with granular distribution and sharing groups, record sightings and export indicators in formats the detection stack already uses, while OpenCTI can ingest feeds through connectors and organize them as structured entities. Both reduce the manual effort of intake and distribution, but they also add recurring costs for hosting, upgrades, connector maintenance and someone who owns the configuration. Ask any implementation partner to separate one-time setup from ongoing operation, and to show which records the platform produces as PM-15 evidence.

Where organizations fall short on PM-15 and how to close it

PM-15 is easy to satisfy on paper and easy to miss in practice. The gaps below share a root cause: contact with security and privacy groups happens through individuals rather than through an institutional process. Each card pairs a common shortfall with the action that closes it and the evidence an assessor would look for.

Contacts held informally by individuals

Many organizations maintain useful relationships with peer groups, sector information sharing forums and vendor user communities, but the relationships live in one engineer's inbox or phone. When that person leaves, the organization loses the contacts and the reason it had them. PM-15 asks for institutionalized contact, so the assessor will look for an organization-level record of which groups the organization belongs to and who holds each membership. Close the gap by assigning a named role to own the contact register, with membership, point of contact and renewal date recorded for each group.

No record of what was learned

Attending a briefing or receiving a threat bulletin has little value for PM-15 if nothing changes afterward. Organizations often lack a place where lessons, recommended practices and newly shared indicators are written down, so the same discussion repeats each year. Close this by logging each exchange with the date, the group, the topic, the decision taken and the owner of any follow-up action. A short log that ties each group to a control change or a training update is the evidence that the contact produced something.

Groups chosen without reference to risk

Organizations often join whichever community is most visible, while the sectors, technologies and supply chain partners that carry their real risk go unrepresented. PM-15 expects contacts that support the organization's education and its awareness of current practices and technologies, so selection should follow the risk assessment and the systems in scope. Close this by documenting the rationale for each group against the organization's risk profile, and reviewing that rationale when the risk assessment changes.

Threat information not routed to the SOC

A threat bulletin that reaches a manager's mailbox does not reach the team that can act on it. Indicators shared by peer groups should flow into detection and vulnerability management so that the security operations center and the vulnerability team can check their environment against them. Close this by defining a routing rule for each shared item, such as which queue receives it, who triages it and how a match is recorded. Ask the team to show one recent example of a bulletin that led to a detection change or a scan.

No review of the group list

Memberships and contacts go stale. Groups change their focus, staff move on and some communities stop being active, yet the list is rarely reviewed. PM-15 is about keeping current, so an outdated list is a finding in itself. Close this by setting a review cadence in the policy, with the owner recording what was kept, dropped or added and why. The review record should be dated and signed off by the role accountable for the security program, so an assessor can see that the list was checked rather than inherited.

Sharing that breaches internal handling rules

Sharing threat and incident information with outside groups can expose sensitive details about systems, customers or ongoing investigations if it happens without rules. Organizations need to decide in advance what may leave the organization, who approves it, and how it is anonymized or marked. Close this by writing a sharing procedure that matches the existing classification and incident response rules, naming the approvers, and recording each external disclosure. Confirm with legal and privacy staff that the procedure covers any personal data that might appear in shared samples.

PM-15 questions buyers ask before bringing in help

How much effort does PM-15 actually take to meet?

PM-15 is mostly an organizational process rather than a technical build, so the effort sits in deciding which groups to join, assigning owners, and making contact routine. The control requires institutionalized contact with selected security and privacy groups and associations, which means a documented procedure, named responsibilities, and a record that the contacts happen. The work recurs: someone must keep memberships current, review what the groups send, and route useful threat, vulnerability and incident information to the teams that act on it. The main cost drivers are how many groups the organization selects, how many staff take part, and whether threat sharing is run by hand or through a platform. Ask any partner to break its quote into the procedure, the staffing model, and the tooling it would deploy.

Can our organization meet PM-15 without outside help?

In most organizations, yes, because PM-15 does not require specialized engineering. Staff can select relevant groups, document the procedure, assign a responsible role, and keep a log of contacts and shared information. Outside help is most useful when the organization lacks a documented program to point to during an assessment, or when it wants a self-hosted platform to receive and distribute threat information. Be clear about what a partner does and does not own: the organization still owns its contacts, its procedure and its decisions about what to act on. An independent assessor then tests whether the process is in place and used. Decide internally who will own the control before you request quotes, because that decision shapes the scope.

What does PM-15 need from our staff?

PM-15 needs a named owner who can commit time to group participation, plus people who can read and act on what those groups share. Assessors look for procedures for establishing and institutionalizing contacts, personnel responsible for them, and evidence that the processes operate. The practical staffing list usually includes:

An accountable owner, often in the security or privacy function
Analysts who triage threat, vulnerability and incident information
Engineers who apply relevant guidance to systems
Someone who maintains membership records and meeting or bulletin logs

Confirm with each group what its membership and participation terms require, since those terms vary and are set by the group itself.

How long does PM-15 setup take?

Setup time depends on scope, and no single duration applies across organizations. The main variables are how many groups the organization selects, whether a procedure already exists, how mature its incident and threat handling is, and whether it needs a self-hosted sharing platform. An organization with a documented procedure and existing memberships may only need to formalize and evidence it. An organization starting from nothing will need to define roles, choose groups, and run the process long enough to produce records. Ask for a written scope with deliverables and milestones before agreeing to a timeline, and confirm the assumptions behind any date with your own environment.

Can a partner build our threat sharing platform?

A partner can plan, implement, customize, harden and document a self-hosted threat intelligence platform inside your infrastructure, as long as the scope is agreed in writing. Two open-source options are commonly considered. MISP, licensed AGPL-3.0-only, correlates indicators, synchronizes events between instances with sharing groups, records sightings, and exports to STIX 1 and 2, CSV, and Suricata, Snort and Zeek rule formats through its REST API. OpenCTI, licensed Apache-2.0, organizes threat intelligence as STIX-based entities and relationships and ingests data through connectors, TAXII, RSS, CSV and JSON feeds. Confirm each platform's current features against its project documentation before you choose, and confirm which feeds and groups your organization is permitted to use.

What will an auditor check for PM-15, and what won't they do?

An independent assessor tests PM-15 against the procedures in SP 800-53A Rev. 5, which include examining procedures, interviewing responsible personnel, and testing whether the processes operate. Expect requests for the documented procedure, the list of selected groups, membership records, and evidence of information received and acted on. The assessor will not design your program, write your procedure, or choose your groups, and a partner that prepares your evidence does not issue an assessment result. Only the independent assessor or the authorizing body reaches a conclusion. Ask your assessor early which evidence formats they accept and how they sample records.

Does PM-15 apply to every system and baseline?

PM-15 is not in the low, moderate or high baselines and is not in the privacy baseline, because NIST treats Program Management controls as deployed organization-wide rather than per system. That means the control applies at the organizational level regardless of each system's impact level. Confirm with your assessor or contracting authority whether they expect it as part of the program, since the way an agreement or overlay references it can differ. Related controls in the catalog are SA-11 and SI-5, which you should review alongside PM-15 when you document the process.

Who owns PM-15: your team, a partner and the auditor

Your organization owns PM-15 because the control is about relationships and judgment that only your staff can hold. Someone accountable must decide which security and privacy groups, associations and information-sharing communities fit your sector, your technology and your threat profile, then establish and maintain the contacts. Your staff also decide what threat, vulnerability and incident information to share, with whom, and under what handling rules. The control asks for institutionalized contact, so the arrangement should survive staff turnover and not depend on one person's inbox.

Selecting groups: Document which groups and associations you chose, why they fit your mission and sector, and who approved them.
Membership and participation: Record who joins, which meetings or working groups they attend, and what they bring back to the organization.
Sharing rules: Define what may be shared externally, what must be withheld, and how sensitive data is handled before it leaves the organization.
Staff education: Show that information from these groups reaches the teams that need it, such as security operations, engineering and leadership.
Procedures and ownership: Assign a named owner for the procedure and a review cycle for the contact list.

Check that your procedure names an accountable owner, that membership records are current, and that the sharing rules were approved before any information left the organization.

How DeployOpen prepares PM-15 evidence

DeployOpen's part in PM-15 starts with a written scope. Before any work begins, we agree in writing which groups and associations the organization will engage, who owns each relationship, how contact is recorded, and which tooling, if any, is in scope. The organization owns the control and the decisions about membership and information sharing. DeployOpen prepares the procedures, the records and the systems that show the contacts are institutionalized, and the quote follows from that written scope. We do not publish a price list, and we do not issue assessment reports. An independent assessor decides whether the control is met, using the examine, interview and test methods in SP 800-53A.

If the organization chooses to share and consume threat information through self-hosted tooling, we deploy and harden it inside the client's own cloud accounts, data center or air-gapped network. For example, an illustrative scope might include a MISP instance for indicator exchange and an OpenCTI instance for organizing reports from groups the organization has joined. We configure sharing groups and distribution levels so that only agreed partners receive data, document the synchronization settings, and set up logs of imports and exports. Whether a given platform meets the organization's distribution rules or data residency requirements is something to confirm against its own documentation and the organization's policy before deployment.

The evidence an assessor will ask for is mostly paper and logs: the procedure for establishing contacts, membership or participation records, meeting notes or advisories received and acted on, and records of information shared. DeployOpen structures these trails so that each contact has an owner, a review date and a link to the action it produced. Ongoing review is available as a retainer, covering periodic checks of the contact list, tool upgrades and evidence sampling before an assessment. Ask any partner to confirm in writing which of these items are one-time deliverables and which recur, and who inside your organization signs off each one.