08.03 Sharing the Risk Dashboard with Stakeholders

Why this matters

A dashboard nobody outside the GRC team sees doesn't drive decisions outside the GRC team. The discipline of getting the dashboard in front of leadership is what closes the governance loop — leadership reads the posture, asks the questions that produce decisions, and the program acts on the decisions. Without the share, the dashboard is a self-talk surface; with it, the dashboard is a leadership tool.

The honest answer about SimpleRisk's built-in sharing capability: there isn't much. Reports and dashboards require a SimpleRisk login. There's no public-link sharing for dashboards (unlike assessment questionnaires, which use tokenized public URLs). There's no built-in scheduled-report distribution in Core (the Notification Extra may add some). There's no native "embed this dashboard in a Slack message" surface. The sharing story comes down to this: take the dashboard, capture it as an artifact a non-SimpleRisk reader can consume, and distribute that artifact through the channels you already use.

The other thing worth knowing: the capture and distribute pattern is more flexible than a built-in share would be, but it depends on discipline. A program that captures dashboards inconsistently (different stakeholders get different cuts at different cadences with different framing) produces a sharing layer that confuses more than it clarifies. The discipline is in standardizing the capture (same source dashboard, same audience-specific framing, same distribution cadence).

The fourth thing: the audience determines the right format. The board reads PDFs in meeting packets; the security committee reads slides in the meeting itself; the SOC manager reads Slack updates between meetings; the auditor reads the underlying data. A single artifact doesn't serve all of them; the share strategy is per-audience.

Before you start

Have these in hand before sharing:

• The dashboard or report you'll share open and current. The dashboards (Risk Management, Compliance, Governance) refresh on page load; navigate to the dashboard fresh before capturing so the data is current.
• A read on the audience. Board readers want one page; the audit committee wants context; the SOC manager wants the latest delta. Pick the format that matches what the audience will actually read.
• A distribution channel. Email for board materials, a meeting deck for committees, Slack for operational updates, a portal upload for external auditors. The channel determines the format constraints (PDF for email attachments, image for Slack, structured data for portals).
• A documented as-of date for whatever you share. Add the date to the file name and include it in the captured artifact (a screenshot timestamp, a cover slide). Without the date, readers assume the data is current as of when they're reading it, which produces "the numbers don't match what I saw" conversations later.

Step-by-step

1. For board readouts: browser print-to-PDF the dashboard

The simplest one-page-board-ready artifact is a browser print-to-PDF of the dashboard itself. The result isn't pretty (it'll show navigation chrome, margins, and possibly some interactive elements that don't render usefully in print), but it's a faithful capture of the data and it takes thirty seconds.

Steps:

1. Open the dashboard in the browser (e.g., /reports/risk_management_dashboard.php).
2. Wait for all widgets to finish loading (charts in particular take a moment to render).
3. Browser print → choose "Save as PDF" as the destination.
4. Use Landscape orientation for dashboards with wide widgets.
5. Set Scale to a value that fits the dashboard on one or two pages without cropping (typically 70–85%).
6. Save with a date-stamped filename: risk-dashboard-2026-Q3-week-3.pdf.
7. Email or attach to the meeting packet.

For the cleanest PDF, hide the sidebar before printing (the SimpleRisk theme typically supports collapsing it via the hamburger menu) and use the browser's print preview to refine the layout before saving.

2. For meeting decks: screenshot specific widgets and embed

When the dashboard goes into a meeting slide deck, the right artifact is usually individual widget screenshots rather than the whole dashboard. The slide can frame each widget with the question it answers and the recommended decision.

Steps:

1. Open the dashboard.
2. Use a screenshot tool (the OS-native one, or a tool like Snagit/CleanShot) to capture each widget individually. Most tools support "capture this region."
3. For each captured widget, embed in the slide with: - A title naming the question the widget answers ("Open vs Closed Risks: Is the Register Growing or Being Worked Down?"). - The screenshot itself. - A two-or-three-bullet read of what the data is showing. - A recommended decision or follow-up.
4. Include an "as of" date on the cover slide and on each individual slide footer.

This pattern produces decks that work without the dashboard underneath them — the reader doesn't need to interpret the chart from scratch.

3. For Slack / Teams / chat channels: post the screenshot with framing

Operational distribution to the on-call team or the security channel works well as a posted screenshot with one-line framing.

Steps:

1. Capture the relevant widget or chart with a screenshot tool.
2. Post to the channel with a one-line message naming what to read: "Weekly risk update — open count climbed 12% this week, mostly from the Q3 vulnerability scan import. The high-severity bucket is unchanged. Full details in the dashboard."
3. Include a link back to the dashboard for readers who want to drill in.

For recurring posts, build a per-week template so the framing stays consistent across the cadence.

4. For external auditors: export the underlying data and pair with narrative

External auditors need the data, not the dashboard. The audit conversation is about specific controls, specific risks, specific evidence — the dashboard view is too high-level.

Steps:

1. Open the relevant detail report (the Dynamic Risk Report for risk-side, the Dynamic Audit Report for compliance-side).
2. Apply filters to scope the data to what the auditor asked for.
3. Export the result via the report's CSV download (Dynamic Risk Report supports this when the Import/Export Extra is active — see Exporting Data and Evidence).
4. Pair the export with a written narrative: a one-paragraph context document explaining what the export contains, the as-of date, the filters applied, and any caveats. The narrative is what makes the export interpretable; the raw CSV alone is just data.
5. Distribute through the auditor's preferred channel (a secure portal for high-sensitivity data, encrypted email for moderate, plain email for low).

Record the share in your audit-evidence log (the artifact, the recipient, the date) so you can reference it later.

5. For recurring distribution: the manual cron pattern

Core SimpleRisk doesn't ship a built-in scheduled-report distribution. Programs needing recurring weekly or monthly distribution have a few options:

• Manual cadence: someone on the team captures and distributes on the cadence. This is the most common pattern; it's also the one most likely to lapse when the responsible person is on vacation. Document the cadence, share the responsibility across at least two people.
• The Notification Extra: for installations with the Notification Extra active, recurring email distribution may be configurable through the Extra's surface. Check simplerisk/extras/notification/ documentation for the specific capabilities.
• A custom cron job: a script that hits the dashboards programmatically (e.g., via headless browser screenshots or via the v2 API for the underlying data) and emails the result. This requires custom development but produces fully-automated recurring distribution.
• A third-party reporting tool: BI tools like Metabase or Looker can connect to the SimpleRisk MySQL database directly (with appropriate read-only credentials) and produce scheduled reports outside SimpleRisk entirely. This is the path for organizations with significant pre-existing investment in BI tooling.

6. Record the share for audit-trail purposes

When a dashboard or report goes outside the GRC team, record the distribution somewhere — a document log, a wiki page, the audit-evidence repository, even a recurring email thread. The recorded artifact becomes a reference point in future conversations: "the report we sent in March" needs to be findable when March's recipient questions it in October. Capture at minimum:

• The artifact (the PDF, the screenshot, the export).
• The as-of date of the underlying data.
• The recipient(s).
• The distribution date.
• Any framing or narrative that went with it.

This is especially important for external distributions (regulators, auditors, major-customer due diligence) where the artifact may be referenced in a formal context months or years later.

Common pitfalls

A handful of patterns recur with dashboard sharing.

• Sending the same artifact to every audience. The single biggest failure pattern. A "weekly risk report" PDF that goes to the board, the audit committee, the security team, and the operations leadership tries to serve four audiences and serves none of them. Build per-audience artifacts; the same source dashboard, repackaged for each reader.

• Sharing without a date. A PDF named "risk-dashboard.pdf" with no timestamp inside it can't be referenced later. Always include the date in the filename and inside the artifact. Ideally include the time of day for high-frequency distributions (the morning capture and the evening capture may differ).

• Treating the screenshot as authoritative. A screenshot captures the data at one moment. The data changes — a closed risk drops the open count, a new submission bumps it back up. Distributing screenshots with no link back to the live dashboard makes the captured number look like the number rather than a number from a moment in time. Include the dashboard URL in the share so readers can drill in for current state.

• Forgetting to refresh before capturing. Capturing a dashboard tab that's been open for two hours produces a screenshot of two-hours-old data. Refresh the dashboard before capturing; the discipline is small and saves the "wait, that's not what's there now" conversation.

• Sharing dashboards that include sensitive data without considering the recipient. A dashboard that shows specific asset names, specific risk subjects with sensitive context, or specific incident details may not be appropriate to share with all audiences. Before distributing externally, redact or scope down. The board doesn't need the asset names; the customer doing due diligence definitely doesn't.

• Building a custom distribution pipeline before exhausting the simple options. A team that immediately reaches for a custom cron + headless browser + email pipeline ends up maintaining bespoke infrastructure for what could have been a calendar-reminder-and-manual-capture process. Start with manual; automate when the manual becomes load-bearing.

• Letting recurring shares lapse silently. A weekly risk update that the team sends consistently for three months and then stops sending leaves leadership noticing the absence (or not noticing, which is worse). Document the cadence as a commitment; have a backup person when the primary is unavailable.

• Not soliciting feedback on the share. Distributing the dashboard regularly without ever checking whether the audience finds it useful produces a one-way artifact stream. Ask the recipients, occasionally: are they reading it? What questions does it answer for them? What questions does it raise that you could address better? The feedback shapes the future shares.

• Overinvesting in the visual at the cost of the data. A pretty PDF with hand-crafted slides, charts, and narrative is great if the program has the time. Most programs don't. A faithful screenshot with a one-paragraph framing email is enough for most distributions; over-polishing produces artifact-quality theater that the program can't sustain weekly.

Related

• What Makes a Good GRC Report?
• The Built-In Reports
• Exporting Data and Evidence
• The Compliance Dashboard
• The Risk Dashboard