A scan reports hundreds of high-severity findings. The infrastructure team has one approved maintenance window this week. The useful question is which few changes will reduce the most risk before that window closes.
Use exploit evidence and business context together
A severity score describes characteristics of a flaw. Prioritisation also needs to consider whether the asset is exposed, whether an exploit is being used, what the asset can access and whether a control already limits the risk. CISA’s known exploited vulnerabilities data and FIRST’s EPSS can inform the decision, but neither tells you whether a particular system is critical to your organisation.
How severe is the vulnerability? The base score describes intrinsic technical severity. Use it alongside evidence about the system and its exposure.
Read the CVSS referenceIs there evidence of exploitation in the wild? Check the Known Exploited Vulnerabilities catalog and confirm your affected asset and version.
Read the CISA KEV referenceWhat is the estimated probability of exploitation in the wild over the next 30 days? Use the score as one input alongside actual exposure and business impact.
Read the FIRST EPSS referenceHow CyberSeal gets findings to closure
CyberSeal’s Vulnerability Management as a Service covers asset discovery, contextual prioritisation, remediation guidance and verification. The team can help identify reachable assets, evaluate evidence and translate it into steps an IT owner can act on. The customer and CyberSeal agree who makes production changes, who owns exceptions, and which results need urgent notification or leadership review.
Explore CyberSeal’s Vulnerability Management (VMaaS).
If a finding comes from broad cloud IAM permissions or exposed storage, the fix may require a change to architecture or deployment templates. Explore CyberSeal’s Cloud Security Services.
From discovery to delivery
- 1 DiscoverReconcile scanned assets with the inventory and flag gaps.
- 2 ValidateConfirm the affected version, actual reachability, and existing protections.
- 3 PrioritiseCombine exploit evidence with the asset’s business importance.
- 4 RemediateAssign an owner and agree on a patch, configuration fix, or mitigation.
- 5 RetestVerify the original exposure is gone and check service health.
- 6 ReviewTrack overdue items, expiring exceptions, and repeat findings.
What CyberSeal VMaaS onboarding looks like
Kickoff and coverage. Bring your asset inventory, cloud account list, public domains or IP ranges you control, a recent scan if available, and the maintenance calendar. Include the people who own infrastructure, applications, security, and production changes. Agree which assets are approved for scanning and identify fragile systems, third-party boundaries, and exclusions that require separate approval.
Set up a representative baseline. Agree on safe scan windows and any approved credentialed checks. Start with a small sample to validate that the scanner can reach the intended assets, that credentials work where needed, and that findings map to the right owners. Record gaps separately. A failed check or an excluded subnet can make a clean dashboard misleading.
Agree how work reaches IT. Decide how findings enter your ticket queue and how quickly owners should acknowledge or address them. Set the urgent notification route for emerging vulnerabilities affecting your stack. Agree who approves a production change and who can accept residual risk. CyberSeal supplies remediation guidance and verification within the engagement scope, while authorised change owners approve and carry out changes as agreed.
Move into ongoing reviews. Review the first group of findings with owners and adjust how items are grouped and assigned. CyberSeal’s service describes monthly IT workshops to track patching commitments, alongside executive reporting on risk trends. Use the workshops to resolve blocked patches and recurring findings, and use the leadership report to surface decisions on overdue exposures and exceptions.
What to check: Track how long important exposures stay open and whether fixes are verified. The raw number of findings can rise simply because you discovered more assets.
Practical details and examples
Establish which assets can be measured safely
Vulnerability management starts with coverage. Agree what the service can see: public applications, cloud hosts, internal devices or other assets approved by the customer. Record who owns each group and where scanning is restricted. A production system with availability constraints may need a different testing approach from an internet-facing staging application. Make exclusions visible, with a reason and a date to review them, so the absence of findings does not look like evidence of safety.
Ask CyberSeal and your IT team to reconcile a small asset sample before agreeing the full schedule. Compare what the scanner sees with the customer’s inventory and check whether the findings can be traced to the people who can act on them. Where a cloud host is short-lived, use the information the environment makes available to identify the workload or build that produced it. Tracking the source configuration can be more useful than sending an owner a list of addresses that no longer exist.
Example: Two urgent findings, one maintenance window
Imagine a patch team can change only one system this evening. One finding affects an externally reachable service, appears in the known exploited vulnerabilities data, and has a clear path to important customer information. The other has a higher technical severity rating but affects an isolated test environment with a limited set of users. The customer still needs to review both, but the first may be the better use of the current window. Confirm actual exposure and exploit evidence rather than inferring either from the scanner label.
If the externally exposed service cannot be patched safely tonight, discuss an approved temporary mitigation, the remaining risk and the person who can accept it. Record when it expires and what will trigger escalation. For the other finding, record why it was deferred instead of leaving it to disappear from the report. This turns prioritisation into a documented decision. The result is a plan the owner can carry out and explain, even if the patch schedule changes or a different team takes over.
Example ticket for the first fix: Affected asset: public customer portal. Owner: application platform team. Evidence: affected version and confirmed external reachability. Action: apply the approved vendor patch. Verification: confirm the fixed version, retest the affected endpoint, and run a customer sign-in smoke test. If the patch must wait, document the mitigation, approver, and expiry.
Make every important finding actionable
A remediation item needs more than the vulnerability identifier. Include the affected asset or component, the evidence that it is exposed, the recommended fix or workaround, and a way to check whether the change worked. Use the customer’s normal ticket workflow where practical so the item reaches the right owner. Agree what details can be sent in an alert and what belongs in a restricted report. A useful notice should tell the owner whether to act now, prepare a change or gather more evidence first.
CyberSeal’s service covers guidance and verification. Decide which party performs patching or configuration changes and who approves production downtime. The customer may own change authority, while CyberSeal explains the technical risk and validates the result. Define what happens when an asset has no owner or a vendor fix is not available. Keep temporary exceptions separate from verified closures; a ticket being marked complete is not enough to show that the exposure went away.
Verify closure and prevent repeat exposure
Retest using an approved method. Check that the relevant version or configuration changed, the original path is no longer exposed, and the business service still works as intended. For image-based workloads, also check whether the upstream image or deployment configuration was corrected. Otherwise the next build may recreate the same exposure. If the original method cannot be repeated safely, agree an alternative verification method and record its limits.
Use ongoing reviews to look at how long critical items stay open, what causes them to reappear and where the customer needs help removing a delivery obstacle. A rising count may reflect better coverage, while a falling count can result from a scan failing. Review coverage and closure together. When the service transitions into steady operations, confirm the scanning schedule, remediation review cadence and the escalation route for important new vulnerabilities. The aim is to keep risk visible while making the volume of work manageable for the team that owns it.
What to ask before committing to VMaaS
Ask to see a sample remediation ticket and a retest record, with customer data removed. Ask who will explain a finding when a system owner disputes it, and what the review will show about exceptions and ageing issues. Share a recent maintenance calendar and identify the systems most sensitive to change. A useful proposal will account for both the organisation’s exposure and its ability to fix problems safely.
VMaaS SLA and remediation checklist
Use this checklist in a kickoff workshop or copy it into your ticket template. Fill in the owners and targets before the first scan.
- Coverage. Record the approved assets, scan schedule, last successful scan, and any exclusions with review dates.
- Priority. Record the affected asset and version, confirmed reachability, exploit evidence, business impact, and existing safeguards.
- Response targets. Define when the clock starts and set separate targets for acknowledgement, mitigation, and a permanent fix for each priority.
- Ownership and escalation. Name the fix owner, change approver, and escalation contact. Agree who acts when a deadline is missed.
- Exceptions. Capture the reason for delay, temporary controls, approver, and expiry date.
- Verified closure. Record the retest result, date, and service health check. Reopen the item if the original exposure persists.
Example: A confirmed, externally reachable flaw triggers an urgent notification. The owner acknowledges it within the agreed window, tracks a temporary mitigation separately if needed, and attaches the retest evidence before closure. Set the targets to match your team’s coverage and change authority.
Frequently asked questions
Is VMaaS the same as penetration testing?
No. VMaaS tracks exposures over time. A penetration test evaluates what an attacker could actually achieve within a defined scope.
Who installs the patches?
That is agreed during scoping. CyberSeal provides remediation guidance and verification; the authorised change owner performs or approves production changes.