Vendor and Platform Governance

Every useful institution depends on outsiders: registrars, web hosts, email providers, payment processors, donor platforms, CRMs, cloud drives, AI vendors, transcription tools, forum platforms, plugins, analytics, and open-source packages. Dependency is not failure. Unreviewed dependency is failure.

Vendor governance is how the institution keeps convenience from becoming capture.

The Rule

No vendor receives trust by default.

Before a platform or tool becomes institutional infrastructure, the institution should know:

• what data it touches;
• who owns the account;
• who can remove access;
• what happens if the vendor changes terms;
• how exports work;
• how breach notice works;
• whether AI training or model improvement uses submitted material;
• whether the tool can publish, spend, send, delete, or change permissions;
• how the institution exits.

If no one can answer those questions, the tool is experimental, not approved.

Vendor Classes

Classify each vendor before use.

The class can change over time. A chat tool becomes high consequence when it receives safeguarding reports. A public AI tool becomes high consequence when members paste testimony into it.

Approval Checklist

Before approval, record:

Vendor/tool:
Purpose:
Owner:
Account email:
Admin roles:
Data touched:
Data classification:
AI training/model-improvement terms:
Retention/export terms:
Breach/security notice terms:
Payment terms:
MFA/SSO support:
Deletion/exit path:
Backup owner:
Review date:
Approved by:

The checklist should live in the institutional tool register, not in one founder’s memory.

Public-facing vendor register fields are governed in Transparency and Public Registers.

Data Questions

Ask every vendor:

1. What data is collected?
2. Where is it stored?
3. Who can access it?

4. Is it used for training, model improvement, analytics, resale, or product development?

5. Can data be deleted?

6. Can data be exported in a usable format?
7. How long are logs retained?
8. What happens when an account is closed?
9. What breach notice does the vendor provide?
10. Does the vendor rely on subcontractors that touch the data?

If the vendor cannot answer basic data questions, do not use it for restricted or highly restricted material.

AI Vendor Review

AI vendors need extra review because generated systems can transform, retain, infer, summarize, and route sensitive material.

Before approving an AI vendor, answer:

• Is submitted data used to train or improve models?
• Can training use be disabled?
• Are prompts, outputs, files, traces, or tool calls retained?
• Can the institution delete logs?
• Does the system connect to external tools?
• Does it support workspace-level controls?
• Does it support human approval before consequential actions?
• Does it provide audit logs or traces?

• Does it allow private testimony, minor material, donor records, or incident notes under the Privacy and Data protocol?

• What happens if the model behavior changes?

Approval of an AI vendor does not approve every use. The workflow still needs the traffic-light review in AI Literacy and Use Protocol.

Supply Chain Rules

For code, plugins, packages, browser extensions, MCP servers, automations, and connectors:

• install only from known sources;
• prefer maintained projects with visible release history;
• record version and purpose;
• review permissions before installing;
• avoid plugins that request broad account access for narrow tasks;
• do not install from links posted in untrusted forums or direct messages;
• keep a rollback path;
• remove unused tools;
• review critical dependencies quarterly.

Software supply-chain risk is not only a large-company problem. A small institution can lose its archive, accounts, or donor records through one over-permissioned plugin.

Capture Risks

A vendor captures the institution when leaving becomes too costly.

Capture signals:

• no usable export;
• one vendor owns account login, payment, and data;
• proprietary formats trap archive material;
• a donor or partner controls the tool;
• a vendor becomes the only place members gather;
• the platform algorithm rewrites public strategy;
• AI vendor terms change but workflows continue unchanged;
• the institution cannot publish, email, receive donations, or access records without one vendor.

For high-value systems, maintain an exit plan before the institution becomes dependent.

Exit Plan

Every important vendor needs an exit plan.

Record:

• what must be exported;
• export format;
• where backups live;
• who can initiate export;
• how long migration takes;
• what public communication is needed;
• what member, donor, or testimony data must be deleted or retained;
• what access must be revoked;
• what replacement exists.

Exit plans should be tested for domains, email, archive storage, payment processors, CRM, newsletter, and AI workspaces.

Quarterly Review

Each quarter, review:

• vendor list;
• account owners;
• admin access;
• MFA status;
• payment method;
• contracts and renewals;
• terms changes;
• data exports;
• breach notices;
• unused tools;
• AI training/retention terms;
• plugin and package inventory;
• open incidents.

Remove what is no longer needed. A tool that no one owns is a risk.

Spiralism Policy

Spiralism should maintain a public-facing posture of tool humility: platforms are useful, but the archive and institution must outlive any one vendor.

No vendor may receive restricted testimony, minor material, donor records, incident notes, care-circle records, credentials, or private companion logs unless privacy, security, retention, consent, export, and breach-notice terms have been reviewed and approved.

This protocol pairs with:

• Digital Infrastructure and Security;
• Privacy and Data Stewardship;
• Finance and Controls;
• Partnership Strategy;
• AI Literacy and Use Protocol;
• Agent Tool Permission Protocol;
• Agent Audit and Incident Review;
• Online Community Moderation.

Sources Checked

• NIST, Cybersecurity Framework 2.0: Quick-Start Guide for Cybersecurity Supply Chain Risk Management, October 2024.
• NIST, The NIST Cybersecurity Framework 2.0, February 26, 2024.
• CISA, Defending Against Software Supply Chain Attacks, accessed May 2026.
• CISA, Securing the Software Supply Chain: Recommended Practices for Managing Open Source Software and Software Bills of Materials, accessed May 2026.
• Federal Trade Commission, Vendor Security, accessed May 2026.
• Federal Trade Commission, Data Security, accessed May 2026.
• NIST, AI Risk Management Framework, accessed May 2026.