Incident Response Policy
Last updated: August 11, 2026
Ruligent maintains an incident-response process for events that may affect confidentiality, integrity, availability, authentication, tenant isolation, billing integrity, or customer data.
1. Detection and triage
Potential incidents may be identified through hosting and application logs, uptime checks, security monitoring, provider notifications, customer reports, or internal testing. Events are triaged according to likely customer impact, scope, exploitability, and urgency.
2. Containment
Depending on the event, containment may include disabling credentials, restricting endpoints, rolling back a deployment, isolating an integration, rotating secrets, applying a kill switch, blocking abusive traffic, or temporarily removing a public route or domain.
3. Investigation and recovery
We preserve relevant evidence where practical, identify affected systems and customers, remediate the root cause, restore from known-good configurations when appropriate, and verify that controls are functioning before normal operations resume.
4. Customer notification
Where an incident materially affects a customer's data or service and notification is required by law, contract, or the applicable DPA, Ruligent will notify affected customers without undue delay after sufficient facts are available. Notices may be updated as the investigation progresses.
5. Post-incident review
Material incidents are followed by a review of root cause, containment effectiveness, recovery, control gaps, and corrective actions. Appropriate changes may be added to product tests, runbooks, monitoring, or governance evidence.
6. Reporting an incident
Report suspected security incidents through the Ruligent contact page. Do not include passwords, API keys, private keys, or other live secrets in an initial report.