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.