Security Incident Response Policy

Purpose

This policy describes how ILLIXIS detects, triages, contains, communicates about, and learns from security incidents. It applies to all systems operated by ILLIXIS (ROI IQ LLC) under the illixis.io domain, including app.illixis.io, www.illixis.io, and supporting infrastructure on Render, Cloudflare, and Cloudflare R2.

A “security incident” means any event that compromises, or is reasonably likely to compromise, the confidentiality, integrity, or availability of customer data or ILLIXIS systems.

1. Detection

Incidents are surfaced through:

• Sentry alerts for application errors and unusual error-rate spikes.
• Render alerts for service health, deploy failures, and resource exhaustion.
• Customer reports sent to support@illixis.io or via in-app contact channels.
• Security researcher disclosures sent to security@illixis.io. ILLIXIS welcomes good-faith vulnerability reports and will acknowledge receipt within two business days.
• Internal review during routine log inspection and access auditing.

2. Triage

Every incident is assigned a severity tier within one hour of detection:

For v1 of ILLIXIS, Nuno Andrade (founder) is the on-call owner for all severity tiers. This is appropriate for the solo-founder stage and will be revisited when ILLIXIS hires its first engineer.

3. Containment and Eradication

Once an incident is confirmed, the response sequence is:

1. Contain — Isolate the affected component. Rotate any credentials that may have been exposed (API keys, OAuth tokens, database passwords, session secrets).
2. Eradicate — Identify and patch the root cause. Deploy the fix to staging first, verify, then promote to production.
3. Monitor — Watch for regression or related anomalies for at least 24 hours after the fix lands.
4. Document — Record a timeline of detection, decisions, and actions taken. The timeline becomes the basis for the post-mortem and any customer notification.

4. Customer and Regulator Notification

ILLIXIS follows the breach-notification obligations imposed by applicable law. Two separate obligations apply to incidents involving personal data:

Regulator notification (GDPR Article 33)

If a personal-data breach occurs that is likely to result in a risk to the rights and freedoms of EU/UK data subjects, ILLIXIS will notify the relevant supervisory authority within 72 hours of becoming aware of the breach, except where the breach is unlikely to result in such risk.

Data-subject notification (GDPR Article 34)

If the breach is likely to result in a high risk to the rights and freedoms of affected individuals, ILLIXIS will communicate the breach to those individuals without undue delay.

State and other jurisdiction notification

Where US state breach-notification laws apply (for example, California Civil Code § 1798.82), ILLIXIS will provide notice to affected residents and, where required, to state regulators, in the manner and time period required by applicable law. Many state statutes require notification “in the most expedient time possible and without unreasonable delay”; others impose specific deadlines (commonly 30 to 90 days). ILLIXIS will comply with whichever standard is most protective in the affected jurisdiction.

Channels

When notification is required, ILLIXIS will communicate through one or more of the following:

• Direct email to the email address on file for each affected customer.
• In-app notice for users who log in during the notification window.
• Public root-cause analysis at https://www.illixis.io/security/incidents/YYYY-MM-DD-<slug> for customer-impacting incidents, where publishing details does not increase risk to affected users.

Content of notification

Where ILLIXIS notifies an affected individual, the notification will include, at minimum: the nature of the breach, the categories and approximate number of data subjects and records concerned, the likely consequences, the measures taken or proposed to address the breach, and a contact point for further information. This matches the GDPR Art. 33(3) and 34(2) content requirements and substantially overlaps with US state law requirements.

5. Post-Mortem

Within five business days of incident resolution, ILLIXIS will conduct a blameless post-mortem covering:

• Detection timeline (when it happened, when we noticed).
• Contributing factors and root cause.
• Customer impact (records affected, downtime duration, data exposure scope).
• Response timeline and decisions.
• Corrective actions and their owners.

Customer-impacting incidents receive a public root-cause analysis published at /security/incidents/YYYY-MM-DD-<slug>. Non-customer-impacting incidents receive an internal memo retained for one year.

6. Vulnerability Disclosure

Security researchers, customers, and other third parties may report suspected vulnerabilities to security@illixis.io. ILLIXIS commits to:

• Acknowledge receipt of the report within two business days.
• Triage the report and assign a severity tier within five business days.
• Communicate progress to the reporter through resolution.
• Credit the reporter publicly on the resolved incident’s RCA page, if the reporter wishes.

A PGP key is not currently published. If a reporter requires encrypted communication, contact security@illixis.io to coordinate.

ILLIXIS does not yet operate a formal bug-bounty program. Good-faith research conducted in line with this policy, against non-production infrastructure where reasonably possible, and without exfiltrating customer data, will not be the subject of legal action by ILLIXIS.

Review

This policy is reviewed at least annually and whenever a material change to ILLIXIS infrastructure, customer base, or regulatory environment requires it. Material updates increment the version number and effective date at the top of this document.

Related

• Security overview — features, infrastructure, FAQ.
• Privacy Policy — how ILLIXIS collects, uses, and protects personal data.
• Subprocessors — third-party services ILLIXIS uses to operate the platform.