Accounts
The accounts the vendor signs in with, shared logins included.
Third-party risk management services
See what your vendors can reach — and where your data goes.
How exposed you are to a vendor is decided on your side of the connection: the access the vendor holds in your systems, what its contract makes it tell you after a breach, and what stops if it disappears. We list what each vendor can reach, mark the access its job doesn't need, then read the contract against that list.
- Built from your own systems and records
- Contract gaps tied to real access
- We reply within one working day.
- NIST CSF 2.0, GV.SC
- NIST SP 800-161 Rev. 1
- RBI Managing Risks in Outsourcing Directions, 2025
In brief
- What it is
- Vendor risk management that starts from your side. We list the accounts, keys, grants, network paths and data flows each vendor holds, taken from your own settings and records, then read its contract against that list.
- Why it matters
- A questionnaire or a certificate shows how a vendor protects itself. It cannot show what the vendor can do inside your systems. Only your side can.
- What you get
- For each vendor: a connection list, the access it doesn't need, the places where one vendor or account sits behind several of your systems, the contract gaps marked beside the access they expose, and what stops if the vendor goes.
What we check
What a vendor holds in your systems, then the contract behind it.
Every connection a vendor holds began as a small approval on your side. These are the six things we check for each vendor.
API keys and tokens
The keys and tokens its software uses to reach yours, and who can rotate them (swap them for new ones).
SSO grants and app consents
Access given through your single sign-on (SSO) and app consent screens, with the scope of each: what it lets the vendor see or change.
Network paths
VPN tunnels, IP allowlists and other openings that let the vendor's systems reach your network.
Data flows
Which fields of your data leave, and who receives them next.
The contract
The terms on breach notification, sub-processors (other firms the vendor passes your data to) and termination, read against the list above.
Buying an AI product? The model behind the vendor raises separate questions, covered on AI vendor risk.
Why paperwork isn't enough
Vendor paperwork can't show what the vendor can reach in your systems.
A vendor can only answer for itself. Its file can be complete and still say nothing about your side of the connection.
A security questionnaire, a certificate and a trust page all describe how a vendor protects its own staff, offices and servers. That is worth having. Stopping there is the mistake. Two vendors with identical answers can carry very different risk. One can read a mailing list. The other can write to production, your live systems.
NIST SP 800-161 Rev. 1 splits the questions the same way in the sample scoping questionnaire it gives for supply chain risk assessments. Questions about the supplier's own affairs go to the supplier. Questions that settle how critical the supplier is go to the acquirer, which is you. Examples are whether the product has root access (full control) to IT networks, or connects to a platform your customers use.
So we keep the vendor's paperwork on file, and add the part it cannot supply.
Access outlives the project that granted it
An admin approves an SSO grant so a trial can start. A developer puts an API key in the build pipeline. An engineer opens a network path for a migration. Each made sense on the day, and a vendor with a clean SOC 2 report can still hold all three.
NIST SP 800-161 Rev. 1 says the access suppliers and service providers hold should be limited to the type, duration and level the work needs. Duration is the easiest to lose track of, because nothing breaks when a grant outlives its purpose.
How we work
We work outward from your systems to the vendor.
The contract reads properly only once you know what the vendor holds. So the list comes first and the paperwork second.
Build the connection list
We record what each vendor holds from your own configuration and records, so the list shows what exists rather than what was declared.
Set access against the job
We compare what each vendor's work needs with what it holds. Anything beyond that is over-broad access, and removing it needs nobody's permission but yours.
Look for shared paths
We check whether one vendor, grant or integration account sits behind several systems, where a single compromise or outage would reach all of them.
Read the contract against the list
We read the breach notification, sub-processor and termination terms, and mark each gap beside the connection it leaves exposed.
Walk through the vendor's exit
We trace the vendor going offline, being acquired or shutting down, and record what stops on your side in each case.
The breach clause
What a contract has to settle before a vendor incident.
A breach-notice clause only helps if the vendor's deadline to tell you starts counting early enough. For each term we read, here is the gap to look for and what closes it.
| Term | The gap to look for | What closes it |
|---|---|---|
| When the clock starts | Once the vendor has confirmed a breach | At the vendor's detection |
| What counts | Breaches of your personal data only | Any compromise of access it holds for you |
| What the notice says | That something happened | Which of your accounts, keys and data were in reach |
| Whose systems | The vendor's own and nobody else's | Its sub-processors' systems as well |
Where vendors handle personal data, see also GDPR compliance and DPDP Act compliance.
If the vendor disappears
What has to be in place before a vendor goes dark.
NIST CSF 2.0 covers this at GV.SC-10: supply chain risk plans that include what happens after a partnership or service agreement ends.
- A named fallback. For each critical vendor, another provider or the work done in-house. RBI's outsourcing directions require commercial banks and NBFCs to identify one in their exit strategy.
- An export that works. A copy of your data in a format another system can load, pulled once already to show the export works.
- A removal plan. An owner and an order for removing every account, key, grant and network path the vendor holds.
- Deletion in writing. Written confirmation of deletion from the vendor and from each sub-processor that held copies.
- A list of what stops. What stops on your side, with the decision about which parts can wait already made.
What this work does not include. SecWiz is not a certification body. We don't certify vendors or give them a single risk score, because a number would hide what each vendor can do inside your systems.
This is one part of risk management. To show your board which vendors sit behind the risks it already watches, see risk management as a service; to run supplier risk as an ongoing program, see GRC as a service.
FAQ
Questions about third-party risk.
Scope, priorities, vendor involvement and reviews. For anything else, ask us directly.
They cover any outside party that holds access to your systems or copies of your data, not only the suppliers your purchasing team pays. A support contractor with a remote session counts, and so does an agency with a login to your ad accounts. Each is assessed by the connection it holds and the contract behind it.
Rank them by reach rather than spend. Start with vendors holding admin rights in your identity provider (the system your staff sign in through) or write access to production, then those holding customer data, then those whose outage would stop something customers notice. A small tool with an admin grant belongs above a large contract with no access at all.
Only for what your side cannot show. A vendor can tell you which sub-processors receive your data, how it detects an incident and who would send the notice. Everything else, from the grants it holds to the terms it signed, can be read without involving the vendor, so the assessment does not depend on its goodwill.
Whenever the connection changes, and not only at renewal. A wider scope on a grant, a new API key, a new data feed, a new sub-processor or the vendor being acquired each changes what it can reach or who else can. Renewal is still worth using, because it is the one moment the terms can change too.
Third-party risk is the exposure created by the outside parties you deal with directly. Supply chain risk follows the chain further, to their own suppliers, sub-processors and the components inside what they deliver. The two meet at the connection: start with what a vendor can reach, then ask who else can reach it through that vendor.
No. SecWiz is not a certification body, and a single number would hide what matters: what each vendor can do inside your systems, and what its contract obliges it to tell you when something goes wrong. A vendor with a good score and an admin grant nobody reviewed can still be the riskiest name on your list.
Let's talk
Start with the vendor that can reach the most.
Tell us which vendors worry you, or which ones nobody on your team can account for. Project work is delivered remotely from India during business hours. We reply within one working day.