Security overview

1. Identity & authentication

• Microsoft Entra ID single sign-on (OIDC + PKCE) for admin access. No application-managed passwords; we never see or store user credentials.
• ID-token signatures are validated against the JWKS published by the customer's Microsoft tenant, with strict issuer, audience, nonce and expiry checks.
• Session cookies use Secure, HttpOnly and SameSite attributes; the session identifier rotates on every privilege change.
• Each product registers its own dedicated Entra applications, so consent and secrets are scoped and independently revocable per product.

2. Microsoft 365 access

• Where a product reads from Microsoft 365, it uses an admin-consented Microsoft Graph application with the scopes listed in the product Schedule — read-scoped by default for the security products.
• The security products are read-first: any data-mutating action is a separate, opt-in, reversible capability, never on by default.
• No MX change, no journaling, no mail-flow rerouting — Olyteck products are not inline mail gateways.

3. Data model — counts findings, never files

• Products persist derived signals, scores, findings, verdicts and minimal metadata rather than raw files, message bodies or document contents wherever the design allows. Each product's Schedule states exactly what it stores and never stores.
• Where applicable, sensitive raw values (URLs, filenames, attachments) are stored as hashes by default, not raw values, unless a tenant opts in for investigation.

4. Tenant isolation

• Every record that touches customer data is bound to the tenant that owns it; removing a tenant removes every record belonging to it.
• Every query that returns customer data filters on the server-side session's tenant identifier, never on a value supplied in the request body or URL.
• Cross-tenant access attempts return a not-found response rather than forbidden, so another customer's data cannot be probed by identifier-guessing.

5. Data in transit

• TLS 1.2 or higher for all customer-facing and Microsoft Graph traffic. Plaintext HTTP is redirected to HTTPS at the edge.
• Standard hardening headers on every response (HSTS, X-Content-Type-Options, X-Frame-Options, Referrer-Policy, and a restrictive content-security-policy).

6. Data at rest

• Databases are hosted on infrastructure operated by Scaleway SAS on servers in France (Paris, PAR1). Disk encryption at rest is provided by the host (AES-256 or equivalent).
• Microsoft Graph access tokens are encrypted at rest; access is short-lived and read-scoped by default.
• Retention windows are product-specific — see each product's Schedule.

7. Audit log

• State-changing and privileged actions are recorded with tenant, actor, before/after state and timestamp.
• Privileged platform actions (operator access to a tenant, plan changes, sub-processor changes) are written to a separate operator-only log.

8. Hosting & backups

• Applications, databases and workers run on infrastructure operated by Scaleway SAS in France (Paris, PAR1) (EU).
• Daily database backups, encrypted at rest, retained in the same EU region; backup-restore drill at least annually (last drill date on request).
• No third-party CDN sees customer data.

9. Sub-processors & AI

The authoritative, version-dated list per product is in its DPA Schedule; the Trust Center shows the company-wide view.

• Common to all products: Microsoft (identity, and where connected, Graph), Scaleway (EU hosting) and Stripe (billing).
• AI varies by product: some use third-party AI/LLM sub-processors under "no training on API data" terms (e.g. Ask, Cyber); others use none (e.g. Guard). See the product Schedule.
• Sub-processor additions are posted at least 30 days in advance (e-mail notifications on opt-in); customers have a contractual right to object.

10. Incident response

• Documented runbook covering detection, scoping, containment, notification, recovery and post-mortem.
• Notification target for any confirmed personal-data breach: 72 hours from awareness, per GDPR Art. 33, to the affected administrators.
• Acknowledgement target for any inbound report to [email protected]: one business day.

11. Vulnerability disclosure

We welcome responsible disclosure. Please:

• Email [email protected] with a description, reproducible steps and the affected component.
• Do not test against another customer's workspace, access data that is not yours, or run automated scans that materially affect availability.
• Give us a reasonable window to remediate before public disclosure (we aim for 90 days).
• We do not currently run a public bug-bounty programme but will credit you (with your permission) once resolved.

12. Security roadmap

Controls we are working toward — not contractual commitments unless reflected in a signed Order Form; published so procurement can see the direction of travel.

• Independent security attestation (SOC 2 Type II / ISO 27001) — status on request.
• SSO/SCIM for admin provisioning — Enterprise, on request.
• Per-tenant audit-log retention & export — Enterprise.

13. Contact

Security issues: [email protected].
Privacy / DPA: [email protected].
General support: [email protected].