For each third-party API, record how your product behaves when the vendor is slow or down: the timeout, whether calls retry, what the fallback is, what the user sees, and who decides to switch it off. Writing this down before an outage turns an emergency into a planned response.
Why it belongs in an inventory
Security thinks about confidentiality, but availability is part of the same risk. A product that hangs for 30 seconds when an analytics call fails has a vendor dependency that nobody listed. A security inventory that lacks this field cannot help in an outage or in an attack that targets a vendor.
The failure behavior fields
| Field | Example question |
|---|---|
| Criticality | Does the core user journey stop without it? |
| Timeout | How many seconds before we give up? |
| Retry rule | How many times, and with what delay? |
| Fallback | Cached data, a default, a second provider, or nothing? |
| User impact | What message or degraded feature does the user see? |
| Kill switch | A flag or config that disables the call without a deploy |
| Decision owner | Who may turn the kill switch? |
| Last tested | Date of the last failure drill |
How to find the current behavior
- Read the client code. Look for timeout settings, retry loops and error handlers around each call. Some SDKs set their own defaults that you never see.
- Check the SDK documentation. Note default timeouts and retry behavior.
- Test in staging. Block the vendor hostname at the network layer and watch what the application does.
- Ask the owner. Compare their answer to what you saw.
You will probably find calls with no timeout and retry loops that make a bad situation worse. Retrying a payment call without protection against duplicates is one example to look for, and the safe approach depends on the vendor's design.
Group by criticality
Sort integrations into three groups. Those that stop the core journey need a tested fallback or an explicit decision to accept downtime. Those that degrade a feature need a clear user message and a timeout. Those that are invisible to users, such as telemetry, should never block a request.
Link to security events
If a vendor reports a compromise, your first safe move may be to disable the integration. That is only possible if a kill switch exists and someone knows they may use it. OWASP's guidance on inventorying integrated services and their role in the system is the natural home for this information.
Try it yourself
The demo shows continuous monitoring. Think about which signals would tell you that a vendor call has started failing, and add that to your row as the detection method.
Click through it at your own pace, or open it full screen.
Quick check
Should analytics calls ever block a page?
No. They should have short timeouts and fail silently so they cannot stop the user's task.
How often should I test failure behavior?
For critical integrations, at least yearly, and after major changes to the client code or vendor API.
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.
