Security and data handling

What Wisteria can see

Access is read-only. Every permission Wisteria requests from a connected system is a read permission. It cannot create, modify, or delete anything in your Microsoft 365, Google Workspace, or Lark tenant.

The specific scopes:

Directory.Read.All on Microsoft 365 is the broadest of these. It is used to resolve who a document is for, so a suggestion can be aimed at the right department. It is still read-only.

Wisteria does not request mail, calendar, chat, or contacts from any provider.

The scan covers the connected workspace, not a folder you choose. There is currently no way to limit the scan to specific folders or sites. What bounds it instead is the size and reach of each scan:

Scan frequency is fixed, not configurable. One scheduled scan per day, plus that manual button for admins.

You can disconnect at any time. Settings → Integrations → Disconnect immediately deletes the stored connection and credentials, and the scan stops. Two things to know:

Every API call Wisteria makes is also logged on your side, in your own provider’s audit log, independently of Wisteria.

Your documents and AI

Your documents are not used to train any AI model — not Wisteria’s, and not a third party’s. Wisteria does not train models.

Content is sent to external AI providers to produce a result and return it. It is not processed in-house.

Both providers state that data submitted through their APIs is not used to train their models.

Spoken quiz audio is never stored. The recording is sent for transcription and discarded. Only the resulting text is saved to your workspace.

If you supply your own AI provider key, your content goes to your own account instead, under your own agreement with that provider.

Where your data lives

Everything Wisteria stores about your workspace — user records, course content, quiz results, audit logs — is held in Singapore. It is not stored in the United States. Content sent for AI processing does go to the US, is processed, and is returned; it is not stored there.

Tenant separation. Wisteria uses one shared database, with every row tagged to a workspace. Separation is enforced by PostgreSQL row-level security, meaning the database itself filters every query to your workspace — not the application code. A mistake in application code cannot expose another customer’s data.

This is not separate databases per customer. If you require physical database separation, Wisteria does not offer it today.

Backups are taken daily and stored in the same region as the primary database. Point-in-time recovery covers the previous 7 days.

Encryption

In transit — HTTPS everywhere, TLS 1.2 or higher. This covers your browser to Wisteria, Wisteria to its database, and Wisteria to every AI provider and connected system.

At rest — the database, its backups, and file storage are encrypted on disk using AES-256.

Some values are encrypted a second time by Wisteria before they are written, using AES-256-GCM, so they remain unreadable even to someone holding the database: integration credentials, AI provider keys where a customer supplies their own, webhook signing secrets, and Slack webhook URLs.

Passwords are stored as bcrypt hashes. Plaintext passwords are never written to the database. After five failed sign-in attempts an account is locked for 15 minutes, enforced server-side.

Who can access your data

Wisteria is operated by one person, its founder. There are no employees, no contractors, and no outsourced support. Nobody else has access to your workspace.

That one person can access production data. It is used for two things: investigating a fault, and responding to a support request you have raised. It is never used to read your training content out of interest, and never for any commercial purpose.

The honest limits of that, so you can weigh them:

If consented, logged support access is a requirement for your organisation, tell us. It is a reasonable thing to ask for, and we would rather build it than claim we already have it.

This section changes when the team does. It is dated for that reason.

Staff phone numbers

Frontline staff often have no company email, so Wisteria lets them sign in with a phone number instead.

What is stored: the phone number, on the employee’s profile. Nothing else — no device identifiers, no location, no contacts.

What it is used for, and nothing else: signing in; delivering the initial invitation and temporary password when the employee has no email; and a one-time code when they forget their app PIN.

Training reminders and notifications do not use the phone number. Those go by email, web push, or in-app.

The number is never used for marketing. It is never sold, rented, or shared with third parties. The only external party that receives it is the messaging provider that delivers the two message types above.

When an employee leaves, deleting their account removes the phone number and the sign-in record. Deactivating an account instead keeps the number on file — delete rather than deactivate if removal is what you need.

Roles. Your organisation is the data controller and Wisteria is the processor. You decide what goes in; Wisteria processes it on your instructions. Employers should obtain staff consent for collecting and using work phone numbers under their own PDPA obligations.

Access controls inside Wisteria

Five roles: learner, auditor, trainer, content manager, super admin.

Authoring is restricted to trainers. Super admins govern the workspace but cannot author or edit training content. Auditors are read-only.

Nothing reaches staff without approval. A course cannot be published while any module is still in draft or awaiting approval, and at least one module must be approved. Approval workflows are configurable per organisation.

Audit trail. Every consequential change is recorded — who did it, what changed, and when — including approvals, rejections, role changes, and publishing. Visible to super admins and auditors, exportable.

The audit log records changes, not reads. Viewing a course or a user list does not create an entry.

Single sign-on is not available. Wisteria does not currently support SAML or OIDC. Sign-in is by email and password, or phone and password, with an optional device PIN and biometric unlock on shared devices.

Retention and deletion

While you are a customer:

Deleting a person removes their profile, sign-in account, progress, results, assignments, and certificates. Audit entries recording their past actions are retained for compliance, showing the name as it was at the time.

When a contract ends, Wisteria deletes or returns your data, at your choice, within 30 days of termination.

On request, Wisteria deletes personal data within 30 days, subject to legal hold.

Backups are overwritten on a rolling cycle. Data in a backup is removed as that cycle turns rather than at the moment of deletion.

PDPA and GDPR

Your organisation is the data controller. Wisteria is the data processor, acting on your documented instructions.

A Data Processing Agreement is available on request, covering processing scope, sub-processors, international transfers, breach notification, and deletion.

Sub-processors: Supabase (hosting and database, Singapore), Anthropic (AI generation, US), OpenAI (speech-to-text, US), Resend (email delivery, US), and the messaging provider used for phone-based sign-in.

Customer data is stored in Singapore. Content sent for AI processing is transmitted to the US, processed, and returned.

Wisteria is operated by 369 Sales Academy PLT, registration 202604000656 (LLP0045881-LGN), registered in Malaysia.

What we don't have yet

Wisteria is a young product and we would rather be accurate than impressive.

If any of these is a requirement for your organisation, tell us — it helps us prioritise, and we would rather you knew now than during procurement.

Questions

Security questions, or a security questionnaire you need completed: security@getwisteria.com

We will complete your own vendor security questionnaire — send it over.