Administration and Security

Incident response

How Ottili ONE handles security incidents and reported vulnerabilities: the disclosure channel (security@ottili.one), the severity model (Critical/High/Medium/Low), the response process, status-page communication, and coordinated disclosure.

Overview

Ottili ONE takes reported vulnerabilities and security incidents seriously. This article explains how to report a security vulnerability responsibly and how Ottili responds to incidents that affect the platform and your company workspace. Everything on this page is the published Ottili policy — it is rendered from a single canonical source and is never hardcoded or freely extended.

The broader security architecture (tenant isolation, authentication, permissions, encryption, secrets management, audit) is covered in [Security overview](/docs/security-overview). This article focuses on vulnerability reporting and the incident-response process.

Report a vulnerability responsibly

Ottili operates a coordinated disclosure channel for security researchers and customers.

Disclosure channel:* send reports to security@ottili.one*. This is the single canonical address for vulnerability reports.
Acknowledgment:* Ottili acknowledges a well-formed report within 72 hours* (acknowledgment SLA).
Encrypted reports (optional):* reports may be submitted encrypted. No PGP fingerprint is published at this time; the page hides the PGP block accordingly rather than showing an invented fingerprint.

What to include

A clear description of the vulnerability and the affected product or surface.
Steps to reproduce, or a proof-of-concept if you have one.
The potential impact you identified.
Your contact details (optional, so we can follow up).

In scope

The Ottili ONE platform and the public Ottili surfaces (website, status page, public docs).
Ottili Auth and the public boundary of the Unified API.

Out of scope

Social-engineering attacks targeted at Ottili staff.
Physical security of Ottili offices or facilities.

Do not

Do not run high-intensity automated scanners against production.
Do not access, modify or delete customer data.
Do not disclose the vulnerability publicly before it is resolved.

Severity model

Every incident is handled against a fixed severity model. The response targets and update cadences are part of the published policy:

Severity	Description	Response target	Update cadence
Critical*	Active exploitation, data exposure, or loss of availability of a core service.	Acknowledge and begin mitigation within 1 hour.	Status updates at least every 4 hours until resolved.
High*	Serious vulnerability with a plausible path to exploitation, or partial degradation of a core service.	Acknowledge within 4 hours and begin mitigation.	Status updates at least twice per day until resolved.
Medium*	Limited impact or exploitation requires specific conditions.	Acknowledge within 1 business day.	Daily status updates until resolved.
Low*	Minimal impact, hardening or defense-in-depth improvement.	Acknowledge within 2 business days.	Updates as work progresses.

Incident response process

Regardless of severity, every incident moves through the same four phases:

1. Detection & triage

Incidents are detected through monitoring, customer reports and the vulnerability-disclosure channel, then triaged by severity.

2. Containment

We isolate affected components and revoke abused credentials or tokens to stop ongoing impact.

3. Communication

Affected companies are notified through the status page and direct channels as the situation develops.

4. Resolution & post-incident review

We remediate the root cause. Where appropriate, we share a transparent post-incident review with affected customers.

Communication during an incident

Real-time status is published on the [Ottili status page](https://status.ottili.one).
Affected companies are contacted directly when an incident affects their workspace.
Post-incident reviews are shared with affected customers on request.

For known outages, check the status page first before contacting support. General support is at [ottili.one/support](https://ottili.one/support); for security matters continue to use security@ottili.one*.

Coordinated disclosure

We coordinate disclosure with reporters and avoid naming individuals.
We do not pursue legal action against researchers acting in good faith.
We credit researchers who wish to be acknowledged for their report.

Feature status terms

The incident-response policy and the public /security/response page are Live (General Availability)*. Ottili ONE clearly distinguishes Live, Beta, Private Beta, In Development, Planned and Concept. For what these terms mean, see [Understand feature status labels](/docs/understand-feature-status-labels).

[Security overview](/docs/security-overview) — the whole security architecture at a glance.
[Secrets management](/docs/secrets-management) — how configuration and integration secrets are protected.
[Tenant isolation](/docs/tenant-isolation) — how your company stays separate from others.
[Account and data security](/docs/account-and-data-security) — authentication, sessions, isolation, audit.
[Roles and permissions](/docs/roles-and-permissions) — who can do what.
[Approval Queue](/docs/approval-queue) — human approval for sensitive actions.
[Support escalation](/docs/support-escalation) — how to escalate to support.
[Understand feature status labels](/docs/understand-feature-status-labels) — what the status terms mean.
[Audit logs](/docs/audit-logs) — accountability across every module.

Was this article helpful?