One+
Operational intelligence, built on trust.
Data Governance & Privacy Plan

Becoming a multi-tenant data platform — without becoming a data swamp.

With deep ingestion from ONTRACK, Duty of Care/SAFETOGO, Traxo, HubSpot, and future connectors, One+ is no longer a portal. It's a multi-tenant platform that handles PII, travel and location data, CRM data, and financial-adjacent ticket data. The safe posture: collect narrowly, store intentionally, isolate tenants aggressively, audit sensitive access, redact AI context, and make deletion and retention real from day one.

01Executive Summary

One+ should assume it will process regulated or sensitive business data.

Data we'll handle
  • Traveler names, emails, profiles, routes, trip dates, locations
  • Unused ticket values, ticket numbers, airline credits
  • Duty-of-care alerts and traveler risk/location signals
  • HubSpot contacts, companies, deals, account notes, activity history
  • Vendor credentials and API tokens
  • AI-derived summaries and recommendations
Main risks
  • Pulling too much data because APIs make it easy
  • Cross-tenant leakage between client organizations
  • Exposing location/duty-of-care data to the wrong role
  • Storing raw HubSpot/Traxo payloads full of hidden PII
  • Sending sensitive data into AI prompts
  • Inability to delete, export, or explain what data we hold
  • Weak vendor/customer contracts on processing and subprocessors

02Operating Principles

The non-negotiable rules behind every connector, table, and prompt.

01 · Purpose first

Every field needs a product reason. "Might be useful later" is rejected.

02 · Field allowlists

Each connector gets explicit fields, classifications, browser exposure rules, AI rules, and retention.

03 · Tenant isolation

Every persisted record is scoped by organization_id. Every query and cache key includes tenant context.

04 · No raw payloads

Raw vendor JSON is disabled unless explicitly approved, encrypted, access-restricted, and short-lived.

05 · Least privilege

Roles separate admin, accounting, travel manager, duty-of-care, traveler, internal support, and AI/system access.

06 · Audit sensitive access

Audit connector changes, sensitive reads, exports, admin changes, syncs, deletion jobs, and support access.

07 · AI as controlled processor

AI gets aggregates and redacted context by default — not full raw records.

08 · Retention from day one

Every data class has a retention period and a deletion/offboarding path.

03Phase Plan

Seven phases that move One+ from an open portal to an enterprise-ready data platform.

1
Governance Foundation

Create the rules before adding more ingestion.

Deliverables

  • Finalize SECURITY_AND_PRIVACY.md
  • Maintain DATA_INVENTORY.md
  • Require CONNECTOR_REVIEW_CHECKLIST.md for every connector
  • Assign internal owners for security/privacy, data inventory, vendor contracts, and incident response
  • Decide whether One+ is controller, processor, or both for each customer relationship
  • Draft customer DPA, privacy notice, subprocessor list, and incident response plan

Outcome

No connector goes to production without a documented privacy and security review.

2
Data Architecture

Prepare storage as if all connectors will persist data.

Deliverables

  • Add normalized tables: organizations, connector credentials metadata, connector runs, travelers, trips, ticket credits, duty-of-care alerts, CRM companies/contacts/context, audit events
  • Require organization_id on all tenant records
  • Add row-level security or equivalent tenant enforcement
  • Store connector run metadata separately from PII
  • Keep raw payload archive off by default
  • Add retention fields: source, source_record_id, ingested_at, expires_at, deleted_at

Outcome

The database supports deep data without becoming a pile of untraceable vendor blobs.

3
Connector Intake Process

Treat every connector as a controlled ingestion pipeline.

For each connector, define

  • Purpose, endpoint/object list, field allowlist, field classification
  • Role access, AI access, retention, sync frequency, deletion behavior
  • Vendor and customer contract permissions

Outcome

Each connector has a bounded, reviewed ingestion contract.

4
Access Control & Audit

Build controls before exposing deep data in the UI.

Deliverables

  • Role matrix: traveler, travel manager, accounting, duty-of-care admin, org admin, internal support
  • API-level authorization checks per data type
  • Audit logging for sensitive reads, exports, credential updates, syncs, role changes, support access, and deletion jobs
  • Export restrictions and a break-glass support process

Outcome

Users only see what their role and organization permit, and sensitive access is reviewable.

5
AI Safety Layer

Make AI useful without turning it into a data leak.

Deliverables

  • AI data policy by connector
  • Redaction utilities for names, emails, ticket numbers, PNRs, phone numbers, exact locations
  • Aggregate AI context preferred: counts, totals, trends, risk categories, compliance summaries
  • Explicit approval required for record-level AI context
  • Do not log full prompts/responses containing PII
  • Track which provider processed which request

Outcome

AI can answer business questions without casually receiving all raw customer data.

6
Legal & Compliance Readiness

Put external protections around the product.

Deliverables

  • Customer MSA, DPA, privacy policy/product privacy notice
  • Subprocessor list, vendor DPAs and security reviews, cyber insurance
  • Incident response plan, data retention policy
  • Data deletion/export request process
  • Security policies: access control, change management, vendor management, incident response, encryption/secrets, vulnerability management

Outcome

The company can sell and operate the platform with the legal and compliance wrapper expected of B2B SaaS handling PII.

7
Security Program & Evidence

Prepare for enterprise customers and future SOC 2.

Deliverables

  • Centralized audit logs, access reviews, MFA enforcement
  • Least-privilege production access
  • Dependency scanning, secret scanning, vulnerability management
  • Backup and recovery testing
  • Pen test before large customer rollout
  • Evidence folder for policies, reviews, incidents, access approvals, vendor reviews

Outcome

Not just secure in code — we can prove the controls exist.

04Connector-Specific Posture

Each integration carries its own risk profile and a default approach to ingestion.

Connector Risk Default Approach
ONTRACK Plus Ticket numbers, traveler names, values Persist normalized ticket credits only
Duty of Care / SAFETOGO Location and risk data Aggregate by default; restrict detail access
Traxo Itinerary, location, compliance Persist normalized trips and segments; avoid raw payloads
HubSpot CRM PII, notes, activity bodies Start with companies/deals/account context; exclude notes initially
AI providers Prompt leakage Aggregates and redaction; no raw PII by default
PII Location data Financial-adjacent Cross-tenant risk Tenant-scoped Allowlisted fields Auditable

05Immediate Next Steps

Before the next connector lands, these need to be in place.

  1. Treat the new docs as release gates.
  2. Add a required connector review before Traxo or HubSpot work starts.
  3. Create a real data model for persisted connector data.
  4. Define a role matrix for ticket, trip, CRM, and duty-of-care views.
  5. Decide whether HubSpot notes and activity bodies are excluded by default.
  6. Decide retention windows for ticket, trip, duty-of-care, and CRM data.
  7. Add audit logging infrastructure before adding deep data views.
  8. Draft DPA, privacy notice, subprocessor list, and incident response plan with counsel.
North Star

One+ should become a trusted operational intelligence layer — not a data swamp. The product can know a lot, but only because every piece of data has a reason, an owner, a retention period, an access rule, and an audit trail.