Incident Response Plan

Last updated: March 1, 2026

Security Incident Response Plan — CronusAI

1. Incident Classification

SOFTBLITZ PESQUISA DESENVOLVIMENTO E CONSULTORIA DE SOFTWARE DO BRASIL LTDA - ME ("SoftBlitz") classifies security incidents by severity and potential impact to prioritize response and comply with state breach notification laws, FTC guidance, and SOC 2 incident management criteria.

Severity Description Examples
P1 – Critical Confirmed compromise of sensitive or mass personal data; immediate risk to individuals Mass data breach, ransomware with data encryption, confirmed unauthorized access to sensitive data
P2 – High Strong suspicion of compromise; personal data potentially affected; significant operational impact Unauthorized access attempt with indicators of success, prolonged unavailability, successful attack on secondary system
P3 – Medium Incident with potential impact on data or availability; requires investigation Blocked intrusion attempt, exploitable vulnerability identified, isolated integrity failure
P4 – Low Incident with limited impact; low risk Security alert without confirmation, blocked brute-force attempt, suspicious activity without confirmation

Classification determines reporting timelines, team composition, and notification requirements.

2. Incident Detection

Incident detection occurs through:

  • Continuous monitoring: Intrusion detection systems (IDS/IPS), security logs, SIEM, and automated alerts.
  • Internal reporting: Users, administrators, or employees who identify anomalous behavior.
  • External reporting: Customers, partners, or third parties who report suspicions.
  • Audits and testing: Penetration tests, security audits, and periodic reviews.

Any indicator of an incident must be reported immediately to the designated channel (e.g., security@orbittai.com or DPO).

3. Reporting Procedures

All suspected or confirmed incidents must be reported:

  1. Primary channel: security@orbittai.com or dpo@orbittai.com
  2. Minimum information: description of the event, date/time, affected systems (when known), data involved (if applicable).
  3. Evidence preservation: Do not alter, delete, or modify systems or logs before authorization from the response team.
  4. Documentation: All reports are logged in the incident management system with timestamp and responsible party.

4. Response Team

The incident response team includes:

  • Response lead: Overall coordination, containment decisions, and communication.
  • Data Protection Officer (DPO): Compliance with breach notification laws, regulatory and individual notification.
  • Technical team: Forensic analysis, technical containment, and recovery.
  • Legal: Advisory on legal obligations and communications.
  • Communications: Preparation of messages for customers and authorities, as applicable.

Roles are defined in internal documentation and updated periodically. The structure aligns with NIST SP 800-61 (Computer Security Incident Handling Guide) and SOC 2 incident management criteria.

5. Containment Procedures

Containment aims to limit impact and prevent expansion:

  • Immediate containment: Isolate affected systems, revoke compromised credentials, block malicious IPs or access.
  • Preservation: Preserve evidence (logs, snapshots, memory) for investigation and legal obligations.
  • Long-term containment: Apply fixes, patches, or configurations to prevent recurrence until investigation and definitive remediation are complete.

The balance between immediate containment and evidence preservation is decided by the response lead based on risk assessment.

6. Investigation

The investigation includes:

  • Forensic analysis of logs, systems, and artifacts.
  • Identification of attack vector, scope of compromise, and affected data.
  • Assessment of risk to data subjects.
  • Detailed documentation for regulatory reporting and potential administrative or judicial proceedings.

The investigation is conducted to preserve chain of custody and confidentiality of sensitive information.

7. Data Breach Notification

Under applicable U.S. state breach notification laws and FTC requirements:

California (Cal. Civ. Code § 1798.82 – SB-1386 / AB-1950)

A business that owns or licenses unencrypted computerized data that includes personal information must disclose a breach to California residents whose unencrypted personal information was, or is reasonably believed to have been, acquired by an unauthorized person. Notification must be made in the most expedient time possible and without unreasonable delay, consistent with legitimate needs of law enforcement. "Personal information" includes name + SSN, driver's license, financial account, or medical information; or name + email/username + password/security question.

New York SHIELD Act (N.Y. Gen. Bus. Law § 899-aa)

Any person or business that owns or licenses computerized data which includes private information of a resident of New York must disclose any breach of the security of the system to affected New York residents in the most expedient time possible and without unreasonable delay.

Texas (Tex. Bus. & Com. Code § 521.053 – HB 4390)

A person who conducts business in Texas and owns or licenses computerized data that includes sensitive personal information shall disclose any breach of system security to any resident of Texas whose sensitive personal information was, or is reasonably believed to have been, acquired by an unauthorized person. Disclosure must be made without unreasonable delay.

FTC and Other Requirements

The FTC may require notification in connection with Section 5 enforcement. Sector-specific laws (e.g., HIPAA, GLBA) may impose additional requirements. Notification timing generally follows "without unreasonable delay" or "in the most expedient time possible," typically interpreted as within 30–72 hours of discovery, with delays permitted for law enforcement needs.

8. Regulatory Notification

Beyond individual notification, regulatory bodies may require reporting:

  • State Attorneys General: Many states require notification to the AG when a certain number of residents are affected.
  • Consumer reporting agencies: When the breach affects more than a threshold number of individuals (e.g., 500+ under some state laws).
  • Federal agencies: As required by sector-specific regulation (e.g., FTC, HHS for HIPAA).
  • Law enforcement: When required by law or court order.

The DPO and legal team assess the need for additional notifications on a case-by-case basis.

9. Customer Notification

When the incident affects customer (Organization) data or data subjects under the customer's responsibility:

  1. Initial notification: Immediate notice of the occurrence, preliminary scope, and measures taken.
  2. Updates: Periodic communication until investigation and remediation are complete.
  3. Final report: Summary of the incident, causes, impacts, and preventive measures, when appropriate and permitted by confidentiality.
  4. Support: Guidance on measures the customer may take in its operations.

Notification is made through contractual channels and in accordance with Data Processing Agreement clauses or equivalents.

10. Post-Incident Review

After response and remediation are complete:

  1. Post-mortem: Team meeting to analyze root causes, response effectiveness, and lessons learned.
  2. Documentation: Record of actions taken, gaps identified, and improvement recommendations.
  3. Procedure updates: Revision of this Plan and related policies based on lessons learned.
  4. Training: Team update on new procedures or identified risks.

The review occurs within 30 days of formal incident closure, unless a longer period is necessary for complex cases. This aligns with NIST SP 800-61 recommendations for post-incident activity and SOC 2 incident management criteria.


Data Controller
SOFTBLITZ PESQUISA DESENVOLVIMENTO E CONSULTORIA DE SOFTWARE DO BRASIL LTDA - ME
CNPJ: 56.145.925/0001-85
Av Paulista 1471 Conj 1110, Bela Vista, São Paulo – SP, CEP 01311-927, Brazil

Security: security@orbittai.com
DPO: dpo@orbittai.com

This Plan is reviewed periodically and updated in accordance with regulatory and operational changes. The last update date is set forth in this document's frontmatter.