Compliance

Compliance reads your register against the frameworks that apply to your organisation, tells you which evidence satisfies which control, and bundles the lot for an auditor.

For: Reads your register against applicable frameworks and bundles the evidence an auditor will ask for.
Will not: It does not send anything, make the breach determination, scan machines, or claim coverage it cannot show. Encryption state, classification and regulatory scope are fields you or an integration fill in.
Writes: It writes evidence reports, an audit evidence pack and audit samples to files you choose; nothing leaves the Mac.

What the portal is for

It answers one question: what will an auditor ask for, and do we have it.

The screen is headed Compliance Portal, with your organisation’s name under it. It is built from a profile: your industry, your jurisdiction, and the kinds of regulated data your machines handle. From that profile Manifest derives a programme, which is the frameworks that apply to you, the controls inside them, and the evidence reports that satisfy those controls. Everything else on the page is that programme, rendered.

Until a profile exists the portal shows one card, Set up your compliance profile, with a Start setup button. The same flow is reachable afterwards from Edit profile in the header, and re-running it re-derives the whole programme. A change of jurisdiction, or a new category of data landing on the fleet, is a profile edit rather than a rebuild.

The Compliance screen showing the summary card with framework and control counts, the applicable framework chips, the Audit Evidence Pack card and the evidence reports list. — The portal with a profile in place. The counts under the header are derived, not typed: change the profile and they change with it.

Twelve frameworks exist in the catalogue: ISO/IEC 27001:2022, ISO/IEC 19770-1, NIST SP 800-53 Rev 5, NIST SP 800-88 Rev 1, NIST CSF 2.0, CIS Controls v8, Hardware Asset Management (HAM), SOC 2, PCI DSS 4.0, the HIPAA Security Rule, GDPR and Sarbanes-Oxley. You will not see all twelve. The chips under APPLICABLE FRAMEWORKS are the ones your answers derived, and the three figures above them are how many that is, how many controls across them your evidence covers, and how many reports the programme requires. A US technology company that takes card payments and holds EU personal data, and no health data, lands on nine.

The fifteen evidence reports

Each row in the list is a report you can produce on its own, without building the whole pack.

Every row shows the report title, a one-line purpose, a coverage badge and a count of the controls it satisfies. The download button at the end of the row generates that report alone. Clicking the row body expands it to show the derivation behind the badge in full, then every control the report maps to, listed as framework, control number and requirement. The badge is a one-word claim; the expansion is the arithmetic behind it.

Report	What it holds, in the app’s own words
Complete Hardware Inventory	Every asset with serial, tag, owner, location, classification, criticality, and lifecycle status, the foundational inventory.
Asset Assignment & Acknowledgement Register	Who holds each asset, when it was assigned, and their acknowledgement of acceptable use / custody.
Media Sanitization Certificates	Per-disposed-asset NIST 800-88 record: method (Clear/Purge/Destroy), tool, operator, and verification.
Disposal Authorization & Chain of Custody	Disposal requests with an independent authorizer (segregation of duties) and custody transfer trail.
Overdue Physical Verification	Assets whose last physical verification is past policy. Proves inventory accuracy is maintained.
Unassigned / Orphaned Assets	Assets with no current owner or never assigned. Surfaces unauthorized / unaccounted-for hardware.
Audit Trail / Change History	The change log, what changed on each asset, by whom, and when, over a chosen period.
End-of-Life, Warranty & Refresh Forecast	Warranty expiry, end-of-life, and recommended refresh dates for lifecycle and budget planning.
Classification & Criticality Register	Each asset’s data classification and criticality tier, the basis for risk-based controls.
Regulatory Scope Register	Which assets are in scope for each regulation (CDE, ePHI, CUI, EU personal data), the basis for PCI scoping, HIPAA/GDPR data-mapping, and segmentation evidence.
Encryption & Recovery-Key Register	Per-asset encryption state, method, verification, and recovery-key escrow. Data-at-rest protection.
Acceptable-Use Policy Attestation	Each user’s acceptance of the acceptable-use policy (version, date). Distinct from device receipt.
Fixed-Asset & Capitalization Register	Capitalized vs. expensed assets with acquisition cost and useful life, the IT fixed-asset register.
Lost / Stolen Device Incident Register	Lost/stolen device incidents: type, dates, containment, and the data-at-risk determination.
Breach Notification Log	For incidents requiring notification: the regulatory deadline, rationale, and when notice was sent.

The evidence reports list with one row expanded, showing the coverage derivation and the controls it maps to. — A row expanded. The derivation sits above the mapping, because the claim should be readable before the list of controls that depends on it.

When a report is saved the confirmation appears at the top of the list rather than the bottom. With fifteen reports the bottom of the card is below the fold, and a confirmation nobody scrolls to is the same as no confirmation. The message names the file, and how many rows it holds.

An empty report still saves. An auditor asking for the breach notification log is entitled to a file that says there were none, and a header-only CSV is that answer. The status line says Nothing on file to report out loud, so an empty file is never mistaken for a failed export.

Reading the coverage badge

Three states, plus an honest fourth for the moment before it knows.

Ready. The population this report reads exists, and every field an auditor expects to find on that population is filled.
Partial. The report generates, but the evidence behind it is absent or has holes. This is the honest answer for an empty register, and for the sample workspace, and neither is special-cased.
Planned. Not generated at all. This one is a fact about the report type rather than about your data: it means the generator has not been written. Every report in today’s catalogue generates, so nothing you own should read Planned.
Checking. What the badge says before the first assessment lands. It is deliberately not a coverage. A badge that answers before it knows is worse than one that admits it does not.

Badges are re-derived whenever the register changes. The tables behind them are observed directly, so an import, an integration sync, an automation rule or a manual edit all cause a recomputation without any of those paths having to remember to ask. An import that commits in a burst is assessed once at the end of the burst rather than once per row.

If the register cannot be read the badges stay blank rather than falling back to something optimistic. From where you are sitting, a stale badge and a hardcoded one look identical.

The Audit Evidence Pack

One file, when the auditor asks for everything.

Generate Audit Evidence Pack opens a save panel and writes a zip holding the full inventory, the audit trail, the sanitization certificates and the worklists, along with a manifest mapping every artifact to the controls it answers. The manifest is the part that matters: it turns a folder into an index, so you are handing over an answer rather than a pile.

While the pack assembles, the card carries a spinner. When it lands, a status line names the file. If it fails, the same line carries the error rather than a dialog you have to dismiss before reading it.

Drawing an audit sample

A draw an auditor can re-run and get the same machines.

Draw Audit Sample… sits beside the pack button and opens a sheet with three controls: a sample size between 1 and 500, a scope, and a seed.

Scope narrows the population before the draw: All active assets, In cardholder data environment, Holds ePHI, Holds EU personal data or Encrypted devices.
Population in scope shows how many assets the current scope matches, so you can see the draw is against the fleet you meant before you make it.
Seed makes the draw reproducible. The same seed against the same population gives the same sample, to you and to them.

Draw & Save… writes two files: the sample as a CSV, and a manifest beside it recording the seed and the population. The manifest is what makes the draw checkable. Without it the CSV is a list of machines with no account of how they were chosen, which is exactly the thing sampling is supposed to rule out.

Open incidents

A lost or stolen machine appears here, with its deadline, until somebody closes it.

Each row carries the asset tag, the incident type and the status. Where a breach notification is required and none has been recorded, the row also carries the deadline, which is why this card sits on the portal rather than inside the asset record. Clicking a row opens the investigation; Close closes the incident.

The investigation holds the facts, the data-at-risk determination, the breach notification determination, the response timeline and the resolution notes. The asset tag in its header is a button that takes you to the machine in Assets. The determinations arrive pre-filled from the asset’s regulatory scope and encryption state, with Re-run suggestion from asset scope to derive them again if the asset has changed since. The suggestion is a suggestion: the toggles are yours, and the rationale field is where you say why.

Closing an incident does not record a notification. They are separate acts, and a closure with no notification date is recorded as exactly that. The breach notification log exports what was recorded, so a file shipping inside an evidence pack never asserts a regulatory action nobody performed.

What it will not do

The deliberate gaps, because an auditor will find them anyway and it is better that you know first.

It does not send anything. Every artifact is written to a file you choose. Nothing leaves the Mac as part of producing evidence.
It does not make the breach determination. Scope and encryption produce a suggestion; the toggles and the rationale are yours, and the rationale is what gets read.
It does not scan machines. Encryption state, classification and regulatory scope are fields on the record, filled by you or by an integration. Nothing here inspects a device to find out.
It does not claim coverage it cannot show. A report with no evidence on file reads Partial, in your register and in the sample one alike.