How to tell how far production has moved since the last penetration test

Assessment freshness is how far production has moved since a penetration test, measured by checking the application from the outside. It describes the application against one specific assessment, and it changes whenever the application changes. This post defines it and sets out what an outside check can see and where it stops. It then describes six plain states for reporting it, with Vikax as the worked example.

What assessment freshness measures

An assessment goes out of date when the application it describes no longer matches what a visitor reaches today. The comparison looks at the application itself and leaves the report's findings aside. It covers the pages in scope, the headers they return, the scripts they load, the routes they expose and the forms they present. It also covers the structure of the data each API returns.

An assessment of an application that has not moved is still current, however old it is. An assessment of an application whose login page was rewritten last week is out of date, however recent it is.

Two practical points follow. First, your team has to measure freshness against evidence, because a date only tells you when the test happened. A twelve-month cycle, the longest interval PCI DSS v4.0.1 allows between penetration tests (requirements 11.4.2 and 11.4.3), says nothing about freshness on any given day of those twelve months.

Second, freshness needs a fixed point to measure from. Without a record of what the test observed, your team has nothing to compare production against. Freshness then falls back to the age of the report.

Vikax uses a record of what the assessment covered, sealed when the assessment ends. The record states what was in scope and gives a reason for anything left out. Once sealed, the record cannot be edited or deleted. Routine clean-up never removes the evidence the record relies on.

What you can check from outside the application

An outside check sees what any visitor can request: headers, pages, scripts, API responses and documents. That is only part of what a tester saw.

A monitor can read the response headers an application sends. Those include the headers an assessment relies on most, such as the content security policy and cookie attributes. It can read the HTML of a page, including the scripts it loads and where each form sends its data. It can read the JavaScript itself, which is often where a new API route or feature flag appears first. It can read the structure of the JSON an API returns and the text of PDF documents. Vikax repeats these checks on a schedule your team sets, from every 5 minutes to once every 7 days.

Form submissions, private networks and the server's internals all stay out of reach. Pages behind a login are within reach only when your team stores a request header for the monitor to send. An outside check therefore measures freshness for the parts a visitor can reach. The assessment covered more than that, and any report on freshness should say so plainly.

The limit also keeps the check safe. The monitor only reads, and it stops each check at 25 MiB or after 30 seconds. It connects on ports 80 and 443 and refuses private network addresses. A read-only check sends only requests that should not change the application's state. The OWASP Web Security Testing Guide describes many active techniques for a tester. A monitor should use none of them.

A plain state says more than a percentage

With a fixed record in place, it is tempting to express the difference as a number. A percentage would mislead for two reasons. A change to the login page matters far more than a change to a footer link. Anyone who saw the figure would also read it as a security rating.

Vikax reports one of six states instead. Each state traces back to the pages and changes behind it.

• Stable. Production still matches the assessment record. Nothing in scope has changed once routine noise is set aside.
• Minor change. Production has changed outside the tested areas, or in parts the assessment did not rely on.
• Significant change. The changes touch what the assessment covered. Examples are a header the test relied on, a script on a page the test examined or a route the test exercised.
• Major change. The tested areas have changed shape. Routes have been added or removed, or the login flow has been rewritten. The assessment now describes a different application.
• Coverage incomplete. Some checks could not run, so the comparison covers only part of the application. It counts as a state because a gap in the evidence is a fact worth keeping.
• Not compared yet. No comparison with the assessment record has run yet.

Each state measures how far the application has moved since the assessment. Vikax never turns the states into a security score. The gap between Significant change and Stable is a fact about the application. What that gap means for risk is a judgement for an analyst. Vikax therefore shows every state beside the evidence behind it.

Which changes count, and which are routine noise

Comparing two versions of a page produces differences. Vikax then names the kind of change behind each one. As of October 2026, Vikax names fifteen kinds of change, shown below in six groups.

A kind of change is a hint for triage. It tells an analyst what sort of thing happened, so the analyst can decide quickly whether it matters. Vikax never presents a kind of change as a vulnerability or a finding.

Vikax also groups the changes it sees into releases. Your team confirms the releases it planned and records its own change reference against each one. Releases nobody confirms go to review. A planned release can still move production a long way from the assessment, so whether a release was planned and how far it moved production are separate questions.

Some content changes on every visit and means nothing. Left alone, it would turn every comparison into a change and make freshness impossible to measure. Vikax ignores routine noise such as timestamps, session IDs and tracking parameters when it compares. The stored evidence stays exactly as observed. Your team can add rules for other routine content, such as a personalised greeting. A rule can apply to the whole workspace, one client, a tag or a single monitor.

Rules change the comparison only. Vikax stores the page exactly as it was received and compares a filtered copy. For pages in a sealed assessment record, both versions carry a tamper-evident reference, so a reviewer can check later which was which.

What freshness tells you, and where it stops

Freshness tells your team whether the assessment still describes the application. Your team needs that answer before it can decide how far to trust the assessment.

Security is a separate question. An application can match its assessment exactly and still be badly broken, if the test missed something. Another can have moved a long way and be fine, if every change was harmless.

Coverage is a separate question too. Parts of the assessment that needed internal access stay beyond any outside check. A product that claimed to measure them would be claiming too much.

Freshness also guides testing. It shows your team which tested areas a change touched, which is where any testing starts. Vikax records the team's call as one of five decisions. They are Keep monitoring, Review first, Targeted testing, Full assessment and No testing needed. Each decision stays with its evidence and cannot be edited or deleted. The next post in this series explains how to decide on targeted testing or a full assessment.

Finally, the date on the report says little about freshness. An assessment from March can describe production better than one from last week. Your team can only tell by keeping the assessment record and checking production against it on a schedule.