Threat Report History: Recheck, Monitor, and Reuse Evidence

Threat evidence changes. A domain can move to new infrastructure, an IP can be reassigned, a URL can disappear, and a hash can gain new detections after your first lookup. The useful question is therefore not only “what did we see?” but also “what changed, and what decision follows?”

The isMalicious Reports workspace gives previous lookups an operational next step. Filter the history, run a fresh check, add a supported entity to monitoring, create a case, or export a lookup index for analysis and record keeping.

NIST SP 800-61 Rev. 3 connects effective detection, response, and recovery with cybersecurity risk management. A searchable history supports that connection by helping analysts revisit evidence instead of rebuilding an investigation from memory.

Treat History as an Investigation Index

The Reports table records the target, resolved entity type, and lookup time. It is best understood as an index of analyst activity, not a substitute for the full report or a forensic evidence vault.

Use the filter to answer practical questions:

• Have we checked this domain or IP before?
• When was the last lookup?
• Which entity type did the product resolve?
• Is there already a related investigation path?
• Which records should we recheck or export?

This is faster and safer than searching browser history, chat threads, or personal notes. It also gives the next analyst a shared starting point.

Use Check Again for Current Evidence

The Check Again action opens a new lookup for the selected target. That distinction matters. The original date tells you when the earlier investigation happened; the new report tells you what is visible now.

When comparing the two moments, examine:

1. whether the verdict or risk level changed;
2. whether new sources now detect the entity;
3. whether registration, hosting, or resolution data changed;
4. whether related infrastructure appeared;
5. whether the entity still overlaps with the affected asset or incident.

Do not reinterpret an old decision using new evidence without preserving the timeline. Record that the conclusion changed and state which observation caused the change.

For an unknown indicator copied from a message or alert, start with Smart Lookup. If the event contains several related indicators, keep their scope visible in a composite report.

Monitor Only When Change Matters

The Watch action lets you add a supported report entity to monitoring. Use it when a future change would alter a real decision, for example:

• a suspicious domain linked to an open phishing investigation;
• an IP communicating with a critical asset;
• supplier infrastructure under active review;
• an indicator associated with a recurring campaign;
• an entity that is currently unknown but high impact.

Avoid monitoring every target you check. A list of monitored items without a reason becomes another noisy feed. Define the trigger before adding the entity: a verdict change, a new detection, new infrastructure, or a deadline for reassessment.

Review monitored entities from Alerts, then prioritize changes that require a response in the Action Center.

Create a Case When the Work Expands

The Case action creates an investigation linked to the report entity and includes report-based evidence. This is the right move when the finding needs more than a single lookup.

Move into Cases when you need:

• a named investigation with a priority;
• several pieces of evidence;
• a timeline of decisions;
• work shared by multiple people;
• an outcome that must survive a shift change.

Keep the case question specific. “Investigate example.com” is a start. “Determine whether example.com delivered the credential-harvesting page reported by Support and identify affected users” gives the team a scope and an exit condition.

Export a Reusable Lookup Index

Eligible plans can export report history as CSV or JSON from the dashboard. The export is intentionally compact: report ID, target, entity type, and creation timestamp.

Use CSV when an analyst needs to sort, filter, or reconcile the index in a spreadsheet. Use JSON when a script, notebook, or internal workflow will consume it. Because the export is an index rather than the complete report payload, retrieve or recheck the full report before making a current threat decision.

The isMalicious API guide explains how to automate fresh lookups. For larger input sets, follow the bulk lookup guide instead of manually opening every historical row.

Build a Weekly Evidence Review

A short weekly review keeps history useful:

1. Filter for indicators related to active incidents and priority suppliers.
2. Recheck records whose evidence can change quickly.
3. Add only high-value entities to monitoring.
4. Convert expanding investigations into cases.
5. Export the index if another team or workflow needs it.
6. Delete records that no longer serve a legitimate operational purpose under your retention policy.

The final step is often missed. Evidence retention should be intentional. Keep what supports investigation, compliance, lessons learned, or an active intelligence requirement. Remove what has no continuing purpose according to your organization’s rules.

Preserve Decisions, Not Screenshots Alone

A screenshot captures an interface at one moment. It rarely captures the query, entity type, source context, analyst conclusion, and later action in a reusable form.

Report history provides the retrieval path. A fresh report provides current evidence. Monitoring provides change detection. Cases provide the durable investigation record. Used together, these features let a team revisit a target without losing why it mattered in the first place.