Vendor Register
Effective Date: 2026-03-02
Last Review: 2026-03-02
Next Review: 2026-09-02
Owner: Greg Felice, Project Lead
1. Purpose
This register documents all third-party vendors and services used by the tomo project, their compliance posture, data handling characteristics, and risk assessment. It supports vendor risk management and ensures that third-party dependencies do not introduce unacceptable risk to the project's security posture.
2. Scope
All external services that store, process, or transmit tomo project data, or that are part of the software supply chain (build, distribution, infrastructure).
3. Vendor Risk Tiers
| Tier |
Criteria |
Review Frequency |
Due Diligence |
| Tier 1 — Critical |
Handles customer data, part of supply chain, or single point of failure |
Semi-annually |
Compliance certifications, security review, DPA |
| Tier 2 — Important |
Infrastructure or operational dependency, no direct customer data access |
Annually |
Compliance certifications, security policy review |
| Tier 3 — Standard |
Convenience service, easily replaceable, no sensitive data |
Annually |
Basic security review |
4. Vendor Register
4.1 Docker Hub
| Field |
Detail |
| Vendor |
Docker, Inc. |
| Service |
Container image registry |
| Tier |
Tier 1 — Critical |
| Purpose |
Distribution of tomo Docker images (PostgreSQL + AGE + pgvector) |
| Data handled |
Container images (public), account credentials |
| Compliance |
SOC 2 Type II |
| Security features |
MFA, access tokens (scoped), Docker Content Trust (image signing), vulnerability scanning |
| Contract / Terms |
Docker Hub Terms of Service (free tier, Pro tier for commercial use) |
| Alternatives |
GitHub Container Registry (ghcr.io), self-hosted registry |
| Risk notes |
Image pull rate limits on free tier; vendor lock-in is low (OCI standard images) |
| Last reviewed |
2026-03-02 |
4.2 PyPI (Python Package Index)
| Field |
Detail |
| Vendor |
Python Software Foundation |
| Service |
Python package registry |
| Tier |
Tier 1 — Critical |
| Purpose |
Distribution of the tomo Python SDK |
| Data handled |
Package artifacts (public), account credentials |
| Compliance |
No formal SOC 2 certification (non-profit); Trusted Publisher (OIDC) support; 2FA enforcement for critical projects |
| Security features |
MFA (TOTP, WebAuthn), Trusted Publisher (OIDC), API tokens (scoped), package yanking |
| Contract / Terms |
PyPI Terms of Use |
| Alternatives |
Self-hosted (devpi), Forgejo package registry |
| Risk notes |
Supply chain target; mitigated by MFA, Trusted Publisher, and signed packages |
| Last reviewed |
2026-03-02 |
4.3 GitHub
| Field |
Detail |
| Vendor |
GitHub, Inc. (Microsoft) |
| Service |
Source code hosting, issue tracking, community engagement |
| Tier |
Tier 2 — Important |
| Purpose |
Public mirror of tomo source code; community issue tracking and discussions |
| Data handled |
Public source code, issues, pull requests, contributor identities |
| Compliance |
SOC 2 Type II, SOC 3, ISO 27001, FedRAMP |
| Security features |
MFA, SSH key auth, branch protection, Dependabot, secret scanning, code scanning |
| Contract / Terms |
GitHub Terms of Service (free tier for open source) |
| Alternatives |
Primary repo is on Forgejo (git.rizlabs.com); GitHub is a mirror |
| Risk notes |
Not the primary repository; compromise affects public mirror only. Low data sensitivity (all public). |
| Last reviewed |
2026-03-02 |
4.4 Backblaze B2
| Field |
Detail |
| Vendor |
Backblaze, Inc. |
| Service |
S3-compatible object storage |
| Tier |
Tier 1 — Critical |
| Purpose |
Offsite encrypted backup storage for PostgreSQL backups and WAL archives |
| Data handled |
Encrypted database backups (AES-256 client-side + SSE), encrypted WAL segments |
| Compliance |
SOC 2 Type II |
| Security features |
Server-side encryption, application key scoping (per-bucket), lifecycle rules, HTTPS-only API |
| Contract / Terms |
Backblaze Terms of Service |
| Alternatives |
AWS S3, Wasabi, MinIO (self-hosted) |
| Risk notes |
Backups are encrypted client-side before upload; vendor compromise does not expose plaintext data. Vendor lock-in is low (S3-compatible API). |
| Last reviewed |
2026-03-02 |
4.5 Cloudflare
| Field |
Detail |
| Vendor |
Cloudflare, Inc. |
| Service |
DNS management, DDoS protection, CDN |
| Tier |
Tier 2 — Important |
| Purpose |
DNS for rizlabs.com domain; DDoS mitigation for web-facing services |
| Data handled |
DNS records, HTTP traffic metadata (if proxied) |
| Compliance |
SOC 2 Type II, ISO 27001, PCI DSS Level 1 |
| Security features |
DNSSEC, WAF (paid plans), DDoS protection, MFA on account |
| Contract / Terms |
Cloudflare Terms of Service (free plan) |
| Alternatives |
Route53, self-hosted DNS (BIND/PowerDNS) |
| Risk notes |
DNS is a critical dependency; Cloudflare outage would affect all services. Mitigated by low TTLs and documented manual failover procedure. |
| Last reviewed |
2026-03-02 |
4.6 Let's Encrypt
| Field |
Detail |
| Vendor |
Internet Security Research Group (ISRG) |
| Service |
Automated TLS certificate issuance (ACME) |
| Tier |
Tier 2 — Important |
| Purpose |
TLS certificates for all *.rizlabs.com services |
| Data handled |
Domain validation records, public certificate data |
| Compliance |
WebTrust audit (CA/Browser Forum requirements) |
| Security features |
ACME protocol (automated, no manual key handling), Certificate Transparency logs |
| Contract / Terms |
Let's Encrypt Subscriber Agreement |
| Alternatives |
ZeroSSL, BuyPass, commercial CAs |
| Risk notes |
90-day certificate lifetime requires reliable auto-renewal (certbot). Renewal failure monitored via Grafana. |
| Last reviewed |
2026-03-02 |
4.7 Hetzner (Future)
| Field |
Detail |
| Vendor |
Hetzner Online GmbH |
| Service |
Cloud infrastructure (VMs, block storage, networking) |
| Tier |
Tier 1 — Critical (when active) |
| Purpose |
Cloud hosting for tomo hosted service (production workloads) |
| Data handled |
Customer databases, application data, infrastructure state |
| Compliance |
ISO 27001, SOC 2 Type II (Hetzner Cloud) |
| Security features |
Firewall, private networking, LUKS-encrypted volumes, API token auth |
| Contract / Terms |
Hetzner Terms and Conditions, DPA (GDPR-compliant) |
| Alternatives |
AWS, GCP, OVH, Vultr |
| Risk notes |
EU-based provider (data residency advantage for European customers). Not yet active. |
| Status |
Planned |
4.8 Stripe (Future)
| Field |
Detail |
| Vendor |
Stripe, Inc. |
| Service |
Payment processing |
| Tier |
Tier 1 — Critical (when active) |
| Purpose |
Subscription billing for tomo hosted service |
| Data handled |
Payment card data (handled by Stripe, not stored by tomo), customer billing info |
| Compliance |
PCI DSS Level 1, SOC 2 Type II, ISO 27001 |
| Security features |
Tokenized card data, webhook signature verification, 3D Secure, fraud detection |
| Contract / Terms |
Stripe Services Agreement |
| Alternatives |
Paddle, Lemon Squeezy, self-hosted (not recommended for PCI scope) |
| Risk notes |
tomo never handles raw card data (Stripe.js + Checkout). PCI scope is minimal (SAQ A). |
| Status |
Planned |
5. Vendor Assessment Process
5.1 New Vendor Onboarding
Before adopting a new third-party service:
- Identify data exposure — What data will the vendor access, process, or store?
- Check compliance certifications — SOC 2, ISO 27001, PCI DSS as applicable
- Review security documentation — Security whitepaper, incident history, vulnerability disclosure
- Assess alternatives — Can the need be met with existing vendors or self-hosted solutions?
- Document in this register — Add entry with all required fields
- Assign tier — Based on data sensitivity and criticality
- Establish DPA — If vendor handles personal data (GDPR/CCPA)
5.2 Ongoing Monitoring
| Activity |
Frequency |
Scope |
| Vendor register review |
Semi-annually |
All vendors |
| Compliance recertification check |
Annually |
Tier 1 and Tier 2 vendors |
| Incident impact assessment |
As needed |
When a vendor discloses a breach |
| Alternative assessment |
Annually |
Tier 1 vendors (ensure no vendor lock-in) |
5.3 Vendor Offboarding
When discontinuing a vendor:
- Migrate data and functionality to replacement
- Revoke all API keys, tokens, and credentials
- Confirm data deletion per vendor's retention policy
- Remove from this register (mark as decommissioned with date)
- Update dependent systems and documentation
6. Compliance Mapping
| SOC 2 Criteria |
Control |
| CC9.2 |
Vendor risk management and assessment |
| CC3.2 |
Identification of risks from vendor relationships |
| CC2.3 |
Communication of vendor-related security matters |
| CC6.1 |
Logical access to vendor-hosted systems |