Skip to content
English
Customer portal
Contact us
  • There are no suggestions because the search field is empty.

08.04 Exporting Data and Evidence

SimpleRisk's export paths candidly mapped — the Dynamic Risk Report's CSV download (Extra-gated), the Import/Export Extra for bulk data, the per-risk print view, the evidence file downloads from compliance and incident records, and the v2 API for everything else.

Why this matters

Export is the discipline of getting SimpleRisk data out of SimpleRisk — into spreadsheets for ad-hoc analysis, into PDF packets for board distribution, into the auditor's workpaper trail, into the customer's due-diligence questionnaire response. The program produces continuous output through the application's own surfaces (dashboards, reports, drill-down detail), but every external audience eventually needs a portable artifact, and export is how you produce one.

The honest answer about SimpleRisk's export story: it's narrower than most users expect. Most reports don't have a built-in download button. The dashboards don't have a "save as PDF" button. The risk register doesn't have an "export everything" link in Core. The export paths are concentrated in two places: the Dynamic Risk Report (CSV download, gated by the Import/Export Extra) and the Import/Export Extra itself (bulk export across many entity types). The rest of the export story relies on browser print-to-PDF, screenshot capture, individual file downloads from evidence sections, and direct API calls.

The other thing worth knowing: evidence files download individually rather than in bulk. A control test with five attached evidence files produces five separate download actions, not a single zip. For audit packaging, the program assembles the export bundle outside SimpleRisk — usually a folder named for the audit with the individual files placed inside.

The third thing: the v2 API is the most flexible export path for any structured data SimpleRisk holds. For programmatic export (recurring data dumps, integration with external BI tools, scripted audit-bundle assembly) the API is more capable than any UI export surface. The trade-off is that it requires scripting; the UI exports require less effort but are limited in scope.

Before you start

Have these in hand before exporting:

  • A clear destination for the export. "I need the data" without knowing what's done with it next produces an export the team doesn't use. The destination determines the right format (CSV for spreadsheet analysis, PDF for distribution, JSON for integration).
  • Permission for the entity you're exporting. Each export inherits the permissions of the source surface — exports of risk data require risk-management permissions, exports of compliance data require compliance permissions, etc.
  • A read on whether the Import/Export Extra is installed for any bulk-export workflow. Most CSV-driven export paths in SimpleRisk are gated by the Extra; without it, the bulk paths don't exist. (See Importing and Exporting Risks for the Extra's full bulk-export capabilities, including the trade-offs around the keyed update behavior.)
  • A naming convention for exported files. Exports without a date in the filename and without a description of the source surface get unfindable within a quarter. risks-export-2026-Q3-week-3-all-open-by-team.csv is much more useful than export.csv.

Step-by-step

Path A: Per-report CSV download (Dynamic Risk Report only)

The Dynamic Risk Report at /reports/dynamic_risk_report.php is the only built-in report with a first-class CSV download in the UI. The download is gated by the Import/Export Extra.

Steps:

  1. Open Reporting → Dynamic Risk Report.
  2. Configure the report: pick the columns you want, apply filters (date ranges, status, severity, team, etc.), choose the sort order.
  3. Click the download action — typically a button labeled Download (or shown via a download icon, varying with theme): - ?option=download — downloads all risks matching the current filters. - ?option=download-by-group — downloads the risks grouped by the selected category (team, technology, etc.) into separate sections.
  4. The browser saves a CSV file with the configured columns and rows.

If the download button doesn't appear, the Import/Export Extra isn't activated; ask your administrator to install/activate it (see Installing Extras in the Administrator Guide).

The Print By Group report at /reports/print_by_group.php follows the same pattern — Extra-gated bulk download with grouping support.

Path B: Bulk export via the Import/Export Extra

For bulk export across many entity types (full risk register, mitigations, reviews, scoring history, assets, controls, users), the Import/Export Extra is the right tool. The Extra exposes a unified Export tab at /admin/importexport.php with selectable export types: Combined (everything), Risks only, Mitigations only, Reviews only, Assessments, Assets, Asset Groups, Controls, Users, Template Groups, Control Tests.

Each export type produces an XLS spreadsheet with the relevant columns. The full walk-through is in Importing and Exporting Risks; the same Extra and the same UI handle exports of the other entity types listed above, not just risks.

Important caveats about the Import/Export Extra:

  • Format is XLS, not CSV. The Extra reads and writes XLS spreadsheets. For tools that expect CSV, save-as-CSV from Excel after opening the export.
  • Export is admin-permission-gated. The page lives in /admin/; only users with admin access can run bulk exports.
  • Re-importing a modified export is a key-driven update, not a fresh insert. The risks_id column on the export is what makes re-imports update existing records; deleting the column turns re-imports into duplicates. See the import-export article for the full story.

Path C: Per-risk print view

For exporting a single risk's full detail (for an audit conversation, for a stakeholder review, for an evidence package), the per-risk print view at /management/print_view.php?id= produces a single-page rendering of the risk and all its associated detail (scoring history, mitigation, review history, comments).

Steps:

  1. Navigate to the risk's detail view (/management/view.php?id= ).
  2. Click the print or download action; depending on theme, this opens /management/print_view.php?id= directly.
  3. Use the browser's print function (Ctrl+P / Cmd+P) and "Save as PDF" to capture as a PDF.
  4. Save with a date-stamped filename: risk-IM-2026-Q3-0042-printview-2026-09-15.pdf.

The print view is the only built-in single-record export surface for risks. Permission-gated by check_riskmanagement. There's no equivalent print view for compliance, governance, or other entity types in Core; for those, the screenshot or browser-print pattern is the path.

Path D: Evidence file downloads

Compliance test evidence files (uploaded against control tests; see Control Tests and Evidence Collection) and incident evidence files (uploaded against incidents; see The Incident Management Extra) download individually through their respective entity views.

For a single test or incident, the evidence section shows each attached file with a download link. Click each file to download it; SimpleRisk serves the file from the compliance_files table (for compliance) or incident_management_incident_evidence table (for incidents).

For audit packaging (the auditor wants all evidence for a control over the audit period) the program assembles the bundle manually:

  1. Open the compliance module's audit history for the relevant control over the period.
  2. For each test audit, open it and download each attached evidence file.
  3. Save into a per-control folder named for the audit period.
  4. Provide the folder to the auditor (via secure file transfer, audit portal, or whatever the audit conversation is using).

This is manual and time-consuming for large audit scopes. For programs running annual audits with many controls, scripting the bundle assembly through the v2 API is often worth the development effort.

Path E: Browser print-to-PDF for any visible page

Any SimpleRisk page can be captured as a PDF via the browser's built-in print function. This is the fallback for pages without a dedicated export button.

Steps:

  1. Navigate to the page you want to capture (a dashboard, a specific report, a risk detail view, an audit history).
  2. Browser print (Ctrl+P / Cmd+P) → choose "Save as PDF" as the destination.
  3. Adjust orientation (landscape for wide content), scale (70–85% typically fits dashboards on one page), and margins (narrow margins maximize content area).
  4. Save with a date-stamped filename.

The output isn't pretty — print stylesheets in SimpleRisk are minimal, so the captured PDF includes navigation chrome, sidebars, and other UI elements that don't render usefully in print. For polished output, screenshot a specific region instead and embed it in a presentation.

Path F: Programmatic export via the v2 API

For any structured data SimpleRisk holds, the v2 API is the most flexible export path. Common patterns:

  • Risk register export. GET /api/v2/risks (with filtering) returns the list of risks as JSON. Pair with per-risk endpoints (/api/v2/risks/{id}, /api/v2/risks/{id}/mitigations, /api/v2/risks/{id}/reviews) to assemble full detail.
  • Compliance test history export. POST /api/v2/compliance/define_tests and /api/v2/compliance/active_audits (the datatable endpoints) produce the test data; per-audit endpoints fetch result detail.
  • Incident export. GET /api/v2/im/incident/get/all returns incidents; per-incident endpoints fetch detail.
  • Asset export. GET /api/v2/assets and the asset-group endpoints.

The API is richer than any UI export — every field SimpleRisk knows about is reachable through the right combination of endpoints. The trade-off is scripting effort. Most programs that build API-based export do so for recurring exports (a nightly data dump for a BI tool, a weekly audit-evidence bundle for an external auditor); one-shot exports usually go through the UI paths.

For BI integration, an alternative is direct database access — tools like Metabase, Looker, or Tableau can connect to the SimpleRisk MySQL database (with appropriate read-only credentials) and produce reports outside SimpleRisk entirely. This bypasses the API but requires careful permission management to ensure the BI tool only sees data appropriate for its audience.

Common pitfalls

A handful of patterns recur with exports.

  • Assuming every report has a download button. It doesn't. Only the Dynamic Risk Report (and the Print By Group report) have built-in CSV downloads, and both are gated by the Import/Export Extra. For other reports, the export paths are browser print-to-PDF or screenshot. Don't waste time looking for download buttons that aren't there.

  • Bulk-exporting via the Extra without checking the Extra status. A planned bulk export discovered on the day of need to depend on an Extra that hasn't been activated produces an emergency activation, plus delays. Confirm the Import/Export Extra is active before relying on it for time-sensitive distributions.

  • Treating exports as snapshots that age well. A CSV exported on Monday and emailed Friday represents Monday's data; the readers will assume Friday's. Always include the as-of date in the filename and inside the artifact (cover page, header row, etc.). For high-cadence distributions, re-export rather than reusing.

  • Bulk-exporting with no destination plan. A weekly full export that nobody actually uses produces an audit trail of exports without producing any program value. Export when the destination is genuinely consuming the data; the export-for-export's-sake pattern just creates noise.

  • Forgetting that exports include sensitive data. The risk register may contain risk subjects describing specific systems, named individuals, and security gaps. Exports of this data shouldn't go to the same channels as routine business communications. Use secure file transfer for external recipients; use channel-appropriate redaction for internal stakeholders without need-to-know.

  • Manual evidence-bundle assembly at audit time. A program with 200 controls and a year of evidence per control is looking at thousands of file downloads at audit time. The manual path doesn't scale. Either script the bundle assembly via the v2 API (development effort once, time savings every audit) or maintain a parallel evidence-tracking system that produces the bundle as a byproduct of the testing cadence.

  • Dropping the risks_id column from the Import/Export Extra exports. This isn't strictly an export pitfall but it's the most common Extra pitfall: re-importing a modified export with the risks_id column dropped produces duplicates rather than updates. If you're exporting for distribution (no re-import planned), keep the column anyway — it's the unique identifier that lets readers correlate the export back to in-system records.

  • Treating XLS exports as CSV. The Import/Export Extra writes XLS, not CSV, despite some internal references using "CSV" generically. Tools that expect CSV need a save-as-CSV step from Excel after opening the XLS. Alternatively, for a pure CSV path, use the Dynamic Risk Report download (which is genuinely CSV).

  • Exporting via the API without rate-limiting. A script hammering GET /api/v2/risks/{id} thousands of times in seconds will hit either the application's connection limits or the database's connection-pool exhaustion. Add a small per-call delay (50–200ms) for any script that touches more than a few hundred records.

  • Not recording external distributions. When an export goes to an external recipient (an auditor, a regulator, a customer), record the distribution somewhere — the artifact, the date, the recipient, the framing context. The recorded artifact is the reference point in future conversations. See Sharing the Risk Dashboard with Stakeholders for the recording discipline.

Related