For Schools
Pricing
Get StartedSign in
Legal

Security

Last updated on August 16, 2026

Overview

Whollify holds coursework, grades, messages and academic records. For institutions, that is the official record of what a student did. This page describes how we protect it. It is written for the person at a school who has to decide whether to sign, so it also says plainly what we have not built yet.

For what data we collect and why, see our Privacy Policy. For which companies process it on our behalf, see Sub-Processors. Live service status is at status.whollify.com.

How Data Is Protected

  • In transit. All traffic between your browser and Whollify is encrypted with TLS. HTTP requests are redirected to HTTPS, and the site is served with a strict Content Security Policy.
  • At rest. Databases, object storage and backups are encrypted at rest by our infrastructure providers.
  • Passwords. Stored only as salted hashes using a modern password-hashing function. Nobody at Sierra Africa can read your password, and we will never ask you for it.
  • Sessions. Authentication uses HTTP-only session cookies that JavaScript cannot read. You can review and revoke active device sessions from your account settings.
  • Secrets. API keys and credentials are held in the deployment platform's secret store, injected at runtime, and never committed to source control.

Tenant Isolation

Each institution operates in its own logically separated tenant. Every query that reads student data is scoped to a tenant, and authorisation is checked on the server for each request rather than in the interface. Staff at one institution cannot see students, records, submissions or messages belonging to another.

We do not combine data across tenants to build profiles, and we do not use one institution's data to provide the Service to another. Aggregate benchmarks, where used, are computed so that no individual or institution is identifiable.

Access Control

  • Roles. What a person can see and do is determined by the role their institution grants them. Roles are enforced server-side.
  • Least privilege for our staff. Access to production systems is limited to the engineers who need it, is granted individually rather than shared, and is removed when someone changes role or leaves.
  • Administrative access is audited. Access to production data is logged. We access an institution's tenant data only to operate the Service, to resolve a support request, or where required by law.
  • Multi-factor authentication is available on Whollify accounts and required for our own staff on the systems that hold production credentials.

Running Submitted Code

Where a course involves executable work, submitted code is run to grade it. Execution happens in an isolated, ephemeral environment with no access to other users' data, to our production systems, or to credentials. Environments are destroyed after the run. Attempting to escape or subvert a sandbox is a breach of our Terms of Service.

Payment Data

We never see your card details. Payments are handled by Stripe and Paystack, both PCI-DSS compliant, and card data goes directly from your browser to the processor. Sierra Africa stores only a transaction reference and a payment status.

Availability and Backups

Databases are backed up automatically by our infrastructure providers, and backups are encrypted. Deleted data may persist in backups for up to 90 days before those backups rotate out, which is why a deletion request is completed on that timescale rather than instantly.

Current and historical availability is published at status.whollify.com. Institutional agreements may include a specific availability commitment; the public tiers do not carry one.

Incident Response

If a personal data breach occurs, we notify the Nigeria Data Protection Commission within 72 hours of becoming aware of it, and the relevant supervisory authority where the GDPR or UK GDPR applies. Where the breach is likely to result in a high risk to affected people, we notify them directly and without undue delay.

Where we process data for an institution, we notify that institution without undue delay after becoming aware of a breach affecting its tenant, and support it in meeting its own notification obligations. As controller, the institution decides what its students are told.

Reporting a Vulnerability

If you believe you have found a security vulnerability, report it to support@whollify.com. Include enough detail to reproduce it. We aim to acknowledge within 1 business day and to keep you informed while we fix it.

We will not pursue or support legal action against a researcher who, in good faith:

  • Reports promptly and gives us reasonable time to fix the issue before disclosing it.
  • Avoids privacy violations, data destruction, and degradation of the service for other users.
  • Accesses only the minimum data needed to demonstrate the issue, and deletes it afterwards.
  • Does not use their own or a test account to reach other people's coursework or records.

We do not currently operate a paid bug bounty, and we will credit researchers who ask to be credited.

What We Do Not Have Yet

Whollify is an early-stage platform and we would rather you hear this from us than discover it in a questionnaire. As of the date at the top of this page:

  • We do not hold SOC 2 or ISO 27001 certification. We have not begun a formal audit.
  • We have not commissioned an independent third-party penetration test.
  • We do not offer single sign-on (SAML or OIDC) or SCIM provisioning for institutions. Accounts are managed within the platform.
  • We do not offer data residency guarantees. Hosting location follows our providers; see Sub-Processors.
  • We do not currently publish an availability commitment for individual plans.

If any of these is a requirement for your institution, tell us before you sign rather than after. Some are on the roadmap, and knowing which ones matter changes the order.

Security Contact