Reports that resolve, not just describe
Strix generates four reports, each written for a specific reader and each a step in fixing the problem — plan the remediation, push it to the user, drive a device to closed, and prove it to an auditor. All are AI-written from your real alert and case data and exported to PDF.
How reports move an issue to resolved
A report isn't the end of the process — it's the instrument that carries an issue through it.
See the posture
Reports roll up real alert and case data into severity, status, and affected-asset counts — the current picture, not a static template.
Drive the fix
Ranked steps, OS commands, and per-device detail turn the picture into concrete action the right person can execute.
Prove & close
Verification steps and evidence sections confirm the fix held, and closure blocks record who signed off and when.
One issue, four audiences
The same underlying incident becomes a different document depending on who needs to act on it — and what "acting on it" means for them.
Admin Remediation Action Report
The technical action plan for grouped critical vulnerabilities and the devices they hit.
What's inside
- The issue / alert group, its severity, and current status
- Every affected device, grouped so one vulnerability isn't chased machine-by-machine
- Recommended SLA and the assigned owner for the fix
- Business impact and an executive summary of what's at stake
- Ranked remediation steps with OS-specific commands, restart, and rollback notes
- Supporting evidence (alert IDs, rule IDs, detection reasons) when included
How it resolves the issue
This is the report you hand to the team that does the work. It turns "we have a critical" into "here are exactly which machines are affected, the ranked steps and commands to fix each, who owns it, and the deadline." Ops follows the plan device by device and tracks progress against the recommended SLA — closing the gap between knowing about a risk and having it patched.
Auditor Remediation Evidence Report
A compliance-grade record of the full detection-to-closure chain.
What's inside
- Control / requirement mapping tying the issue to a framework obligation
- Issue severity, remediation SLA, and overall status
- The evidence owner accountable for the record
- The complete chain: how it was detected, remediated, verified, and closed
- Detection evidence — alert IDs, rule IDs, and the reason each fired
- Executive summary of the incident and its handling
How it resolves the issue
This report resolves the "can you prove it?" problem. When an auditor or regulator asks whether a risk was handled correctly, it lays out the full chain of custody — detected here, fixed this way, verified with this evidence, closed on this date — mapped to the control it satisfies. It converts remediation work you already did into audit-ready proof, so a finding is closed with evidence instead of a promise.
Device Owner Patch Advisory
A short, plain-language notice for the person sitting at the affected machine.
What's inside
- What was found on your device, in plain language — no jargon
- Why it matters, framed for a non-technical reader
- Simple, numbered steps to apply the fix
- What to expect (e.g. a restart) and who to contact for help
How it resolves the issue
This report resolves the last-mile bottleneck: getting the fix onto machines central IT can't all touch directly. Instead of a technician visiting every laptop, the person at the keyboard gets a clear notice they can act on themselves. On a distributed fleet that's the difference between a patch that ships in hours and one that drags for weeks — self-service remediation, guided.
Device Remediation Report
The complete single-machine playbook, from what's wrong to signed-off closure.
What's inside
- Report Summary — severity, status, recommended SLA
- Issue Summary — plain explanation, business risk, exploit possibility
- Affected Assets and Technical Details — CVE, CVSS, detected vs fixed version
- Remediation Steps — OS commands, restart-required, rollback note
- Verification — how to confirm the patch and re-scan
- Evidence and a Closure block (patched by, verified by, date, final status)
How it resolves the issue
This is the artifact that walks a single asset from detected to closed. An analyst opens it for one device and has everything needed in one place — what the vulnerability is, the exact fix and its rollback, how to verify it actually worked, and a closure block to sign off. Nothing is left to tribal knowledge: the same report that diagnoses the machine also proves and records that it was fixed.
Generating a report
Three choices, then it's ready to hand off.
Pick a period
Choose the date range the report should cover — the last week, a specific incident window, or a full quarter for an audit.
Choose what to include
Toggle Evidence (alert IDs, rule IDs, detection reasons) and Recommendations (step-by-step remediation) on or off for the audience.
Generate & deliver
Generate the PDF, then download it, email it to a stakeholder, or save it as a draft to finish later.
Everything is archived
Every report you generate is saved to your organization's report library, ready to re-download whenever you need it again.
Deliver where it's needed
Download the PDF or email it straight to a stakeholder. Scheduled recurring delivery is on the roadmap.
Frequently asked
Generate your first report from live data in Strix.
Open Reports