Targeted testing or a full assessment: deciding from the evidence

When an application changes after its penetration test, somebody has to decide what the change means for testing. Targeted testing takes days and answers one specific question. A full assessment takes weeks and answers every question again, until the next change. Leaving the change untested costs nothing today and leaves an open question for the next audit. This post sets out our method for that decision. It shows how to map a change to the OWASP testing guides and why the decision belongs in the record.

Five decisions about testing

In Vikax, your team records one of five decisions about a change.

Vikax records that production changed and keeps the evidence. It does not look for vulnerabilities, so none of the five decisions says the application is safe. Testing shows whether the change caused a problem, and your team records the outcome when the work is done. The seven outcomes are planned, completed, no security impact found, security issue identified, configuration regression found, known expected change and inconclusive. Decisions and outcomes cannot be edited or deleted.

Start with what the change touched

Four pieces of evidence show what a change touched. Read them in order.

How far the application has moved. Vikax compares production with the last assessment and reports one of six states, described in our post on assessment freshness. A Minor change sits outside the areas the assessment covered. Once an analyst confirms the scope, it usually ends in Keep monitoring. A Significant change sits inside those areas, so the question becomes which tested behaviour it affects. A Major change means the tested areas themselves have moved, and targeted testing may not be possible to scope.

The kind of change. Vikax names each kind of change, and each kind points at part of the assessment. Our post on what happens to a penetration test report the day after delivery covers which kinds tend to move first.

• A security header removed or changed, or a content security policy changed or widened, points at security configuration and client-side controls. If the assessment relied on that policy to stop an attack, test that protection again.
• A new third-party domain or an added external file points at client-side controls. A new script on the login page is code the assessment never tested.
• An API route added or removed points at API security and authorisation. New routes are untested, and a removed route may have taken a control with it.
• A form destination changed or a login flow changed points at authentication and session management. A form that posts somewhere new also needs its input validation tested.
• A feature flag changed points at business logic and at whatever the flag switched on.
• An API response structure changed points at API security and input validation, because every new field is a new input.

The release. Vikax groups changes into releases for each application and environment. Your team confirms the releases it planned and records its own change reference, such as a change number. Releases nobody confirms stay open for review. Vikax stores the reference as your team wrote it and does not check it against a ticketing system.

A planned release confirmed under its change reference is part of the evidence for the decision. A header update confirmed this way may reasonably end in No testing needed. An unconfirmed overnight change to the login page is a different matter, and an analyst should read it first. Confirmation shows that someone expected the change, and the reviewer still reads what it did.

The evidence before and after. Vikax shows the evidence from before and after the change, with the lines that differ. An analyst who reads that comparison can usually tell in minutes whether the change is cosmetic or structural. That reading is the core of the method.

Give the tester a scope from the OWASP guides

Targeted testing needs a scope a tester can act on. Vikax states that scope in the OWASP terms testers already use.

Vikax maps each change to the testing areas it touches. The areas are authentication, session management, authorisation, input validation, security configuration, client-side controls, file handling, business logic and API security.

Each area points at the matching section of the OWASP Web Security Testing Guide that a tester would open. It also points at the Application Security Verification Standard chapters that set the matching requirements. For API changes, the areas point at API1, API3 and API5 of the OWASP API Security Top 10, which in its 2023 edition are all authorisation risks. The guides renumber their chapters between editions (version 5.0 of the verification standard, published in 2025, reorganised them), so a tester should read the brief against the edition the engagement uses.

Vikax delivers the mapping as testing guidance, a brief for the tester. The brief sets what changed against what the assessment covered and lists the areas to test. A person still does the testing and decides what counts as a finding. The brief carries the evidence from before and after, since it is only as good as that evidence.

Targeted testing scoped this way stays small. A widened content security policy on the account page means testing that page's client-side controls and configuration, perhaps for a day. A new third-party script on the checkout means testing the client-side controls of the payment step, perhaps for two days. A full assessment prompted by either change would take weeks and mostly confirm what your team already knew.

When does a change need a full assessment?

Sometimes the last assessment has stopped describing the application. Three cases come up most often.

A major change. Examples are a rewritten login, a new API version, a new platform and the loss of routes the tester used. Vikax shows this state as Major change. Targeted testing needs stable tested areas to aim at, and here they have gone.

Accumulation. A dozen Significant changes over six months can add up to an application the assessment no longer describes. Your team tested or reviewed each one, and none crossed the line on its own.

Missing coverage. Checks on some pages have failed for weeks, and the state has shown Coverage incomplete ever since. Your team lacks the evidence to justify any smaller decision.

Each case still rests on evidence, and that matters when someone has to approve the cost. A request that lists twelve changes to the tested areas since March, with evidence, gives a budget holder something to approve. Vikax exports that record as PDF, HTML, JSON or ZIP.

External rules sometimes make the decision for you. PCI DSS v4.0.1 (requirements 11.4.2 and 11.4.3) requires penetration testing after any significant infrastructure or application upgrade or change. NIST SP 800-115 (Appendix C) recommends testing applications again when significant patches, updates or other modifications are made. Each organisation decides what counts as significant. A record of observed changes, each with its state, gives your team a defensible answer.

Keep every decision with its evidence

The last step is to record the decision and never edit it.

Vikax keeps a permanent history of each decision and its outcome. Each entry shows what your team decided, who decided it, when, and what came of it. A decision is written once. If it later proves wrong, your team records a new decision, and the old one stays. The outcome is written once too, when the testing is done. Neither can be edited or deleted, and Vikax keeps the audit log for at least 400 days.

The analyst who made a decision can read their own reasoning when the same kind of change returns. The tester commissioned for targeted testing receives the brief and the evidence behind it. Auditors and customers receive an export of what your team decided each time the application changed.

A penetration test describes the application on the day it was tested. Your recorded decisions show what your team did about the changes that followed. Vikax keeps each one with the evidence that led to it.