Reports & Compliance

The Reports module turns platform data into summaries a decision maker can read. Every report is built from live data at the moment it is generated, so it reflects the current state of the platform rather than a cached copy.

The catalogue holds ninety six report definitions across twelve modules, from endpoint inventory to governance and audit. Two rules keep reports useful. First, always state the date range and the target scope. Second, compare a report with the previous report instead of reading it alone.

Close image

Open Reports and then Report Catalogue from the sidebar. The catalogue is one list grouped by module. Each row shows the module icon, the report name, a one line description and the report category. The name is a link that opens the report viewer with live rows, charts and summary metrics.

• Search matches the report name, the description, the category and the module.
• The module filter limits the list to one module and shows how many reports it holds.
• Run generates the report in the background and stores it in the run history.
• Schedule creates a recurring delivery for the same definition.
• Custom Report creates a new definition from a base report. You select the columns and the filters the audience needs, and the derived report appears in the catalogue.

Twelve modules contribute report definitions. The count next to each module is the number of reports it holds in the catalogue.

Nine regulations have a control by control report. Each report assesses the articles of the regulation with live platform evidence and marks the items the platform cannot measure as manual review.

• The date range sets the evidence window. Reports that measure activity, such as the audit trail, file integrity events and password rotation, are limited to that window.
• The target scope narrows endpoint derived evidence to the selected groups, profiles, tags, endpoints or custom fields.
• Platform wide evidence, such as MFA, single sign on, SIEM forwarding and the audit trail, is labelled as platform wide in the evidence text, so it is not read as narrowed.
• An empty scope does not fall back to the whole fleet. The affected control becomes manual review and reports that no endpoint is reporting.
• Each control is graded from its evidence. Ninety percent or more is compliant, sixty percent or more is partially compliant, and below that is non compliant.
• Every framework report lists the other frameworks that share the same evidence in an Also Satisfies column.

Close image

• Date range: always set it explicitly. A report without a date range cannot be compared with the next one.
• Target scope: limit the report to a group, profile, tag, endpoint or custom field. The same control is used in every report.
• Module filter: include only the modules the audience cares about.
• Severity and status filters: exclude informational items from a management report and keep them for an engineering review.
• Search, sorting and pagination run on the server, so a report with a large result set stays responsive.

1. 1
   Choose the scope

   Set the module, target scope, date range and status filters. A narrow scope produces a report that can actually be acted on.

2. 2
   Generate the report

   Run the report from the catalogue or from the viewer. Generation happens in the background and the result is stored in the run history.

3. 3
   Review the results

   Compare the summary metrics with the detail records and look for gaps, not only for failures.

4. 4
   Deliver and keep the baseline

   Send the output to the responsible team or schedule it for recurring delivery, and keep the file so the next report can be compared against it.

A schedule delivers the same report on a fixed cadence. Run history keeps every generated report with its requester, format and delivery state.

• A schedule stores the definition, the filters, the target scope, the output format and the recipients.
• Recipients receive the file through the platform notification system, so delivery follows the same mail configuration as the rest of the platform.
• Pause stops delivery without deleting the schedule. Run now produces the report immediately.
• The schedule list shows the last delivery result, the last error and the next run time.
• Run history lists queued, running, completed and failed reports. A completed report can be downloaded by the user who has access to it.
• Generated files are kept for the retention window configured on the appliance, thirty days by default, and are then removed automatically.

A report can be produced as CSV, Excel (XLSX), PDF or JSON. The format is selected when the report is generated or scheduled.

• PDF carries the Moftgate logo, the report date in your time zone, the name of the user who generated it, page numbers and an optional footer note.
• The footer note is available for PDF only and holds up to five hundred characters. Use it for the audit reference or the period label.
• Excel output adds a report information sheet with the same metadata as the PDF.
• CSV and JSON carry the rows only and are intended for downstream processing.