Multi-change vendor register template for SaaS teams
As the stack grows, a one-row public subprocessor list stops being enough. This register gives you a private operational view of vendor additions, replacements, notice requirements, owners, and evidence so each change can move through review without guesswork.
This template helps you manage the process. It does not decide whether a specific vendor change triggers notice, counsel review, or a different disclosure path.
Why a register beats a single list
Teams do not usually change one vendor at a time forever. They add a support tool, replace a billing vendor, move analytics, and then need to explain which changes were proposed, which were approved, and which still need notice.
A register keeps the change history visible so the public page can stay simple while the operational detail stays private.
Core columns
- Change ID.
- Vendor name and change type.
- Vendor purpose and processing region.
- Current status and source URL.
- Security and privacy review status.
- Notice required flag plus dates.
- Owner, evidence folder, and notes.
Example register rows
| Change | Vendor | Type | Status | Notice |
|---|---|---|---|---|
| CHG-2026-001 | Example Email Cloud | Add | Proposed | Needs counsel review |
| CHG-2026-002 | Legacy Support Desk | Replace | Replaced | No notice needed |
What to log for each change
Change context
Capture whether the vendor is new, replacing an old tool, or expanding into a new product area so later reviewers understand why the row exists.
Notice logic
Record whether notice is required, which deadline applies, and who approved the timing so the team does not have to re-derive the answer later.
Evidence path
Use the evidence folder or link column to keep the public page, draft notice, screenshots, and review notes together.
Ownership
Assign one person to each row. A register without an owner becomes a status list nobody is responsible for closing.
Use the register to keep the public page simple
When the register is current, the public page can stay readable. It should name the active vendors and the last update date, while the register holds the internal status, review notes, and unresolved questions.
Best fit for this template
Use this when multiple vendor changes are active, the team needs a private source of truth, and the same reviewer keeps asking for the latest status. If you only need one answer for one questionnaire, the starter pack is still the shorter path.