Why a calendar interval is only part of the answer
An assessment describes systems under the conditions and methods used at the time. The next day, a team may publish a new service, change a firewall rule or install a component with a newly disclosed weakness. A date in the calendar does not respond to those events by itself.
For a UK business, the useful planning question is how long a meaningful exposure could remain unnoticed and who will act when it is found. More frequent discovery may reduce that delay, but only if coverage is reliable and findings reach an owner. Repeated reports that nobody reviews create activity rather than effective vulnerability management.
Keep three workstreams distinct: scheduled assessments establish recurring coverage; event-driven checks respond to a changed risk; retests verify remediation. Their timing should reinforce one another. Do not delay an urgent response until the next scheduled report simply because that report is already booked.
What should determine the baseline schedule?
Exposure and accessibility
Internet-facing systems can be reached without an internal foothold, so changes to their exposure deserve particular attention. Identify the actual public services, remote access gateways, administration interfaces and cloud-hosted endpoints. An incomplete asset list makes even a frequent assessment unreliable.
Business impact and data sensitivity
Consider what failure would mean for customers, operations and information. A system holding sensitive records or supporting an essential process may warrant closer attention than a low-impact test environment. Internal systems can also be critical: public visibility is one factor, not the entire risk assessment.
Change rate and ownership
Frequent releases, infrastructure automation and multiple delivery teams can create exposure between scheduled checks. Assign owners who know when changes occur and can trigger targeted testing. A stable system still needs review because vulnerability knowledge and external dependencies change even when its own configuration does not.
Existing coverage and response capacity
Consider what patch management, configuration checks and recurring monitoring already reveal, and where their blind spots remain. The assessment schedule should address those gaps. Ensure the team can validate and remediate findings; do not solve a backlog simply by accepting a longer detection window without an explicit risk decision.
Document why the chosen frequency is appropriate and when it must be reconsidered. The National Cyber Security Centre’s vulnerability-management guidance treats asset knowledge, prioritisation and ongoing review as parts of a wider process. It does not make an arbitrary assessment interval appropriate for every organisation.
Events that should trigger an additional review
A trigger does not always require repeating the entire previous assessment. Identify what changed, which controls or assets are affected and what evidence is needed. Expand the scope when the change reaches beyond the initially identified component.
| Event | Question to answer | Possible response |
|---|---|---|
| New public application or service | What is now reachable, and is its configuration appropriate? | Targeted external assessment and relevant application testing before launch |
| Major configuration or identity change | Have access boundaries or permissions changed? | Review affected services, roles and connected paths |
| Newly disclosed vulnerability | Do we run the affected component in a relevant configuration? | Establish applicability, prioritise remediation and verify the response |
| Migration or acquisition | Which systems, owners and trust relationships are new or uncertain? | Refresh asset discovery and assess the changed environment |
| Remediation completed | Does the original failure remain possible? | Retest the finding and related conditions |
Give internet-facing changes a clear owner
A new subdomain, temporary support interface or altered network rule can expose a service that was absent from the last inventory. Make discovery and review part of the release or infrastructure-change process. Record what should be reachable so an unexpected exposure can be recognised rather than treated as normal.
External checks and internal configuration information answer different questions. An external assessment observes the accessible surface; an internal owner may be needed to confirm deployment details, compensating controls or a vendor-supported fix. Do not conclude that a vulnerability is absent solely because an unauthenticated scan could not establish the software version.
An External Vulnerability Assessment can establish a defined view of public exposure. For migrations, compare the old and new environments where authorised: obsolete endpoints and parallel systems may remain reachable after the main service has moved.
Respond to vulnerability information without waiting for the next scan
When a relevant advisory appears, first establish whether the affected product, version and configuration are present. Use a maintained asset inventory and supplier information alongside technical checks. Where exploitation is reported or the potential impact is serious, prioritise investigation and protective action according to the evidence.
A scanning tool may not yet have a reliable check for a newly disclosed issue. A missing alert therefore does not settle applicability. Equally, a product-name match alone does not prove vulnerability. Document what is confirmed, what remains uncertain and who is responsible for resolving that uncertainty.
Assessment frequency is not a patching deadline. Routine updates and urgent remediation should follow the organisation’s risk-management process, with relevant vendor guidance and operational safeguards. Avoid leaving a known exposure open merely to obtain a more dramatic testing result.
Recurring monitoring, assessment and penetration testing
Recurring monitoring helps identify changes and new signals over time. Its practical value depends on the assets observed, check frequency, alert quality and response process. “Continuous” should not be interpreted as every asset being examined every second or every weakness being immediately detected.
A periodic assessment provides a defined review with analysis, prioritisation and stated coverage. It may investigate signals that monitoring cannot resolve on its own. Continuous Vulnerability Monitoring should therefore complement planned assessments rather than replace them.
A practical framework for setting and reviewing frequency
- Define the asset groups. List public infrastructure, sensitive applications and other relevant systems, with owners and known dependencies.
- Describe the consequences. Record the information, permissions and business processes at risk if a control fails.
- Choose baseline coverage. Set an assessment interval and methods for each group, explaining the rationale and known blind spots.
- Set event triggers. Include launches, material changes, migrations, relevant advisories and significant changes to exposure.
- Assign the response. Decide who triages findings, approves remediation priorities and records risk decisions.
- Plan verification. Reserve a route for retesting and track findings until evidence supports closure.
- Review the plan. Adjust frequency and coverage when missed assets, repeated findings or organisational changes show that the current process is insufficient.
The plan should identify its owner and next review date. If a scheduled assessment is postponed, record the coverage gap, temporary measures and rescheduled activity. An unexplained missed date should not silently become the new operating model.
Hypothetical example
A fictional retailer changes its public storefront regularly, while a separate supplier portal changes less often. Both use synthetic data in the testing examples. The business decides that one identical schedule would ignore their different change patterns.
For the storefront, it combines recurring exposure monitoring with targeted checks after new public services or material infrastructure changes. For the portal, it retains a planned periodic assessment and adds testing when access roles or supplier workflows change. The exact intervals are recorded by the business after considering impact and available coverage.
A critical vendor advisory affecting either environment triggers an applicability review immediately rather than waiting for the next routine assessment. After a corrective change, a retest verifies the affected condition.
Use retesting and history to improve the schedule
A remediation ticket marked complete is not the same as evidence that the issue is fixed. Retesting should check the affected system and relevant conditions, with supporting observations and an outcome that distinguishes a full correction from a partial one. Where the same configuration is reused elsewhere, consider whether those assets also need verification.
Use findings history to review the process: which assets were missed, which weaknesses returned, how long ownership took to establish and whether important changes triggered checks. Raw finding counts alone can mislead because asset numbers, test methods and coverage may differ. Compare like with like before concluding that risk has improved or worsened.
What about contractual or regulatory requirements?
Some organisations have specific obligations arising from contracts, assurance schemes or sector requirements. Establish which ones actually apply and verify their current wording with the responsible owner. A requirement for a particular test does not automatically cover every other system or risk.
This guide does not prescribe a universal legal interval. Keep any applicable minimum requirement alongside the risk-based plan, rather than assuming that meeting a calendar requirement removes the need to respond to a new exposure. Record the scope and evidence needed so the commissioned work answers the real obligation.
Frequently asked questions
Is an annual vulnerability assessment enough?
It may leave significant gaps in a changing environment. Decide the baseline from risk and supplement it with checks after material changes and relevant vulnerability information. An annual date alone is not evidence of adequate coverage.
Should every business scan monthly?
There is no universally suitable monthly rule. Select check frequency and assessment depth for the systems involved, then document the rationale and review whether findings are being acted on.
Do we need another assessment after every small change?
Not necessarily. Use change impact to identify the security controls and assets affected. A minor content edit and a new authentication integration do not automatically require the same response.
Should we wait for an assessment before applying an urgent fix?
Do not delay a necessary protective action merely to wait for a routine report. Confirm applicability, follow an appropriate change process and verify the result.
Does monitoring replace penetration testing?
No. Monitoring can detect changes and certain weaknesses, while penetration testing investigates selected attack paths in greater depth. Agree the role and limits of each.
When should a fixed vulnerability be retested?
Once the relevant remediation is implemented and the environment is ready for verification. Timing should reflect impact and residual exposure, with an agreed owner and evidence requirements.
AUTHORISED SECURITY TESTING
Build an assessment plan your team can act on.
Start with your public systems, change patterns and remediation priorities, then agree appropriate testing coverage and review triggers.