Which report for which audience
An audit is worth what you deliver from it. The same stored run renders four to six different ways, because the board, the administrator who fixes things and the compliance officer are not looking for the same thing. Here is which report goes to whom, and in which format.
Why not one report
A single hundred-page document is read by nobody: the executive cannot find the decision, the administrator cannot find the offending object, the auditor cannot find the framework. So the audit is stored once — with its date, its baseline and its scope — and rendered once per audience. The figures cannot drift between documents, because they are computed once rather than once per report.
The report types
Executive report — management, CISO, security committee
One page. The weighted score, its change in points, the split of verdicts, and the three findings that expose the client most, written without jargon. This is the document that releases a budget, not the one that explains how to fix things. Deliver it as PDF.
Detailed technical report — IT team, administrators, managed service provider
Every evaluated control with its verdict and, above all, the named objects at fault — not “non-compliant”, but which accounts, which groups, which resources. Each control carries the verification command, so the client's administrator can replay the check and, if need be, challenge the result. An audit you cannot replay does not get fixed; it gets argued about.
Prioritised remediation plan — project manager, run team
Non-compliances only, sorted by real severity — level 1 first, then by number of affected objects — rather than in catalogue order. In Excel or CSV, each row becomes a ticket: add an owner and a due date, and the action plan turns into a project tracker.
Compliance by framework — compliance, external audit, insurer, regulator
Coverage and compliance rate framework by framework, plus, on Active Directory, the ANSSI maturity tier and the attack path graph. This is the exhibit you attach to a NIS2 file, an insurer's questionnaire or a client security review.
Situation report — steering committee, quarterly review
Available on Active Directory. It does not re-describe the audit: it says what moved since the previous one, at comparable scope — and says so explicitly when the scope changed, otherwise the curve lies. Regressions are listed before fixes, because a control that becomes non-compliant again is a drift signal, not a detail.
Attack paths — Active Directory team, technical management
Specific to Active Directory. It does not say a right is misplaced; it shows the chain, ranked by severity × breadth, with domain takeovers flagged. This is the report that gets remediation approved rather than merely acknowledged. See how to read one.
Five formats, and when each earns its place
| Format | Use it for |
|---|---|
| HTML | The main deliverable. One standalone file, no dependency, opens in any browser — the recipient installs nothing. On Active Directory it is the only format that renders the maturity tiers and the attack path graph. |
| What gets signed, archived and attached to a contract. | |
| Excel | Where the remediation plan becomes a tracker: add an owner column, a due date column. |
| CSV | Import into a ticketing tool. Semicolon separated, UTF-8 with BOM. |
| JSON | Integration: SIEM ingestion, GRC tooling, automated comparison of two audits, time-stamped evidence. |
Where each one lands in an engagement
- Day 0 — framing. The baseline is frozen. Scope is written before the audit, not negotiated after.
- Day 1 — audit. The detailed report goes to the IT team the same day, while the findings are fresh and verifiable.
- Day +2 — management. The executive report as PDF: one score, one trend, three risks.
- Week 1 — plan. The remediation plan in Excel, one row per action, with owners.
- Quarterly — committee. The situation report, or a fresh audit compared with the reference one.
- Yearly — compliance. The framework report, attached to the NIS2 or DORA file.
Under your brand
Every report carries your logo, your name and your issuer details, with the audited client's logo on the cover. The same audit renders in French or English without being re-run — the interface language at export time decides. And the export stays a local file: no client data goes through a third-party service, which is often the very condition for auditing a sensitive environment.