Incident-response process

1. Report and triage

Security concerns go to security@citeply.com; product availability issues go to support@citeply.com. Reports are assigned a severity, an incident owner, a timestamped record, and an initial scope. Credentials and confidential source files must not be included in the first report.

2. Contain and preserve

The incident owner may revoke sessions or connector access, isolate affected integrations, stop a write path, preserve relevant logs and object versions, rotate credentials, and temporarily disable an affected feature. Evidence collection is limited to what is necessary to investigate and recover.

3. Investigate and recover

Citeply identifies the affected tenants, data classes, time window, root cause, and integrity impact; applies a tested remediation; verifies database and object-storage health; and monitors the restored service before closure. Recovery actions must preserve tenant boundaries and the append-only audit trail.

4. Communicate

Service-wide availability updates are published on the status page. Affected customers receive material security or personal-data incident information without undue delay and within the time required by the signed agreement and applicable law, as facts become sufficiently reliable.

5. Learn and verify

After resolution, Citeply records the timeline, impact, root cause, corrective actions, owners, and due dates. Material incidents receive a post-incident review. Recovery, notification, and escalation procedures are exercised periodically; an exercise is not represented as an independent certification.

Response roles

• Incident commander: owns severity, coordination, decisions, and closure.
• Technical lead: contains, diagnoses, remediates, and validates recovery.
• Customer communications: maintains status updates and direct notices.
• Privacy/legal reviewer: assesses notification duties and contractual commitments.