Your posture score dropped 3.33 points. Here is what moved it, and who.
A Zscaler posture score is only useful if it moves and explains itself. ZHERO tracks the trend, attributes every point to a change, and projects the next one.
A configuration assessment gives you a number that was true on the day somebody ran it. A posture score is only worth managing if it moves, explains itself and can be projected forward. In ZHERO the Zscaler posture score is a candlestick trend, every movement is reconciled against your audit logs, and staged changes show their impact before you apply them.
The hidden cost of a number that was true on Tuesday#
The expensive part of a configuration assessment is not the assessment. It is the gap afterwards.
You get a report, it is accurate, everybody agrees on the findings, and then the tenant keeps changing. Three weeks later somebody adds a firewall rule for a project, somebody else widens a bypass to unblock a meeting, and the number in the report quietly stops being true. Nobody notices, because nothing in the process was built to notice. The next assessment, six months later, discovers the drift and the cycle restarts.
That is what a score is supposed to fix, and a score that only exists at assessment time does not fix it. It just makes the photograph nicer.
It has a trend, and the trend is a candlestick#
Score history in ZHERO is not a line chart. It is a candlestick chart, the kind you would read on a trading screen.
The reason is that a daily average hides exactly what you want to see. A candle shows the open, the close, the high and the low of that day, so a tenant that dropped four points at 11
and got them back at 16 looks different from a tenant that sat still. You can zoom down to the hourly view to find the single movement that matters, and ZIA and ZPA are tracked separately, because they are usually different products with different owners.Over a quarter, the trend is also the only honest answer to “is the program working”. A rising line on your own tenant is a better board slide than any benchmark.
It explains itself#
A trend without attribution just relocates the mystery. So every movement is reconciled against your Zscaler audit logs.
That is a real drop on a real tenant: 65.13 down to 61.8, minus 3.33 points. The MOVED
BY section breaks it down template by template. Allowing QUIC traffic on a firewall rule
cost 3.15 points on its own. A potentially useless firewall rule cost 1.66. The QUIC
exposure analysis added 1.59. Two unreachable policy assignments took the last half point
between them. Underneath, the change itself: a CREATE on an object called Firewall_10, and
the admin who made it.
One firewall rule, created for a perfectly reasonable local reason, moved four separate analysis templates at once. That is the part nobody can work out by hand, and it is the difference between “the score went down” and “here is the rule to look at”.
First it waits, then it tells you#
The alert arrives in two steps, and the first one is the interesting one.
When the number starts falling, ZHERO says so, and says that it is still verifying the drop against the recompute wave. The card resolves on its own if the drop was noise. Only when the regression is confirmed does the second card arrive with the attribution.
We built it that way on purpose. An alerting system that cries wolf during a recompute gets muted within a week, and a muted alert is worse than no alert, because everyone believes it is still watching.
It projects#
The same machinery runs forward as well as backward.
Stage a change and the gauges show a projected number in blue next to the current one, per product and overall: on this tenant, Global from 65.13 to 66.45 and ZIA from 82.19 to 85.49 once the queued changes land. You read the posture impact before you apply, which also turns the projection into a prioritization tool: stage the candidates, compare what each one is worth, do the one that moves the number most.
This is the other half of the change management loop. Changes are staged, reviewed and shared before they are committed, and now the review includes what they will do to your posture.
The number tells you how it was computed#
One detail in that screenshot matters more than it looks. Under each gauge there is the coverage: 61 of 61 templates for Global, 34 of 34 for ZIA, 27 of 27 for ZPA, plus a note where an extra check becomes available with OneAPI, and for the Client Connector vertical an “as of” date rather than a template count.
And in orange, spelled out: reduced by 4% due to low SSL inspection. The penalty is not buried inside the arithmetic where somebody will find it six months later and stop trusting the number. It is written on the gauge.
A posture score is a claim about your tenant. It should be auditable like one.
Not every movement is a configuration change#
The honest caveat, because it belongs in the same article and not in a footnote somebody discovers after the fact.
Most movements in the trend are configuration changes, and those are attributed precisely. But the score can also move for two other reasons. ZHERO’s own analysis evolves: when we add a template, the yardstick changes, and the score can shift without anybody touching the tenant. And the API coverage available at collection time affects what could be evaluated in that run.
This is why the trend and the attribution are read together, never separately. A movement with a named cause is a change in your tenant. A movement with no attribution is usually us, not you.
What changes for the person who has to answer for it#
Put the four together and the posture conversation stops being an event on a calendar.
Before a change, you know what it is worth. At the change, you see it land. After the change, if the number regresses, you know within minutes which rule did it and who created it. Six months of that, and the trend line is the evidence that the program works, or the evidence that it does not.
It is the same posture score described in the post on how the scoring works: ZIA, ZPA and Client Connector scored separately, every point explained by a finding. What the trend adds is time.
Frequently asked questions
Does every movement in the posture trend mean somebody changed a configuration?
No, and this matters. Most movements are configuration changes, and those are attributed to the exact change and admin. But the score can also move because ZHERO's own analysis changed (a new template means a new check, so the yardstick moved) or because the API coverage available at collection time was different. When you read a trend, read the attribution next to it before drawing conclusions.
How does ZHERO know which change moved the score?
The attribution engine reconciles each movement against your Zscaler audit logs. Opening a score event shows the templates that moved the number and how many points each one cost or gained, the change behind it, and the admin who made it, with a link into the exact audit entry.
Can I see the effect of a change before applying it?
Yes. When changes are staged as pending, the gauges show a projected score next to the current one, for each product and overall. You read the posture impact before you apply, not after, which also makes the projection a way to prioritize: stage the candidates, compare the projections, apply the one that moves the number most.
What happens when the score drops?
The alert arrives in two steps. First a card that says the score appears to be dropping and that ZHERO is verifying it against the recompute wave; that card resolves on its own if the drop was noise. If the drop is real, a second card names the cause: which templates moved the number, by how many points each, and which change and admin are behind it.
