Incident Response Plan

This Incident Response Plan (IRP) establishes Ad Legends' formal procedures for detecting, analyzing, containing, eradicating, and recovering from security incidents. It is designed to minimize impact, preserve evidence, and ensure regulatory compliance.

1. Purpose and Scope

The purpose of this Incident Response Plan is to define a structured approach to handling security incidents that threaten the confidentiality, integrity, or availability of Ad Legends' systems, data, and services.

This plan covers:

• All Ad Legends production systems, APIs, and infrastructure
• User data, brand assets, and creative content
• Authentication and authorization systems
• Payment processing and billing infrastructure
• AI processing pipelines and model integrations
• Third-party service integrations and subprocessors

This document is intended for internal security personnel, enterprise clients, auditors, and regulatory bodies. It is reviewed and updated at least annually or after any significant security incident.

2. Definitions

Security Incident: Any event that actually or potentially jeopardizes the confidentiality, integrity, or availability of an information system, or constitutes a violation of security policies, acceptable use policies, or standard security practices.

Data Breach: A security incident in which sensitive, protected, or confidential data is accessed, disclosed, or exfiltrated by an unauthorized party.

Incident Commander (IC): The designated individual responsible for coordinating the incident response effort and making tactical decisions during an active incident.

Severity Classification

3. Incident Response Team

The Incident Response Team (IRT) comprises the following roles, activated based on incident severity:

4. Detection and Identification

Ad Legends employs multiple layers of detection to identify security incidents as early as possible:

4.1 Audit Logging

All authentication events, administrative actions, and security-relevant operations are recorded in a comprehensive audit log stored in our database. Each entry captures the user identity, IP address, user agent, endpoint, event type, severity level, and a full detail payload with timestamps.

4.2 Brute Force Detection

Our system automatically detects brute force attacks by monitoring for repeated failed authentication attempts. When five or more failed login attempts are detected from the same account within a one-hour window, a high-severity alert is automatically generated and the security team is notified.

4.3 Real-Time Alerts

High and critical severity events trigger automated email alerts to the security team in real time. Alert categories include brute force detection, account suspensions, administrative privilege escalations, and anomalous access patterns.

4.4 Web Application Firewall (WAF)

Our hosting infrastructure includes a Web Application Firewall with DDoS protection, IP-based access controls, OWASP managed rulesets, and bot protection. All incoming traffic is inspected at the edge before reaching application servers.

4.5 Health Monitoring

A public health check endpoint monitors database connectivity, application availability, and system performance. This endpoint supports integration with external uptime monitoring services for 24/7 coverage.

4.6 Dual Audit Trail

Security events are recorded in two independent systems: our application-level audit log and our authentication provider's built-in audit log. This dual trail ensures no single point of failure for security event recording and provides independent verification of incident timelines.

5. Containment Procedures

Upon confirming a security incident, the following containment measures are available and can be executed immediately through our administrative security dashboard:

5.1 Account Suspension

Compromised accounts can be immediately suspended, which blocks all API access, bans the account at the authentication provider level (preventing token refresh), invalidates all active sessions across all devices, and generates an audit log entry with the full action context.

5.2 Session Revocation

For situations requiring session termination without full account suspension, all active sessions for a specific user can be globally revoked. The user retains their account but must re-authenticate on all devices.

5.3 IP Blocking

Attacking IP addresses identified through audit log analysis can be blocked at the WAF level. IP blocking is applied at the edge network and takes effect immediately across all application endpoints.

5.4 Credential Rotation

In the event of infrastructure-level compromise, service credentials including database connection strings, API keys, authentication service keys, and third-party integration tokens can be rotated. Credential rotation procedures are documented in our internal runbooks.

6. Eradication and Recovery

6.1 Root Cause Analysis

Following containment, the security team conducts a thorough root cause analysis using audit log data, infrastructure logs, and any available forensic evidence. The analysis identifies the attack vector, scope of compromise, and any vulnerabilities exploited.

6.2 Remediation

Based on root cause analysis, remediation actions are implemented. These may include patching vulnerabilities, updating access controls, strengthening authentication requirements, modifying firewall rules, or updating application code.

6.3 System Restoration

Affected systems are restored to a known-good state. User accounts are unsuspended after identity verification, sessions are re-established, and normal operations resume under enhanced monitoring.

6.4 Enhanced Monitoring

Following an incident, enhanced monitoring is implemented for a minimum of 30 days. This includes increased alert sensitivity, additional logging, and more frequent security reviews of the affected systems.

7. Evidence Preservation

Preserving evidence is critical for post-incident analysis, compliance requirements, and potential legal proceedings.

7.1 Audit Log Export

Complete audit logs can be exported in CSV format with full detail payloads including event IDs, user identities, IP addresses, user agents, endpoints, timestamps, and action-specific metadata. Exports are generated before any remediation actions are taken.

7.2 Log Indexing and Filtering

Audit logs are indexed by severity, event type, user identity, and timestamp, enabling rapid filtering and analysis during active incidents. Pagination ensures complete data access regardless of log volume.

7.3 Chain of Custody

Exported evidence files are stored with descriptive naming conventions including incident date and description. Access to evidence files is restricted to authorized security personnel and is tracked for chain of custody purposes.

7.4 Dual Audit Trail Verification

Evidence from both the application audit log and the authentication provider's audit log is cross-referenced to verify incident timelines and ensure completeness. Discrepancies between the two trails are investigated as part of the evidence review process.

8. Communication Protocols

8.1 Internal Communication

Security alerts are automatically distributed to the security team via email when high or critical severity events are detected. The Incident Commander coordinates all internal communications during an active incident.

8.2 Affected User Notification

Users affected by a confirmed security incident are notified within 72 hours of incident confirmation, in compliance with applicable data protection regulations. Notifications include a description of the incident, the data potentially affected, actions taken, and recommended user actions.

8.3 Enterprise Client Communication

Enterprise clients receive dedicated incident communications through their designated security contacts. Communication timelines and formats are governed by the applicable Service Level Agreement (SLA). Enterprise clients may request detailed incident reports for their own compliance and audit requirements.

8.4 Regulatory Notification

Where a data breach meets the notification threshold under applicable regulations (including GDPR, CCPA, and state breach notification laws), the relevant supervisory authorities are notified within the required timeframes. Legal counsel coordinates all regulatory notifications.

8.5 Public Communication

Public communications regarding security incidents are authorized only by the Executive Sponsor and coordinated through the Communications Lead. Public statements are reviewed by legal counsel before release.

9. Post-Incident Review

9.1 Review Timeline

A formal post-incident review is conducted within 48 hours of incident closure for P1 and P2 incidents, and within one week for P3 incidents.

9.2 Incident Report

Each reviewed incident produces a formal report containing: a complete timeline of events, root cause analysis, scope and impact assessment, containment and remediation actions taken, effectiveness evaluation, and recommended improvements.

9.3 Procedure Improvements

Findings from post-incident reviews are incorporated into updated procedures, detection rules, and response playbooks. This Incident Response Plan is updated to reflect lessons learned and close any identified procedural gaps.

10. Technical Infrastructure

Ad Legends' security infrastructure includes the following technical controls:

10.1 Encryption

• All data in transit is encrypted using TLS 1.2 or higher
• Data at rest is encrypted using AES-256 encryption
• Database connections require SSL with certificate verification

10.2 Security Headers

• HTTP Strict Transport Security (HSTS) enforced
• X-Content-Type-Options: nosniff
• X-Frame-Options configured to prevent clickjacking
• Content Security Policy (CSP) headers active

10.3 Authentication Security

• Industry-standard authentication provider with built-in rate limiting
• JWT token management with secure refresh mechanisms
• Support for OAuth 2.0 social authentication providers
• Global session revocation capability

10.4 Database Security

• Database-level isolation with automated credential rotation
• Connection pooling with encrypted connections
• Parameterized queries enforced through ORM to prevent SQL injection
• Regular automated backups with point-in-time recovery

10.5 Web Application Firewall

• DDoS protection active on all endpoints
• OWASP managed rulesets enabled
• IP-based access controls with real-time blocking
• Bot detection and mitigation

10.6 Health Monitoring

• Automated health check endpoint with database connectivity verification
• 30-second polling interval from administrative dashboard
• Integration support for external uptime monitoring services
• Version tracking and environment identification

11. Data Protection Measures

11.1 AI Data Processing

Ad Legends follows Zero Data Retention (ZDR) principles for AI processing. User content and prompts sent to AI models are processed ephemerally and are never used to train, fine-tune, or improve any AI models. Creative content remains exclusively owned by the user.

11.2 SOC 2 Compliance

Ad Legends operates on SOC 2 Type II–compliant infrastructure. Our security controls are designed to meet or exceed the Trust Services Criteria for security, availability, processing integrity, confidentiality, and privacy.

11.3 Encrypted Storage

All user assets, brand materials, and creative content are stored in globally redundant, encrypted storage with private access controls. Direct public access to storage is prohibited; all asset access is mediated through authenticated proxy endpoints.

11.4 Data Processing Addendum

Enterprise customers may request a Data Processing Addendum (DPA) that provides additional contractual commitments regarding data handling, security controls, breach notification, and compliance obligations.

12. Compliance and Standards

This Incident Response Plan is aligned with the following standards and regulations:

• SOC 2 Type II: Our infrastructure and operational controls are designed to meet SOC 2 Trust Services Criteria
• GDPR (General Data Protection Regulation): Incident response procedures include 72-hour breach notification to supervisory authorities and affected data subjects where required
• CCPA (California Consumer Privacy Act): California residents are notified of data breaches in accordance with CCPA requirements
• NIST Cybersecurity Framework: Our incident response procedures align with NIST SP 800-61 (Computer Security Incident Handling Guide) phases: Preparation, Detection & Analysis, Containment, Eradication & Recovery, and Post-Incident Activity

13. Policy Review and Updates

13.1 Annual Review

This Incident Response Plan is reviewed and updated at least annually by the security team and executive leadership. Reviews assess the effectiveness of current procedures, incorporate industry developments, and address any identified gaps.

13.2 Post-Incident Updates

Following any P1 or P2 security incident, this plan is reviewed within 30 days to incorporate lessons learned and procedural improvements identified during the post-incident review.

13.3 Tabletop Exercises

The Incident Response Team conducts tabletop exercises at least twice per year to validate procedures, identify gaps, and ensure team readiness. Exercise scenarios are based on current threat intelligence and lessons learned from past incidents.

14. Contact Information

For security concerns, incident reports, or questions about this plan, please contact us through the following channels:

• Security Team: security@adlegends.ai
• Data Protection Officer: dpo@adlegends.ai
• General Support: support@adlegends.ai
• Mailing Address:
  Ad Legends, Inc. (a Delaware corporation)
  590 East Riverside Drive
  Bastrop, TX 78602

Enterprise clients with dedicated SLAs should contact their assigned account representative or use the enterprise support channel specified in their service agreement.