Vulnerability disclosure goes to [email protected]. We use defensive tripwires (canary tokens) on our own infrastructure for breach detection. We commit to 72-hour breach notification. We publish what we run on, how we sign deploys, and how we encrypt the data we hold.

Found something? Write to [email protected]. If your finding is sensitive — credentials, active exploitation paths, data you were able to access — encrypt it using our PGP key at /.well-known/security-key.asc before sending.

Here is what happens after you write:

• We respond within 7 days to confirm we received your report.
• We confirm scope and severity within 14 days — whether the finding is in scope, how we’ve ranked its severity, and whether we’re treating it as a high-severity issue requiring expedited handling.
• We fix high-severity findings within 90 days. If we need longer, we negotiate a timeline with you before the 90-day mark. We won’t use the extension to delay indefinitely — the conversation is real.

We credit researchers in our changelog by default. If you’d rather not be named, tell us when you submit and we’ll honor that.

We do not pursue legal action against researchers who operate in good faith and within the disclosure scope: finding a bug, documenting it, and reporting it to us. We don’t require that you give us an exclusive period before publishing — we only ask that you give us enough time to fix it first.

We use defensive tripwires — canary tokens — on our own infrastructure to detect compromise. They include things like fake credentials planted in source artifacts and tagged URLs embedded in internal documents. When something accesses one of these tokens, an alert fires and we investigate immediately.

What canaries are not:

• They are not marketing trackers. They don’t track website visitors or collect data about people browsing Eleven11 properties.
• They don’t appear on any customer-facing surface. A user navigating Eleven11 will never encounter a canary token.
• They don’t collect data about you. Their only job is to fire when accessed, confirming that something reached a place it shouldn’t.

Where canaries appear in customer-facing scope: Dhara may deploy canary tokens during security engagements you scope and explicitly authorize — for example, placing a fake credential file in a test directory to detect whether an attacker who gains access reaches it. This is documented in your engagement record. Canaries are never deployed against systems outside your authorized scope. Full detail at /trust/dhara.

We commit to notifying affected customers within 72 hours of confirming a personal-data breach. The notification will tell you: what was affected, what we know about how it happened, what we did to contain it, and what steps you should take.

We also notify supervisory authorities where law requires it:

• India — the Data Protection Board under the DPDP Act, within the prescribed deadline.
• EU / UK — the relevant national supervisory authority (e.g., ICO for UK, the lead DPA for EU), within 72 hours of awareness.
• US states — applicable state AGs where state-level breach-notification law is triggered.

After any confirmed breach, we document the incident: the affected scope, the root cause, the steps we took to contain and remediate it, and the steps we’re taking to prevent recurrence. We hold a post-incident review and publish a redacted version of the findings to our changelog. Redaction removes details that would make future exploitation easier; the rest goes public.

Here is the actual stack, not the marketing version:

• Infrastructure — Eleven11 runs on Hetzner (EU-DE and EU-FI datacenters), fronted by Cloudflare for DNS, CDN, and edge protection. Data stays in the EU by default.
• Source and deploy — Source lives in GitHub. We ship via GHCR-published Docker images, built and signed in CI, deployed over SSH to the server. There is no manual “copy files up” step in the production path.
• Inter-service trust— Inter-service traffic is HMAC-signed at the boundary. We don’t treat internal network calls as implicitly trusted. A service on the internal network still has to authenticate to another service.
• Secrets at rest — OAuth tokens and customer secrets are encrypted at rest with service-managed keys. Keys are rotated on a documented cadence. We do not store secrets in code or in environment variables that could be baked into images.
• LLM tenancy— By default, no shared LLM tenancy. Each customer’s content goes to a separate context window. Cross-customer leakage paths are part of our threat model — we design against them, not around them. BYOK (bring your own key) is available for products that use an LLM; if you supply your own key, your content never transits our LLM credentials.

We don’t currently hold SOC 2, ISO 27001, or similar third-party certifications. They’re on the roadmap — see /aupand pricing for which tiers will include formal attestation. We’re not going to put a badge on the site until we can back it with a certificate.

What we do claim, and back with the specifics above:

• GDPR-aligned processing (EU/UK)
• DPDP-aligned processing (India)
• Encrypted-at-rest secrets, service-managed keys
• Signed deploys from CI, not manual pushes
• Audit-logged admin operations
• 72 hours breach notification to affected customers
• The vulnerability disclosure path described above

We’d rather under-claim and over-deliver than the reverse. If you have specific security requirements for a procurement process, write to [email protected] and we’ll give you a straight answer about what we can and cannot support.

[email protected] for vulnerability disclosure. PGP-encrypted submissions preferred for sensitive findings — key at /.well-known/security-key.asc. [email protected] for anything else.