SYNTHET Security Incident Response Policy

1) Scope

This policy applies to security incidents affecting:

• SYNTHET's production infrastructure, services, and dashboards
• Operator/admin systems used to manage the Service
• Customer-facing web dashboards and APIs
• Data processed or stored by the Service (including limited billing records where applicable)

This policy does not cover incidents solely within Discord's platform, third-party customer environments, or customer-managed systems unless those incidents directly impact SYNTHET's systems or data.

2) Definitions

• Security Incident: A confirmed event that compromises (or has a high likelihood of compromising) the confidentiality, integrity, or availability of SYNTHET systems or data.
• Personal Data: Information relating to an identifiable individual.
• Breach: A security incident that results in unauthorized access to, disclosure of, or loss of personal data or restricted data.
• Restricted Data: Sensitive operational data, security secrets, authentication artifacts, billing evidence (limited), or logs that could increase risk if exposed.

3) Incident Severity Levels (Public Classification)

We classify incidents to drive consistent response:

• SEV-1 (Critical): Active exploitation or high-confidence compromise of restricted data, widespread service compromise, or materially harmful impact.
• SEV-2 (High): Confirmed vulnerability exploitation with limited scope, significant service disruption, or restricted data exposure risk not yet fully contained.
• SEV-3 (Moderate): Contained incident with limited scope (e.g., single subsystem), no confirmed restricted data compromise, or moderate operational impact.
• SEV-4 (Low): Suspicious activity, failed exploit attempts, minor misconfigurations, or issues with no confirmed impact.

Severity may be updated as investigation progresses.

4) Preparedness (What We Maintain)

We maintain an incident response capability designed for rapid containment and recovery, including:

• incident response roles and escalation paths
• on-call coverage (as operationally feasible)
• security monitoring and alerting for production systems
• audit logging for privileged actions
• backups and recovery procedures for critical systems
• access controls (least privilege, RBAC/ORBAC for operator actions)
• secure key/token handling and rotation procedures
• documented runbooks for common incident classes

5) Detection and Reporting

5.1 Detection Sources

We may detect incidents via:

• automated monitoring and security alerts
• anomaly detection (traffic, auth failures, abuse signals)
• internal audits and operator review
• reports from customers or security researchers
• third-party provider notifications

5.2 How to Report a Security Issue

If you believe you have discovered a vulnerability or security incident involving SYNTHET, contact:

[email protected]

Include:

• a clear description of the issue
• reproduction steps (if safe)
• affected URLs/endpoints/features
• timestamps and evidence
• whether personal data may be involved

Do not publicly disclose the issue before we have had a reasonable opportunity to investigate and remediate.

6) Response Lifecycle (How We Handle Incidents)

Our response generally follows these phases (some may occur in parallel):

6.1 Triage

• validate the report and determine if it is a security incident
• assign an initial severity (SEV-1 to SEV-4)
• establish an incident commander (IC) for SEV-1/SEV-2 incidents
• start an incident record (ticket) with timestamps and actions

6.2 Containment

We take actions appropriate to the incident, such as:

• isolating affected systems or services
• blocking malicious IPs/identities (where feasible)
• disabling risky features temporarily (safety shutdown)
• revoking or rotating exposed credentials, tokens, or keys
• enforcing additional access controls

6.3 Eradication

• identify root cause (vulnerability, misconfiguration, compromised credentials, etc.)
• remove malicious artifacts or persistence
• patch vulnerabilities and harden controls
• validate via testing and security checks

6.4 Recovery

• restore services safely and incrementally
• validate integrity, configuration, and access boundaries
• monitor for recurrence
• ensure billing and entitlement systems are consistent (where relevant)

6.5 Post-Incident Review

• write a post-incident report (internal)
• implement corrective actions and preventive measures
• update runbooks/controls
• consider customer-facing summary where appropriate

7) Customer Communication and Notifications

7.1 Status Updates

For incidents that materially affect availability or security, we may post updates to our public status page and/or Dashboard notices. Updates may include:

• what is impacted (high level)
• current status (investigating/mitigating/monitoring/resolved)
• recommended customer actions (if any)

7.2 Data Breach Notifications (KSA + International)

If we determine that an incident constitutes a breach involving personal data or restricted data and notification is required under applicable laws/regulatory guidance:

• we will notify relevant stakeholders as required and as soon as practicable, considering legal obligations, investigation needs, and guidance from competent authorities
• notifications will be scoped to affected customers/users where feasible
• we will provide high-level details, impact, mitigation steps, and recommended actions

7.3 What We Will Not Disclose

To protect customer security and reduce risk, we generally will not publicly disclose:

• detailed exploit chains or step-by-step attack instructions
• sensitive internal architecture diagrams
• full logs, secrets, or identifiers that increase risk
• information that would compromise ongoing investigations

8) Data Handling During Incidents (Minimization + Security)

During incident response, we apply strict controls:

• access to incident artifacts is limited to authorized personnel
• sensitive fields are redacted where possible
• evidence is retained only as long as necessary for investigation, legal compliance, and dispute defense (where applicable)
• incident records are logged and audited

We do not collect additional personal data for incident response unless necessary to investigate or comply with legal obligations.

9) Coordination With Third Parties

If the incident involves or impacts third parties (e.g., hosting providers, payment providers, Discord platform dependencies), we may:

• coordinate remediation with those providers
• follow their incident reporting processes where relevant
• apply additional safeguards or temporary restrictions

10) Customer Responsibilities (Shared Security)

You are responsible for:

• keeping your Discord account secure (strong security, MFA where available)
• assigning Dashboard access appropriately via RBAC
• limiting privileged bot permissions to what your server needs
• promptly reporting suspicious behavior or suspected compromises

11) Vulnerability Disclosure (Public Guidance)

We encourage responsible vulnerability disclosure.

• Do not exploit vulnerabilities beyond what is necessary to demonstrate the issue.
• Do not access other users' data.
• Do not conduct disruptive testing (e.g., DDoS, mass spam).
• Provide sufficient detail to reproduce and fix the issue.

We may acknowledge researchers where appropriate, subject to our policies.

12) Policy Updates

We may update this policy to reflect changes in legal requirements, operational processes, or security posture. The “Last Updated” date will change when we do.

13) Contact