Vendor dependency review

Review external services and dependencies

Discuss data, permissions, failure behavior, ownership and exit planning before adding an external dependency.

Prepare the conversation

Topics to discuss

The dependency has a clear purpose and an internal owner for configuration, renewal and replacement decisions.

Data sent to the provider is known and unnecessary sensitive fields are excluded where possible.

API keys, OAuth scopes, admin roles and connected actions follow least privilege for the actual workflow.

Administrative access, MFA options and account-recovery ownership are understood.

Operational logs, provider retention and local copies are understood well enough for support and privacy decisions.

The system behavior is understood if the provider is slow, unavailable, rate-limited or returns invalid data.

Important API, model, pricing, policy or platform changes have an owner who can assess their technical impact.

There is a known path for provider incidents, account compromise or urgent support when that dependency is critical.

Important data/configuration can be exported or recreated and replacement assumptions are documented where practical.

Provider secrets are stored and rotated using a controlled process rather than embedded in code or shared casually.

Material subprocessors, hosted components or secondary dependencies are considered when they affect data or continuity.

A failure, suspension or accidental configuration change has a documented recovery or fallback approach where needed.

Use WhatsApp, phone or email to discuss these topics and agree the next step. Keep passwords, API keys and recovery codes out of your message.