ServiceNow Vendor Risk Management Best Practices

Vendor risk management is the practice of assessing each supplier's security, financial stability and business continuity, scoring the result and deciding what to do about it. This page sets out eight practices, from the questionnaire and scoring rules to tracking incidents, keeping a central registry and reviewing the process each year.

Practice 1: Develop a Vendor Risk Assessment Questionnaire

Create a questionnaire that assesses vendor security, financial stability, and business continuity. Ask about: data security practices (encryption, access controls), employee security training, incident response capability, business continuity and disaster recovery planning, regulatory compliance certifications, financial stability indicators. Tailor the questionnaire to vendor type: a cloud provider needs detailed infrastructure security questions, a staffing agency needs background check and onboarding process questions. Use multiple-choice and yes/no questions for easy scoring, supplemented by open-ended questions for context. Keep the questionnaire short: Keep the questionnaire short enough that a vendor can finish it in one sitting.. Longer questionnaires are rarely completed honestly.

Practice 2: Define Clear Risk Scoring and Categorization

Convert questionnaire responses into a risk score: high-risk, medium-risk, low-risk. Define scoring rules explicitly: vendors with no incident response plan are automatically high-risk. Vendors with SOC 2 attestation and no recent security incidents are automatically low-risk. Vendors that fall in between are medium-risk. Use a consistent scoring methodology so that all vendors are assessed fairly. Document the scoring so that if a vendor disputes their risk rating, you can explain the rationale. Risk categorization then sets monitoring frequency: high-risk vendors are monitored more often than medium-risk vendors, and low-risk vendors least often.

Practice 3: Establish Remediation Plans for High-Risk Vendors

When a vendor is rated high-risk, do not automatically terminate the relationship. Instead, create a remediation plan. Identify specific actions the vendor must take to reduce risk, set a timeline suited to the gap, and assign accountability. Example: “Vendor must complete SOC 2 Type II audit by Q2 and provide report.” Work with the vendor to understand barriers and provide support if appropriate. Follow up at regular checkpoints within the timeline. At the end of the timeline, reassess: if the vendor has remediated, their risk score improves and monitoring frequency can be reduced. If they have not, then you face a decision: extend the timeline if progress is evident, or terminate the relationship.

Practice 4: Track Vendor Incidents and Security Events

When a vendor experiences a security incident, breach, or major operational failure, your organization must know. Subscribe to vendor security notifications or set up automated monitoring of vendor status pages. When an incident occurs, categorize its impact: does it affect your data, your systems, or just the vendor internally? Immediately assess whether the incident impacts your risk rating. A critical vulnerability discovered in a vendor’s software might jump their risk score from low to high. Create an incident record and link it to the vendor risk record. Use vendor incidents to update assessment questionnaires: if a major incident occurred, ask specifically about their response and improvements.

Practice 5: Maintain a Centralized Vendor Risk Registry

Keep all vendor information in one place: vendor name, type, services provided, data access level, risk score, last assessment date, next assessment due, remediation plan status, contact information. This registry is your system of record for vendor risk. Report on it monthly: which vendors are high-risk, which assessments are overdue, which remediation plans are at risk of missing deadline? Use the registry for onboarding: when a new person joins the organization, show them the vendor risk registry so they understand which vendors are critical and which have known risks.

Practice 6: Define Escalation and Exception Processes

Define when and how vendor risk decisions are escalated. If a critical vendor is high-risk and cannot be quickly remediated, escalate to executive leadership: “We need Vendor X to process our payroll, but they are high-risk. Do we accept this risk, or do we invest in an alternative?” Document the decision. If vendor risk increases unexpectedly (security incident or assessment failure), escalate to risk leadership immediately. Define who has authority to accept risks, who can approve exceptions, what documentation is required. This prevents ad-hoc decisions and ensures consistent risk governance.

Practice 7: Integrate Vendor Risk into Procurement and Contract Decisions

Do not engage a vendor without a risk assessment. When procurement evaluates vendor cost, also evaluate vendor risk. A vendor that offers significantly lower pricing but carries high-risk may not be worth the cost savings. Include risk assessment results in vendor selection discussions. Once a vendor is selected, include risk requirements in the contract: the vendor must maintain security certifications, notify you of incidents, undergo annual risk reassessment. Include termination clauses if the vendor becomes high-risk and cannot remediate. This ties vendor risk to actual business decisions and ensures risk is managed proactively, not reactively.

Practice 8: Review and Refine Your Assessment Process Annually

Once a year, review your vendor risk assessment process. Are questionnaire questions still relevant? Have new risks emerged that the questionnaire does not address? Are risk scores accurately predicting real issues? If you have had incidents from low-risk vendors, investigate: was your assessment process missing something? Use incident data to improve the assessment. Also review your vendor list: are there vendors you assessed years ago who should be reassessed now? Plan annual reassessments accordingly. Keep your vendor risk program current; do not let it ossify into a process that rubber-stamps vendor risk without real insight.

Keeping vendor evidence current between reviews

A vendor risk file is only as good as its most recent evidence. The difficulty is that evidence ages quietly. A certificate that was valid at onboarding may have lapsed months ago, and the record will still show a green status until somebody checks the expiry date. Good practice treats each piece of evidence as having its own clock, separate from the vendor’s review cycle, so that a lapse is visible on the day it happens rather than at the next scheduled review.

Deciding which field is the source of truth

Duplicated fields cause most of the disagreements that reviewers spend time resolving. A vendor’s contact details may appear in procurement, in finance and in the risk register, and each copy drifts. Decide, for each important field, which system holds the authoritative value and which copies are read-only. The register should display the source and the date of the last change, so a reader can tell whether a value is current or merely copied.

1. List every field that influences a risk decision, such as service type, data access, hosting location and contract end date.
2. Name the system or role that owns each one.
3. Mark the copies that other systems hold as read-only in the risk register, or as refreshed from the owner.
4. Record a last-changed date and the person who made the change on each field that drives a decision.
5. Review the list whenever a new integration or template goes live.

A monthly hygiene pass that stays small

A short, regular review finds problems before they accumulate. The pass should be narrow. Check for expired evidence, overdue reviews on high-risk vendors, acceptances without an end date and records with no relationship owner. Anything beyond those items belongs in a separate review. Keep the pass to the same agenda each month so that trends are visible, and record how many items were found and how many were cleared. The KPIs and metrics guide defines the measures the module reports on. The count itself can help the governance group see whether the program is improving.

Practices that look sensible but cause harm

Two habits in particular make a vendor file worse over time. The first is bulk-renewing expired evidence on the strength of a relationship: marking a certificate as current because the vendor has always been reliable. The second is copying a previous assessment into a new one and changing only the date. Both produce a record that looks complete while its contents describe a vendor that no longer exists in that form. If a renewal cannot produce new evidence, record that as an open issue rather than carrying the old answer forward.

Who should chase vendors who are slow to send evidence?

The relationship owner should make the first request, because the vendor already talks to them. If the evidence is still missing after a reasonable window, the risk owner takes over and decides whether to accept the gap or restrict the service. Make that handover explicit in the register so nobody assumes someone else is chasing.

Is a vendor’s own security statement enough evidence?

It can support a review but rarely closes one on its own. A statement tells you what the vendor claims. Independent evidence, such as a certificate from a recognized body, or a sample of the controls described, tells you whether the claim holds. Record which type of evidence each conclusion rests on.

How much should reviewers document for low-risk vendors?

Enough that a later reader can see why the vendor was judged low risk, and nothing more. A short note naming the services, the data involved and the evidence reviewed is usually enough. Heavy documentation for low-risk suppliers wears out reviewers and hides the records that matter.

How do we keep the register consistent across business units?

Agree one set of mandatory fields and one definition for each. Units can add local fields, but the shared fields should mean the same thing everywhere.

If the register has outgrown its rules, the evidence model is worth a second look.

Related guides: ServiceNow CMDB Data Quality Rules That Matter and ServiceNow Data Sources: Govern Authority and Conflicts.