The necessary ones make the site work. The others measure which pages help and which ads bring the people who need DM11. Your choice, and you can revisit it from the footer.
VULNERABILITY MANAGEMENT
Almost every company that buys scanning discovers the same thing: finding is the cheap part. The report comes back with hundreds of items, the team fixes what it can, and six months later the same items are still there, now joined by new ones. Vulnerability management is the work that turns that report into a queue that moves, with an order set by business risk and someone accountable for chasing it until the item is gone.
This is routine work, not an event. It does not replace a penetration test, which proves what an attacker can do, and a penetration test does not replace this routine, which covers the whole year. Where a formal requirement asks for both, as PCI DSS does, they are engaged together and scoped separately.
Who runs the work
Vulnerability analysis with a Qualys Certified Specialist
CEH, Certified Ethical Hacker from EC-Council
CISA, information systems auditing
17 years of governance, risk and compliance
WHAT IT IS
Vulnerability management is the routine of discovering what is exposed, deciding what matters first, fixing it, and confirming the fix took. Each of those four stages fails for a different reason, and the one that fails most is not discovery. It is the prioritisation decision, because it needs someone who knows the business and has the authority to say the high-severity item can wait and the medium-severity one cannot.
This is the item almost everyone skips and the one that most undermines the rest. A report saying 94% of assets are up to date is reporting on 94% of the assets the scan could see, not of what the company owns. What falls outside is always similar: old network equipment, a system a supplier operates alone, a cloud environment bought by a department, and the machine nobody can claim. The first useful measurement is not the number of flaws, it is the gap between what the inventory says and what the scan found.
CVSS is a public scale describing how serious a flaw is in the abstract, and it is good at exactly that. What it does not know is where that system sits in your company, what it holds, whether it is reachable from outside, and whether anyone is exploiting it right now. A medium-severity flaw on an exposed server holding customer data beats a high-severity flaw on an isolated lab machine, every day. Ordering the queue by score alone is the most common way to spend a year fixing things that do not move the risk.
The first is technical severity, which CVSS gives you for free. The second is business criticality: what that system supports, and what happens if it stops or leaks. The third is whether the flaw is being exploited in the real world, because an old flaw with known exploitation is more dangerous than a new theoretical one. Only the first arrives ready from the tool. The other two depend on the inventory and on a conversation with whoever operates the environment, and that is what separates vulnerability management from a scanner subscription.
We do not publish deadline numbers because they are not ours to publish: the company, together with whoever runs its IT, decides how long each severity can wait. What DM11 does is help reach an agreement that survives daily reality, with the exception criterion written down and a review date attached. The point is this: without an agreed deadline, remediation competes with today's support ticket and always loses, and when IT is outsourced that agreement has to be in the contract or it does not happen.
WHEN IT MAKES SENSE
All three end in the same place: there is information about flaws and no process turning it into reduced risk.
The most common case. The tool was bought, it runs, it produces a report, and the report gets filed. Technology is not what is missing: what is missing is an agreed deadline per severity, an owner per item, and someone whose explicit job is to chase. Where IT is run by a third party, what is also missing is the contract clause that lets remediation compete on equal terms with today's ticket.
PCI DSS requires quarterly scanning from anyone processing card data, on top of the annual test. Large customers in due diligence ask how often the company scans and what it does with the result, and the second half of that question is usually the one without an answer. Here the deliverable that matters is not the report, it is the record that the queue was chased.
Cloud bought by a department, a new application every quarter, a supplier running an entire system, a merger that joined two networks. In that scenario the first useful deliverable is not the scan, it is the inventory: without it there is no way to know what fell outside, and every coverage percentage is a guess wearing the clothes of a fact.
TRANSLATING THE ASK
The four ways the ask arrives, with what each one means in practice and what changes the size of the work.
| What they asked for | What that actually means | What changes the size |
|---|---|---|
| We want to buy vulnerability scanning | Recurring discovery of what is exposed, with human review of the output to separate a real finding from a false positive. | The number and variety of assets, whether cloud enters the same cycle as the network, and whether there are environments only a supplier can reach. |
| We need a continuous programme | The whole cycle: inventory, discovery, validation, prioritisation, remediation tracking and measurement of what actually closed. | Whether an inventory exists, how many teams do the fixing, whether IT is in-house or outsourced, and whether deadlines per severity are agreed. |
| A customer asked for evidence that we remediate | What a third party will read is the record of the cycle, not the list of findings: what was found, what was fixed, what was accepted and on what grounds. | The period the requester covers, and whether exceptions must be formalised with an owner and a review date. |
| We want to prioritise better what we have already found | Re-prioritisation work over the existing backlog, crossing technical severity with business criticality and known exploitation. | The size of the accumulated queue, whether assets have defined owners, and whether there is any classification of what each system supports. |
None of these starts by buying a tool. Where one already exists, the work is usually making it pay off, and that is cheaper than replacing it.
STORIES
We change our customers' names with the same confidentiality that will protect your company later. The names change, the pattern of the problems repeats. Where a customer authorises it, we share named references in a conversation.
Financial services
The scan ran on schedule, the report came out and went into a folder. The infrastructure team fixed what it could between support tickets, with no defined deadline and no order anyone had decided. The items at the top were always the same, and nobody could say whether that was bad or normal.
We did not replace the tool. We built the inventory to find out what it was not seeing, assigned an owner per asset, and sat down with whoever operates the environment to agree deadlines per severity, with the exception criterion written down. The queue was then ordered by severity, system criticality and the existence of known exploitation, rather than by score alone.
Several items from the top of the old list moved down, because they sat in isolated environments, and medium-severity items on exposed servers moved up. From the third cycle onwards the average queue age started falling, and that is the number the board has followed since.
Technology
The quarterly report showed a high percentage of assets up to date, and the company presented that number in due diligence. What nobody had measured was the denominator: the scan covered the corporate network, and did not cover the cloud accounts opened by product teams nor the environment a supplier ran alone.
We reconciled the lists that already existed in different places, IT's, finance's and whoever signs the contracts, and the inventory began coming from the cloud account itself rather than a hand-maintained spreadsheet. What the supplier operates became a contractual conversation before a technical one: who scans, how often, who receives the result, and within what deadline they fix.
The percentage fell in the first report after the change, and that fall was the best news of the project: for the first time the number described the whole environment. The company stopped presenting coverage in due diligence and started presenting coverage alongside the measured gap against the inventory.
E-commerce
The quarterly scanning requirement was met, and then the auditor asked for something else: proof that the findings had been dealt with. There were four discovery reports and no record of remediation, of risk acceptance or of exceptions. What had been resolved was resolved, and nobody could show it.
We built the record of the cycle rather than another findings report: what was found, what was fixed and when, what was accepted and by whom, and what stayed as an exception with an owner and a review date. Confirmation that a fix had taken moved to a fresh scan rather than the word of whoever made it.
The next audit received the cycle record and asked for nothing beyond it. A side effect appeared quickly: with exceptions requiring an owner and a date, the number of informal exceptions fell on its own, because several existed only by never having been written down.
HOW WE RUN IT
What separates this work from a scanner subscription is that each stage produces a measurement, and the measurements tell you whether risk is falling or merely changing name.
It starts here because everything else depends on it. We map the assets, reconcile the lists that already exist in different places, IT's, finance's and whoever signs the contracts, and assign an owner per item. Only then does scan coverage mean anything, because it is measured against the inventory rather than against itself.
A reconciled inventory, with an owner and criticality per asset
What each system supports, so prioritisation has a basis
Environments currently outside the scan, listed with the reason
Coverage measured as the gap between the inventory and what the scan reaches
What starts being measuredThe gap between what the company owns and what the scan sees, as a number.
Scanning runs at the agreed frequency, and the output goes through human review before becoming a task. That review exists for a practical reason: a false positive delivered as a task burns the credibility of the team doing the fixing, and after two or three of them they start treating the whole queue as noise. What comes out of here is a validated list, not a tool export.
Recurring scanning, at the frequency agreed in the contract
Human review of the output, separating real findings from false positives
Critical findings reported outside the cycle, without waiting for the report
A record of what was discarded and why
What starts being measuredA validated list, with the false positive rate tracked cycle by cycle.
The stage that decides whether the year is well spent. We cross technical severity with asset criticality and with information about known real-world exploitation, and the queue comes out ordered by risk rather than by score. This is also where the deadline per severity is set, alongside whoever operates the environment, and the criterion for recording an exception with an owner and a review date.
A queue ordered by severity, business criticality and known exploitation
Deadlines per severity agreed with whoever operates, not published by us
Exceptions recorded with an owner, a reason and a review date
Routing to the responsible team, with the item already assigned
What starts being measuredEvery item has an owner, a deadline and a written reason for its position.
The stage that turns a report into reduced risk. We follow the queue until the item disappears from the next cycle, confirm through a fresh scan that the fix took, and measure what matters: average queue age, how many items closed within the agreed deadline, and how many reopened. That record is what auditors and customers ask for, more than the list of findings.
Confirmation through a fresh scan that the fix took
Queue age, items closed on time and items reopened, measured per cycle
A cycle report with what closed, what did not, and why not
A record ready for audit and for the customer questionnaire
What starts being measuredThe queue has a measured average age, and it falls from one cycle to the next.
HOW OFTEN
We do not publish a standard frequency or remediation deadline, because both depend on your environment and on an agreement with whoever operates it. These are the three factors that most affect cadence, and the first conversation already shows which one your company is in.
Where one exists, it sets the floor and not the ceiling. PCI DSS requires quarterly scanning from anyone processing card data, and large customers usually ask about frequency in the due diligence questionnaire. Outside a formal requirement, cadence is a choice, and the right choice depends on the two factors below.
A stable environment with few changes per quarter supports a longer cycle without losing anything. An environment where a new application ships every month, or where cloud grows on a department's decision, needs a shorter cycle, or the scan always describes an environment that has already changed.
This is the factor most people forget when choosing a cadence. Scanning faster than the team can remediate does not reduce risk: it grows the queue and the discouragement of whoever receives it. The cadence has to fit the remediation capacity, or the process produces reports instead of results.
FREQUENTLY ASKED
The questions that come up in almost every first meeting, answered without hedging.
No, and the confusion is expensive in both directions. Vulnerability management is year-round routine and answers what is wrong and in what order to resolve it. A penetration test is a periodic event and answers what an attacker can actually do, chaining flaws that looked small in isolation. One covers breadth, the other covers depth. Where there is a formal requirement, both are usually asked for: PCI DSS, for example, requires quarterly scanning and an annual test. The full comparison lives on the pentest versus vulnerability assessment page.
In most cases, no. The tool is rarely the problem: what is usually missing is an inventory to know what it is not seeing, an agreed deadline per severity, an owner per item, and someone chasing until the item closes. Making the existing tool pay off is cheaper and faster than replacing it, and it avoids starting the year on a migration project instead of a risk reduction project. If the tool does turn out to be the limit, that shows up as evidence rather than as an opinion.
No, and the reason is not commercial reticence. The remediation deadline is not ours to promise: the fixing is done by your team or your IT supplier, and a number published on a website would become a third party's commitment. What we do is help reach an agreement on deadlines per severity that survives daily reality, with the exception criterion written down, and then chase against that agreement. Where IT is outsourced, that agreement has to sit in the supplier contract, or remediation competes with today's ticket and always loses.
It solves a third of it. CVSS describes how serious a flaw is in the abstract, and it is good at that. What it does not know is where that system sits in your company, what it holds, whether it is reachable from outside, and whether anyone is exploiting it right now. A medium-severity flaw on an exposed server holding customer data beats a high-severity flaw on an isolated lab machine. The two missing pieces come from the inventory and from a conversation with whoever operates the environment, and that is what separates this work from a scanner subscription.
Four numbers, and none of them is the count of flaws found, which goes up when coverage improves and therefore makes a poor thermometer. We measure coverage, the gap between the inventory and what the scan reaches; average queue age, which shows whether it moves; how many items closed within the agreed deadline; and how many reopened, which exposes fixes that did not take. A fifth useful measurement is the false positive rate, because it predicts when the team doing the fixing will start ignoring the queue.
Both go into the same cycle, and they are exactly the ones that tend to fall outside and leave the percentage looking good by omission. In cloud, the inventory has to come from the account itself rather than a hand-maintained list, because silent growth today comes almost entirely from there. For what a supplier operates, the conversation is contractual before it is technical: who scans, how often, who receives the result, and within what deadline they fix. Without that in writing, the environment exists in your risk and not in your report.
It does, with a much smaller scope than the name suggests. In a small operation the big gain does not come from an expensive tool: it comes from knowing how many devices and services exist, switching on automatic updates wherever there is no reason not to, and having one person reviewing the output regularly. That alone takes most of the risk in this area off the table, because the common attack uses a known flaw, with a published fix, in software everyone has. The full programme comes later, when the environment justifies it.
A short conversation already shows how much of your environment today's scanning does not see, and what would have to exist for the queue to start shrinking. Where a tool already exists, the work is usually making it pay off.
Comparisons on this subject
See all 13 comparisonsCenter for Internet Security · versão 8.1, de junho de 2024 · accessed on
NIST, instituto nacional de padrões e tecnologia dos Estados Unidos · NIST CSWP 29, publicado em 26/02/2024 · accessed on
OWASP Foundation · edição 2025, primeira revisão desde 2021 · accessed on
PCI Security Standards Council · PCI DSS v4.0.1 · accessed on
This page is informational and describes how DM11 reads and applies the sources above. It does not reproduce the text of any standard, does not replace reading the official document, and does not replace an audit, a certification, an independent assessment or legal advice. Where a standard requires formal assessment, it is carried out by an accredited body, auditor or assessor, always separate from whoever did the preparation.