Skip to contentAbout Fig Group

Vulnerability Scanning

Consolidate scanner output, prioritise by exploit likelihood, and track remediation.

The challenge

Does this sound familiar?

Multiple scanners produce conflicting data. Severity-only prioritisation misses actively exploited CVEs. Manual remediation tracking breaks under scale.

How Fig helps

Vulnerability Scanning with Fig

EPSS and CISA KEV Prioritisation

Vulnerabilities scored using Exploit Prediction Scoring System (EPSS) and CISA Known Exploited Vulnerabilities (KEV) data, not just CVSS severity. All decisions remain auditable.

Multi-Scanner Consolidation

Normalise output from multiple scanner sources into one consolidated portfolio view.

Fig Vulnerability Scanning platform view
Core Capability

Fig includes a built-in vulnerability scanner for external-facing assets. Each scan generates a structured report suitable for client delivery, audit submissions, or stakeholder review.

Governed Exceptions

Every accepted risk records who approved it, why, what conditions apply, the scheduled review date, and links to the risk register. Revocation tracked automatically.

Audit-Ready Evidence

Structured packs linking findings, remediation actions, ownership chains, and verification outcomes.

Audit-ready workflow

How Vulnerability Scanning becomes evidence

Vulnerability Scanning should not be treated as a standalone tool surface. In Fig it is part of a governed workflow: a signal is captured, an owner is assigned, a control or risk is updated, and evidence is retained so the organisation can prove what happened later.

Lifecycle

Where it sits in the operating model

The Protect phase is where this capability sits in the wider Fig operating model. Multiple scanners produce conflicting data. Severity-only prioritisation misses actively exploited CVEs. Manual remediation tracking breaks under scale. Fig turns that problem into a repeatable lifecycle so MSPs, risk teams, and auditors are not relying on static spreadsheets or ad hoc screenshots when a buyer asks for proof.

Evidence captured

What auditors and buyers see

For vulnerability scanning, useful evidence normally includes the triggering record, the affected asset or supplier, the control requirement, the assigned owner, the decision made, the timestamp, and the outcome. That evidence is mapped back to frameworks such as Cyber Essentials, ISO 27001, NIS2, DORA, GDPR, CMMC, and internal policy requirements where relevant.

Implementation checks

Four steps to roll this out

  • 01Define who owns vulnerability scanning and what events should trigger review.
  • 02Connect the relevant source systems so evidence is collected continuously.
  • 03Map outputs to the frameworks and policies that matter to the organisation.
  • 04Review exceptions, accepted risks, and overdue actions before audit or renewal.

Useful references

Independent sources buyers and auditors recognise

The exact evidence required still depends on your scope, risk profile, sector, and framework obligations.

Built for you

Who uses this?

MSPs & MSSPs

Multi-client, multi-scanner management with consistent workflows across CMMC, Cyber Essentials, and CS&R frameworks.

Learn more

Security & risk teams

Operational vulnerability work converts directly into compliance outputs. No duplicate effort.

Learn more

Compliance & audit

Programme effectiveness reporting linked to controls and risk registers.

Learn more

Common questions

Frequently asked questions

Which scanners does Fig integrate with?

Fig normalises data from Tenable, Qualys, Rapid7, Nessus, Microsoft Defender, and others. New scanner integrations are added monthly.

How does prioritisation differ from CVSS scoring?

Fig overlays exploit intelligence and asset context on top of CVSS scores to prioritise vulnerabilities that are actively being exploited in the wild.

How does Fig handle false positives?

Fig correlates scanner output with asset context, exploit intelligence, and configuration data to reduce false positives. Findings can be marked as accepted risk with documented justification, approval chains, and scheduled review dates.

Can we set different remediation SLAs per client or severity level?

Yes. Remediation SLAs are configurable per client, asset criticality, and vulnerability severity. Fig tracks SLA compliance and escalates overdue items automatically to the assigned owner and their manager.

Do we need to rip out our existing scanners to use Fig?

No. Fig sits on top of your current scanners and normalises their output into one view. You keep running the scanners you already have, and Fig handles consolidation, prioritisation, and evidence packaging.

What is the vulnerability governance workflow?

Fig manages vulnerabilities through a 9-state lifecycle: Reported, Triaged, Remediation, Remediated, Verified, Disclosed, and Closed. Each state transition is logged with a tamper-evident audit trail. This separates Fig from tools that just show scan results.

Next step

See Vulnerability Scanning in action.

Book a walkthrough tailored to your frameworks and tooling.