Ce document est un brouillon basé sur un modèle, en attente de révision par un conseil juridique.
Le texte ci-dessous est un langage de base SaaS générique destiné à communiquer l'intention pendant que la version formelle est finalisée avec notre conseil. Ne vous fiez pas à ce document pour la conformité, les achats, les audits ou toute décision juridiquement contraignante. Pour la version contraignante actuelle applicable à votre engagement, contactez notre équipe juridique.
En vigueur2026-05-11
Versionv0.1 (draft)
JuridictionEure, Normandie, France
1. Overview
ObservOne operates the platform with a defence-in-depth posture appropriate to the criticality of the infrastructure our customers run. The program is anchored on three principles:
Single-tenant data planes — customer telemetry is isolated by tenant at the storage and compute layer, not just logically
Customer-managed keys — where customers require it, encryption keys are held by the customer, not by us
Region pinning by default — customer data stays in the region of origin unless the customer explicitly elects otherwise
This page summarises the program. Detailed control mappings are available under NDA on request.
2. Infrastructure security
Cloud provider
We run an EU-resident multi-cloud architecture with the data plane pinned to the EU and CDN globally distributed. The underlying providers collectively hold SOC 1, SOC 2 Type II, ISO 27001, ISO 27017, ISO 27018, ISO 27701, PCI DSS, FedRAMP and HIPAA attestations.
Network segmentation
Production is segmented from staging and corporate networks. Public endpoints sit behind a managed WAF and DDoS protection layer. Service-to-service traffic is authenticated and encrypted in transit.
Host hardening
Production hosts are immutable images deployed via signed pipelines. SSH access to production is disabled by default; break-glass access is time-boxed, logged and reviewed.
3. Application security
Secure SDLC
Code changes are reviewed by a second engineer, run through automated static analysis and dependency scanning, and tested against a battery of unit and integration tests before merge. Production deploys are gated on those signals.
Secrets management
Secrets are stored in an enterprise-grade secrets manager with hardware-backed encryption and access audit trails, scoped per-environment, rotated on a defined cadence and never stored in source code.
Dependency hygiene
Third-party dependencies are inventoried and continuously scanned for known vulnerabilities. Critical-severity findings are remediated within defined program SLAs.
4. Data security & encryption
Encryption in transit
All connections to the Service use TLS 1.2 or higher with modern cipher suites. Internal service-to-service traffic uses mutual TLS.
Encryption at rest
All Customer Data is encrypted at rest using AES-256. Database storage, object storage and snapshots are encrypted by default.
Key management
Default key management is performed by our cloud provider's managed KMS. Customers on eligible tiers may bring their own keys (BYOK) via a customer-controlled external KMS.
Data residency
Customer Data is pinned to its region of origin by default. Multi-region replication is opt-in per tenant.
5. Identity & access management
Customer-side
SSO via SAML 2.0 and OIDC
SCIM provisioning for user lifecycle
MFA enforced for privileged roles
Role-based access control with least-privilege defaults
Audit log of every authentication and write event, exportable in OpenTelemetry
Internal access
Employee access to production is granted on a least-privilege basis, tied to job function, and reviewed quarterly. All access requires SSO + MFA. Privileged operations are logged and monitored.
6. Operational security
Change management
Production changes flow through a versioned pipeline with mandatory peer review, automated tests and a staged rollout. Rollback is one command away.
Vulnerability management
Continuous scanning of hosts, containers and dependencies. Findings are triaged into our ticketing system with SLAs based on severity:
External penetration tests are conducted annually and after major architectural changes by an accredited third party. A current attestation summary is available under NDA.
Logging & monitoring
Centralised logging across application, infrastructure and audit events. Alerts feed our on-call rotation 24/7.
7. Vendor & sub-processor management
Every sub-processor undergoes due-diligence review before onboarding and a recurring review thereafter. Material changes to the sub-processor roster are announced in advance via the sub-processors page.
8. Business continuity & DR
Production runs across multiple availability zones with automated failover. Backups are encrypted, region-isolated and tested quarterly. Recovery objectives:
RTO — Defined in customer MSA per environment tier
RPO — Defined in customer MSA per environment tier
9. Incident response
We maintain a documented incident response plan with defined roles, escalation paths and communication templates. In the event of a security incident affecting Customer Data:
Customer notification within regulatory windows (GDPR Article 33: 72 hours for qualifying incidents). Specific customer commitments in MSA.
Status updates at frequency defined in MSA until resolution
Post-incident report including root cause, impact assessment and corrective actions, delivered per contractual timeline in MSA
10. Vulnerability disclosure
We welcome reports from security researchers. Submit findings to security@observone.com; PGP key on request. We commit to:
Acknowledgement within 5 business days
Initial assessment within 10 business days
Coordinated disclosure timeline agreed with the reporter
Public credit, with the reporter's consent, in our security advisories
We do not pursue legal action against researchers acting in good faith under these terms.