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

01.09 Importing and Exporting Risks

Bulk-import risks (and mitigations, reviews, and scoring) from a spreadsheet, and export the register out to one — using the Import/Export Extra. Covers the column-mapping flow, the keyed update behavior, and the recovery cautions.

Requires: Import/Export Extra

Bulk import and export of risks (along with associated mitigations, reviews, and scoring) is provided by the Import/Export Extra. Core SimpleRisk supports per-risk submission and review through the standard forms only; the spreadsheet-driven bulk path is gated behind the Extra.

Why this matters

Most working programs eventually need to move risk data into or out of SimpleRisk in bulk. The recurring scenarios are predictable: an existing register lives in a spreadsheet and needs to land in SimpleRisk to start; a leadership readout needs the register exported to a spreadsheet for a board meeting; a renormalization (new owner field across forty risks, new category taxonomy across the whole register) is too large to do per-risk through the UI. The Import/Export Extra is what makes those scenarios tractable.

The Extra is also what makes spreadsheet-based migration paths into SimpleRisk possible. Customers landing from another GRC tool (or from a homegrown spreadsheet register) usually arrive with their data in some columnar shape, and getting that data into SimpleRisk without re-typing it is the difference between a migration that takes two days and one that takes two months.

The cost of this power is that bulk operations bypass the per-risk visual confirmation that the standard forms provide. A wrong column-mapping in an import affects every row in the spreadsheet at once, and the recovery path is restoring from a backup. The workflow in this article spends real time on the verification step for that reason.

Before you start

Have these in hand before opening the Extra:

  • Admin access to SimpleRisk and the Import/Export Extra installed and activated. The page lives at /admin/importexport.php, which is admin-permission-gated. If the Extra isn't installed, the page shows an Activate button (or a subscription-upgrade message if your install type doesn't include it). See Installing Extras for the activation flow.
  • A current database backup. Bulk imports rewrite many rows in one operation, and the recovery path from a misconfigured import is restoring from backup. Take a real backup, not "I'll just keep the export" — the export covers the columns mapped, not the full schema. See Database Backup and Restore in the Administrator Guide.
  • A clear spreadsheet shape. For a fresh import, decide which fields the spreadsheet will populate and which will be left default (the Submitting a Risk walk-through is the field-by-field reference). For a re-import (bulk update), start with an export so the existing column structure carries through and the risks_id keys line up.
  • Microsoft Excel format expected. The Extra reads and writes XLS spreadsheets, not plain CSV. Open the export in Excel (or a compatible tool that preserves XLS); editing the export in CSV-only tools risks dropping cells or corrupting the format.

Step-by-step

1. Open the Import/Export page

Sidebar: Configure → Import/Export opens /admin/importexport.php. The first time you arrive, the page either shows the Activate button (Extra installed but not enabled) or the active Import/Export interface. Activating the Extra is a one-click action; once active, the page persists in active state across sessions.

Once activated, the page splits into Export and Import tabs.

2. Export a snapshot before any import

This is non-negotiable. Even when the bulk operation you're planning is a fresh import (no overwrite intended), exporting the current state first gives you something to compare against if anything looks wrong after the import.

On the Export tab:

  1. Pick the Export Type. The dropdown options include Combined (risks plus mitigations, reviews, and scoring all joined into one wide spreadsheet), Risks (just the risk fields), Mitigations, Reviews, Assessments (if the Assessments Extra is also installed), and Assets, Asset Groups, Controls, Users, Template Groups, and Control Tests for the related entities.
  2. Click Export. SimpleRisk generates the spreadsheet and downloads it. Combined is the right pick when you want the full picture for backup-before-changes purposes.

The downloaded file's columns include the risks_id (the SimpleRisk-internal primary key for each risk) on the risk-bearing rows. That ID is what subsequent re-imports use to link the spreadsheet row back to the existing risk. Don't delete the column.

3. Decide what you're importing

Two distinct workflows live behind the same Import button:

  • Bulk update — re-importing a previously-exported spreadsheet, possibly with edits. The risks_id column links each row back to an existing risk; matching IDs trigger an update of the changed columns. This is the workflow for "renormalize this field across forty rows."
  • Bulk create — importing a fresh spreadsheet with rows that have no risks_id yet. Each row becomes a new risk with the next available SimpleRisk ID. This is the workflow for "land an existing register from another tool."

A single spreadsheet can contain both (some rows with IDs, some without) and the import will handle both in one pass — but verifying the result is harder. Splitting them into two separate imports is usually less stressful.

4. Open the Import tab and upload the file

On the Import tab:

  1. Pick the Import Type matching the spreadsheet you're importing (Risks, Mitigations, Reviews, Combined, etc.). The type controls which mapping template the column-mapping modal will preselect.
  2. Click Choose File and pick the XLS spreadsheet from your local filesystem. The Extra reads the file and parses the column headers.
  3. Click Upload (or the equivalent button on your install — labeling varies slightly with theme).

The Extra opens a column-mapping modal showing each column from your spreadsheet on the left and a dropdown on the right offering the SimpleRisk fields each column could map to. The default mapping is the SimpleRisk Combined Import template, which assumes the spreadsheet uses the column names from a prior SimpleRisk export.

5. Verify the column mapping carefully

This is the step that prevents most disasters. Read each row of the mapping modal and confirm:

  • Each spreadsheet column maps to the SimpleRisk field you intend.
  • Columns you don't want imported are mapped to (skip) rather than to a wrong field.
  • The risks_id column (if present, for an update workflow) maps to the SimpleRisk risks_id field — not to a different field with a similar name.
  • Date columns are formatted in a way the import understands (ISO YYYY-MM-DD is safest; locale-specific date formats sometimes drift).
  • Multi-value fields (Affected Assets, Tags, Stakeholders) use the convention the import expects (typically comma-separated within the cell).

If the mapping needs a change, click the dropdown for the row and pick the right field. Save the mapping for reuse if the same shape will be imported again — the Extra supports per-user saved mappings.

6. Run the import and verify

Click Import to execute. The Extra processes each row and reports per-row success/failure. Errors (typically validation failures: invalid date, missing required field, unknown enum value) are reported with the row number so you can fix the spreadsheet and re-run just the failed rows.

After the import completes:

  1. Open the Risk Management Dashboard and confirm the headline counts changed by the expected magnitude. A fresh import of fifty new risks should bump the open count by fifty.
  2. Spot-check three to five of the affected risks via the detail view. Confirm the imported field values look right and the Audit Trail section recorded the import-driven change with your username and the import timestamp.
  3. For an update workflow, run a follow-up export of the affected rows and compare against the spreadsheet you imported. The two should now match (modulo any computed fields like residual risk that the Extra didn't write).

The verification is what catches the "wrong column mapped to the wrong field" cases. The longer you wait to verify, the harder the recovery is — discovering the misimport a week later means a week of additional changes have stacked on top of it.

7. Programmatic import/export via the v2 API

The Extra registers its own v2 API surface under /api/v2/... (the routes are loaded dynamically when the Extra is active). The API endpoints are useful for scripted bulk operations that recur on a schedule — a nightly sync from an external system, for example, that doesn't want to drive the admin UI. The endpoint set mirrors the UI: per-row create, per-row update, full-export, mapping-management. Treat the API path as you would the UI path: with a backup, with verification, with rate-limiting on large batches. (See Bulk Operations on Risks for the broader API guidance.)

Common pitfalls

A handful of patterns recur when import/export goes sideways.

  • Skipping the backup. "I'll just take the export — that's basically a backup" is the sentence we hear before the support ticket. The export is a snapshot of the columns mapped; restoring from it doesn't restore fields you didn't export, audit log entries from after the export, or any associated entity (assets, controls, documents) that the export didn't include. Take a real database backup first; the database backup is the actual restore-target if something goes wrong.

  • Editing the export in a CSV-only tool. Opening an XLS file in a basic CSV viewer can drop cells, mangle multi-line text, or change the column delimiter. The Extra writes XLS, expects XLS, and works most reliably when the round-trip stays in Excel (or a compatible XLS-aware tool). If you need to edit in a CSV environment, export to CSV from Excel after opening the XLS, edit the CSV, then save back as XLS before re-importing.

  • Deleting the risks_id column thinking it's metadata. The risks_id column on a re-import is what links each spreadsheet row back to the existing risk. Deleting the column makes every row a new submission instead of an update, which produces forty duplicated risks instead of forty updated ones. The recovery is closing the duplicates and starting over. Keep the risks_id column on every re-import.

  • Importing without checking the column-mapping modal. The default mapping is "the SimpleRisk Combined Import template" — accurate when the spreadsheet was exported from SimpleRisk, probably wrong when the spreadsheet came from somewhere else. Foreign-spreadsheet imports require you to set every column mapping by hand. Don't rubber-stamp the modal because you're impatient; the modal is the last point at which the import can be redirected before it commits.

  • Importing computed fields. Residual risk score, calculated risk level, and mitigation_planned/mgmt_review flag fields are derived from underlying data — setting them in the spreadsheet doesn't actually change anything; the values get recomputed from the source fields after the import. If your spreadsheet has values in these columns, map them to (skip) rather than to the field; otherwise the modal misleadingly suggests the values will land.

  • Importing assets-by-name when the asset doesn't exist. The Affected Assets field accepts asset names as input, but if the named asset doesn't exist in the inventory, the behavior depends on the Extra's auto-create setting (some installs auto-create new assets, some skip the link silently, some error). Verify the asset inventory is complete before bulk-importing risks that reference asset names; otherwise your imported risks land with broken or empty asset links.

  • Importing without telling stakeholders. A bulk import that creates fifty new risks fires fifty notification emails (if the notification cron is enabled), one per risk, to all configured recipients. The result is an inbox flood at 9 AM the morning after the import. Pause the email-notification cron before a large bulk import, or import outside of business hours.

  • Rerunning the import on a partial-failure spreadsheet without trimming. When some rows fail validation, re-importing the original spreadsheet runs the successful rows again, creating duplicates. After a partial failure, trim the spreadsheet to just the failed rows before re-running the import.

Related