Compliance Evaluation

What this screen is for

This screen shows one compliance pack evaluated against your tenant's live keys: those active, expired or suspended. Every control and calendar entry of the pack version is listed with its result and the reason for it, grouped by result, and the keys a result names link to their detail. The evaluation blocks nothing. A satisfied platform-observable item does not mean the regime is satisfied. You can download it as an evidence package for an auditor.

What must exist first

The permission to read your tenant's analytics shows the screen. The pack must be one the deployment licence includes; otherwise it is not evaluated, and the screen shows it locked (below).

Decisions you make here

Reading the results

Failed: your keys do not meet the item. The keys it names are the ones to change, for example by rotating to another algorithm or setting an expiry date.
Warning: a calendar milestone applies to a key and has not taken effect yet. The effective day is shown. A dated entry fails from its effective day, except an entry scoped by a risk class, which stays a warning on either side of its day and never fails.
Passed: the platform's state meets the item.
Informational: the regime permits or recommends something your keys use; nothing is required.
Not applicable: no live key is affected.
Not evaluated: the platform cannot decide the item from its own state.

Reading the reasons

Attested by the customer items are never evaluated: their evidence lies outside the platform. An entry scoped by a risk class, as in the EU roadmap, stays a warning on either side of its day, because classifying your use cases is your organisation's call.

A calendar entry applies to a key when the key's own algorithm is listed and the key's purpose, encryption or signing, is in the entry's scope. A composite key never matches an entry about one of its components.

Cryptoperiod

The cryptoperiod items fail for every live key without an expiry date, or whose expiry date lies beyond its maximum cryptoperiod, counted from the creation of the key's current material: 24 months for a symmetric key, 36 months for a signing key, 24 months for a key-establishment key. A verify-only public key has no maximum. The figures come from NIST SP 800-57 Part 1.

The remediation plan proposes the expiry to set, or a rotation when the key is already past its cryptoperiod.

Remediation plan

The Remediation plan tab, beside Evaluation and evidence, turns the failing items into actions: the operation that fixes each one, who owns it and by when. Nothing runs until you preview a step and confirm it. The plan never destroys a key and never re-encrypts your data.

Keys the catalogue does not resolve

A key whose algorithm resolves in no catalogue is listed apart. An item that would pass while such a key is in its population is shown as not evaluated, and the pack reads Incomplete, with no score, until no such key remains. A control that could not be evaluated is listed with its reason and is not in the score, so a score never means that every control passed.

Reading the trend

The trend shows the score stored each day by the daily snapshot. A change of pack version shows on the day it happened. Days on which the licence did not include the pack are drawn as a muted band and listed as Not evaluated — licence inactive, with their first and last day. They are never filled in later. A day with neither a bar nor a band is a day nothing was stored, for example because the daily snapshot did not run.

A pack not included in your licence

When the deployment licence does not include the pack, the screen shows it locked, labelled Not included in your licence, with its description and controls, no evaluation and no evidence package. Evidence already issued for it still verifies; new evidence cannot be issued. Contact your platform administrator to have it added to the licence. View the remediation plan opens its plan, read-only, and the trend below keeps the history recorded while the pack was licensed.

Downloading the evidence package

Download evidence package saves one ZIP file to give your auditor. It holds:

report.pdf: this evaluation as a report for people to read.
evidence.jose.json: the signed evidence, signed by the deployment with ML-DSA-65. This is the authoritative file.
cbom.cdx.json: the list of your tenant's live keys and their algorithms, as CycloneDX for inventory tools.
verification-keys.json: the public keys the auditor checks the signature with, offline.
README.txt and SHA256SUMS: what each file is, how to verify the package, and the checksums.

The signed evidence carries the report's fingerprint, so the one signature also covers the report. The report and the README are in the console's current language, English or Spanish. Pack titles and control statements stay in English.

The package is produced when you download it and is not kept; each download is a new package, recorded in your audit trail. The console saves it exactly as the server sent it.

If the download fails, the problem is shown beside the button with a retry. A tenant with too many live keys for one package is refused as too large. The service prepares one package at a time; when it is busy with another, the console shows how many seconds the server asked you to wait before trying again.

Downloading the files on their own

The package is the download to give an auditor. Below it, Individual files offers two of its files on their own, for an auditor who asks for them separately:

Download signed evidence saves the signed evidence alone, compliance-evidence-<packId>-<day>.jose.json.
Download verification keys saves the deployment's public verification keys, compliance-evidence-verification-keys-<installationId>.json.

The package already carries both. Hand the verification keys to an auditor through a channel other than the evidence: a key that arrives with the evidence cannot prove who issued it. If a download fails, the problem is shown with the server's detail and Retry. Both downloads need the same permission as the package.

History integrity

For the NIST CSWP 39 pack, the evidence-integrity item fails with The stored evaluation history fails verification when a stored history of your tenant no longer verifies, and does not apply with No evaluation history is stored yet before the first daily snapshot. A tenant with no live key still sees this item, but it does not count towards the score, which stays Not scored.

How it relates to other screens

Compliance Evaluations lists every evaluated pack, Compliance Pack shows the pack's definition, Key Inventory opens a key the evaluation names, and Remediation Plan turns the findings into actions.