THE SHORT ANSWER
Review what a vendor can access, why access is needed, how it is authenticated, whether actions are logged, how incidents are communicated, how access is revoked and what happens to data when the relationship ends. Apply scrutiny in proportion to potential impact.
Ask before connecting
- Which data and systems can the vendor access?
- Which permissions are essential?
- Can access be limited and revoked?
- Who controls vendor admin accounts?
- How are important incidents communicated?
- Can data be exported or deleted at exit?
- What operational dependency remains if service fails?
Include plugins, agencies and API connections
Third-party risk is not limited to major cloud contracts. Browser extensions, plugins, automation connectors, contractors and dormant tokens can hold significant access.
Review, change and exit
Maintain an owner and inventory, reassess high-impact access, remove unused connections and complete offboarding for people, tokens, data and accounts.
Turn guidance into an owned business action
Choose one relevant account, system, data set or workflow. Record the owner, current control, most important failure, detection signal, response step and recovery dependency. Escalate specialist, legal or regulatory questions to qualified advisers for the applicable context.
Sources & further reading
- The NIST Cybersecurity Framework 2.0
National Institute of Standards and Technology. Current outcome-based guidance for governing, identifying, protecting, detecting, responding to and recovering from cybersecurity risk. It does not prescribe one implementation.
- Authorization Cheat Sheet
OWASP Foundation. Security guidance emphasizing least privilege, deny-by-default behavior and authorization checks on every request. Implementation details depend on the application's threat model.
Examples and exercises are illustrative unless attributed to a source. No independent expert review is claimed.
A correction, a counterexample or an experience worth sharing?
Join the conversation ↗