Why 96 of our controls honestly report n/a
A compliance score you can defend beats one that looks good. Here's why we refuse to count a control as passed when no automated check actually ran.
There are 317 controls in AzureProof. 221 of them run a real Azure API check. The other 96 report
n/a. That is not a bug and it is not a roadmap footnote — it is the most important
number on our dashboard, and this post explains why.
The easy way would have been a fake pass
When a control has no automated check — say, a key-rotation procedure that only exists in a
runbook, or a SAS token lifetime boundary that is not readable through any API — the cheap move is to
return pass anyway and let the number look good. Every compliance vendor has done it at
some point, and every auditor has caught it eventually.
We did a full pass over our catalog and found exactly that pattern: controls that performed no
API call and returned a hardcoded pass. On a real run those inflated the score and
appeared as satisfied controls in the customer-facing evidence packet — even though nothing had been
checked.
What n/a actually does
When a control reports n/a, it is excluded from the score. It is not counted as
passed, and it is not counted as failed. The dashboard marks it for manual review, and the report
tells the auditor plainly that this control was not verified automatically. A number you can
defend beats a number that looks good — and an auditor can tell the difference in about thirty
seconds.
Why this is the honest choice
For a product whose entire value is trustworthy evidence, a fabricated trust signal is the single most damaging thing we could ship. The same rule applies to our marketing — no invented customers, no borrowed logos, no competitor claims — and to our engine. If a control cannot be verified, we say so.
The 96 n/a controls are not abandoned. They are the queue for the next batch of
detection work, prioritized by what auditors actually ask for. As each one gets a real, tested check,
it moves out of n/a and into the automated count — and the score only ever improves
because something was actually verified.
That is the whole philosophy in one line: we would rather show you a lower number you can defend than a higher one you cannot.
Get new posts in your inbox
One thoughtful email per month on Azure compliance. No spam.
See it in your own tenant
Connect a read-only service principal and run your first evidence collection the same day.
Start free trialKeep reading
A plain-language walk through the architecture behind AzureProof — the server-rendered frontend, the Node.js evidence engine, the PostgreSQL database with row-level security, and the read-only pipeline that talks to Azure.
Every deploy runs typecheck, 72 frontend and 689 engine tests, Trivy vulnerability scans, and a database security gate that rebuilds the schema from zero — then rolls back automatically if the health check fails.