If you find an unknown third-party integration in production, do not delete it first. Identify what it is and who added it, check what data it receives, then decide to keep it, restrict it or remove it. Whatever you decide, add it to the inventory so it stops being unknown.
Why not delete immediately
Unknown does not mean unused. The call might power a checkout step, a nightly export or a compliance report. Removing it blind can cause an outage and teach teams to hide integrations. The goal is understanding in hours, not a blame hunt.
The exception is evidence that the integration is malicious or sending data to a destination nobody could plausibly have approved. In that case treat it as a security incident and follow your incident process.
Six steps
- Capture the facts. Hostname, first and last seen dates, which service or page makes the call, request volume, and the version of any SDK involved. Save logs before anything changes.
- Find the origin. Search the repository history for the hostname or package, check who added the dependency or config, and check vendor dashboards for accounts created with company email addresses.
- Identify the owner. Ask the likely team, with the facts. The answer is usually a trial that became permanent, a leftover from a former colleague, or a connector in a tool someone adopted.
- Assess the data. Inspect a sample request, using a safe test environment where possible, to see which fields leave. Compare against your data classes. OWASP lists a sensitive data flow with no approval, no inventory and no visibility of what is shared as a blind spot, so these are the questions to answer.
- Decide. Choose from the outcomes below and set a date.
- Record it. Create the row, with owner, purpose, data classes, credential location and the decision. Note how it was discovered, so you can improve the discovery method.
Decision table
| Situation | Outcome |
|---|---|
| Needed, owner found, data appropriate | Keep and document |
| Needed, but sends more than necessary | Restrict fields, narrow scopes, then document |
| Needed, vendor not reviewed | Keep temporarily with a review date, ask privacy and security to assess |
| Not needed or owner cannot be found | Disable in a staging window, watch for breakage, then remove and revoke credentials |
| Suspicious destination or unapproved data flow | Handle as an incident |
Close the loop
Ask why it was missed. Maybe there is no pull request prompt, maybe the integration came through a browser script or a no-code tool, or maybe the team did not know where the inventory lives. Fix the cause with one change, such as a check in review or a periodic comparison against outbound traffic.
Do the removal properly: revoke API keys, delete webhook registrations at the vendor, close accounts if appropriate and update the data flow map. Requests to a vendor to delete data are a privacy matter, so involve your privacy lead.
Quick check
Should I block the traffic right away?
Only if you have evidence of harm. Otherwise identify the owner first, since blocking can break a live feature.
How fast should this happen?
Aim to identify the owner and the data sent within a day or two, and to set a decision date within a week.
Safeguard offers SBOM and dependency scanning and asset discovery that can feed this kind of inventory. You can run a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
