Security Policy

Last Updated: 5/20/2026

Stream.Estate (operated by DLL SAS) implements a layered set of technical and organisational measures to protect the confidentiality, integrity and availability of its API, its data and the information of its customers. This page describes the principles and controls that are in place. It is referenced by, and incorporated into, the API License Agreement.

1. Hosting and infrastructure

  • Production workloads are hosted in European data centres operated by Tier-1 cloud providers that maintain ISO/IEC 27001, SOC 2 and equivalent certifications.
  • Network access is restricted by default; only the services that need to reach a resource can do so, through firewalled and authenticated channels.
  • Production environments are logically and operationally separated from development, staging and analytics environments.
  • All public-facing endpoints sit behind a DDoS-protected edge and Web Application Firewall.

2. Encryption

  • In transit: all communication with the API uses TLS 1.2 or higher with strong cipher suites; legacy protocols (SSLv3, TLS 1.0, TLS 1.1) are disabled.
  • At rest: sensitive data is encrypted using AES-256 (or equivalent) at the storage layer.
  • Secrets: credentials, tokens and signing keys are stored in a managed secrets vault with strict access controls and full audit trails.
  • Customer API keys: stored only as cryptographic digests; the raw key is shown to the customer once at creation time and is not recoverable afterwards.

3. Access control and authentication

  • Multi-factor authentication (MFA) is enforced for all team members accessing administrative or production systems.
  • Access to production data is granted on a least-privilege, need-to-know basis and reviewed periodically.
  • Joiner / mover / leaver processes are documented; access is revoked promptly upon role change or departure.
  • Privileged actions (deployments, configuration changes, database access) are logged and auditable.
  • Customer authentication uses revocable API keys with optional scoping, and the dashboard supports password + MFA.

4. Logging and monitoring

  • Application, system and access logs are centralised and retained for an appropriate period.
  • Continuous monitoring covers availability, latency, error rates and security signals; alerts route to an on-call rotation.
  • Anomaly detection is in place for suspicious authentication, exfiltration and rate-limit-evasion patterns.

5. Backups and disaster recovery

  • Customer configuration and operational data are backed up regularly using encrypted, geographically redundant storage.
  • Recovery procedures are documented and tested on a periodic basis to verify that restoration objectives are met.
  • The API content itself is sourced from upstream providers and continuously regenerated; the disaster-recovery posture combines automated reconstruction with backup-based restoration as appropriate.

6. Software development lifecycle

  • Code changes go through peer review and automated tests before reaching production.
  • Dependency management uses automated vulnerability scanning; flagged dependencies are evaluated and updated according to severity.
  • Static analysis and secret-scanning checks run on every change.
  • Production deployments are reversible and traceable to a specific change.

7. Vulnerability management

  • Known vulnerabilities affecting our stack are tracked, prioritised by severity and remediated within defined service levels.
  • Periodic security assessments and penetration tests are conducted by qualified third parties; findings feed into the remediation backlog.
  • Critical findings receive expedited remediation outside the standard cycle.

8. Personnel security

  • All team members sign confidentiality undertakings before being granted access to production data.
  • Security awareness training is delivered at onboarding and refreshed periodically, covering phishing, credential hygiene and data handling.
  • Workstations are managed, encrypted and configured with screen-locking, full-disk encryption and endpoint protection.

9. Incident response

We maintain a documented incident response process covering detection, triage, containment, eradication, recovery and post-mortem analysis. In the event of a security incident affecting customer data, Stream.Estate notifies the affected customer(s) without undue delay and, where the incident is material, no later than seventy-two (72) hours after becoming aware of it. The notification describes:

  • the nature and scope of the incident;
  • the categories of data potentially affected;
  • the measures already taken or planned to contain and remediate the incident;
  • the contact point for further information.

10. Data location and transfers

Customer operational data is stored in the European Union. Where any service involves a transfer of personal data outside the European Economic Area, Stream.Estate relies on the European Commission Standard Contractual Clauses or another lawful transfer mechanism, complemented by supplementary measures where required.

11. Compliance and certifications

Stream.Estate aligns its practices with the ISO/IEC 27001 control framework. Certifications, attestations or audit reports that are obtained will be referenced here once available. Customers under NDA may request the current state of the security programme by writing to [email protected].

12. Reporting a security issue

If you believe you have identified a vulnerability or security issue affecting Stream.Estate, please report it to [email protected] with sufficient detail for us to reproduce and triage the issue. We commit to:

  • acknowledge receipt within five (5) business days;
  • keep you informed of progress;
  • refrain from initiating legal action against researchers acting in good faith and respecting reasonable disclosure principles.

13. Updates to this policy

This security policy evolves alongside our infrastructure and our threat model. Material changes are notified to customers under contract and reflected in this page. Customers with specific security requirements (for example detailed technical and organisational measures schedules) can request a dedicated security addendum to their contract.