Readiness Score & Frameworks

How the Compliance Hub collects evidence for your audit against SOC 2, ISO 27001, HITRUST CSF, HIPAA Security Rule, PCI DSS, GDPR, CCPA/CPRA and NIST CSF. It tracks 146 controls across 8 frameworks. This is evidence for your audit; Zonitix itself is not certified against these standards.

Where This Page Fits

Three pages cover the Compliance Hub, one job each. This one is the readiness score and how evidence is stored. What is collected and when, evidence files and auditor access are on Evidence Collection. Control states, reports, the evidence vault and every endpoint are on Compliance Hub & Reporting.

Readiness Scoring & Audit Activity

The readiness of a framework is the share of its controls that pass right now: the controls passing, divided by the controls in scope, as a whole percentage. Every screen, report and saved assessment works it out with the same rule.

• In scope. Every control of the framework except the ones marked Not applicable. An N/A control neither raises nor lowers the score. An N/A recorded without a reason is still left out, and is labelled “N/A — justification missing” so that a report shows it.
• Passing. A control whose current state is a pass and whose evidence is still in date. Evidence the product collected goes out of date after 30 days if it is not seen again; a reviewed or attested pass after 365 days. A pass with out-of-date evidence counts as not passing until it is collected or attested again.
• In scope but not passing. A control that fails, has an exception or needs attention; one that is submitted and waiting for review; one with only part of its evidence; and one not started. All of them stay in the count of controls in scope, so each lowers the score.
• Nothing in scope. When every control of a framework is N/A, the score is 0.

Two figures come from that one sum. The ring on the Compliance Hub Overview shows verified readiness, which is the figure these docs call the readiness score: a pass counts only when the product collected the evidence itself, or when a person other than the one who submitted it reviewed it. A pass that one person attested, or that the submitter approved themselves, is shown beside the ring as self-attested, with the percentage you would have if those were counted. That second, wider figure, with self-attested passes counted, is the readiness that reports and saved assessments carry; how the server works it out again when an assessment is saved is under Score Recompute — The Integrity Control.

Audit events are a separate subject. They are reviewed in System → System Logs — a filterable, paginated table that re-reads itself every 30 seconds and has a refresh button (the circular-arrow icon; hovering over it shows Refresh Logs), not a live streaming feed. Its filters, export limits, how long entries are kept and forwarding to your own monitoring system are described in Audit Log & Log Forwarding.

Evidence That Refreshes Itself

Instead of spending weeks collecting compliance screenshots before an annual audit, Zonitix re-harvests evidence on a background timer, not only when someone opens the Compliance Hub; the schedule is on Evidence Collection. It creates timestamped, access-controlled reports confirming that user groups are audited, MFA is active for everyone, and all offboarded employees have had their access revoked.

If something here is not working as you expect, start with When something goes wrong.

How Evidence Is Stored

The compliance engine (`compliance-service`) harvests evidence from the platform’s services and stores it in Postgres, with uploaded artifacts written to an access-controlled storage volume. Access is gated by the manage_compliance permission, and reads are themselves logged.

• A harvesting session pulls the current state from each service and writes evidence rows; it sweeps every open audit record. When it runs is on Evidence Collection. Every record is timestamped and permission-gated.
• The central audit log is hash-chained in the database: a before-insert trigger serializes each row by its sequence number, and a daily off-box external anchor lets the chain be corroborated independently. A one-click integrity check returns a green or red verdict, and an auditor export is built in. This is tamper-evidence (tampering is detectable and provable), not a claim that the system cannot be attacked. The chain is described under Audit Log: The Tamper-Evident Hash Chain.
• Each report run stored in the evidence vault carries its own keyed tamper seal, which is checked when the run is downloaded; see Compliance Hub & Reporting: Evidence Vault, Share Links & File Verification.