Scope this review to the proposed use and configuration. Reference protected assurance material rather than redistributing it.
Scope
Vendor / product / business owner:
Reviewer / date:
Use case / data categories / expected dependency:
Inherent risk tier and the reason (sensitivity of data, breadth of access, how hard the service would be to replace):
Data flow, integrations, and permissions requested, including any tenant-wide or administrative consent:
Where the data is stored and processed, and whether the firm can choose:
Overlap with a vendor the firm already uses, and whether consolidation was considered:
Evidence review
Distinguish evidence the vendor claims from evidence on file and read. Record the expiry date of each document so the next review knows what to refresh.
| Question | Evidence and scope / date | Gap | Owner / condition |
|---|---|---|---|
| Account and session lifecycle, including single sign-on and enforced multi-factor sign-in | |||
| Access model and audit visibility available to the firm | |||
| Processing, retention, deletion, and subprocessors | |||
| Relevant assurance coverage (report type, period, exceptions, and whether the reviewed service is in scope) | |||
| Incident notification commitment (what, to whom, within what time) and how the firm would be reached | |||
| Continuity and recovery evidence for the service itself | |||
| Usable export and exit, including format and assistance | |||
| AI input / output treatment, if relevant (training use, retention, human review by the vendor) | |||
| Contract terms confirmed by the adviser (confidentiality, breach notice, audit or assurance right, termination assistance, liability) | |||
| Vendor viability and concentration (ownership changes, funding, dependence on its own key providers) |
Configuration test
Tested user roles / data scope:
Access removal result:
Export result and missing content:
Administrative activity visible in the vendor's log, and whether the firm can retrieve it:
Default settings changed before approval (sharing, retention, integrations, AI features):
Decision
Approved use and restrictions:
Open conditions and owners:
Accepting decision owner / date:
Review triggers: broader access / new data / material product change / incident / renewal / change of ownership or subprocessor
Renewal, support, and exit owner:
Inventory entry made (system list, service ownership map, data map) on:
Ongoing oversight
| Check | Cadence | Owner | Last done | Result |
|---|---|---|---|---|
| Assurance report refreshed and exceptions read | ||||
| User and permission list reviewed | ||||
| Subprocessor and terms changes reviewed | ||||
| Export tested | ||||
| Incident notifications received and handled |
Vendor exit
- [ ] Accounts, API keys, certificates, and integrations belonging to the vendor are listed so they can be revoked on exit.
- [ ] Data return and deletion confirmation are required by the agreement, and the person who will collect the confirmation is named.
- [ ] The replacement or fallback for the service is identified for critical vendors, even if only a manual workaround.
Common failure modes
- The assurance report covers a different product or an earlier period.
- Approval is given for a narrow use and the product expands without another review.
- Nobody records who is notified of a vendor incident, so the notice arrives in an unmonitored mailbox.
- Exit is assumed possible and never tested until the relationship sours.
This brief covers the firm's review and acceptance. It does not certify the vendor's security, and it does not replace the legal review of the agreement.