Standing up a vendor risk program from scratch

If your current vendor risk process is "we emailed the CEO's brother who runs IT", this guide is for you. A modern, defensible vendor risk program doesn't have to be heavyweight — it just has to be repeatable.

Repeatable means the same vendor, reviewed by two different people, gets the same tier, the same questions, and roughly the same outcome. It means you can show an auditor or a customer why a vendor was approved, what you looked at, and when you will look again. If you need a refresher on the underlying concept first, start with our glossary entry on third-party risk.

Step 1: Inventory

You cannot manage what you cannot see. Start by listing every vendor with access to your data, systems, or physical premises. Pull this from procurement, finance, and SaaS management tools.

In practice no single source is complete, so triangulate:

Accounts payable and corporate card exports. Twelve months of payment data catches most paid vendors, including the ones someone expensed on a credit card.
Procurement and contract repositories. These show signed agreements, renewal dates, and the business owner who requested the vendor.
SSO and identity provider app catalogs. Every app connected to your identity provider is a vendor with access to user identities at minimum.
SaaS management or CASB tools. Useful for finding shadow IT that never went through procurement.
Cloud marketplace subscriptions and OAuth grants. Third-party apps granted access to your email, code repositories, or collaboration tools are easy to miss and often have broad scopes.
Engineering dependencies. Hosting providers, CDNs, email delivery services, monitoring and logging platforms, and payment processors that sit in your production data path.
Facilities and HR. Cleaning, security guards, payroll providers, background check firms, and benefits administrators often handle sensitive data or physical access.

Don't forget free tools. A vendor you don't pay can still hold your customer data.

For each vendor, capture a minimum record: legal name, service description, business owner, internal technical contact, what data it processes, which systems it connects to, contract start and renewal dates, and annual spend. Deduplicate aggressively; the same company often appears under a parent name in finance and a product name in SSO.

Finally, set a rule so the inventory stays current: no new vendor gets paid or connected to SSO until it has an inventory record and a tier. Tying intake to procurement or identity provisioning is the single most effective control in the whole program.

Step 2: Tier by risk

Not every vendor deserves the same scrutiny. Score vendors on two axes: criticality (what breaks if they go down?) and data sensitivity (what do they touch?). A simple 3-tier model works for most programs.

A three-tier model keeps the decision fast and defensible. The key is to write the criteria down so tiering is not a judgment call made differently by each reviewer. Our vendor risk tiering template gives you a starting model you can adapt.

Criterion	Tier 1 (Critical)	Tier 2 (Moderate)	Tier 3 (Low)
Data access	Customer personal data, regulated data (health, payment card, financial), credentials, or source code	Internal business data or limited employee personal data	No access to non-public data
System access	Production environment, network-level access, or privileged admin access	User-level access to internal systems or SSO-connected app	No system access
Operational criticality	Outage stops customer-facing service or revenue within hours	Outage degrades internal operations; workarounds exist	Outage is an inconvenience
Substitutability	Replacement would take months	Replacement would take weeks	Replacement would take days
Regulatory or contractual exposure	Vendor is a processor or subprocessor named to customers or regulators	Vendor is covered by internal policy only	No specific obligations
Typical examples	Cloud hosting, core payment processor, customer support platform with ticket data, identity provider	HR information system, project management tool, marketing automation	Office supplies, event venues, design tools with no customer data

The rule of thumb: a vendor takes the highest tier any single criterion puts it in. A low-spend tool with production database access is still Tier 1. Spend is a poor proxy for risk and should not drive tiering.

Record the rationale alongside the tier. When a customer or auditor asks why a vendor was Tier 2, "it only has SSO-level access to internal project data" is a better answer than a number.

Step 3: Run due diligence

For top-tier vendors, collect SOC 2 reports, ISO certifications, and DPAs. For middle-tier, a short questionnaire is usually enough. Low-tier vendors can be reviewed annually with minimal paperwork.

The table below turns that principle into a working standard.

Activity	Tier 1	Tier 2	Tier 3
Security questionnaire	Full questionnaire, or accept a completed industry-standard one	Short-form questionnaire	None; intake form only
Independent assurance	SOC 2 Type II or ISO 27001 certificate required; review the report, not just the cover page	Requested; accept if available	Not required
Data processing agreement	Required where personal data is processed	Required where personal data is processed	Not applicable in most cases
Penetration test summary	Requested	Optional	No
Business continuity and resilience	Review BC/DR summary, RTO/RPO commitments, and subprocessor dependencies	Confirm backups and uptime commitments	No
Financial and reputational check	Yes	Light-touch	No
Approval	Security plus business owner, with documented risk acceptance for any gaps	Security reviewer	Business owner
Reassessment	Annually, plus event-driven	Every two years, plus event-driven	At renewal or when scope changes

Questionnaires

Don't write a 300-question questionnaire from scratch. Two widely used industry formats cover most needs:

SIG (Standardized Information Gathering) from Shared Assessments, available in lighter and fuller versions, is common in financial services and larger enterprises.
CAIQ (Consensus Assessments Initiative Questionnaire) from the Cloud Security Alliance is aligned to the Cloud Controls Matrix and is well suited to cloud and SaaS providers. Many providers publish completed CAIQs.

Accepting a vendor's already-completed SIG or CAIQ saves weeks for both sides. For Tier 2 vendors, a focused set of 30 to 60 questions covering access control, encryption, incident notification, subprocessors, data retention, and secure development is usually enough. Our vendor security questionnaire template is a reasonable starting point.

Whatever format you use, read and score the answers. A "No" on MFA for admin access should weigh far more than a "No" on awareness posters.

Step 4: Collect and read the right evidence

A logo on a vendor's website is not evidence. Here is what to ask for and what to check when it arrives.

SOC 2 reports

A SOC 2 report is an independent auditor's attestation on a service organization's controls against the AICPA Trust Services Criteria. When you receive one:

Confirm the type. A Type I report covers control design at a point in time. A Type II covers design and operating effectiveness over a period, usually 6 to 12 months. For Tier 1 vendors, prefer Type II.
Check the period. If the audit period ended many months ago, ask for a bridge letter (sometimes called a gap letter). It is a statement from the vendor's management, not the auditor, covering the gap between the end of the report period and today and asserting there have been no material changes to controls. It is useful but carries less weight than the report itself.
Check the scope. Make sure the system description covers the actual product and infrastructure you use, and note which Trust Services Criteria categories are included. Security is always in scope; availability, confidentiality, processing integrity, and privacy are optional.
Read the opinion and exceptions. A qualified opinion or a list of testing exceptions tells you where controls did not operate as described. Decide whether any exception affects your use of the service.
Review CUECs. Complementary user entity controls are the controls the vendor assumes you operate, such as managing your own user access, enabling MFA, or reviewing audit logs. If you don't operate them, the vendor's controls may not achieve their objectives. Map each relevant CUEC to an owner on your side.
Look at subservice organizations. Reports often carve out the vendor's own providers, such as its cloud host. That means those providers' controls were not tested in this report, and you may need their reports too.

ISO 27001 certificates

An ISO 27001 certificate shows that an organization's ISMS was audited by a certification body. Check:

Scope statement. The certificate names what is covered. A certificate scoped to one office or one internal function does not cover the product you are buying.
Validity dates. Certificates run on a three-year cycle with surveillance audits in between. Confirm the certificate is current.
Issuing body and accreditation. Prefer certificates from accredited certification bodies, and verify the certificate where the body offers a lookup or through an accreditation database.
Statement of Applicability. Vendors often won't share their full SoA, but asking which Annex A controls are excluded can be informative.

Other artefacts

Depending on tier and service, also request a data processing agreement, a list of subprocessors, a recent penetration test executive summary with remediation status, business continuity and disaster recovery summaries, and cyber insurance confirmation.

Step 5: Put it in the contract

Due diligence tells you where a vendor stands today. The contract is what gives you leverage tomorrow. For Tier 1 and most Tier 2 vendors, security or legal should confirm the agreement includes:

Security requirements. A commitment to maintain a defined security standard or program, ideally referencing the controls or certifications you relied on during diligence.
Breach notification. A specific notification window for security incidents affecting your data, with a named contact and the information the vendor must provide.
Right to audit or assurance. Either a right to audit or an obligation to provide current independent assurance reports annually.
Data protection terms. Where personal data is processed on your behalf, a data processing agreement. Under GDPR, Article 28 sets out what a controller-processor contract must contain.
Subprocessor controls. Notice of new subprocessors and the right to object.
Data location, retention, return, and deletion. Where data is stored, how long it is kept, and certification of deletion at termination.
Service levels and continuity. Uptime commitments, support response, and recovery objectives for critical services.
Liability and insurance. Liability caps that are meaningful relative to the data at risk, and minimum cyber insurance where appropriate.

Agree in advance which clauses are mandatory for Tier 1 and who can approve an exception.

Step 6: Monitor continuously

Annual reviews are not enough anymore. Set up alerts for certification changes, breaches, and material corporate events.

Continuous monitoring doesn't mean re-auditing every vendor every week. It means watching for signals that should trigger an early reassessment:

Security incidents and breach disclosures involving the vendor or its subprocessors.
Assurance changes. An expired SOC 2 report, a lapsed ISO certificate, or a new qualified opinion.
Corporate events. Acquisitions, mergers, major layoffs, or financial distress, which can change ownership of your data or the vendor's ability to deliver.
Scope changes on your side. A Tier 3 tool that starts receiving customer data is now a different vendor from a risk perspective. Require business owners to report this.
Subprocessor changes announced by the vendor.
Security ratings or external attack surface signals, used as an input for prioritization rather than a verdict.

Pair event-driven triggers with a fixed cadence: annually for Tier 1, every two years for Tier 2, and at renewal for Tier 3. Track expiry dates for every piece of evidence so you chase a new SOC 2 report before the old one goes stale, not after an auditor points it out.

Step 7: Close the loop

Every finding from a vendor review should turn into a tracked action — not a PDF buried in SharePoint.

For each gap you identify, choose one of three outcomes and record it:

Remediate. The vendor commits to fix the issue by a date. Track it and follow up.
Compensate. You add a control on your side, such as restricting the data shared, enforcing SSO, or enabling additional logging.
Accept. A named risk owner with the authority to do so formally accepts the residual risk, with a review date.

Significant vendor risks belong in your enterprise risk register alongside other information security risks, scored with the same methodology. Our guide to building a risk register covers how to do that consistently.

Offboarding vendors

Programs that are strong at onboarding are often weak at exit. When a vendor relationship ends:

Revoke SSO access, API keys, service accounts, VPN accounts, and OAuth grants.
Request return or deletion of your data and obtain written confirmation of deletion.
Remove the vendor from subprocessor lists you publish to customers.
Retrieve any physical assets or badges.
Update the inventory status to offboarded rather than deleting the record, so you retain the history.

Build these steps into a checklist triggered by contract termination or non-renewal.

Metrics that show the program is working

Keep reporting short and focused on coverage and follow-through:

Percentage of vendors inventoried and tiered.
Percentage of Tier 1 and Tier 2 vendors with a current assessment.
Number of vendors with expired assurance evidence.
Open vendor findings by severity and age, and the number past their due date.
Number of active risk acceptances and how many are due for review.
Average time to complete an assessment, by tier.
Percentage of new vendors that went through intake before contract signature.

The last metric is the one that tells you whether the program is embedded or just running alongside the business.

A 90-day rollout plan

Phase	Timing	Key activities	Output
Foundation	Days 1–30	Write a short vendor risk policy; agree tiering criteria; pull vendor lists from finance, procurement, and SSO; deduplicate; assign business owners	Vendor inventory, approved tiering model, policy
Tier and assess	Days 31–60	Tier every vendor; choose questionnaire formats per tier; send requests to Tier 1 vendors; review SOC 2 reports and ISO certificates; map CUECs to internal owners	Tiered inventory, Tier 1 assessments in progress, CUEC list
Operationalize	Days 61–90	Add intake gate to procurement and SSO provisioning; define mandatory contract clauses; complete Tier 1 reviews; log findings and risk acceptances; start Tier 2 reviews; set reassessment dates and evidence expiry reminders; produce first metrics report	Working intake process, findings tracker, first management report

Resist the urge to assess every vendor in the first quarter. Getting all Tier 1 vendors done properly and the intake gate in place is a far better 90-day result than shallow questionnaires sent to 200 vendors.

Common mistakes

Treating the questionnaire as the program. Collecting answers without reading them, scoring them, or acting on findings creates paperwork, not assurance.
Tiering by spend. The cheapest tools are often the ones with the broadest OAuth access.
Accepting a SOC 2 report without reading it. Scope, period, exceptions, and CUECs matter more than the fact that a report exists.
Ignoring subservice organizations. A carved-out cloud host is still part of your data path.
No intake gate. Without one, the inventory is out of date the week after you finish it.
Findings with no owner. A gap without an owner and a date will be the same gap next year.
Forgetting offboarding. Stale integrations and forgotten data copies are a common source of exposure.

How frameworks expect this

Vendor risk management is not optional under the major frameworks, which is why auditors ask about it in almost every engagement.

ISO 27001:2022 addresses supplier relationships in Annex A controls 5.19 (information security in supplier relationships), 5.20 (addressing information security within supplier agreements), 5.21 (managing information security in the ICT supply chain), and 5.22 (monitoring, review and change management of supplier services). Control 5.23 covers information security for use of cloud services. Auditors typically look for a documented process, a supplier inventory, evidence of assessments, security requirements in contracts, and records of periodic review.
SOC 2 criterion CC9.2 requires the entity to assess and manage risks associated with vendors and business partners. Auditors commonly test that vendors were assessed and that reviews of vendor assurance reports took place during the period.
NIST CSF 2.0 introduced a dedicated Cybersecurity Supply Chain Risk Management category (GV.SC) within the Govern function.
GDPR Article 28 requires controllers to use only processors providing sufficient guarantees, governed by a contract with specified terms.

Because these requirements overlap heavily, one well-run process with good records can satisfy several frameworks at once.

How Asurvo helps

Asurvo's Third Party module brings the program described above into one place: a vendor inventory, tiering, questionnaires, risk scoring, and continuous monitoring, with findings and accepted risks linked into the risk register so vendor risk isn't managed in a separate silo. Evidence management tracks expiry, so lapsed reports surface before an audit does. To see how teams structure the rollout, read the vendor risk program use case.