Breach-Response Policy

1. Purpose

This Breach-Response Policy describes Cracken's approach to identifying, escalating, investigating, containing, remediating and notifying about security incidents and personal data breaches. It is designed for a cybersecurity platform that may process sensitive testing targets, vulnerability evidence, credentials, logs, prompts, reports and compliance records.

This external policy should be supported by a more detailed internal incident-response runbook.

2. Definitions

"Security Event" means an observable occurrence that may affect confidentiality, integrity, availability, safety, compliance or trust.

"Security Incident" means a Security Event that Cracken determines has or is reasonably likely to have an adverse effect on systems, data, customers or service integrity.

"Personal Data Breach" means a breach of security leading to accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to personal data.

"Customer Data Incident" means unauthorized access to, disclosure of, alteration of, loss of, or confirmed compromise of Customer Content or Customer Personal Data.

3. Incident objectives

Cracken's incident-response objectives are to:

• protect customers, users, affected individuals and Cracken systems;
• contain unauthorized access and prevent further harm;
• preserve evidence and maintain an audit trail;
• assess legal, contractual, regulatory and customer-notification obligations;
• restore secure operations;
• communicate accurately and without speculation;
• remediate root causes and prevent recurrence;
• coordinate with customers where incidents affect their data or authorized testing environments.

4. Reporting channels

Suspected incidents may be reported to: security@cracken.ai

Privacy incidents may be reported to: privacy@cracken.ai

Legal/regulatory notices may be sent to: legal@cracken.ai

5. Incident classification

Cracken classifies incidents based on impact and sensitivity, including:

• unauthorized access to customer content, vulnerability evidence, credentials, reports or logs;
• compromise of production systems, cloud accounts, CI/CD, identity provider or administrative accounts;
• unauthorized model, prompt, agent or tool behavior that exposes or misuses customer data;
• loss or exposure of personal data;
• suspected export/sanctions evasion, unlawful hacking or platform abuse;
• sub-processor incident affecting Cracken data;
• availability incidents with security or data-integrity impact;
• accidental disclosure through support, email, analytics, logs or business tools.

6. Response lifecycle

Cracken follows a lifecycle appropriate to the incident:

1. Detect and triage: validate alert, identify affected systems/data/customers, assign severity and start an incident record.
2. Contain: disable compromised credentials, isolate systems, block malicious traffic, pause unsafe workflows, suspend accounts or restrict features as needed.
3. Preserve evidence: collect logs, snapshots, access records, relevant communications and sub-processor notices using chain-of-custody appropriate to the incident.
4. Investigate: determine timeline, root cause, affected data categories, affected customers/individuals, threat actor, blast radius and ongoing risk.
5. Eradicate and remediate: remove unauthorized access, patch vulnerabilities, rotate credentials, adjust controls, fix misconfigurations and validate remediation.
6. Recover: restore secure services, monitor for recurrence and validate integrity.
7. Notify and coordinate: provide required notices to customers, regulators, affected individuals, insurers, law enforcement or other parties as applicable.
8. Lessons learned: document root cause, corrective actions, owners and follow-up verification.

7. Customer notification

Cracken will notify affected customers without undue delay and within any legally or contractually required notification period after confirming a Security Incident affecting their Customer Personal Data or Customer Content, unless legally prohibited or unless notification would compromise the investigation or security. Notices will include information reasonably available at the time, such as:

• incident summary;
• affected service or workspace;
• affected data categories;
• known or suspected cause;
• containment and remediation steps;
• recommended customer actions;
• contact point for follow-up;
• updates as material information becomes available.

8. Regulatory and individual notification

Cracken will assess whether notification to regulators, supervisory authorities, law enforcement or affected individuals is required. Where Cracken acts as processor, the customer generally controls regulatory and data-subject notifications, and Cracken will reasonably assist. Where Cracken acts as controller, Cracken will handle applicable notifications.

9. Sub-processor incidents

Cracken requires sub-processors to notify Cracken of actual or suspected incidents affecting Cracken data. Cracken will assess sub-processor notices, request relevant information, coordinate mitigation and notify affected customers where required by the DPA or law.

10. Offensive-security misuse incidents

Because Cracken is a vibe-hacking / adversarial-validation tool, suspected misuse is handled as a security incident when it involves unauthorized targets, prohibited exploitation, out-of-scope activity, attempts to evade safety controls, credential theft, extortion, public disclosure of unremediated vulnerabilities, restricted territories or illegal end use.

Cracken may immediately pause workflows, suspend accounts, revoke credentials, preserve evidence, request supporting documents for risk users/features/actions/triggers, notify affected parties where legally appropriate, cooperate with authorities and terminate subscriptions according to the Terms and Acceptable Use Policy.

11. Export/sanctions, abuse and law-enforcement coordination

Cracken's self-serve export/sanctions baseline restricts access from, for the benefit of, or in connection with: Russia; Belarus; Cuba; Iran; North Korea / DPRK; Syria; Crimea / Sevastopol / occupied or non-government-controlled Ukrainian territories, including Donetsk, Luhansk, Kherson and Zaporizhzhia areas; and any other restricted party, end use, sector, transaction or territory under applicable EAR, ITAR, OFAC, EU, UK, UN or similar rules.

For offensive-security misuse, sanctions/export evasion, unlawful hacking or serious platform abuse, Cracken may preserve evidence, restrict access, suspend workflows, notify affected customers, coordinate with vendors and comply with valid legal process.

12. Communications

Only authorized personnel may communicate externally about incidents. Communications should be factual, concise and updated as facts develop. Cracken should avoid speculation, blame, unsupported attribution or disclosure of exploit details that could increase risk.

13. Post-incident improvement

After material incidents, Cracken should document corrective actions, such as control changes, additional monitoring, code fixes, architecture changes, vendor changes, training, policy updates, customer guidance or product safety improvements.

14. Testing and maintenance

Cracken should review and test the incident-response process at least annually, ad hoc after material incidents, and after significant changes to product architecture, sub-processors, AI systems or operating model.

Owner: security@cracken.ai

Legal/privacy escalation: legal@cracken.ai; privacy@cracken.ai