Trust Center
Everything procurement needs. No email gate.
Compliance crosswalk. DPA + BAA templates. Pre-filled security questionnaire. Threat models. SBOM. Audit chain protocol. Downloadable. Inspectable. Yours.
Compliance crosswalk. DPA + BAA templates. Pre-filled security questionnaire. Threat models. SBOM. Audit chain protocol. Downloadable. Inspectable. Yours.
Pathfinder is a single-user desktop application running entirely on customer-owned hardware. There is no Pathfinder SaaS, no shared multi-tenant backend, no inbound network listener, no shared credential store.
The trust boundary is the customer's macOS user account. CDM Migration Services operate within the same trust boundary. The vendor — including us — isn't in the chain of custody.
What procurement actually asked for. Read in browser or save to PDF.
Controls mapped to SOC 2 Type II, HIPAA §164.308/.310/.312, and GDPR Article 32 — with code paths cited.
Read →CAIQ-Lite / SIG-Lite format. Real answers, not lawyer dodges.
Read →STRIDE-aligned models for the four trust boundaries: IPC, MCP, HTTP, Connector.
Read →72hr acknowledgment, 7-day triage, 30-day fix SLA, 90-day coordinated disclosure. Safe harbor.
Read →Pathfinder's tamper-evident audit chain. Documented in the open so any auditor can implement a verifier independently.
Every mutation in the audit_log table is bound to the previous one by:
row_hash = SHA-256(FRAME_PREFIX || prev_hash || len(payload) || payload)Frame and length prefixes enforce domain separation and defeat the concatenation attack — two adjacent events can't be re-cut into a single event that hashes the same.
The genesis hash mixes the workspace ID into the tree's root:
genesis = SHA-256("pathfinder-audit-log-genesis\x00" || chain_id)A signed window from one workspace's chain can't be transplanted into another without detection.
Every 256 leaves, the writer seals a Merkle root and signs it with the workspace's Ed25519 key. Ed25519 because:
Two passes:
verify_chain walks every entry, re-derives row_hash, and fails at the first broken row index.verify_signed_root recomputes the Merkle root over the sealed window and checks the Ed25519 signature against the pinned fingerprint.At chain depth ~10K, the sealer crosses 100ms. Tracked as an incremental-tree follow-up. Not a soundness gap.
A key rotation is itself a row in the chain. Historical roots verify forever under their original fingerprint. No invisible key churn.
Today: verification runs inside Pathfinder's CLI and API. A standalone signed verifier ships with the product. Tomorrow: we publish the protocol so any auditor can implement an independent verifier. The source is available to authorized reviewers under standard MNDA. Request via security@colbysdatamovers.com.
Pathfinder's controls map to SOC 2 Type II criteria, HIPAA §164.308/.310/.312, and GDPR Article 32. CDM Migration Services follow the same control framework.
Pathfinder is not SOC 2 certified. Pre-audit. Target Type II audit window TBD. The disclaimer is the durable claim.
The crosswalk PDF (above) cites the code path for every control. That's the artifact your auditor wants.
| Subprocessor | Purpose | Data type |
|---|---|---|
| Cloudflare | CDN, DNS, Pages hosting, Web Analytics | Site traffic only. No PII. |
| FormSubmit | Contact form delivery | Form submissions (name, org, situation). |
Short list is a virtue. No subprocessor sees customer Salesforce data. No subprocessor is in the Pathfinder execution path.
security@colbysdatamovers.com (PGP key on request)
Or tyler@colbysdatamovers.com for non-PGP routing.
Good-faith security research is welcome. We will not pursue legal action when you report directly, don't access or modify customer data, don't pivot, and respect the disclosure timeline.
Full policy: Vulnerability Disclosure.
Bundle the artifacts and send to legal. Or book the technical session.