Re-scanning after a fix: how Veracly tracks compliance regression

The reason continuous monitoring exists is that the vast majority of compliance bugs are introduced after the original audit, not during it. A marketing team ships a new analytics pixel; a partner agency drops in a Hotjar tag for a campaign; a redesign re-orders the cookie banner with a different reject-all path. None of those changes touched the page that was originally audited, and all of them break compliance.

Veracly’s weekly re-scan plus score-drop alert is the answer. Here is how the mechanic works and how to investigate when an alert fires.

What the weekly re-scan covers

The same scope as your initial scan: every page in your configured page budget (fifty on Starter, two-fifty on Growth, five hundred on Pro). The scanner discovers pages from your sitemap and from internal links found during the crawl, so new pages you ship automatically enter the scan set as soon as they are linked from the rest of the site.

Every scan produces a full report — same structure, same rule set, same PDF. We keep the report history on your account so you can diff any two scans against each other.

What triggers a score-drop alert

We watch two signals per scan, per jurisdiction:

1. Score delta of 3 or more on any jurisdiction card. A 78 → 74 fires; a 78 → 76 does not. The dead zone exists because some compliance signals are stochastic: a third-party widget that loads slowly on one scan and fast on another produces a 1-point difference that does not represent a real regression.
2. Any net-new critical finding, regardless of score. A new pre-consent pixel firing, a new missing form label on a high-traffic page, a new broken accessibility statement — even if the overall score moves only a point, criticals are alert-worthy on their own.

The alert fires by email within 4 hours of the scan completing. On the Growth tier and above it also fires by Slack (configure under Account → Integrations → Slack). The dashboard shows the same alert as a banner on next login.

What an alert email contains

The email is short on purpose. Three sections:

• What changed: the jurisdiction, the score delta, the count of net-new criticals if any.
• What we think caused it: the top 3 new findings (with the URL the finding fired on and a one-line explanation).
• Where to go: a deep link into the dashboard’s scan-diff view for that pair of scans.

The dashboard’s diff view is the same data, expanded. It shows resolved findings (issues that existed in the previous scan and no longer do), net-new findings (issues introduced this scan), and persisted findings (issues present in both). Resolved is what you sent the alert email about; net-new is what to file.

Investigating a regression in under 15 minutes

One workflow that works:

1. Open the alert email, click the diff link. The dashboard shows the net-new findings list.
2. Look at the affected URLs. If they are clustered on one page or one path, the regression came from a change on that page. If they are spread across many pages, the regression came from a global change (a layout component, a CDN-loaded widget, a CMP configuration change).
3. Check the deploy log for the same window. Most regressions are traceable to a specific deploy or marketing tag manager change in the previous 7 days.
4. File one ticket per new finding. The remediation appendix in the new report has the fix snippet, same as the first scan.
5. Trigger a re-scan after the fix lands. Do not wait for next week’s scheduled scan — an on-demand re-scan from the dashboard takes 5–15 minutes depending on site size.

The patterns we see most often

Across the regressions we have alerted on in the first hundred customer accounts, three patterns account for the majority:

• New tracking pixel added without consent gating (about 40% of regressions). A marketer adds a Meta Pixel via Tag Manager; nobody on the team noticed it was firing pre-consent.
• Redesign introduced a focus trap or a low-contrast color (about 25%). The new design passed visual review; the accessibility regression was invisible to anyone not using a screen reader or contrast checker.
• Cookie policy went stale (about 15%). A third-party tool was added or removed, but the cookie policy page was not updated to match. This is the regression that gets flagged in regulator follow-ups more than any other.

Tuning the alerts

If the default 3-point delta is too noisy for your site (large sites with lots of third-party widgets sometimes oscillate within a 5-point band), the threshold is configurable per site under Account → Sites → [domain] → Alerts. We recommend tuning it after observing two or three normal-state weekly scans rather than at signup.

The critical-finding trigger is not tunable. A new critical is always worth knowing about, regardless of how often it happens.

See also: Reading your first Veracly report · The top 10 issues Veracly finds and how to fix them