Free Cloud Audit: Compliance Findings Shown, the Rest Locked
A free audit only works if it shows enough to be believable and locks enough to stay free. ZopNight’s new cloud audit flow lets a visitor sign up, connect a cloud account with read-only access, and see the top findings from their own account.
Each recommendations section (Savings, Compliance, Risk and Advisory) lists its top findings with a count of how many more are locked. Request upgrade unlocks the full list and the rest of the product. Until then the organization stays read-only and is limited to two cloud accounts. Organizations on other plans see no change.
The one-window rule is the principle behind this. Each section’s visible findings come from a single ordered window. That same window applies to every place a finding can leave the system.
A Visible Window Is Ordered by Time, Then by Identifier
Each of the four sections has its own plan limit, and a fifth limit caps cloud accounts. A section’s window is ordered by the time a finding was generated, then by the finding’s identifier. The order is stable, so the same findings are visible on every load.
Stability is what keeps the lock honest. If the order changed between requests, a visitor could reload the page and read a different slice each time. With a fixed order, a reload shows the same findings and the same locked count.
The window is applied on every exit path, not only the list on screen.
| Where a finding can leave the system | How the window applies |
|---|---|
| Recommendation list and summary | Returns a locked block with the limit, hidden count and sections |
| Export | Same window as the list |
| gRPC reads | Same window as the list |
| Weekly digest | Same window as the list |
| Policy dispatch | Same window as the list |
| Ready email | Same window as the list |
The lookup of a plan’s limit fails closed. If the limit cannot be read, the answer is the restricted one, so an unknown limit never turns into an unlimited list.
The Audit Plan Is Granted Once, at Signup
The audit plan comes from a signup channel that is written once. It is granted only to an organization under an hour old that has no cloud account yet. An organization that already exists, or already has accounts, cannot move itself onto the audit plan.
Audit organizations are refused read-write access, provisioning and Azure tenant scope. The two account cap is enforced under a Redis fence, so two connections made at the same moment cannot both slip past it.
The ready email is triggered by the first sync finishing, not by signup. A visitor who connects an account is therefore told when there is something to look at, rather than opening an empty page.
This works because the plan marker is write-once. It would not hold if an existing organization could request the audit channel later, which is exactly the case the under-an-hour, no-account rule rules out.
Signup Is Built for a Visitor Who Has No Account Yet
A visitor arriving from a landing page has no existing setup to lean on, so the flow carries its own checks. A new test-connection endpoint lets a cloud account be tested before it is saved, and GCP keys are checked for the right shape before they are used.
Sign-in with Microsoft verifies a state value on the way back, and a phone number is optional on the signup form. None of this changes anything for organizations on other plans.
