Skip to main content
New: Manufacturing Quotes — source from manufacturers in 35 countries.Start a Project
GH
Security

How GHMAP protects workspace and service data

GHMAP uses encryption, Supabase Row Level Security, organization-scoped isolation, and reviewed authentication so market-access teams can work inside clear access boundaries.

No patient data required

Source-tagged intelligence records

Professional review at every step

Audit-ready decision context

Important notice

This page describes GHMAP's security approach for public website visitors and workspace users. It is not a certification claim, security audit report, legal advice, or guarantee of absolute protection. Market-access content still requires professional review before business use. Do not submit patient data, medical records, passwords, bank information, or confidential contracts through public pages.

Security controls

Controls that shape how GHMAP handles data

01

Data encryption

Workspace and service traffic is protected in transit, and stored data is encrypted at rest by the underlying infrastructure.

  • In transit: client and service connections use TLS so credentials and workspace payloads are not sent in clear text over the network.
  • At rest: database and object storage managed through Supabase use provider encryption at rest for persisted workspace records and related service data.
  • Public demo and inquiry forms should carry only business contact and product context — never passwords, bank details, patient records, or confidential contracts.
  • Encryption is one control among several. Access boundaries, authentication, and operational review remain part of how GHMAP protects workspace data.
02

Row Level Security and multi-tenant isolation

Supabase Row Level Security (RLS) and organization-scoped records keep workspace data separated across tenants.

  • Shared workspace tables are designed around an organization boundary so records belong to a specific tenant, not a global shared pool.
  • Row Level Security policies are intended to limit which authenticated members can read or write rows for their organization.
  • Membership and role checks sit in the access path so one organization’s submissions, projects, and workspace records are not treated as visible to another.
  • Isolation is an architectural requirement for GHMAP’s multi-tenant model. Policy details continue to be reviewed as workspace features expand.
03

Authentication and access control

Workspace access is reviewed and role-aware. Public pages stay separate from authenticated app workflows.

  • Workspace access is invite-only or otherwise reviewed — not open self-registration into operational data.
  • Authentication is handled through Supabase Auth so session identity is tied to membership and role checks.
  • Role-based workspace controls limit what members can see and change according to their assigned organization role where those controls are implemented.
  • Public website behavior on ghmap.io remains separate from authenticated workspace behavior on app.ghmap.io.
04

Responsible disclosure

If you find a security issue, report it privately so it can be reviewed and addressed.

  • Email security findings to security@ghmap.io with enough detail to reproduce the issue without exploiting other customers or tenants.
  • Do not access data that is not yours, disrupt service availability, or attempt social-engineering of GHMAP users or staff.
  • Please allow a reasonable time for review before any public discussion of a vulnerability.
  • Reports that help protect customer and workspace data are welcome; coordinated disclosure helps keep the platform trustworthy for healthcare market-access work.

Contact: security@ghmap.io

Related notices

Security sits alongside privacy, product boundaries, and trust governance. Use these pages for the full picture of how GHMAP handles information and review requirements.

Privacy →Trust →Disclaimer →Start a Project