Skip to content
Menu
PLAYORA

SECURITY

Built to be examined.

Security should not depend on claims you cannot verify. Here is how PLAYORA protects institutional and student data, and the controls behind it.

Data isolation

Database enforced

Access control

Role based

Auditability

Activity recorded

India hosting

Primary data

Five controls. How they work.

Security language is easy to write. Controls are harder. These are some of the mechanisms PLAYORA uses to protect institutional and student data, along with how they are enforced or verified.

  1. Institution data stays separated

    Each institution operates within its own data boundary.

    PLAYORA uses PostgreSQL row-level security (RLS) to enforce tenant isolation at the database layer. Application requests operate within the context of the relevant institution, and database policies restrict which records can be returned.

    The application connects using a non-superuser database role without BYPASSRLS, so application code cannot simply bypass those policies.

    If a valid institution context is not present, protected queries are designed to return no institution records rather than expose data across institutions.

    Tenant-isolation behaviour is also covered by automated tests as part of the development and deployment process.

    How it is checked

    Database-enforced row-level policies and automated tenant-isolation tests.

  2. Primary data is hosted in India

    PLAYORA’s primary application data is hosted in India by default, on Amazon Web Services (AWS) in the Asia Pacific (Mumbai) region, ap-south-1.

    AWS operates the data centre and its physical, environmental and network controls. How PLAYORA is built, configured and accessed remains ours, and is what the rest of this page describes.

    We select infrastructure and service providers with security, reliability and data-handling requirements in mind.

    Where supporting service providers or subprocessors are used, their role and applicable data-handling requirements are reviewed as part of our security and privacy practices.

    How it is checked

    Infrastructure configuration, region selection and service-provider review.

  3. Authentication is designed around modern standards

    PLAYORA uses established authentication and token-security practices to reduce the risk of unauthorised account access.

    Depending on the application and authentication flow, these controls include:

    • OAuth 2.0 authorization-code flows with PKCE
    • Ed25519-signed access tokens
    • separate token audiences between applications
    • rotating refresh tokens
    • refresh-token reuse detection
    • Argon2id password hashing where passwords are managed by PLAYORA

    How it is checked

    Authentication tests, token validation and application security review.

  4. Important activity is auditable

    PLAYORA maintains audit information for security-relevant and administrative activity where appropriate.

    Audit records are designed to help authorised teams understand who performed an action and when it occurred.

    Controls are applied so that ordinary application users cannot modify protected audit records through normal application access.

    How it is checked

    Application audit records and database-level access restrictions.

  5. Access follows the principle of least privilege

    Users should only be able to access the information and actions required for their role.

    PLAYORA uses role-based access controls to separate responsibilities between institutional administrators, sports teams, students and other authorised users.

    Access controls are enforced by the application and supporting data-access policies rather than relying solely on what is visible in the user interface.

    How it is checked

    Role and permission testing across protected workflows.

How institution isolation works

A request belongs to one institution. That context travels with it to the data layer, where row-level policies decide which records can be returned.

A request from one institution carries that institution’s context to the data layer. PostgreSQL row-level security policies then restrict which records can be returned, so a request made in the context of Institution A can reach Institution A records and not those of Institution B or Institution C. If a valid institution context is not present, protected queries are designed to return no institution records rather than expose data across institutions.

Flow diagram. Institution A makes a request, which passes through the shared request path and returns only that institution’s records.

Who can access what

PLAYORA is designed so that different users interact with different parts of the sports programme.

  • PLAYORA Campus

    Authorised institutional staff, managing sports operations.

    Access may include

    • events
    • registrations
    • eligibility
    • trials
    • selections
    • fixtures
    • results
    • participation records
    • reporting

    Boundary

    Access depends on the user’s assigned role. Campus users do not automatically receive unrestricted access simply because they belong to the institution.
  • PLAYORA Athlete

    Students, interacting with their own sports journey.

    Access may include

    • information made available to them through their institution
    • functionality relevant to their own participation

    Boundary

    Students are not given administrative access to the institution’s sports-management environment.

PLAYORA Central

Coming soon

PLAYORA Central is being developed for university-level visibility across affiliated institutions.

Its final security, permission and data-access model will be documented before the product becomes generally available.

Student data and privacy

PLAYORA is designed to support institutions in handling student and sports-programme information responsibly and in accordance with applicable data-protection requirements.

The institution determines what information is collected through PLAYORA, who within the institution is authorised to access it and the purposes for which it is used.

PLAYORA processes institutional data to provide the services agreed with the institution.

Data retention, access, correction, deletion and other data-handling requirements are governed by applicable law and the agreement with the institution.

For information about personal data collected through the public PLAYORA website, please see our Privacy Policy.

Read the Privacy Policy

Security questions reviewers ask

The questions an IT, security or procurement team raises during a review, answered before you have to ask them.

How is our institution’s data separated from other institutions?

PLAYORA uses tenant-aware application controls together with PostgreSQL row-level security to enforce institution-level data boundaries.

The application database role does not have permission to bypass those row-level policies.

Where is our data hosted?

PLAYORA’s primary application data is hosted in India by default, on Amazon Web Services (AWS) in the Asia Pacific (Mumbai) region, ap-south-1.

AWS operates the underlying data centre. How PLAYORA is built, configured and accessed remains our responsibility.

If your procurement or security team needs more detail about infrastructure, supporting services or data flows, we can provide the relevant information during your security review.

Who within our institution can access the data?

Access is based on assigned roles and responsibilities.

An authorised administrator can be given different permissions from a sports coordinator or student. Users do not automatically receive access to every function or record simply because they have an account.

Can PLAYORA staff access our data?

Access by PLAYORA personnel is restricted to authorised purposes such as providing the service, support, maintenance, security or resolving technical issues.

Access is limited to personnel who require it for their responsibilities and is subject to appropriate internal controls.

Is activity logged?

Security-relevant and administrative activity is logged where appropriate so that authorised teams can investigate actions and operational issues.

Protected audit information is not intended to be editable by ordinary application users.

What happens to our data when our agreement ends?

Data retention, export and deletion requirements are handled according to the applicable institutional agreement, legal requirements and agreed retention arrangements.

We recommend that institutions discuss any specific retention or exit requirements with us during procurement so they can be reflected in the applicable agreement.

How are backups and recovery handled?

PLAYORA maintains backup and recovery measures appropriate to the production environment.

Detailed backup frequency, retention and recovery arrangements can be shared with authorised institutional reviewers as part of the security or procurement process.

What happens if there is a security incident?

PLAYORA maintains processes for investigating and responding to security incidents affecting the service.

Where an incident requires notification to an institution or another party, notification will be handled in accordance with applicable law and contractual obligations.

Does PLAYORA use third-party service providers?

Like most cloud software platforms, PLAYORA may use carefully selected infrastructure and technology providers to operate parts of the service.

Where third parties process data on our behalf, we assess their role and apply appropriate contractual, security and data-protection requirements.

Information relevant to an institution’s security review can be provided during procurement.

Can our IT or security team review PLAYORA before we proceed?

Yes.

We welcome technical and security review as part of an institution’s procurement process.

If your team has a security questionnaire or needs information about architecture, access controls, hosting, data handling, backups or other controls, send it to us and we will provide the information relevant to your review.

What we do not claim

PLAYORA does not currently claim certifications or attestations that it has not obtained, including ISO 27001 or SOC 2.

We prefer to describe controls we actually use rather than rely on security labels.

If your institution requires a particular certification as part of procurement, tell us during the evaluation process so that requirement is clear from the beginning.

We can provide additional information about our security architecture, access controls, hosting, data handling, backup and recovery practices, incident response and supporting service providers as part of an authorised security review.

Need to review PLAYORA?

If you are responsible for IT, information security, procurement or data protection at your institution, we will answer the questions your review requires.