Vendor + Subprocessor Management Policy
Owner: Security. Review cadence: annual or on material change. Approver: CEO.
This is the company-level policy for taking on, monitoring, and
offboarding third-party vendors and subprocessors that touch MeterBox's
Confidential or Restricted data. It is the intake + lifecycle counterpart
to the BCP/DR policy § 8 (which
covers vendor continuity) and the public
subprocessor list (which is the
current authoritative roster).
1 — Purpose + scope
A vendor or subprocessor is any third party MeterBox pays or contracts
with that either (a) processes Confidential or Restricted data on
MeterBox's behalf, or (b) is on the operational critical path for serving
tenants (compute, identity, KMS, email, payment, observability).
In scope: every entry on the public subprocessor list,
plus any future addition.
Out of scope: vendors that never see customer data and are not on the
critical path (e.g. office supplies, marketing tools used only with
aggregated/public data).
2 — Roles
- CEO — signs DPAs and master service agreements.
- Security lead — runs the intake review (§ 4), maintains the public
subprocessor list, runs the annual review (§ 6).
- Engineering lead — confirms the technical integration meets the
least-privilege + data-minimization commitments.
- Legal — engaged for DPA execution + breach-notification language +
data-residency commitments.
3 — Intake gate
A new vendor MAY NOT be sent Confidential or Restricted data until all
of the following have happened:
- Security review (§ 4) completed and recorded.
- DPA executed (Art. 28 GDPR; CCPA equivalent where applicable).
- Master service agreement or equivalent signed.
- Public subprocessor list
updated, with ≥ 30 days notice to tenants per Art. 28(2) GDPR before
the vendor goes live (notice is the listing being published; the listing
commit date is the notification date).
- Engineering integration uses the least-privilege role + the smallest
data scope that satisfies the use case.
A vendor that fails any of these is rejected or held until remediated.
4 — Security review checklist
The Security lead runs this on every intake and records the answers in a
vendor file (private; not in this repo).
- Attestation — SOC 2 Type II, ISO 27001, or equivalent valid report.
Vendor without an attestation: documented compensating controls + CEO
sign-off (rare; auditor will flag).
- DPA — present, current, covers the data categories we'll send.
- Data residency — region commitments compatible with the tenant
region (Managed-tier deployments pin region; the vendor must respect
it).
- Sub-subprocessor list — disclosed by the vendor + reviewed for
surprises.
- Breach notification SLA — vendor commits to notifying MeterBox
within an acceptable window (≤ 72 hours preferred, > 30 days is a
blocker).
- Encryption posture — in transit (TLS 1.2+) and at rest documented.
- Access controls + audit log — vendor offers MFA, role-based access,
and an audit trail MeterBox can review on request.
- Deletion + offboarding terms — vendor commits to deleting MeterBox
data on termination + providing a deletion certificate.
- Insurance + indemnity — cyber liability coverage commensurate with
data sensitivity.
5 — Approval matrix
| Vendor handles |
Approver |
| Public data only |
Security lead |
| Confidential data |
Security lead + CEO |
| Restricted data (cryptographic material, signed contracts) |
Security lead + CEO + Legal |
| Operationally critical (control plane, cloud, KMS, identity, payment) |
Security lead + CEO + Engineering lead |
6 — Annual review
Every vendor is reviewed once per year. The Security lead:
- Re-collects the vendor's current attestation (SOC 2 letter / ISO cert).
- Confirms the DPA + data-residency commitments are still in force.
- Re-checks the sub-subprocessor list against the prior year — any
additions reviewed individually.
- Confirms the integration scope hasn't crept beyond what was approved at
intake.
- Records the review date on the vendor file + in the public subprocessor
list (the listing's "last reviewed" field).
A vendor that fails review enters offboarding (§ 7) on a planned schedule
unless remediation is possible within 30 days.
7 — Offboarding
When a vendor is dropped (planned replacement, end of life, failed
review):
- Engineering lead disables the integration in production.
- Security lead requests the vendor's deletion certificate (MeterBox
data destroyed within the contracted window).
- Public subprocessor list updated; tenants notified.
- Vendor file marked closed; retention per data retention
policy.
8 — Sub-subprocessor change notification
Vendor adds a sub-subprocessor: vendor notifies MeterBox → Security lead
reviews against § 4 → if approved, the public subprocessor list is updated
within 30 days. Material changes that fail review trigger vendor
offboarding (§ 7).
9 — Review + version control
This policy is reviewed annually or on material change (new vendor
category, new regulator requirement, new high-impact subprocessor).
Last reviewed: 2026-06-04
Related docs