ServiceNow Vendor Risk Management: Security and Access Design

Role Model for Vendor Risk Assessment Access

Vendor risk information includes security questionnaires, assessment results, and remediation plans. Not all of this information should be visible to all staff. A procurement officer needs to see vendor risk scores to make buying decisions, but does not need to see detailed security questionnaire answers. A vendor relationship manager needs to track assessment and remediation, but does not need to see assessment answers for vendors they do not manage. Security leadership needs to see all vendor risk information to understand overall third-party risk exposure. Executives need risk dashboards but not detailed questionnaire data. Design role-based access based on job responsibility.

Vendors themselves should have limited access: they can see their own assessment results and remediation plans, but not see assessments of competing vendors or internal risk scores and commentary. This gives vendors visibility to their own risk status and motivates remediation, while protecting competitive intelligence and sensitive internal discussions.

Least Privilege: Restricting Assessment and Scoring Authority

Assessment questionnaires must be completed by someone with sufficient knowledge. A junior staff member should not independently assess a vendor’s security posture; they are more likely to miss red flags or accept evasive answers. Restrict assessment authority to senior security staff or trained assessors. Restrict the ability to assign risk scores to experienced risk managers. Restrict the ability to accept high-risk vendors to executive leadership or a risk committee. This segregation ensures that risky decisions are made by the right people with appropriate review and accountability.

Segregation of Duties: Assessment Versus Remediation Authority

Separate the people who assess vendors from the people who manage remediation. The assessor’s job is objective: evaluate the vendor’s response truthfully. The remediation manager’s job is to help the vendor improve. If the same person does both, there is pressure to be lenient in assessment so that fewer vendors are high-risk and fewer require remediation. Separate these roles so that assessments remain objective.

Audit Trail: Documenting Vendor Decisions and Their Rationale

Every vendor assessment decision must be auditable. Record who completed the assessment, when, and what the vendor’s answers were. Record who scored the results and what the risk score is. Record who reviewed the assessment and whether they agreed with the score. Record decisions to accept high-risk vendors: who made the decision, when, and what was the business justification? If a vendor later has a security incident, auditors and management can trace back to see whether that risk was identified and accepted beforehand. Audit trails protect your organization by showing that risk was consciously managed, not negligently missed.

Maintain immutable logs: once an assessment is recorded, it cannot be edited or deleted retroactively. If an error is discovered, create a new assessment record showing the correction, do not edit the old one. This preserves the audit trail and shows the evolution of your vendor risk understanding.

Protecting Vendor Confidentiality While Sharing Risk Intelligence

Vendor questionnaires contain sensitive information: detailed security architecture, system vulnerabilities the vendor is aware of, security budgets, employee counts. Vendors share this in confidence. Protect it: do not publish raw questionnaire answers to the entire organization. Instead, publish risk scores, trend data, and summary conclusions. “Vendor X is high-risk due to inadequate access controls” is appropriate to share; “Vendor X has 3 security staff and 50 engineers” is not. Redact or abstract sensitive details when sharing vendor risk information within your organization.

Compliance Evidence and Regulatory Audit Support

Vendor risk assessments are evidence of due diligence in compliance audits. When a regulator reviews your vendor risk program, they expect to see: documented assessments, risk scores, remediation plans, and evidence that you monitored vendors. Ensure your Vendor Risk Management system can generate this evidence on demand. Configuration controls, change logs, and immutable assessment records should all be retrievable. Design your system to support audit queries: show all assessments completed in a date range, show all high-risk vendors and their remediation status, show evidence of monitoring activities.

Data Privacy: Protecting Vendor Personal Information

Vendor questionnaires may include personal information about employees (contacts, job titles, training records). Design access controls to protect this data. If a vendor contact person leaves the company, their personal information should be archived or deleted according to your data privacy policy. Comply with data privacy regulations: if a vendor asks for their data to be deleted, fulfill the request unless retention is legally required. Document data retention policies for vendor assessment records.

Where vendor data leaks in a platform build, even when the role model looks right

A role model on paper rarely fails in the place the designer was watching. The vendor record itself is usually locked down correctly. The leaks tend to sit in the places around it: a reference field on an assessment that lets a user walk to the vendor’s score from a screen they were never meant to open, an attachment uploaded with a questionnaire that carries its own permissions, a scheduled report that emails a full export to a distribution list, or a dashboard widget that shows detail the viewer’s role should not reach. Here the reader is the platform administrator who has agreed the roles and must now show that the data follows them.

Mapping every path to the data, not just every table

Start with an inventory of paths rather than tables. A path is any route by which a user can see a field: a form, a list, a related list, a report, an export, a notification, an API response, a Performance Analytics widget, or an attachment viewer. Tables are only one of these. The table below sets out which routes most often carry assessment detail past the intended controls, and the check that usually closes each route.

Testing access as the people who will actually hold it

Administrators commonly test access from an admin account, which proves very little because admin rights override most of the rules being tested. Log in as each role on a non-production copy and run the screens, searches and exports that role uses day to day. Record what each role can see, in writing, before go-live. The test is complete only when a user with the lowest right in each group has been shown to reach nothing beyond it.

1. List every role that touches vendor records, including vendor users, service accounts and read-only executives.
2. For each role, write the three things it must be able to do and the three things it must never see.
3. Impersonate the role and run the list views, reference lookups, exports and dashboard widgets that role uses.
4. Repeat the same run after any change to a data policy, an ACL, a report schedule or a portal page, because these changes are where access drifts.
5. Keep the results with the access design, dated and signed, so the evidence is ready when it is asked for.

Design choices that cause trouble later

Some decisions look harmless at build time and create the most work during an audit. Granting a broad read role to make a dashboard work is the usual one. The team then cannot explain who saw what, because the role is shared by people with unrelated responsibilities. Another is letting the vendor portal share a list view with internal users, so that a sort or filter reveals records the vendor should never see. A third is treating questionnaire attachments as harmless documents and leaving them outside the parent record’s access rules.

When you find one of these, fix the design rather than the symptom. Splitting a shared role into two narrower ones is almost always cheaper than explaining an exception to an auditor. Who gets which split is a question for the roles and RACI guide, and the security, risk and governance service page covers that area.

When tight access is not the right priority

Very small programs with a handful of vendors and a single assessor do not need a multi-role model with service accounts and portal restrictions. The risk of over-engineering is that the access model becomes too fragile for the one person who has to maintain it. In that situation a simple model with two roles, one for assessment and one for reading results, and a clear rule that exports are produced only by the assessor, is easier to defend and easier to keep correct.

Should vendor users be able to see their own assessment scores?

That is a policy choice, not a technical one. Showing the score can motivate remediation, but it can also invite argument about the scoring method. Many teams show the open findings and the remediation tasks to the vendor and keep the scoring model internal, then review the position with legal before it goes live.

How do we stop a scheduled report from exposing detail to the wrong people?

Run scheduled reports as a service account whose rights match the recipients, not as the user who built the schedule. Review the distribution list whenever someone joins or leaves the risk team, because the list is often the weakest control in the chain.

Do attachments need their own review?

Yes. Vendors often upload documents that contain more detail than the questionnaire asks for, including network layouts and staff lists. Check the attachment rules on the parent record and decide whether any attachment type should be reviewed by an assessor before it is shared more widely.

What evidence should an access review keep?

Keep the role list, the impersonation results, the date of each run and the names of the people who signed off the result. An access review without that record is an opinion, and an auditor will treat it as one.

Access designs are easiest to check against live paths, so a walkthrough of one real report and the role list is a good opening step.