Skip to main content

Reports

The Reports module turns your compliance posture into a deliverable: a document you can hand to a customer, an auditor, or your board. Everything else in SolveGRC accumulates state — framework scores, control assessments, evidence, risks. Reports is where that state becomes an artifact with a date on it, generated from the live data at the moment you run it.

This guide covers the module in two pages:

  1. Overview (this page). What a report is, what kinds exist, and how the module connects to the rest of the platform.
  2. Build and deliver. Generating a report from the catalog, composing a custom report in the builder, and getting the result to the people who asked for it.
ScreenshotThe Reports hub: KPI row (Generated · 30 days, Active schedules, Last delivery) above the report catalog, recent runs with live progress, and the Schedules section.

What lives in the hub​

The Reports page is one screen with three numbered sections:

  • Report catalog. The list of report definitions you can generate from. Each entry carries a System or Custom tag: system definitions are prebuilt and seeded by the platform, custom definitions are ones your team composed in the builder. Every entry shows its block count and default output format, with a format picker and a Generate button on the row.
  • Recent reports. Every run, newest first, with a status badge — Queued → Generating → Completed (or Failed / Cancelled) — and a live progress bar while it generates. Completed runs offer View, a download button per output file, and Send.
  • Schedules. Recurring generation. A schedule runs a definition on a cadence and can deliver the result to a recipient list automatically, which is what the Active schedules and Last delivery KPIs at the top track.

Reports render in up to four formats — PDF, HTML, CSV, and XLSX — and you can select more than one format for a single run.

There is also a Branding button in the page header: the logo, colors, and footer you set there are applied to every generated report, so what you send out looks like yours rather than ours.

Before you start​

A report is only as good as the data behind it. The blocks pull live framework scores, control assessments, evidence state, and risk posture — so a report generated before those modules have content will be technically correct and practically empty.

Generate after the work, not before

Activate your frameworks, link your evidence, and let assessments settle before you generate a report for an external audience. The report reflects whatever is true at generation time.

You will also need:

  • Access to the module. Reports appears in the sidebar only if your role can read it, and generating, building, or scheduling a report requires create permission. If the Generate buttons are missing, ask an administrator.
  • An active subscription. The module is gated behind your plan.

How this connects​

Reports sits at the end of the pipeline. It consumes:

  • Framework scores and gaps from the Frameworks module — compliance percentages, control satisfaction, what is still open.
  • Evidence from the Evidence Locker — so every number in a report can be traced back to the records behind it.
  • Risk posture from the Risks register.

It produces shareable compliance reports, and those feed the people outside the pipeline: customers doing due diligence, auditors preparing an engagement, and your board.

One distinction worth keeping straight: a report is a snapshot document generated from live data. If an auditor needs the underlying evidence files themselves — frozen and packaged for an engagement — that is the Audits module, not Reports.