> ## Documentation Index
> Fetch the complete documentation index at: https://docs.petrasecurity.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# Policy Report
> A white-labeled PDF for a single Conditional Access policy: proof of what it blocked if it is enforced, or a pitch and sign-off request if it is not.
The Policy Report is a client-ready PDF built for one Conditional Access policy on one tenant. What it says depends on whether the policy is doing anything yet:
* If the policy is **enforced**, the report is proof of value: what it actually blocked over the last 30 days.
* If the policy is **report-only** or **disabled**, the report is a pitch: what it would have blocked, plus a built-in request for the client to approve turning it on.
Use an enforced policy's report in a QBR to show the value of something you already turned on. Use a
report-only or disabled policy's report to ask a client to approve enabling it.
***
## How to reach it
1. Open a tenant's **Policies** page.
2. Click into the policy you want to report on.
3. Click **Generate policy report**.
This opens a dialog where you can add an optional note to the client and, for report-only or disabled policies, choose whether to include a formal approval request.
Click **Generate report** and the PDF downloads immediately.
The reporting window is fixed at the last 30 days and cannot be changed. The report is scoped to a
single policy, there is no batch option to generate one for every policy at once.
***
## The optional note
The **Note to the client** field is free text, up to 600 characters, that you write at the moment you generate the report. It is not saved anywhere else and does not carry over to future reports for the same policy.
Whatever you write appears verbatim, in italics, in a card near the top of the PDF titled **A note from \**. Use it for context the numbers don't show on their own, like when you turned the policy on or why you're recommending it now.
***
## Requesting approval
For a policy that is **report-only** or **disabled**, the dialog shows a **Request approval** checkbox, checked by default. Leave it checked and the report's top card becomes **Approval requested** instead of a plain note. It includes:
* A short explanation of what you're asking for and why, worded for whether the policy is currently report-only (Microsoft is evaluating sign-ins but not blocking anyone) or disabled (nothing is being evaluated at all, so any figures in the report come from an earlier period).
* Your note, if you wrote one.
* A sign-off block: a checkbox next to a line stating that the client has reviewed the report and authorizes you to enable the policy, with blank lines for a name, signature, and date, and instructions to return the signed page to you.
This is a print-and-sign flow, not a digital signature. Petra doesn't email the client, doesn't collect their response, and doesn't track whether they approved. The signed page comes back to you however you choose to collect it.
If you don't want the approval ask on this run, uncheck **Request approval**. The report still generates, it just shows your note in a plain card without the sign-off section.
An already-enforced policy has nothing to ask permission for, so the approval option only appears for
report-only and disabled policies.
***
## What's in the PDF
1. **Title card**: the policy name, a status pill (**Enforced**, **Report Only**, **Disabled**, or **State unavailable**), a short plain-English description of what the policy does, the reporting period, and when the policy was created and last modified.
2. **Note or approval request**, if you added one.
3. **Activity**: four stat tiles covering sign-ins blocked (or would-have-been-blocked), attacks stopped, accounts affected, and blocks from proxy, VPN, or datacenter IPs, followed by a breakdown of affected countries and a table of the most affected accounts.
4. **Who and what this policy covers**: side-by-side cards for what's in scope and what's excluded, a table of any excluded accounts that still had sign-ins during the window (so a client can see who a fix would need to account for), and a plain-English summary of the grant requirement, conditions, and session settings.
5. **Appendix**: the policy's full raw configuration, for anyone who wants the technical detail behind the summary.
The plain-English policy description is written automatically from the policy's configuration. If that generation fails for any reason, the report still downloads with a simpler fallback description, and Petra tells you so at the bottom of the screen so you can regenerate it later.
***
## Related
* [Conditional Access Policies](/docs/policies/conditional-access-policies) covers Petra's policy recommendations, simulator, and version history.
* [Posture Report](/docs/reporting/posture-report) covers a tenant's full Microsoft 365 configuration, not just one policy.