Information Sharing Governance

To meet the Information Sharing Governance requirement, you need documented, approved policies that define how your organization shares security-relevant information and communicates internally and externally, and you must tie that governance directly into enterprise risk management (ERM). Your goal is provable, repeatable decisions about what gets shared, with whom, under what conditions, and how exceptions are handled. ¹

Key takeaways:

• Document the “rules of sharing” (scope, roles, approvals, allowed channels, and escalation) and publish them to the teams that must follow them. ¹
• Integrate information sharing decisions into ERM so risk acceptance, prioritization, and reporting follow your enterprise governance path. ¹
• Keep operating evidence (versions, approvals, meeting notes, bulletins, and incident comms) that shows the policy runs the day-to-day program. ¹

Information sharing breaks down in predictable ways: the wrong data gets shared, the right data gets stuck in legal review, or teams “share” informally in chat with no record of what was sent and why. The C2M2 Information Sharing Governance requirement is designed to prevent those outcomes by forcing two things to be true: (1) information sharing and communications are guided by documented policies, and (2) that governance is integrated with the enterprise risk management program. ¹

For a Compliance Officer, CCO, or GRC lead, “operationalizing” this requirement means you are building a durable governance lane that security, operations, legal, procurement, and communications can actually use under pressure (incident response, vulnerability disclosure, sector alerts, third-party issues). Your north star is auditability: a reviewer should be able to see your policy, trace who approved it, confirm it is reviewed on a defined cadence, and verify that real communications followed the policy rather than ad hoc judgment. ¹

This page gives you requirement-level steps, evidence expectations, and an execution plan you can run with immediately.

Regulatory text

Requirement (excerpt): “Information sharing and communications activities are guided by documented policies and integrated with the enterprise risk management program.” ¹

Operator meaning: You must (a) have written policies and procedures that govern information sharing and communications, and (b) connect that governance to ERM so decisions, exceptions, and prioritization flow through the same risk framework the enterprise uses. A policy that sits in a binder or a SharePoint folder without proof of operation will not meet the intent. ¹

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

A mature program has one clear “source of truth” for:

• What information is shareable (by category and sensitivity).
• Who can authorize sharing (roles, not names).
• Approved channels (how you communicate and store records).
• When sharing is required (e.g., incident notifications, sector coordination).
• How risk is evaluated (ERM linkage: risk statements, acceptance, escalation).
• How you handle exceptions (documented, time-bound, approved). ¹

Who it applies to

This requirement applies to organizations using C2M2 within a defined scope (business unit, function, or OT environment) and assessing maturity for that scope. It is especially relevant for energy sector organizations and other critical infrastructure operators where timely, governed sharing (internally and with third parties) affects resilience. ¹

Operational contexts where auditors focus:

• Incident response communications (internal leadership updates; external notifications).
• Threat intel ingestion and dissemination (sharing IOCs, TTPs, advisories).
• Vulnerability disclosure (internal handling; coordination with affected third parties).
• Third-party coordination (cloud providers, MSPs, OEMs, sector partners).
• Regulator and customer communications tied to cyber events or systemic risks.

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

Step 1: Define scope and inventory information-sharing “lanes”

Build a simple inventory of the recurring communication lanes, then map each to an owner:

• Security operations bulletins
• ERM risk reporting and KRIs
• Incident notification workflows
• Third-party security communications
• Sector/community information sharing (ISAC-style participation, peer calls)
• Executive and board updates

Deliverable: “Information Sharing & Communications Inventory” (one page is fine) that lists lane, purpose, typical data types, owner, and where records live.

Step 2: Draft the governing policy and the procedures people follow

Write an Information Sharing Governance Policy plus short procedures that answer the questions teams ask during real events.

Minimum policy content operators expect:

1. Purpose and scope (systems, teams, and data in scope).
2. Roles and responsibilities (RACI for Security, ERM, Legal, Comms, Privacy, Procurement, OT leadership).
3. Information categories & handling rules (examples: public, internal, confidential, regulated, security-sensitive).
4. Approval and escalation rules (what needs Legal sign-off; what can be shared by on-call security leadership).
5. ERM integration points (when sharing triggers risk creation/update, escalation, or risk acceptance).
6. Third-party sharing rules (NDA requirements, minimum contractual hooks, permitted recipients).
7. Recordkeeping (what must be recorded, where, and for how long based on your internal retention schedule).
8. Exceptions (who can approve; how to document and sunset).
9. Training and enforcement (who must be trained; consequences for bypassing). ¹

Practical procedure set to attach (keep them short):

• “External sharing approval workflow”
• “Incident communications workflow”
• “Threat intel sharing workflow”
• “Third-party security communications workflow”

Step 3: Integrate with ERM (make it explicit and testable)

This requirement is commonly failed here: teams publish a security policy but do not connect it to ERM operations.

Make the ERM integration concrete:

• Add a risk taxonomy tag or risk category for “Information Sharing / Communications Risk”.
• Define triggers that require an ERM update (examples: sharing a material vulnerability with a third party; disclosing incident details externally; publishing an advisory).
• Require a risk entry (or update) when you approve high-impact sharing, including rationale, approver, and compensating controls.
• Align reporting cadence: what goes to the risk committee, who receives summaries, and what metrics you track (qualitative is acceptable if you cannot measure reliably yet). ¹

Deliverable: A documented “ERM linkage” section in the policy plus an ERM procedure note that references the information sharing governance.

Step 4: Establish governance mechanics (ownership, cadence, approvals)

Operationalize the governance so it survives staff changes:

• Assign a policy owner and backup owner.
• Define a review cadence (set your own cadence; examiners will ask you to justify it).
• Require documented approvals (GRC + Security + ERM owner; include Legal/Privacy where external sharing is common).
• Publish the policy in your controlled repository with version history. ¹

Step 5: Implement “default allowlist” sharing patterns (reduce ad hoc decisions)

Create pre-approved sharing patterns so responders can move quickly:

• Approved recipients (roles/organizations)
• Approved data types (what is safe to share)
• Approved channels (secure portal, encrypted email, ticketing system)
• Required disclaimers or markings (e.g., “confidential”, “do not redistribute”)

This reduces exceptions and makes your operating evidence cleaner.

Step 6: Train the people who actually share information

Train to roles, not the whole company:

• SOC/on-call responders
• Incident commanders
• OT operations leadership
• Third-party managers and procurement
• Corporate communications
• ERM team members who intake escalations

Evidence tip: Keep attendee lists and the specific module content for “what can/can’t be shared” and “how to request approval.” ¹

Step 7: Prove operation with artifacts from real work

Auditors look for “policy-to-proof.” Create a lightweight evidence pipeline:

• For each major sharing event, retain the approval record, what was shared, recipients, and date/time.
• For recurring bulletins, retain samples plus distribution lists.
• For exceptions, retain the exception request, approval, and closure. ¹

If you use Daydream, treat this as a governance workflow: map the policy to control objectives, store approvals and versions, and attach operating artifacts to the control so evidence is ready for internal testing and external requests without a scramble.

Required evidence and artifacts to retain

Keep artifacts that show both design (policy exists and is governed) and operation (teams follow it).

Design evidence (governance)

• Approved Information Sharing Governance Policy (current version)
• Procedure documents and workflow diagrams
• Version history and change log
• Approval records (signatures, meeting minutes, or ticket approvals)
• Named owner, review cadence, and distribution list ¹

Operating evidence (day-to-day proof)

• Samples of internal/external security communications tied to the policy
• Incident communications timeline (what was shared, by whom, approvals)
• Threat intel sharing records (inbound/outbound summaries)
• ERM artifacts: risk entries/updates triggered by sharing decisions
• Exception register for information sharing (requests, approvals, closure) ¹

Common exam/audit questions and hangups

Auditors and assessors frequently ask:

• “Show me the policy and who approved it. When was it last reviewed?” ¹
• “How do you decide what can be shared externally, and who signs off?”
• “Where is the ERM integration? Show me a risk record created or updated because of an information-sharing decision.” ¹
• “How do you handle exceptions, and how do you prevent shadow channels?”
• “Give examples from the last incident or advisory. Prove the workflow was followed.” ¹

Hangups you can prevent:

• Policy exists but no procedure or evidence trail.
• ERM linkage is a sentence in the policy, but ERM has no record of it.
• Sharing happens via chat/email with no approvals retained.

Frequent implementation mistakes (and how to avoid them)

1. Writing a policy that reads like a statement of intent.
   Fix: Add decision rules, approval thresholds, and required records. Make it executable.

2. Treating “communications” as PR only.
   Fix: Include security operations communications, third-party coordination, and sector sharing lanes.

3. No ERM handshake.
   Fix: Define explicit triggers and require a risk entry/update for higher-impact sharing decisions. ¹

4. Uncontrolled repositories and missing version history.
   Fix: Store policies in a controlled system and retain prior versions and approvals. ¹

5. Over-restricting sharing so teams bypass the process.
   Fix: Create pre-approved sharing patterns and fast approvals for responders; reserve heavy review for high-risk disclosures.

Enforcement context and risk implications

C2M2 is a maturity model and the provided sources do not include public enforcement actions tied to this specific requirement. ¹

Your risk exposure still increases when governance is outdated, unapproved, or not followed: inconsistent decisions, uncontrolled disclosures, and weak audit defensibility during internal control testing, customer diligence, and regulator review. ¹

Practical 30/60/90-day execution plan

First 30 days (stabilize and document)

• Confirm scope for C2M2 assessment and list information-sharing lanes.
• Draft the policy with clear roles, approvals, channels, recordkeeping, and exceptions.
• Identify the ERM integration point owner and define initial triggers.
• Stand up a controlled repository location for versions and approvals. ¹

By 60 days (operationalize and connect to ERM)

• Publish the policy and procedures; route for formal approvals.
• Train the roles that share externally and during incidents.
• Implement an exception register and a standard approval workflow.
• Run a tabletop exercise focused on external sharing and capture artifacts.
• Confirm ERM workflow: show at least one example risk entry/update caused by a sharing decision. ¹

By 90 days (prove repeatability)

• Perform a control self-test: sample recent communications and verify approvals, markings, recipients, and retention.
• Tune pre-approved sharing patterns based on what teams needed during incidents.
• Report status to the risk committee (or equivalent) with evidence attached in your GRC system.
• Set the ongoing review cadence and assign next-review tasks to the owner. ¹

Frequently Asked Questions

Does “information sharing” mean only external sharing (ISACs, regulators, peers)?

No. The requirement covers information sharing and communications activities broadly, including internal communications that drive security decisions and incident response. Your policy should address both internal and external lanes. ¹

What does “integrated with ERM” mean in practice?

ERM integration is visible when information-sharing decisions trigger risk entries/updates, escalation, or documented risk acceptance through your normal enterprise path. A cross-reference in a policy is not enough without operating artifacts. ¹

Who should own the Information Sharing Governance policy?

Assign a single accountable owner (often GRC or security governance) with named supporting owners in ERM, Legal, and Communications. What matters is that approvals, review cadence, and operational workflows are clear and maintained. ¹

What evidence is most persuasive to an assessor?

A controlled policy with version history and approvals, plus real samples: incident comms, external sharing approvals, exception records, and ERM risk updates tied to sharing decisions. Evidence should show repeatable use, not one-off documentation. ¹

How do we handle urgent sharing during an incident without slowing response?

Create pre-approved sharing patterns and a fast approval path for defined roles, then require after-action documentation in the incident record. Keep strict review for higher-risk disclosures and exceptions. ¹

We share with many third parties. Do we need separate rules per third party?

You need a consistent governance standard with room for third-party-specific constraints (contract terms, NDAs, data handling). A baseline policy plus an allowlist/exception approach scales better than bespoke rules for every relationship. ¹

What you actually need to do

Use the cited implementation guidance when translating the requirement into day-to-day operating steps. ²

Footnotes

1. Cybersecurity Capability Maturity Model v2.1

2. DOE C2M2 program