reference vendor security posture

Posture model

For each vendor, we track:

• Data flow direction (operator-side → vendor / vendor → operator-side / bidirectional)
• PII level transferred (per reference_data_classification.md)
• Auth method (OAuth / API token / cookie+CSRF / session)
• Token rotation cadence (target: 90 days for production-critical)
• DPA status (Data Processing Agreement — whether the vendor has one with the operator)
• Incident contact (how the vendor would notify us of a breach)
• Sub-processors (who they share with)

Risk register

Tier 1 — Critical (full PII access)

#### Cloudflare (Pages + KV + Workers)

• Role: PWA hosting, approval queue (KV), Worker Functions for /api/dismiss /api/feedback /api/capture
• Data flow: approval queue items (lead names, draft bodies, recipient emails) flow operator-side → CF KV. CF returns approval state back.
• PII level: L3 (Sensitive)
• Auth: Account-level API token (in Keychain cloudflare_api_token)
• Token rotation: Last rotated ~2026-04-24. DUE: 2026-07-23
• DPA: CF standard DPA + GDPR addendum applies (CF business plan)
• Incident contact: trust@cloudflare.com (per CF security.txt)
• Sub-processors: CF data centers (global edge); Joseph's project pinned to ORD/DEN region for proximity
• Concentration risk: HIGH — single vendor for hosting + KV + Worker. If CF outage, PWA + approvals down.

#### Google Workspace (Gmail + Calendar + Drive)

• Role: Email I/O, calendar source, file storage (Drive sync mirrors ~/Desktop/SkyRun)
• Data flow: all operator's prospect emails, transcripts, calendar events, deliverables
• PII level: L3 (full prospect dataset transits Gmail; full property docs in Drive)
• Auth: OAuth 2.0 via Gmail/Calendar/Drive MCP connectors. Refresh tokens held by Claude harness (NOT in secrets.py).
• Token rotation: Google handles refresh-token rotation automatically. Re-consent annually or on scope change.
• DPA: Google Workspace Business Standard DPA applies
• Incident contact: Google admin alerts via Workspace admin console
• Sub-processors: Google's own data centers; Workspace Business agreement
• Concentration risk: HIGH — operator's primary workspace. Mitigations: Drive 2-step verification, account-level MFA, Workspace audit log enabled.

#### HubSpot (Sales CRM)

• Role: Source-of-truth for active prospect records, deal pipeline, contact engagements
• Data flow: bidirectional — operator pushes new leads + reads/updates deal stages
• PII level: L3 (full contact records: name, email, phone, address, deal value, notes)
• Auth: Cookie + CSRF token via Chrome session (chrome_bridge). NOT a proper API token.
• Token rotation: Cookie session tied to login; re-auth weekly or on session timeout
• DPA: HubSpot Pro DPA applies
• Incident contact: trust@hubspot.com
• Sub-processors: HubSpot infrastructure (AWS-hosted)
• Migration TODO: move to Private App API token (scoped) instead of cookie-CSRF. Deferred — current works.

Tier 2 — Important (PII + revenue data)

#### Track (PMS)

• Role: Property management actuals — bookings, ADR, occupancy, owner-side reports
• Data flow: READ-ONLY from chrome_bridge'd browser session
• PII level: L3 (booking guest names, dates, revenue per property)
• Auth: Browser session (CSRF). No automated token.
• DPA: Track standard SaaS agreement
• Migration TODO: Track API integration (Phase 2+)

#### KeyData (Market analytics)

• Role: Market-level ADR + occupancy benchmarks for projection deliverables
• Data flow: READ-ONLY benchmark data; no operator PII sent
• PII level: L1-L2 (operator's queries reveal which markets/properties; no prospect data)
• Auth: Browser session
• DPA: KeyData standard

#### SmartLead (Cold outreach platform)

• Role: Sequenced cold-email sender — 3 active campaigns (HOT+WARM, SWITCH, NURTURE+LOW)
• Data flow: operator-side → SmartLead (CSV uploads via browser injection); SmartLead → Gmail (sends from operator's Workspace addresses)
• PII level: L3 (lead emails + names + property data flow into SL CSVs)
• Auth: Browser session (no API key in use yet)
• DPA: SmartLead Premium SaaS agreement
• Concentration risk: MEDIUM — 209 leads currently enrolled. SmartLead breach would expose all enrolled prospect emails.

#### BeenVerified (Premium contact enrichment)

• Role: Owner-name → personal email/phone enrichment
• Data flow: operator queries names; BV returns contact data
• PII level: L3 (BV is itself a PII broker; we're consuming PII data they aggregated)
• Auth: Browser session
• Subscription: Premium 400 reports/mo
• Concentration risk: LOW (single-direction read; no operator PII sent)

Tier 3 — Operational (no PII, low risk)

#### ntfy.sh

• Role: Push notifications to operator's iPhone
• Data flow: alert title + short body → ntfy → iPhone
• PII level: L2 (notifications occasionally name a prospect — "Hadank reply RED"). MITIGATION: keep notification bodies short + non-specific.
• Auth: Topic name (Keychain'd ntfy_topic)
• Concentration risk: LOW (anyone with topic name can post; 8-hex random topic provides obscurity-as-defense)

#### Anthropic API + Claude Code

• Role: Inference engine for the entire ambient system
• Data flow: every skill prompt + retrieved context → Anthropic; responses come back
• PII level: L3 (full prospect context flows into prompts; Anthropic's enterprise data-handling applies)
• Auth: Anthropic API key (managed by Claude Code harness; rotation via account)
• DPA: Anthropic enterprise DPA + zero-retention API option
• Sub-processors: Anthropic infrastructure (AWS); reviewed annually
• Concentration risk: N/A — fundamental dependency

#### iCloud (Quarterly backup mirror)

• Role: off-Mac backup target for quarterly_backup.sh
• Data flow: quarterly zip → iCloud Drive
• PII level: L3 (full SkyRun zip = all PII)
• Auth: iCloud account (Apple ID)
• DPA: Apple privacy policy
• Encryption at rest: iCloud Advanced Data Protection (E2E) recommended

#### Operto / RiaMAze / PriceLabs / Rental Guardian

• Role: Operations vendor stack (not yet automated by ambient system)
• PII level: L3 (each holds owner + guest data within their domain)
• Auth: Operator-managed; not yet automated
• Notes: Not in scope for SkyRun ambient automation today; tracked here for completeness.

Vendor incident triggers

If any vendor announces a security incident OR Joseph receives a breach notification:

1. Within 1 hour: Read the incident notice. Identify which data was exposed.
2. Within 24 hours: Rotate all tokens/credentials for that vendor. Run python3 secrets.py rotate <account> <new>.
3. Within 72 hours: Audit operator data for compromise indicators (unexpected access, anomalous activity in vendor logs).
4. Within 7 days: Document the incident in ~/Desktop/SkyRun/audit/incidents/<date>_<vendor>_breach.md with: vendor, scope, data classes affected, mitigations applied, residual risk.
5. If L3 PII confirmed exposed: consider operator's notification obligations under state breach laws (CO Colorado Privacy Act applies to GC operations).

Annual vendor review

Joseph re-reviews this register every quarter (or sooner if relationships change):

• Are all tokens still active and scoped correctly?
• Have any vendors changed sub-processors?
• Have any DPAs expired?
• Has the operator's data footprint at any vendor changed materially?

Add new vendors to this register IMMEDIATELY when integrated.

Cross-references

• reference_data_classification.md — what counts as L3
• reference_incident_runbook.md — IR procedures
• reference_disaster_recovery.md — DR for vendor outages
• reference_security_posture.md — overall architecture