Griffinity

Legal

Security Overview

A plain-language summary of how Griffinity protects accounts, learning data, and platform infrastructure. This is not a formal certification report.

Last updated: 28 July 2026

Griffinity teaches trust, governance, and responsible data practice. We apply the same mindset to our own platform: minimise access, encrypt in transit, separate roles, and prefer managed infrastructure with strong defaults. This page summarises current practices for customers, learners, and partners.

1. Architecture snapshot

  • Application — modern web application (Next.js) served over HTTPS
  • Identity — server-managed authentication with session cookies; passwords handled by the auth provider (hashed; not stored in plaintext by Griffinity)
  • Data store — managed Postgres with row-level security policies to restrict learner, order, progress, and profile access
  • Media — course media delivered via configured hosts; signed or controlled delivery where implemented
  • Payments — card data handled by PCI-oriented payment providers; Griffinity stores payment references/status, not full PAN/CVV

2. Access control

  • Role-based access for administrators versus learners
  • Entitlement checks before paid lesson access
  • Principle of least privilege for staff tooling
  • Administrative actions intended to be attributable to authenticated staff accounts

3. Encryption and transport

  • TLS/HTTPS for data in transit between users and the platform
  • Encryption at rest provided by underlying managed cloud providers according to their service terms and configuration
  • Secrets and API keys stored in environment configuration, not in public repositories

4. Application security practices

  • Input validation and server-side authorization on sensitive actions
  • Protection against common web risks (e.g. injection, broken access control) as part of ongoing development
  • Dependency and platform updates on a maintained cadence
  • Separate handling of public marketing pages versus authenticated learning and admin areas

5. Monitoring and incidents

  • Operational logs for diagnosing errors and investigating abuse
  • Incident response: contain, assess, notify affected customers/controllers where legally required, remediate, and review
  • Security contact: hello@griffinity.com with subject line “Security”

6. Business continuity

Managed providers supply backup and durability features according to plan. Griffinity aims to restore service promptly after infrastructure incidents. Any contractual recovery targets must be agreed in a separately signed statement of work.

7. Your responsibilities

  • Use strong unique passwords and keep credentials private
  • Provide accurate information and promptly request corrections or removals where appropriate
  • Do not upload regulated special-category datasets into free-text fields unless a written agreement covers that processing
  • Keep devices and browsers reasonably up to date

8. Third parties and subprocessors

We rely on reputable managed services for hosting, auth, email, payments, and media. Their security programmes apply to their layers of the stack. See the Privacy Policy and DPA for sharing and processor terms.

9. Limitations

No online system can guarantee absolute security. We cannot fully prevent credential sharing, phishing of end users, or zero-day vulnerabilities in upstream providers. This overview does not create warranties beyond those in our Terms.

10. Vulnerability disclosure

If you believe you have found a security vulnerability in Griffinity, email hello@griffinity.com with steps to reproduce. Please avoid public disclosure until we have had a reasonable chance to investigate and remediate. Do not access data that is not yours or degrade service availability.

11. Contact

Questions about this document: hello@griffinity.com. Postal / registered address details will be inserted once finalised.