I work in a fairly large organization with the number of the hosts reaching into the tens of thousands spanning accross every type of environment imaginable including dmz, QA, dev, trusted, user, and internet facing. The enterprise is constantly growing and changing and hosts are being put up and taken down constantly as we evolve, grow and update. This has lead to a little problem which I am still trying to solve. The problem occurs when some vulnerabilities are discoved on a machine which leads to the machine being decommissioned. This actually happens quite a bit because in developement and test environments, machines are put up for temporary reasons and they often stay up until there is a compelling reason to take them down. Qualys in many cases becomes the reason which is good for me because it gives me much needed leverage to get folks to clean up after themselves and it drives them to comply because they don't like showing up in vulnerability reports. Now here's the problem. When remediation of vulnerabilities is performed by decommissioning a server, Qualys doesn't really recognize that remediation has occurred. Because the machine is unreachable, Qualsy cannot definitivly confirm that the vulnerabilities have, in fact, been resolved and so they remain open until the problems have A) been ignored or B) the host has been purged. We opt for option B because, if a machine is taken down,we may want to recycle the IP address and that requires a purge or you risk adding historical vulnerability data to a new machine. But the flipside is that when you purge you lose all the historical data - it's as if the machine never existed. This creates a problem during reporting (especially trending) because credit is not given for remediation if the remediation that was performed includes decommissioning the machine. This sounds like a very trivial problem but it adds up. In an extreme example - if you were to update an entire office with new desktops and you purged all of the old IP addresses for the old desktops, you would lose the ability to trend the effectiveness of your desktop patching program because you would not have a historical record of any remediation against your desktops. To date, the only way around that his that I know of would be to run some reports prior to purging and save them off for posterity. I would estimate that we probably replace 10-20% of our inventory annually. So it would seem that our reports could be skewed to the same degree. Since our remediation efforts are driven by Qualys reporting, the reports are heavily scrutinized and they lose some of their authority when the numbers don't add up from month to month. Any ideas out there regarding this conundrum?