Evryday Portal is built for program information that should not live in scattered spreadsheets and email threads. This page explains the current access, data handling, and infrastructure posture in plain language.
Participant data handled intentionally
Portal may store participant names and contact details, emergency contacts, waiver status, medical, emergency, passport, driver, and background-related details where the workflow requires those records.
Organization admins can access participant records for their own organization.
Participant-facing access is limited to invited workflows.
Sensitive sections should be shown only where the workflow requires it.
Organization separation
Each organization has its own workspace. Portal should not mix one organization's participants, trips, invitations, reports, or admin access with another organization's records.
The product is designed around tenant-scoped records.
Broader launch should keep tenant separation backed by tests and review.
Security language should point to details instead of relying on a standalone secure claim.
Infrastructure and uptime posture
Portal relies on managed infrastructure, including Supabase and the hosting provider, plus application-level care. Until formal service levels exist, Evryday does not make uptime guarantees, instant recovery promises, or enterprise disaster recovery commitments.
Backup and restore posture should be published before uptime promises are made.
Incident support should use the published contact path.
Sensitive reveal and audit behavior should stay documented as the product matures.