For systems a vendor runs, shift from scanning to oversight: keep an inventory, set minimum practices by contract, ask for evidence of the vendor's own vulnerability handling, watch public advisories for the products involved, limit the vendor's access to your data, and reassess on a schedule based on risk.
What changes and what does not
When software is hosted by someone else, the vendor patches the servers. You cannot run a scanner against them, and you should not try without permission. But you remain responsible for the customer data and the service you promise your own customers.
The FTC Safeguards Rule, for the institutions it covers, asks you to oversee service providers by selecting and retaining capable ones, requiring safeguards by contract, and periodically assessing them based on the risk they present. New York's rule says similar things: policies for due diligence, minimum practices, periodic assessment and notice of cybersecurity events. This is general information, not legal advice.
NIST on shared responsibility
NIST's patch management guide suggests tracking, for each asset, the party who administrates it, including third parties, vendors and shared responsibility models. It also notes that using managed services instead of self-run software can reduce the patching burden, which is a reason many teams choose them.
A five step approach
- Inventory. List every vendor-run service, who owns the relationship, what data it touches and how it connects to your systems.
- Tier. Rank by data sensitivity and by how badly an outage or breach would hurt you.
- Ask. For higher tiers, request evidence: the vendor's security report, how it handles vulnerabilities and patches, how fast it notifies customers of incidents, and penetration test summaries.
- Watch. Subscribe to the vendor's advisories and check public sources for flaws in their products.
- Limit. Give the vendor only the access and data it needs, with scoped keys and logging.
Questions to ask
| Topic | Question |
|---|---|
| Patching | How quickly are critical flaws fixed on hosted infrastructure? |
| Disclosure | Is there a public advisory process and a security contact? |
| Testing | When was the last independent penetration test, and are summaries shared? |
| Notice | How soon will you tell us about an incident affecting our data? |
| Subprocessors | Which third parties handle our data on your behalf? |
| Exit | How do we retrieve our data if the relationship ends? |
What to put in your own vulnerability program
- A line in the policy stating that vendor-run systems are covered through oversight, not scanning.
- A register of vendors with tier, last review date and open concerns.
- A process for acting on vendor advisories, with an owner.
- Exceptions when a vendor cannot meet your minimums, with compensating controls such as reduced data sharing.
Your integration is still yours
Even when the vendor's platform is fine, your side of the integration can be vulnerable: libraries, SDKs, API keys, webhooks. Scan those. Safeguard's dependency scanning and SBOM generation cover the code you run that talks to vendors, which sits squarely inside your remit.
Quick check
Can we run a vulnerability scan against a SaaS vendor?
Not without written permission, and most terms forbid it. Ask for the vendor's own testing evidence instead.
Does a vendor security report replace our oversight?
It supports it. You still need to read it, check scope and dates, and track follow-up on any gaps.
Sources
- 16 CFR 314.4(f), Safeguards Rule oversight of service providers
- 23 NYCRR 500.11, Third party service provider security policy
- NIST SP 800-40 Rev. 4, sections 3.1 and 3.2
Last reviewed: 19 October 2026.
