Security

Pamoja.ai by myGalago is designed to support GDPR requirements and the trust expectations of foundations, schools and trusts handling student, donor and academic data. This page summarises the practical measures in place today. It is not a certification claim.

• Role-based access control, admin, staff (volunteer), donor (sponsor), school and student / alumni roles, each with the minimum permissions required for their job.
• Per-organisation data separation, every record is scoped to a tenant (foundation_id) and access is enforced server-side, including via Postgres row-level-security policies.
• Authentication, passwordless magic-link login by default; multi-factor authentication available for admins.
• Principle of least privilege, service accounts and API keys are scoped to the narrowest permission set that lets them function.

• Swiss primary storage, Supabase (Zurich, eu-central-2) for the database, authentication and file storage. Switzerland holds an EU adequacy decision, so transfers from the EU/EEA require no additional safeguards.
• Edge delivery, Vercel’s edge platform with HTTPS-only access and HSTS.
• Encryption, TLS in transit; at-rest encryption provided by the underlying managed services.

• Audit log, visible to a foundation’s staff: sign-ins, sign-in link requests and selected admin actions (some record edits, imports, exports, emails sent). Staff changes to a student’s record are logged separately with the values before and after. Not every change is logged; signed-in users cannot edit or delete entries, but members of a foundation can add them.
• Error tracking, Sentry, EU region. Request bodies, cookies, query strings and IP addresses are not sent, and email addresses are masked before sending.
• Email deliverability events, Resend webhooks (delivered / bounced / complained / unsubscribed) feed into an audit-friendly communications log.

The database is backed up daily by Supabase, and the last 7 days of backups can be restored (Supabase Pro plan). Stored files such as photos and documents are not part of these backups. Specific recovery objectives can be agreed in a customer-specific annex.

• Customers can export their data at any time during the subscription via the in-app exports surface or by written request.
• On termination, an export window (typically 30 days) is offered before deletion in line with the DPA.
• Customers can request deletion of specific records during the subscription term.

• Messaging inside the portals, donors and students write to each other in the donor and student portals. Neither side is shown the other’s email address or phone number, and a student sees their sponsor only as “Donor”.
• Several sponsors for one student, a student’s message goes to their sponsor, or to all of their current sponsors when they have more than one. Each donor sees only their own messages and the student’s messages sent to them or to all current sponsors; a donor is never shown another sponsor’s messages, attached files or name, and a donor who takes over a sponsorship does not see the previous sponsor’s messages. Read status is kept separately for each donor, so one sponsor opening a message does not mark it read for another. These rules are enforced in the database, not only in the portal.
• No review before delivery, messages and attached files are delivered straight away; the foundation does not review them before the other side can read them.
• Email notifications to donors, when a student writes, each donor the message is for is emailed shortly afterwards with the student’s name, up to 240 characters of the message (or a note that photos were sent) and a link to read and reply in the donor portal. Messages sent close together produce one email, and attached files are never included. A donor can turn these emails off, and back on, with the link at the bottom of each one (or their mail program’s own Unsubscribe button) or in the donor portal; this affects only these emails, and messages still appear in the portal. Foundation staff can also turn them off for a donor who asks, which is recorded in the audit log, but cannot turn them back on once a donor has opted out themselves. They are sent through our email provider (see Subprocessors), and a copy is kept in the foundation’s record of emails sent to that donor. Students are never emailed about messages.
• Staff oversight, foundation staff can read every conversation in their foundation. The admin area shows a badge for conversations with new messages since a staff member last opened them, and the foundation’s contact address and administrators are emailed when a new message arrives. That email names the student but contains no message text and no donor name; staff read the message after signing in.
• Message record, each message is stored with who sent it (donor or student), the student, the donor it was sent by or to where recorded, whether the student has read it, and when it was sent. For a student’s message, each donor’s read status is recorded separately, with the time they opened the conversation.
• Ending access, student portals are off unless Pamoja switches them on for a foundation, and a foundation can end a student’s portal access at any time by removing the portal address. A donor’s portal shows only children they actively sponsor. There is no feature to mute a conversation or to delete a message from the admin area.

• Secrets stored as environment variables in the deployment platform (not committed to source).
• Production database access restricted to the operator and the managed-platform vendor.
• Dependency updates and security advisories monitored continuously.

We track the following enhancements on the roadmap and will update this page as they ship: formal SOC 2 / ISO 27001 alignment, a publicly-published vulnerability-disclosure policy, and configurable per-tenant data-retention rules.

Suspected vulnerabilities or security incidents should be reported to marcbonischarancle@gmail.com with the subject prefix [security]. We will acknowledge receipt within two business days and coordinate a remediation timeline.