Pathfinder Compliance Crosswalk
Controls mapped to SOC 2 Type II, HIPAA Security Rule, and GDPR Article 32 — with code paths cited.
Audience: acquirer's diligence team, customer security/compliance reviewers, internal pathkeeper audits.
Posture statement. Pathfinder is a single-user macOS desktop app 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 macOS user account. This posture eliminates many controls common to SaaS products (no shared databases, no multi-tenant logical separation, no centralized log SIEM) but inherits others (Keychain ACL, OS notarization, TLS-pinned outbound to SaaS APIs).
Below: where Pathfinder's design and code map onto SOC 2 Type II trust-services criteria, HIPAA Security Rule, and the GDPR Article 32 hardening expectations.
SOC 2 Type II (Trust Services Criteria, 2017)
| TSC | Pathfinder posture | Substrate / artifact |
|---|---|---|
| CC1 (Control Environment) | Pathkeeper roster (147 agents) gives every domain, lifecycle stage, and cross-cutting pattern a named owner. The roster is enforced by a lefthook gate (pathkeeper-roster-coherence). |
.claude/agents/ROSTER.md + lefthook.yml |
| CC2 (Communication & Info) | Threat models per surface; runbooks per substrate. | acquisition/threat-models/, docs/runbooks/ |
| CC3 (Risk Assessment) | Per-PR refresh of the owning pathkeeper; lifecycle/code-reviewer checks the threat model was touched when a new IPC/MCP/connector surface lands. | This document + acquisition/STEP2_5_PATHKEEPER_AUDIT.md |
| CC4 (Monitoring) | Instrument catalog (17 named instruments today) covers each substrate; cargo-deny + Dependabot run on every push; H6_DEPENDABOT_TRIAGE.md documents the standing posture. |
pathfinder-core/src/observability/instruments.rs |
| CC5 (Control Activities) | All migrations require explicit user approval recorded in the Ed25519 audit-log chain; the chain is verified on workspace open. | pathfinder-core/src/audit_log_chain*.rs |
| CC6 (Logical & Physical Access) | Single-user app; macOS Keychain is the sole credential store; secrets-lint CI gate (E3.5) prevents accidental literal-secret commits. | src-tauri/src/keychain.rs, scripts/secrets-lint.sh |
| CC7 (System Operations) | Workspace SQLite WAL + integrity_check on open; orchestrator checkpoints + idempotent CDC (E1-S2). | pathfinder-core/src/orchestrator/checkpoint.rs, migrations/20260617000006_create_cdc_tables.sql |
| CC8 (Change Management) | Forward-only migrations; signed git tags; release checklist (E7.1). | docs/RELEASE_ENGINEERING.md |
| CC9 (Risk Mitigation) | Per-connector base-URL allow-list (E3.8); rate-limiting + retry classifier in the connector SDK; Tauri capability allow-list (E3.2). | connectors/src/sdk/base_url_policy.rs, connectors/src/sdk/http.rs, src-tauri/capabilities/default.json |
| A1 (Availability) | Customer-owned; uptime is the customer's macOS uptime. Pathfinder degrades gracefully when SaaS APIs throttle (E3.7 / E4.3 metrics). | n/a — runtime is customer property |
| PI1 (Processing Integrity) | Transform typechecker (E1-S4), mapping validation, dry-run, golden dataset diff, signed audit chain. | pathfinder-core/src/transform/typeck/, pathfinder-core/src/mapping_validate.rs, pathfinder-core/src/transform/dryrun/, pathfinder-core/src/transform/golden/ |
| C1 (Confidentiality) | Per-workspace SQLite (no shared DB); Keychain-only secrets; .keychain and per-connection secret files excluded from workspace archives. |
pathfinder-core/src/workspace_archive.rs, src-tauri/src/keychain.rs |
| P1–P8 (Privacy) | All processing happens locally on customer hardware. Pathfinder never exfiltrates customer data; the only outbound network paths are the customer's own SaaS APIs (Salesforce, RENXT, etc.). | Threat model HTTP §"Explicitly out of scope: inbound traffic" |
HIPAA Security Rule (45 CFR §164.308–§164.312)
Pathfinder is a business-associate-style tool — it processes PHI on behalf of a covered entity, on hardware controlled by that entity. The following controls map:
| Rule | Pathfinder posture |
|---|---|
| §164.308(a)(1) Risk analysis | Threat models per surface (acquisition/threat-models/). |
| §164.308(a)(3) Workforce access management | macOS Keychain ACL prompts on every Keychain read; user must consent on first use per workspace. |
| §164.308(a)(5) Security awareness/training | Pathkeeper roster includes a documentation lifecycle agent that owns runbook clarity. |
| §164.310(d) Device and Media Controls | Customer-owned device; Pathfinder excludes the Keychain from workspace archives. |
| §164.312(a)(1) Access control: unique user identification | macOS user account = trust root. Pathfinder does not invent its own user model. |
| §164.312(a)(2)(iv) Encryption and decryption | Pathfinder relies on macOS FileVault for data-at-rest. TLS via rustls for data-in-flight. |
| §164.312(b) Audit controls | Ed25519-signed Merkle audit-log chain per workspace. |
| §164.312(c)(1) Integrity | Workspace SQLite integrity_check on every open; checkpoint checksums verified per batch; transform typechecker. |
| §164.312(e)(1) Transmission security | TLS 1.2+ via rustls; per-connector base-URL allow-list. |
GDPR Article 32 (Security of processing)
| Art. 32 measure | Pathfinder posture |
|---|---|
| Pseudonymisation | Identity blocker explanations preserve record-id provenance; data is never pseudonymized in transit between customer SaaS endpoints (Pathfinder is a conduit, not a pseudonymizer). |
| Encryption | TLS in flight; macOS FileVault + Keychain at rest. |
| Confidentiality, integrity, availability | Per-workspace SQLite; Ed25519 audit chain; integrity_check on open; checkpoint resume. |
| Restoring availability after incident | Workspace archive export + import; recovery commands (commands/recovery.rs). |
| Regular testing of measures | 5,200+ tests, 20+ property tests, 7 bench suites, connector contract harness, secrets-lint CI gate, cargo deny advisory sweep. |
Out-of-scope frameworks
- PCI-DSS — Pathfinder does not store, transmit, or process payment card data.
- FedRAMP — Pathfinder is not a SaaS / cloud service. Customers needing FedRAMP-equivalent assurance run Pathfinder on a FedRAMP-authorized endpoint of their own choosing.
- ISO 27001 — Customer's responsibility on customer's hardware.
Diligence questions and answers (one-liners)
| Q | A |
|---|---|
| Where does customer data live at rest? | The customer's macOS workspace SQLite file. Pathfinder operators do not have access. |
| Where do credentials live? | macOS Keychain. Never SQLite, never env vars, never logs. |
| What outbound traffic does Pathfinder send? | Only the customer's own SaaS APIs (Salesforce, RENXT, etc.), pinned by the connector base-URL allow-list. |
| Is there a backend / control plane we have to trust? | No. Pathfinder is a local desktop app. |
| What happens to our data if we uninstall? | The workspace SQLite stays on your disk. Pathfinder owns no remote copy. |
| How are migrations approved? | A signed entry in the per-workspace audit-log chain, written before the migration runs. |
| How are tampered audit logs detected? | Chain seal recomputes the Merkle root; verify_chain fails fast on hash mismatch. |
| Do you do third-party penetration tests? | Not currently. Decision documented in ENTERPRISE_HARDENING_PLAN.md §21. |
Maintenance
This document refreshes on every release tag. The owning pathkeepers are domain/security + lifecycle/contract-reviewer.
Have procurement questions?
Email security@colbysdatamovers.com or book a discovery call.
Book a discovery call →