Exports
An audit is only as useful as the artefacts it produces. The export menu turns one into a spreadsheet, a Word report, a zip for an assessor who wants the evidence too, or a machine-readable OSCAL document.
Where to find it
Section titled “Where to find it”Open an audit and click the Export button at the top right of the summary card. The Export options dialog opens with two groups, Audit and Action plan; each entry shows its format and a one-line description, and clicking it starts the download.
Which entries appear depends on the framework and on who you are: third-party respondents see only the evidence bundle, and the framework-specific entries appear only for the frameworks they apply to.
Audit exports
Section titled “Audit exports”| Entry | Format | Contents |
|---|---|---|
| Requirements data | CSV | Flat list of every requirement with its scores, observations and answers. The starting point for a pivot table. |
| Requirements workbook | XLSX | The full dataset — answers, scoring and progress — as a formatted workbook. |
| Executive summary | DOCX | A Word report: cover page, spider chart, framework tree and scored requirements. For a reader who does not want a spreadsheet. |
| Bundle with evidences | ZIP | An HTML snapshot packaged with every attached evidence file. Give this one to an external assessor: the proof travels with the claims. |
| as OSCAL | JSON | A machine-readable OSCAL Assessment Results document — see below. |
| CyFun assessment | XLSX | CyFun only: the self-assessment sheet in the layout the Belgian Centre for Cybersecurity expects. |
| SoA builder | HTML | ISO 27001 only: opens the Statement of Applicability report builder rather than downloading a file. |
Action plan exports
Section titled “Action plan exports”The action plan is the set of applied controls linked from the audit’s requirements. Its exports are about work, not compliance:
| Entry | Format | Contents |
|---|---|---|
| Controls list | CSV | Flat list of the applied controls with their metadata. |
| Controls workbook | XLSX | The same controls as a formatted workbook. |
| Status-grouped report | Controls grouped by status and sorted by ETA — the remediation plan as a document. |
These entries are hidden from third-party respondents.
The OSCAL export
Section titled “The OSCAL export”as OSCAL produces an OSCAL Assessment Results document, version 1.1.2, as JSON. OSCAL is NIST’s machine-readable format for assessment artefacts, and this export is what lets an audit feed a pipeline instead of a human reader.
The document carries metadata (the audit’s name and framework, its version, its timestamp, and its authors and reviewers as OSCAL parties), one result covering the audit with a reviewed-controls list naming every assessable requirement, and one finding per assessed requirement — the requirement’s reference and name as the title, the auditor’s observation as the description, links to the attached evidence, and remarks explaining any lossy mapping.
Two details matter when you consume the output:
Requirements that are still Not assessed produce no finding at all. They appear in reviewed-controls but are absent from findings, which is the schema-correct way of saying “nothing to report yet”. A consumer counting findings will undercount unless it reconciles against the reviewed-controls list.
The five-value result is collapsed onto OSCAL’s two states. OSCAL only knows satisfied and not-satisfied, so the export encodes the nuance in the reason, the remarks and the properties:
| Result | OSCAL state | Reason | How the detail survives |
|---|---|---|---|
| Compliant | satisfied | pass | — |
| Partially compliant | not-satisfied | other | Remark naming the original result |
| Non-compliant | not-satisfied | fail | — |
| Not applicable | satisfied | other | An applicability property plus a remark |
Every finding also carries the original values as properties: cyberguard-result, cyberguard-status, the framework URN, the framework reference id, the extended result and the score when one is set. Nothing is lost — it is just moved out of the status field.
Control identifiers are emitted as URNs in the form urn:cyberguard:framework:FRAMEWORK-URN:REFERENCE-ID, since the platform ships no OSCAL catalog per framework. Document, result and finding UUIDs are derived deterministically, so re-exporting an unchanged audit produces identical identifiers and diffs stay meaningful.