For trustees & directors

Data Governance

Effective: 30 September 2026

Your data is yours. Stored in Switzerland. Exportable to Excel at any time.

This page summarises how Pamoja handles your foundation’s data. For the full legal treatment, see our Privacy Policy.

1 · Who owns the data

Your foundation owns 100% of the data in its Pamoja workspace, sponsors, students, schools, payments, communications, every record. Pamoja is the processor; you are the controller. We do not sell or rent your data, and we do not use it to train AI models.

If you leave Pamoja, the data leaves with you. We keep a 30-day grace period after account closure then permanently delete it.

2 · Where the data lives

All data is stored on Supabase (Postgres) in Zurich, Switzerland (eu-central-2). Switzerland benefits from a European Commission adequacy decision, so transfers from the EU/EEA require no additional safeguards. Backups are encrypted at rest and in transit. The application’s server functions run on Vercel in Paris, Dublin, Frankfurt and London, and pages are delivered through Vercel’s global edge network. Both providers are SOC 2 Type II certified and sign data-processing agreements under GDPR.

Some services that process personal data operate outside the EU/EEA and Switzerland, or have not yet confirmed their processing region: the AI provider (Anthropic), email delivery (Resend), sign-in with Google or Microsoft, Google Drive where a foundation keeps documents there, the anti-bot check on public forms (Cloudflare) and maps (OpenStreetMap, CARTO). The full list, with what each receives and where, is on our Subprocessors page.

3 · Who can see what

Every query made with a signed-in user’s credentials passes through row-level security in the database, so a user cannot read data from a foundation they do not belong to. Server-side features that need wider access (for example the donor and student portals, which show a fixed set of fields) use a privileged connection and apply the same foundation scoping in code. Pamoja’s platform operator can access foundations to provide support. Inside your workspace, access is governed by roles:

  • Admin, full read/write, manages team and settings.
  • Staff, scoped edit access to students, sponsors, schools, grades, events, programmes, leads.
  • Auditor, read-only on students, donors, schools, grades, audit trail.
  • Sponsor, limited portal: only the students they sponsor, and only the fields the portal shows (no contact details, home location, date of birth, fees or family details).
  • Student, off by default: student portals are switched on per foundation by Pamoja, and the database refuses a portal address while they are off. A student sees their own results, uploads and messages, not their fee balance or whether a sponsor has read their message.
  • School, email-invited portal for partner-school staff, revocable by an admin at any time.

Sign-ins are recorded in an audit log: staff and donor sign-ins by the database, student and alumni portal sign-ins by the application. The log also records sign-in link requests and a selection of admin actions, such as record edits made from some screens, imports, exports and emails sent. When a staff member changes a student’s record, the change is recorded separately with the values before and after. This is not a complete record of every change. Signed-in users cannot edit or delete audit entries, but members of a foundation can add entries to its log, and Pamoja’s server processes can change it. Your foundation’s staff can view its audit log in the admin area.

4 · Getting your data out

Admins can export every table (students, sponsors, payments, academic results, communications, audit log, …) to Excel / CSV directly from the Exports page. No request form, no waiting period, no lock-in.

If you decide to migrate to a different platform (Salesforce, Airtable, a spreadsheet), you can do so with one export and no data-escape fees.

5 · Security posture

  • TLS 1.2+ for all traffic; no plaintext endpoints.
  • Passwordless magic-link authentication, no password database to leak.
  • Row-level security enforced at the database layer, not just the application.
  • Daily database backups, kept for 7 days (Supabase Pro plan). Stored files such as photos and documents are not part of these backups.
  • Sign-ins, sign-in link requests and selected admin actions are recorded in the audit log (section 3).
  • Vulnerability disclosures and security questions: contact@pamoja.ai.

6 · Sub-processors

  • Supabase, database, sign-in and file storage, Zurich.
  • Vercel, application hosting, EU and UK server functions.
  • Anthropic, AI features used by foundation staff (documents, narratives, data assistant).
  • Resend, email delivery.
  • Sentry, error monitoring, EU region, personal data removed before sending.
  • Google and Microsoft, sign-in; Google Drive where a foundation stores documents there.
  • Cloudflare, anti-bot check on public forms.
  • OpenStreetMap, CARTO and unpkg, maps.
  • Stripe, foundation subscription billing.

What each one receives, and where it operates, is on the Subprocessors page.

We notify admins by email before adding a new sub-processor with access to personal data.

7 · Incident response

In the event of a security incident affecting your data, we notify affected foundation admins within 72 hours of confirmation, in line with GDPR Article 33. The notice describes what happened, what data was involved, what we are doing, and what you should do.

Questions

Governance, procurement, audit or security questions go to contact@pamoja.ai.

We reply within two working days and happily hop on a call with your board or audit committee.

← Back to homePrivacy PolicyTerms of Service