The same questions come up in nearly every onboarding: how is data hosted, how is it secured, how do users authenticate, what happens during an incident, and who else touches the data. The answers below apply to every edition of Wellbeing Matters @ Work (Workplace, University, Life, Veterinary, Sport, School Kids/Youth, In Aging Well, Bespoke). Where a specific edition narrows the scope further, that’s called out in your contracted Statement of Service at signing.
For deployment-specific questions (data residency override, sub-processor scope changes, contracted MFA / SSO commitments, pen-test scope, etc.) request the deployment-specific questionnaire response from your representative under NDA.
Short version: respondent identity, response answers, and audit / operational logs. Card payments are processed by Stripe, and card details never reach the application.
Across every edition the platform stores and processes the following:
Stripe. Card details are entered into Stripe’s own payment form and never reach our servers; the application keeps the purchaser’s name and email, the amount, the currency and Stripe’s payment reference. Invoiced subscriptions are billed through Zoho Books. The platform never sees credit-card or bank-account numbers.Short version: production data is hosted at the SiteGround Tier-1 data centre closest to your country, with optional residency lock to a single region.
Production hosting is on SiteGround Hosting Tier-1 data centres. Your data sits at the location closest to your country. The available regions are Sydney (Australia), Singapore, Iowa (USA), London (UK), Frankfurt (Germany), Eemshaven (Netherlands), matching the residency map published in our Privacy Policy.
For deployments that require data not to leave a single jurisdiction (e.g. an Australian government-adjacent contract or an EU-only public-sector contract), residency can be locked to a single region under your contract. The locked region is documented in your Statement of Service and enforced at provisioning time. Each SiteGround facility provides 24×7 human security, biometric access control, and video surveillance.
Short version: nightly encrypted backups are held in Australia with Backblaze B2, kept on a daily, weekly and monthly cascade, and are never web-accessible.
mysqldump), compressed, checksummed and written outside the web root, then copied off-site to Backblaze B2, where it is encrypted at rest. Each response is also archived off-site as it is submitted.Short version: administrators sign in with email + password (bcrypt-hashed, never stored in plain text); respondents use a single-use access link delivered by email.
password_hash() with bcrypt; plain-text passwords are never stored or logged.Short version: yes: SAML 2.0 and OIDC, with group-claim mapping for role assignment.
Yes. SAML 2.0 and OIDC are supported. SSO is configured against your tenant for the administrator surface (the dashboard side). Group-claim mapping is supported so security groups in your IdP drive administrator / co-administrator role assignment automatically, with no per-user role provisioning needed.
The respondent surface remains link-based by default. Respondents in the field don’t always carry corporate credentials on personal devices, and forcing IdP authentication on the evaluation itself would block the offline-capable Card-mode use case for sites without reliable connectivity. SSO on the respondent side can be enabled if your contract requires it.
Short version: four role tiers, all enforced server-side, every query scoped by tenant and role.
Yes. The platform implements four role tiers, all enforced server-side:
Every data query is scoped server-side by subscription_id / org_id against the role on the active session. Role checks are enforced in the data layer, not just the UI. Hiding a button is never the security boundary.
Short version: yes, by policy. Platform administrators always sign in with a one-time code sent by email, and a client organisation can require the same of every administrator and viewer on its subscriptions. With SSO, your identity provider’s MFA applies.
Short version: yes: AES-256 at the file-system level, plus application-level hashing for credentials and tokens.
Yes. Hosting facilities encrypt disk volumes at the file-system level using AES-256. Database files, backup archives, and uploaded media all sit on encrypted volumes. Application-level: passwords are bcrypt-hashed; auth + reset tokens are stored as one-way hashes; session tokens are random 32-byte values.
Short version: yes: HTTPS only, TLS 1.2 minimum, HTTP redirected at the edge.
Yes. All traffic to and from the application is HTTPS only with TLS 1.2 minimum. Plain HTTP requests are 301-redirected to HTTPS at the edge. SSL certificates are managed via Let’s Encrypt with auto-renewal. Internal service-to-service traffic (PHP ↔ MySQL, backup write, internal log fan-out) uses the hosting provider’s private VLAN inside the contracted region.
Short version: application patches deploy continuously; OS / database patches are applied by the hosting provider within 72 hours of vendor publication, faster for critical CVEs.
Short version: continuous static + dependency scanning on every change; quarterly external application scans; ad-hoc after major architectural change.
Short version: annual independent third-party pen test, plus an interim spot-test after any major architectural change.
Short version: yes: documented, tested at least annually, covers triage through post-incident review.
Yes. The Good Foundry maintains a documented Security Incident Response Plan covering: triage, severity classification (P1–P4), containment, evidence preservation, customer notification, root-cause analysis, and post-incident review. The plan is reviewed and tested at least annually.
Detection inputs include:
error_log table: every error captures timestamp, level, source, message, context (stack trace + request body), request id, user email, IP, user agent.activity_log table: every administrator action against a client record (entity type, action, detail, actor, request id, timestamp).Short version: yes: direct email + phone call to your nominated administrator, with a written incident summary, regardless of mandatory-notification thresholds.
Yes. Where a confirmed security incident or data breach impacts your data, your nominated administrator(s) on record will be notified directly via email and follow-up phone call, with a written incident summary describing scope, root cause, impact, remediation actions taken, and forward-looking changes. Notice is sent regardless of whether the incident reaches the threshold for mandatory notification under the Australian Privacy Act’s Notifiable Data Breaches scheme, the GDPR (EU), or your local equivalent.
Short version: initial notice within 72 hours; detailed report within 30 days; weekly updates while an incident is open.
Short version: The Good Foundry operates to ISO 27001-aligned controls; our hosting provider is independently ISO 27001 certified; our billing sub-processor is SOC 2 Type II attested.
Short version: yes: under mutual NDA we can supply policies, architecture overview, pen-test summary, sub-processor list, and DPA.
Yes. The following can be supplied to your InfoSec team under mutual NDA:
Short version: only for support requests you raise, implementation, or active incident response. Never for marketing, analytics, or AI model training.
Limited. Only the following circumstances apply:
In no other circumstances does TGF staff access your production data. Your response data is never used for marketing, analytics, AI model training, or any purpose outside delivering the contracted service. Your data is never sent to a third-party AI service for training purposes. If any optional AI Power-Up is contracted (e.g. AI Seeding, Let’s Talk, Coaching & Leadership Videos), the scope and data flow is documented separately and explicitly opt-in.
Short version: yes: every action lands in activity_log, every sign-in in auth_sessions, errors in error_log, plus the host-level access log. Retained 12 months minimum.
Yes. Every administrator action against a customer record writes to:
activity_log: structured per-entity audit trail (entity_type, entity_id, action, detail, user_email, request_id, timestamp).auth_sessions: every sign-in event with email, IP, user agent, request id, timestamp.error_log: admin-triggered actions that fail, for forensic reconstruction.Log records are retained for 12 months minimum and can be exported on request.
Short version: yes: full export, full deletion, or hybrid, at no cost. Backup-tape rotation completes within 35 days of a deletion request; a deletion certificate is provided.
Yes. On contract termination you may request, at no cost:
The mechanism, timeline, and data-return format are documented in the Master Services Agreement / DPA before contract execution.
Short version: yes: a tightly scoped list, all bound by confidentiality + data-processing agreements. Optional AI Power-Ups are explicitly opt-in and not in the default scope.
Yes. The following sub-processors are engaged for the platform’s default deployment. Each is bound by a confidentiality and data-processing agreement (per Privacy Policy: "we sign confidentiality and data processing agreements with all third-party service providers"). Any optional AI or video sub-processor underpinning a contracted Power-Up (e.g. AI Seeding, Let’s Talk, Coaching & Leadership Videos) is not in the default scope. It is engaged only when that Power-Up is explicitly contracted, with the third party named and the data flow documented in writing under the contract.
| Sub-processor | Purpose | Region | Data accessed |
|---|---|---|---|
| SiteGround Hosting | Application hosting, MySQL database, nightly backups, web-server access logs | Your contracted region | All in-scope data |
| Let’s Encrypt / ISRG | TLS certificate issuance for HTTPS | Global certificate authority | None: public-key validation only |
| SMTP relay (hosting provider) | Transactional email delivery (respondent invitations, password resets, admin notifications, scheduled reports) | Your contracted region | Recipient email address + email body |
| Zoho Books / Zoho Billing | Subscription billing, invoicing | Per-tenant Zoho data residency | Your billing contact name + email only. No respondent data, no response data |
| Google Workspace (TGF internal) | Internal email, support ticket management for designated client contacts | The Good Foundry’s own region | Names + email addresses of designated client contacts only |
| Backblaze (B2) | Encrypted off-site backup on a daily, weekly and monthly cascade | Australia | Full database snapshot, encrypted at rest |
| Stripe | Card payments | AU / US entities per billing region | Purchaser name + email, amount and currency. Card details never reach our servers |
| MyMemory (Translated srl) | Translation of interface and question text | European Union (Italy) | Interface and question text only. Nothing a respondent has typed or answered |
| Google (Translate) | Second translation provider, and the cloud read-aloud voice | United States | Interface and question text only. Nothing a respondent has typed or answered |
The canonical, version-pinned sub-processor list (cited as Schedule A of our Data Processing Agreement) lives on its own page so the DPA can reference a stable URL:
Open the live Sub-Processors list →
The table above is the default scope as of v1.2 (6 Oct 2026), kept inline for InfoSec teams reading this FAQ end to end. Power-Up sub-processors (Anthropic, ElevenLabs, Twilio, LiveAvatar, HeyGen, Google NotebookLM, Google Health / Fitbit, Google Gemini and Zoom) are engaged only when the matching Power-Up is contracted, and are listed with what each can access on the versioned page.
The questions above cover what applies across every edition. If your InfoSec team has a vendor questionnaire, contracted residency requirement, or specific control frameworks they’re assessing against (ISO 27001, SOC 2, Essential Eight, IRAP, NIST CSF, GDPR), we’ll respond directly against the format they use.