FAQ — Security and hosting

This page summarizes the most frequent security and hosting questions. For an exhaustive description, Omniscol provides the official documents on request (or under NDA depending on the case):

  • SECURITY_OVERVIEW.md — public overview,
  • SECURITY_ONE_PAGER.md — summary for CISOs,
  • SECURITY_FULL.md — complete documentation (governance, infrastructure, controls, compliance, incident response),
  • ISO27001_MAPPING.md — mapping to ISO 27001 controls,
  • SSI_QUESTIONNAIRE_STANDARD.md — answers to the standard information security questionnaire.

For any security question: security@omniscol.com.

Where is my data hosted?

The legal notice states that hosting is located in the European Union, on AWS Paris and Scaleway. The precise commitments on redundancy, backup, retention and availability depend on the contractual framework applicable to your account.

Is Omniscol GDPR compliant?

Omniscol is designed for GDPR-compliant use. Practical consequences:

  • Hosting exclusively in the EU (France).
  • Logical isolation per customer: no cross-account access is possible.
  • No profiling, no resale of data, no secondary use of your school's content.
  • Reversibility: complete JSON export via Download.
  • Data subject requests handled according to the applicable contractual and regulatory framework.

Is Omniscol ISO 27001 certified?

Not certified to date, but practices are aligned with the principles of the standard and follow a risk-based, continually reviewed approach. Details of the controls can be provided under the appropriate contractual or security framework.

How are passwords protected?

Omniscol protects passwords in the following way:

  • Client-side pre-hashing with scrypt — your plaintext password never reaches the servers.
  • Server-side storage as a salted hash.
  • No plaintext password is ever transmitted or stored.
  • No Omniscol administrator can read, retrieve or recover a user password.

If you suspect an account has been compromised, changing the password invalidates any derived access that depends on this secret, in particular share links tied to the creator's password.

Are communications encrypted?

Public application access goes through HTTPS. The network exposure configuration depends on the chosen deployment and must be checked within the security or contractual framework of the account concerned.

How does authentication work?

Omniscol sessions use signed tokens with a limited lifetime; access is renewed while the user works in the interface.

Share links and API tokens follow separate rules:

  • a share link can have an expiry date and also depends on the account that created it; changing that account's password or deactivating it invalidates the related access;
  • an API token depends on a key created in the interface; deleting that key or reaching its expiry date invalidates the associated tokens.

See also Sharing link and Omniscol API.

API: keys and tokens

API access is managed from the interface with two visible objects:

  1. Key — created with a label and, if needed, an expiry date. This expiry can be changed later.
  2. Token — generated from a key, with a list of authorized API endpoints and its own expiry. This expiry cannot be changed after generation; a new token must be created.

Best practice: one key per integration, with an explicit label and an appropriate expiry. When in doubt, delete the key and create a new one.

See Omniscol API.

Can my users use their corporate account (SSO)?

Yes, via OIDC / SSO, when the configuration is enabled on the account. Omniscol supports Google Workspace, Microsoft Entra ID and generic OIDC providers.

Each user then signs in with their corporate identity and keeps the permissions configured in Omniscol.

What protections exist against abusive sign-in attempts?

  • Failed authentication responses are deliberately slowed down.
  • Administration screens have stronger protections.
  • Omniscol does not reveal whether the username exists: the message stays generic.

User account lifecycle

  • Deactivation without deletion — a deactivated account can no longer sign in, but its associated data is preserved.
  • Mandatory change on first access — when a password is set manually, the user must change it on first sign-in.
  • Reset — an administrator can trigger a password reset without knowing the existing password.

Network security and operations

The security documents provided on request detail the hosting, the network separation, the data access rules and the operational procedures applicable to the account concerned.

Is there an audit log?

Yes, when the logs option and the corresponding retention are enabled for the account. The visible scope depends on the logged operations and the depth configured by Omniscol. See Activity log (logs).

OWASP Top 10

Omniscol applies controls aligned with the OWASP Top 10 risks: access control, encryption, input validation, secure configuration, dependency monitoring, session protection and logging. The exact scope can be detailed in the security documents provided on request.

Automated security testing

Automated checks are integrated into Omniscol's development and deployment process. Their scope evolves with the product; the detailed elements can be provided under the appropriate security framework.

How to perform a manual backup?

The Download button downloads a complete export of the account in JSON format. The file must be stored with care: it contains the password hashes and all personal data.

In the event of a major incident, this file can be sent back to the Omniscol team for re-import.

If the Snapshots option is enabled on the account, you can also automate the creation of restorable backup points. See Backup points.

Incident history

As of the most recent review (February 2026):

  • 0 customer data breaches (cumulative history).
  • 0 security incidents in 2025.

These figures are published in SECURITY_ONE_PAGER.md, a document reviewed quarterly.

See also