Epistemic — Learning Assessment System

Epistemic LAS policies

Data Security

Verifiable data security controls, responsibilities, and limitations at Epistemic LAS.

Security is a shared responsibility among Epistemic LAS, its providers, and each Institution. This page distinguishes controls verified in code or an environment from commitments that must still be documented contractually; it is not a certification or SLA.

1. Scope and shared responsibility

Controls cover the WordPress website, authenticated application, API, and related operations to the extent described. Epistemic LAS protects the platform and its access; providers protect their contracted services; and the Institution protects identities, devices, networks, configurations, legal basis, and quality of the data it controls.

2. Architecture, environment separation, and isolation

The SaaS applies logical isolation by organization and verifies on the server that each identity and permission matches the requested context before authorizing an operation. Public, beta, development, and application environments have separate purposes; their separation requires ongoing configuration, review, and testing.

3. Identity, sessions, and access control

Access is based on accounts and authorized functions; sessions are validated, renewed, and revoked through server controls and available identity flows. The application retains only the strictly necessary material described in the Cookie Policy, sensitive access flows include controls against automated abuse, and internal areas remain restricted.

4. Transport, platform, and secrets

  • HTTPS/TLS and HSTS protect configured public interfaces;
  • operational secrets are supplied outside application code and checked for exposure;
  • workloads and containers apply limited permissions, non-privileged users, and read-only filesystems where the component permits;
  • WordPress reduces unnecessary public endpoints, headers, and functions and limits editorial access to authorized users.

5. Application and data security

Input validation, role and tenant authorization, error handling, and persistence must be applied at API boundaries rather than relying only on the interface. Permissions follow least privilege, and security logs must avoid exposing credentials or unnecessary educational content. Encryption and retention specific to each data service must be stated in the applicable architecture and contract.

6. Development, changes, and dependencies

Changes undergo testing, static review, checks for secret exposure, and a controlled release process. Dependencies and versions must be reviewed before promotion; automated controls reduce risk but do not replace design review, security testing, or vulnerability management.

7. Continuity, backups, and recovery

Beta website changes require a prior backup and a controlled recovery path. SaaS backup scope, frequency, encryption, location, retention, and restoration testing must be confirmed by environment and in the applicable agreement. This page publishes no recovery-time objective, recovery-point objective, or restoration guarantee that has not been formally validated.

8. Logging, monitoring, and incidents

Operational and security signals needed to detect failures, investigate access, and respond to incidents are retained under the applicable purpose and schedule. Classification, containment, recovery, and communication depend on risk and each party’s role. Notices to the Institution, individuals, or authorities follow the contract and legal deadlines; we do not claim an uncontracted universal timeframe.

9. Providers, infrastructure, and payments

Providers that may access data must be assessed, contracted under suitable obligations, and listed in subprocessor documentation where applicable. Their locations and transfer safeguards must be verified. Epistemic LAS does not currently process card data through the Website or SaaS; therefore we claim no PCI DSS scope and do not copy controls from a payment processor that is not present. If online payment is added, this page and the responsibility model must be updated before activation.

10. Institution responsibilities and responsible disclosure

The Institution must review access, remove accounts promptly, protect devices, train users, classify and minimize data, maintain incident contacts, and validate integrations. A potential vulnerability may be responsibly reported to info@epistemic-las.com with reproducible steps and without accessing, altering, or disclosing another party’s data.

11. Scope, evidence, and certifications

We describe controls supported by available evidence and review them when code, providers, or environments change; in particular, we do not claim ISO, SOC, PCI DSS, or other certifications that have not been formally obtained, nor the absolute absence of incidents. Specific audits, penetration tests, recovery commitments, and service levels must be documented in the relevant contracting process.