Look in six places: DNS records, cloud and virtual machine accounts, department web hosting, grant and purchase records, the code repositories that deploy things, and your own memory of old projects. List what you find, assign an owner, and shut down whatever nobody claims.
Why forgotten systems are the real risk
You cannot scan or patch what you do not know exists. In research groups, forgotten systems pile up: a demo site for a paper, a test server from a student project, a virtual machine started for a workshop. Each one runs software that stops getting updates the day people stop caring.
An asset you forgot is also an asset nobody watches.
Six places to look
| Source | What to look for |
|---|---|
| DNS records | Subdomains pointing to servers or hosted services you no longer use |
| Virtual machine and cloud accounts | Running instances, storage buckets, databases started under lab accounts |
| Department or campus web hosting | Project pages, wikis, content management sites |
| Grant, purchase and account records | Servers, domains and subscriptions bought under project funds |
| Repositories | Deployment files, container definitions, CI configuration that publish something |
| People | Ask current and former members: what did you set up that is still running? |
The people question is often the most productive. A five minute conversation with a former student can reveal a server nobody else knew about.
Build one list
For each item record: name or address, what it does, who owns it, when it was last updated, who can reach it, and what data it holds.
Then sort it:
- Still used and owned: keep, and add to your scan schedule.
- Used but ownerless: assign an owner this week.
- Unused: shut down, after taking a backup.
- Unknown: isolate or turn off, and wait to see who complains.
Option four sounds harsh but works. If nobody notices within a month, the system was not needed.
Dangling DNS
A DNS record that points to a service you stopped using can be a problem on its own, because someone else may be able to claim the target. When you shut a system down, remove its DNS record at the same time, and add that step to a decommission checklist.
Make it repeat
Do this once each term. Keep the list in one place that outlives any single student. When someone sets up something new, they add it to the list. When someone leaves, they review their entries.
What scanning adds once you know what exists
After the list exists, a scan tells you what is wrong with each item. Safeguard includes asset discovery and dependency scanning, so you can find and then check what is deployed from your repositories. Start with the free scan on one project.
A short decommission checklist
When you do retire something, follow the same steps each time:
- Take a backup and note where it lives.
- Tell known users and give a date.
- Remove the DNS record and any certificates tied to it.
- Delete or archive the data according to your institution's retention rules.
- Remove the entry from the list and record the date.
Doing this in order avoids the two classic mistakes: deleting data someone needed, and leaving a DNS record pointing nowhere.
Warning signs that something is forgotten
A few clues suggest a system has no owner: nobody can say who created it, the last login was over a year ago, the software version is several releases behind, or the page still advertises a conference that has already happened. Any one of these is a prompt to ask around. Two or more is usually enough to schedule a shutdown with a clear date and a backup.
Quick check
Is it safe to just turn off an unknown server?
Back it up first, then power it down rather than deleting it. If nothing breaks in a month, remove it.
Who should keep the list?
A role, such as the lab manager or research computing contact, not a single student.
Last reviewed: 19 October 2026.
