Procurement evidence
Procurement evidence for managed B2B launch.
A bounded review pack for legal, privacy, security, subprocessors, DPIA, AI governance, and launch acceptance. It shows what exists now and what still needs customer-specific approval.
Legal artifacts
| Artifact | Status | Current evidence | Buyer use | Remaining evidence |
|---|---|---|---|---|
| Data Processing AddendumJoint | published | Published Article 28 processing terms, security duties, audit/support language, and customer controller obligations. | Attach to the order form and record any customer-specific deviations in the implementation record. | Customer countersignature or order-form incorporation remains customer-specific external evidence. |
| Service levels and supportThesmios | published | Published support severity model, response targets, status communication path, readiness endpoint, and incident handling references. | Use for private-beta support expectations and incident escalation planning. | Paid or enterprise service credits, uptime targets, and custom support hours require signed order-form scope. |
| Subprocessor registerThesmios | published | Published hosting, storage, email, analytics, and AI-processing subprocessors with privacy notice links. | Review before approving production processing and data residency boundaries. | Customer-specific approval, objections, replacement windows, and urgent-change exceptions must be attached to the launch record. |
| Privacy rights operationsJoint | managed beta | Authenticated privacy export, data-rights request intake, fulfilment evidence, retained-data notes, and processor log references. | Use to prove DSAR and fulfilment workflow exists before storing real employee evidence. | Customer-specific deletion execution and processor-side log reconciliation remain launch evidence. |
| Security assurance packJoint | managed beta | Vendor risk, technical security, continuity, privacy, AI-governance review bundles, and launch rehearsal records. | Use as procurement-review pack without overclaiming SOC 2, ISO, pen-test, or customer-specific DPIA evidence. | Independent pen-test, external certifications, restore rehearsal, and customer DPIA approval remain external or customer-specific. |
| Order-form templateJoint | customer specific | Commercial defaults, plan limits, excluded roadmap boundaries, launch acceptance gates, signature blocks, and evidence attachments. | Use as the starting point for a private-beta or paid-beta agreement. | Actual signatures, PO references, pricing approval, and customer-specific data scope remain external evidence. |
Subprocessor notice process
One notice path for register changes and customer objections.
Material subprocessor changes should be assessed, published, notified through the security status audience, and attached to the customer launch record with an objection or acceptance decision.
Notice window: 30 days
Urgent security, availability, or compliance-driven changes may be made sooner, but the customer-impact decision and notice rationale must be recorded.
Assess materiality
ThesmiosRecord processing purpose, data categories, location, transfer basis, and whether the change is material for launch tenants.
Update public register
ThesmiosPublish the updated subprocessor entry and attach the diff or approval reference.
Notify subscribed reviewers
ThesmiosRun `/api/status/broadcast` as a security notice in dry-run mode first, then controlled-send mode after sender configuration.
Handle objections
JointRecord customer objection, mitigation, replacement plan, or accepted boundary in the customer request or launch room.
Attach acceptance evidence
CustomerAttach customer approval or accepted-with-exclusions note to the tenant launch acceptance package.
Dry-run command
curl -X POST https://www.thesmios.com/api/status/broadcast -H "authorization: Bearer <STATUS_BROADCAST_SECRET>" -H "content-type: application/json" -d '{"eventType":"security","severity":"info","title":"Subprocessor change notice","summary":"Thesmios intends to add, replace, or materially change a subprocessor. Attach the updated register, data categories, transfer basis, objection window, and customer-impact assessment.","operatorReference":"subprocessor-change-YYYY-MM-DD","dryRun":true}'
DPIA and AI governance questionnaire
Processing scope and controller/processor roles
JointWhat worker populations, jurisdictions, compliance modules, and verifier audiences are in scope for the launch tenant?
The product records tenant scope through implementation requests, launch-room sections, retention policy, and launch acceptance evidence.
Customer input: Approved worker cohort, modules, verifier audiences, and excluded populations.
Which party is controller, processor, or independent verifier for each evidence flow?
The DPA and order-form template define processor scope; verifier shares remain purpose-bound and owner-controlled.
Customer input: Customer legal role decision and any independent-controller verifier terms.
Personal data, special category data, and minimisation
JointWhat personal data and evidence files are processed, and which fields are hidden from verifiers by default?
Credential details, evidence metadata, passport shares, and privacy export outputs identify records without embedding private file bodies.
Customer input: Customer-approved data inventory, special-category handling, and field-release policy.
What retention period, legal hold rule, and deletion exception apply?
Tenant settings support retention/legal-hold policies and privacy fulfilment evidence with retained-data notes.
Customer input: Customer-approved retention schedule and legal-hold decision.
AI governance and human oversight
ThesmiosWhere is AI used, and can a human review or override evidence decisions?
AI-assisted verification is positioned as support for evidence review; lifecycle routes retain actor IDs, status decisions, and audit records.
Customer input: Customer policy for human review, appeal, and prohibited automated-decision uses.
What model, prompt, or third-party AI processing boundaries apply to customer data?
Subprocessor and capability maturity materials identify AI-processing boundaries without claiming customer-specific model approval.
Customer input: Customer-approved AI-processing scope, excluded data classes, and required model/vendor restrictions.
Security, subprocessors, and international transfers
JointWhich subprocessors process tenant data and how are changes notified?
The public register is live; notices use security-scoped status subscribers and `/api/status/broadcast` evidence.
Customer input: Customer objection window, recipient contacts, and any prior-approval requirement.
What data residency, transfer, access, encryption, and audit controls are accepted for the tenant?
Security assurance, tenant governance, audit export, and readiness evidence cover the current state and remaining external proof.
Customer input: Approved residency, transfer mechanism, and any customer-specific access restrictions.
Data-subject rights, incidents, and communications
JointHow are access, deletion, correction, restriction, and objection requests recorded and fulfilled?
Privacy routes provide export, request intake, and fulfilment evidence with processor log references.
Customer input: Customer support routing, statutory deadlines, and deletion approval procedure.
How are incidents, personal-data breaches, security notices, and product availability updates communicated?
Status subscriptions and broadcasts provide scoped audience evidence; SLA and DPA describe legal thresholds.
Customer input: Named incident contacts, escalation channel, and contract-specific notice windows.
Residual risk and approval
CustomerWhich residual risks, external certifications, and proof gaps are accepted for managed private beta?
Launch evidence and security assurance packs list current proof, managed-beta boundaries, and external-required evidence.
Customer input: Signed residual-risk acceptance, excluded scope, and go/no-go decision.
Who signs off the DPIA/AI governance questionnaire and how is acceptance recorded?
Tenant launch acceptance records signer, decision, scoped exclusions, evidence references, and approval references.
Customer input: Customer privacy/security approver and final written approval reference.