Continuous assurance
Broad, repeatable coverage of what is exposed, run on a cycle, with the output triaged by someone rather than emailed to you as a CSV.
A penetration test answers a question about a moment in time. It is deep, it is manual, and you do it once or twice a year. In between, your estate keeps changing: someone stands up a server, a dependency ships a CVE, a firewall rule gets widened for a deadline and never narrowed again.
Vulnerability assessment covers that gap. It is broader and shallower than a penetration test by design, and the value is not in the scanning, which is commodity. It is in the triage: deciding which of four thousand findings are reachable, which are already mitigated by something else, and which twelve actually need doing this month.
What we do
Authenticated and unauthenticated assessment across servers, network devices, and the perimeter. Authenticated scanning finds substantially more and produces far fewer false positives, which is why it is worth the effort of arranging credentials.
Assessment of what is actually installed and actually patched across your fleet, against what your management tooling reports. The gap between the two is a normal finding rather than an unusual one, and it is the gap an assessor will find if you do not.
Posture checks across cloud accounts and subscriptions: public exposure, over-broad identity, unencrypted storage, and logging that was never turned on. Distinct from adversarial cloud testing, which asks what someone could do with what is exposed.
See also: Cloud Architecture Assessment
The part that makes the rest useful. Findings are assessed against your environment: whether the affected service is reachable, whether a compensating control already covers it, and what it would actually cost an attacker. A prioritized list of twelve is actionable in a way a list of four thousand is not.
Following findings through to closed rather than reporting them and moving on, including verification that a fix worked. Recurring assessment produces trend data, which is usually the first evidence a board sees that the programme is working.
Most frameworks require vulnerability management as an operating process rather than an annual event, and require you to show it running. The output is produced in a form an assessor accepts.
See also: Compliance Readiness
Process
Establish what is in the estate, which is frequently the first accurate inventory an organization has. Anything not in the inventory does not get assessed, so this step decides the value of every one after it.
A first full pass to establish where you are starting. This one is usually uncomfortable and is meant to be: it is the number every later cycle is measured against.
Findings assessed against your environment and reduced to a prioritized list. Volume is not the deliverable.
Your team fixes, or we do, depending on the engagement. Fixes are verified rather than assumed.
A cycle agreed to your risk and your change rate, monthly or quarterly for most organizations, with trend reporting across cycles.
Deliverables
Every engagement produces documentation you can hand to an auditor, a customer, or your own board without translating it first.
The common starting point is a tool nobody reads the results of. That is a triage problem rather than a tooling one.