Departments: Vendor Access Governance – Bitsight Knowledge Base

Departments provide several key benefits to organizations, including:

Limiting vendor access based on team or function.
Mitigating the risk of overexposure.
Enhancing administrative efficiency.
Facilitating scalable, distributed Vendor Risk Management (VRM) operations.

How Departments Work with Other Access Controls

Departments serve as the primary visibility control in VRM. A user must be associated with a department that includes the vendor in order to see and interact with that vendor—regardless of their assignments or role.

Other access features like Internal Contacts, Assignments, and Roles define what users can do only after visibility has been granted by a department.

Clarifying Each Component

User Roles & Permissions: Defines what a user can do on a vendor if they have access to it.
Departments: Defines which vendors a user can see — it's about visibility.
Internal Contacts: Defines specific assignment-based access to a vendor — typically scoped access tied to a task or functional participation.
Assignments: Triggers inclusion into Internal Contacts and notifies the user; it's the action that initiates engagement.

Feature	Controls	Overrides?	Notes
Departments	Visibility	Not overridable	Primary gatekeeper for vendor access
Internal Contacts	Engagement	Only works if department grants access	Used after access is granted
Assignments	Engagement	Doesn't grant access unless visibility exists	Adds user to contacts, no access unless visible
Roles	Permissions	Cannot override visibility	Actions depend on permissions, not access

Example Scenarios

Understanding how Departments, Assignments, and Roles interact is key to managing access. Below are four common scenarios that demonstrate how visibility and permissions work together.

Scenario A

An user with the Internal Business User role is assigned a task for Vendor A, but the user is not part of the department that Vendor A belongs to.

Result: The user cannot see Vendor A in the platform and cannot perform any actions, even though they’ve been assigned.
Why: Assignments alone don’t grant visibility—department alignment is required first.

Scenario B

The user with the Internal Business User role is part of the same department as Vendor A and has been assigned a task for that vendor.

Result: The user can see Vendor A, is listed in Internal Contacts, and can perform actions (based on their role), except for certain restricted actions like Assessment Setup.
Why: The user meets both requirements—visibility through department and engagement through assignment.

Scenario C

The user with the Internal Business User role is not in any department but is assigned a task for Vendor A, which does belong to a department.

Result: The user can see Vendor A and take permitted actions.
Why: In this case, having no department doesn’t block access if the vendor has one. The assignment adds them to Internal Contacts and grants visibility.

Scenario D

The user with the Internal Business User role is in a department, but Vendor A does not belong to any department. The user is assigned a task for Vendor A.

Result: The user cannot see Vendor A and cannot take any action.
Why: Because Vendor A has no department, the user’s own departmental access rules prevent visibility. Assignments and Internal Contacts do not override this.