Vulnerability management and verified remediation

What CyberScan can establish

CyberScan’s public baseline is a configuration check. Connected launch modes support HostedScan SSLYZE and Pentest-Tools.com Website Scanner in light mode, using existing provider targets. Imported assessments retain the provider’s scope. The application does not turn an API connection into authenticated application testing, independent penetration testing or continuous monitoring.

Compare the assessment routes and their coverage, or read how the current application handles data.

Prioritise the service impact and the evidence

The NCSC treats vulnerability management as a way to validate software updating and secure configuration. Its guidance recommends triage using exploitation risk and the organisation’s business context. Start by checking the asset, the affected product and the relevant vendor advisory. A score can help organise work, but it cannot supply missing information about your deployment.

Attach the finding to a service the business recognises. Record whether it concerns a public customer portal, an administrative component or an asset that is no longer needed. If a provider owns the component, ask for the evidence it can supply and the decision it needs from you. Track an unresolved attribution or affected-version question explicitly.

Sources: NCSC: Vulnerability management (opens in a new tab); NCSC: 10 Steps — Vulnerability management (opens in a new tab)

Choose scanning and testing for the question

Automated scanners cover different assets, deployment models and test types. Check what ran, which checks were skipped and whether access restrictions reduced coverage. A penetration test is a separately scoped exercise and provides a point-in-time view of the tested systems. Neither a provider API key nor a completed public check establishes that application permissions or business logic were assessed.

Define closure before asking for a change. For an update, useful evidence may include the deployed build and the vendor’s applicable advisory. For a configuration change, retain the approved value and an observation from the correct endpoint. Where a suitable retest is unavailable, keep the item at the level the evidence supports, such as provider-confirmed or awaiting verification.

Sources: NCSC: Vulnerability scanning tools and services (opens in a new tab); NCSC: Penetration testing (opens in a new tab)

Four practical steps

1. Validate the finding’s context. Record the target, provider, scan mode, time, observed condition and coverage limits. Confirm which system and business service the evidence describes.
2. Decide priority and responsibility. Review the vendor advisory, exposure, service impact and available mitigation. Assign the technical owner and the person who can approve a disruptive change.
3. Make a controlled change. Keep the proposed action, approval, deployment evidence and rollback route together. Escalate a blocked fix to the accountable owner with its remaining risk.
4. Verify and review. Repeat a suitable check against the same scope. Record the actual outcome, unresolved limits and next review date. A failed or blocked retest remains an incomplete result.

Worked example: A reported version needs deployment evidence

Synthetic worked example. No real product, vulnerability, customer or scanner result is asserted here.

Vulnerability remediation and retest log

A blank CSV connecting findings, advisories, asset ownership, decisions, changes and retest evidence. Preserve the difference between provider confirmation and independently observed results.

Open in a spreadsheet application and replace the blank-entry rows with your own records. The template contains no findings, formulas or macros. Completing it does not upload it to CyberScan.

Common questions

Choose your next step

See how observations, limits and follow-up actions stay together, then choose a suitably scoped assessment.