Auto-Delete Rules vs Archive Rules for VR

[micahbugbee5593]

I see that in a production instance, they have been using Archive Rules to clean out VITs closed over 90 days ago.  As a result, the Archive Vulnerable Item table has compiled over 118 million records over a period of 14 months.  I also do not see any Archive Destroy Rules for this archive vulnerable item table.  I would imagine this will have a negative impact of performance of the instance. 

So my question is, are there any best practice recommendations for instead using a VR auto-delete rule using the same closed over 90+ day window?  Could there be a reason to use archive instead for audit purposes?  I greatly appreciate any feedback!

[Hemanth M · Accepted solution]

Hi @micahbugbee5593 ,

It wouldn't really affect day today instance performance(not involved in transactions, queried) however, accumulating 118 million records is not best practice (unless there are strict multi year audit requirements). It may cause issues during upgrades, BD size, instance backups etc.

I would suggest checking with your GRC/IRM team regarding audit requirements:

• If they only care about the current state or 90-day trends, disable the Archive Rule and enable the VR Auto-Delete Rule.
• If not, apply an Archive Destroy rules (maybe set to 180 or 360 days) to the existing Archive Rule (or you can adjust this based on your requirements).

For the already accumulated records, once confirmed with your GRC team, Architect and Platform Owner, you can apply either a Table Cleaner or a scheduled job to delete them.

Hope it helps!

[Shahjay]

Hi @micahbugbee5593 ,

Adding to @Hemanth M's answer — agree with the overall approach, a couple of points to add:

On the “archive vs delete” question: this is really an audit/retention question, not a platform one. If GRC/IRM only needs current exposure and a short closed window, turn off the Archive Rule and enable the VR Auto-Delete Rule instead (note: it ships inactive by default with a 365-day closed-age threshold, so someone has to deliberately turn it on — worth checking that’s not why it was left on Archive in the first place). Make sure Cascade Delete is enabled on the rule so detections and the VIT-to-vulnerability-group M2M records get cleaned up along with the VIT itself, otherwise you’ll end up with orphaned child records.

If GRC does need the closed records retained for a year or more, keep the Archive Rule but pair it with an Archive Destroy rule on the archive table (180–365 days depending on your retention requirement) — otherwise the archive table just becomes the new 118M-row problem instead of solving it.

One thing to flag before touching the existing 118 million records: once you’ve agreed the retention window with GRC, your architect, and the platform owner, get the delete-criteria fields (state, closed date) properly indexed before enabling Table Cleaner / auto-delete at that volume. The Auto Flush job runs hourly against that criteria, and an unindexed query at 118M rows can hurt performance on the very table you’re trying to fix. If you’re not sure about the indexing or the job impact, raising a case with ServiceNow support first is a reasonable step. The Data Management Console (Zurich) is a good place to manage this going forward — it gives you visibility into archive/destroy rules, Table Cleaner jobs, and backlog metrics for this table in one place, rather than flying blind.

Same logic (retention-driven archive+destroy vs. straight auto-delete, cascade for child records, index before bulk-deleting a large backlog) applies if you’re seeing similar growth on Application VR, Container VR, or Configuration Compliance tables.

If this helped, please mark it Helpful / Accept as Solution.
Thanks

[micahbugbee5593]

Thanks for the detailed responses!  I will find out what GRC/IRM data retention requirements are for auditing and adjust accordingly