Security Incident Response Policy

Last updated: March 23, 2026 — Effective Date: March 23, 2026

This Security Incident Response Policy ("Policy") establishes the procedures, roles, and responsibilities that Gemhubx, operated by Frenchy Digital L.L.C. ("Company," "we," "us," or "our"), follows when detecting, responding to, containing, eradicating, and recovering from security incidents that affect our platform, infrastructure, merchant data, or end-customer information. This Policy is designed to minimize the impact of security events, protect the confidentiality and integrity of data entrusted to us, and ensure compliance with all applicable legal and contractual obligations.

Gemhubx operates as a Shopify application and standalone platform accessible at https://gemhubapp.com. As a processor of merchant and customer data, we recognize our heightened responsibility to maintain robust incident response capabilities and to communicate transparently with affected parties.

1. Purpose

The purpose of this Security Incident Response Policy is to:

• Establish a structured, repeatable framework for identifying, classifying, and responding to security incidents in a timely and effective manner
• Define clear roles, responsibilities, and escalation paths for all personnel involved in incident response activities
• Minimize the duration and impact of security incidents on Gemhubx operations, merchant stores, and end-customer data
• Ensure the preservation of evidence for forensic analysis, regulatory compliance, and potential legal proceedings
• Satisfy notification obligations under the General Data Protection Regulation (GDPR), the California Consumer Privacy Act (CCPA), and Shopify Partner Program requirements
• Provide a basis for continuous improvement through post-incident reviews and lessons learned
• Maintain merchant and partner trust by demonstrating a professional, transparent approach to security event management
• Comply with industry best practices, including NIST SP 800-61 (Computer Security Incident Handling Guide) and ISO/IEC 27035 (Information Security Incident Management)

This Policy is a living document and is reviewed quarterly or immediately following any significant security incident to ensure its continued effectiveness and relevance.

2. Scope

This Policy applies to all security incidents that affect or have the potential to affect the Gemhubx platform, its users, and associated data. Specifically, this Policy covers:

2.1 Systems and Infrastructure

• All production servers, application servers, and database servers (including the Contabo VPS infrastructure)
• Staging and development environments that contain or have access to production data or credentials
• MySQL databases containing merchant accounts, product data, order information, and customer records
• Web application code, including the Laravel application, Blade templates, API endpoints, and background queue workers
• Content delivery and proxy infrastructure (Cloudflare)
• DNS records and domain management systems
• SSL/TLS certificates and HTTPS enforcement mechanisms
• Backup storage locations and disaster recovery systems
• Monitoring, logging, and alerting infrastructure

2.2 Data Categories

• Merchant account data (names, email addresses, business information, billing details)
• Shopify and WooCommerce API tokens and OAuth credentials (encrypted at rest)
• End-customer personal data processed through merchant stores (names, addresses, email addresses, phone numbers, order history)
• Product catalog data, pricing information, and supplier relationship data
• Application logs, audit trails, and session data
• Internal credentials, SSH keys, API secrets, and encryption keys

2.3 Personnel

• All Company employees, contractors, and temporary staff with access to Gemhubx systems
• Third-party service providers and sub-processors with access to Company infrastructure or data
• External security researchers participating in responsible disclosure

2.4 Third-Party Integrations

• Shopify API and App Bridge integrations
• WooCommerce REST API connections
• Payment processing integrations (PayPal, Shopify Billing)
• Supplier data feeds and API connections
• Email delivery services and notification systems
• Any other SaaS tools or external services that interact with Gemhubx data

3. Incident Severity Classification

All security incidents are classified into one of four severity levels based on their actual or potential impact on data confidentiality, system integrity, service availability, and regulatory exposure. The severity level determines the response urgency, escalation requirements, and notification obligations.

Severity levels may be escalated at any point during the response process as new information becomes available. An incident initially classified as Level 3 that reveals evidence of data exfiltration must be immediately reclassified to Level 1.

4. Incident Response Team

The Gemhubx Incident Response Team (IRT) is responsible for coordinating all aspects of incident detection, analysis, containment, eradication, recovery, and post-incident review. The IRT is activated whenever an incident of Level 2 or higher is declared.

4.1 Team Roles and Responsibilities

4.2 Escalation Path

The following escalation path is followed when an incident is detected:

1. Detection: Any team member or automated monitoring system identifies a potential security event and immediately notifies the on-call Technical Lead via the designated incident communication channel
2. Initial Triage: The Technical Lead performs rapid triage (target: under 15 minutes) to confirm whether the event constitutes a genuine security incident and assigns an initial severity level
3. IRT Activation: For Level 1 and Level 2 incidents, the Technical Lead immediately notifies the Incident Commander. The Incident Commander activates the full IRT and establishes an incident war room (virtual or physical)
4. Executive Notification: For Level 1 incidents, the Incident Commander notifies executive leadership within 30 minutes of confirmation. For Level 2 incidents, notification occurs within 2 hours
5. External Escalation: If the incident involves a confirmed data breach affecting personal data, the Incident Commander authorizes the Communications Lead to initiate regulatory notification procedures in accordance with Section 6 of this Policy
6. Ongoing Coordination: The IRT conducts status check-ins at regular intervals (every 30 minutes for Level 1, every 2 hours for Level 2) until the incident is resolved

4.3 Contact Information

Primary incident reporting channels:

• Security Team Email: [email protected]
• General Support: [email protected]

All incident reports are acknowledged within the response time specified for the assigned severity level.

5. Response Phases

Gemhubx follows a structured six-phase incident response methodology aligned with NIST SP 800-61 guidelines. Each phase has defined objectives, procedures, and deliverables.

5.1 Phase 1: Preparation

Preparation is the foundation of effective incident response. Gemhubx maintains the following preparedness measures on an ongoing basis:

Access Controls and Authentication:

• All production server access requires SSH key-based authentication; password-based SSH login is disabled
• Administrative access to the application is restricted by role-based access control (RBAC)
• Shopify API tokens and OAuth credentials are encrypted at rest using AES-256 encryption
• Database credentials are stored in environment variables, never in source code or version control
• Multi-factor authentication (MFA) is enforced for all administrative accounts and hosting control panels
• API rate limiting is enforced to prevent abuse and credential stuffing attacks

Monitoring and Detection:

• Application error logging via Laravel's logging subsystem with daily rotation and 90-day retention
• Server access logging (SSH, HTTP) with centralized log aggregation
• Cloudflare Web Application Firewall (WAF) with real-time threat detection and blocking rules
• Automated alerting for unusual error rates, failed authentication attempts, and abnormal traffic patterns
• Database query logging for privileged operations (CREATE, ALTER, DROP, DELETE on sensitive tables)
• Webhook signature validation on all incoming Shopify and partner webhook payloads

Security Hardening:

• UFW firewall configured to allow only ports 22 (SSH), 80 (HTTP), and 443 (HTTPS)
• HTTPS enforced via Let's Encrypt certificates with automatic renewal
• SameSite=None cookies with Secure flag for Shopify embedded app compatibility
• Content Security Policy (CSP) frame-ancestors header to prevent clickjacking
• Regular dependency updates and vulnerability scanning via composer audit
• PHP configuration hardened (expose_php=Off, display_errors=Off in production)
• MySQL configured with restricted user privileges (principle of least privilege)

Data Protection:

• Database encryption at rest for sensitive fields (API tokens, OAuth secrets, payment credentials)
• TLS 1.2+ enforced for all data in transit
• Automated daily database backups with off-site storage and 30-day retention
• Backup integrity verification through automated restoration tests (monthly)
• Secure deletion procedures for deprovisioned merchant data

Training and Awareness:

• All team members complete security awareness training upon onboarding and annually thereafter
• Incident response tabletop exercises conducted semi-annually to test team readiness
• Responsible disclosure procedures documented and communicated to all personnel
• Phishing simulation exercises conducted quarterly to measure awareness

5.2 Phase 2: Detection and Analysis

The detection and analysis phase focuses on identifying potential security incidents, confirming their validity, and determining the scope and severity of the event.

Detection Sources:

• Automated monitoring alerts (Cloudflare, server monitoring, application error tracking)
• Manual review of application and server logs
• Reports from merchants, customers, or external security researchers
• Shopify Partner Dashboard notifications and security advisories
• Third-party vulnerability disclosure databases (CVE, NVD)
• Anomaly detection in API usage patterns, traffic volume, or authentication behavior

Analysis Procedures:

1. Event Correlation: Cross-reference the detected event across multiple log sources (application logs, server logs, Cloudflare logs, database logs) to establish a complete timeline
2. Scope Assessment: Determine which systems, data categories, and users are affected or potentially affected by the incident
3. Impact Analysis: Evaluate the potential for data loss, data exposure, service disruption, financial harm, and reputational damage
4. Severity Classification: Assign an initial severity level per the classification table in Section 3 and escalate if warranted
5. Evidence Preservation: Create forensic copies of relevant logs, files, and system states before any remediation actions are taken
6. Documentation: Record all findings, timestamps, and analyst observations in the incident log

Indicators of Compromise (IoC):

5.3 Phase 3: Containment

The containment phase aims to limit the scope and impact of the incident while preserving evidence for forensic analysis. Containment strategies are selected based on the severity and nature of the incident.

Immediate Containment (Short-Term):

• Network Isolation: Isolate affected servers from the network using firewall rules or Cloudflare IP blocking. For critical incidents, take the affected server offline entirely if necessary to prevent further data exposure
• Credential Revocation: Immediately revoke and rotate all potentially compromised credentials, including Shopify API tokens, database passwords, SSH keys, OAuth secrets, and session tokens
• IP Blocking: Block attacker IP addresses and ranges at the Cloudflare WAF level and at the server firewall (UFW) level
• Session Invalidation: Force termination of all active sessions for affected accounts. Clear the Laravel session table for compromised users
• Account Lockout: Temporarily disable compromised merchant accounts to prevent further unauthorized access
• Webhook Suspension: If webhook forgery is suspected, temporarily suspend webhook processing and validate all pending webhook payloads against HMAC signatures

Extended Containment (Long-Term):

• Emergency Patching: Apply emergency security patches to address the exploited vulnerability. Test patches in staging before deploying to production when time permits; for Level 1 incidents, direct production patching is authorized
• Network Segmentation: Implement additional network segmentation to isolate sensitive systems (databases, backup storage) from potentially compromised application servers
• Enhanced Monitoring: Deploy additional monitoring and logging on affected systems to detect any continued attacker activity or lateral movement
• Backup Isolation: Verify the integrity of recent backups and isolate them from potentially compromised systems to ensure recovery capability
• Third-Party Notification: Notify affected third-party service providers (Shopify, payment processors, hosting providers) of the incident and coordinate containment measures

5.4 Phase 4: Eradication

The eradication phase focuses on completely removing the threat from all affected systems and eliminating the root cause of the incident.

Eradication Procedures:

1. Root Cause Identification: Conduct thorough forensic analysis to identify the exact vulnerability, misconfiguration, or human error that enabled the incident. Document the attack vector, entry point, and exploitation technique
2. Threat Removal: Remove all malicious code, unauthorized accounts, backdoors, persistence mechanisms, and attacker artifacts from affected systems. Verify removal through independent scanning
3. Vulnerability Patching: Apply permanent fixes for the exploited vulnerability. This may include code changes, configuration updates, dependency upgrades, or architectural modifications
4. Credential Rotation: Complete rotation of all credentials that may have been exposed during the incident, including:
   • Application encryption keys (APP_KEY)
   • Database user credentials
   • Shopify API secrets and OAuth tokens for affected merchants
   • SSH keys for all team members with access to affected systems
   • Third-party API keys and integration credentials
5. System Hardening: Implement additional security controls to prevent recurrence. This may include firewall rule updates, WAF rule additions, stricter access controls, or enhanced input validation
6. Comprehensive Scan: Perform a full vulnerability scan and security assessment of all production systems to identify and remediate any additional weaknesses

5.5 Phase 5: Recovery

The recovery phase restores affected systems and services to normal operation while implementing enhanced monitoring to detect any recurrence.

Recovery Procedures:

1. Backup Restoration: If system integrity cannot be verified, restore affected systems from the most recent known-good backup. Verify backup integrity through checksum validation before restoration
2. System Redeployment: Redeploy the application from a clean, verified source (Git repository) with all security patches applied. Run the full deployment checklist:
   • composer install --no-dev
   • php artisan config:cache
   • php artisan route:cache
   • php artisan migrate
   • php artisan queue:restart
3. Validation Testing: Execute comprehensive validation before returning to normal operations:
   • Run the full automated test suite (php artisan test)
   • Verify Shopify OAuth flow and embedded app loading
   • Test GDPR webhook endpoints
   • Validate product import and sync functionality
   • Confirm queue worker processing
   • Verify the /health endpoint returns successful status
4. Gradual Service Restoration: Restore services incrementally, starting with core functionality (authentication, dashboard access) before enabling data-intensive operations (product imports, order sync)
5. Extended Monitoring Period: Maintain heightened monitoring for a minimum of 30 days following recovery. This includes:
   • Increased log review frequency (daily manual review)
   • Lowered alerting thresholds for anomalous activity
   • Additional integrity checks on sensitive database tables
   • Monitoring for attacker re-entry through alternative vectors
6. Merchant Communication: Notify affected merchants when services are fully restored and provide guidance on any actions they should take (e.g., reconnecting their store, reviewing imported products)

5.6 Phase 6: Post-Incident Review

A formal post-incident review is conducted within five (5) business days of incident resolution to capture lessons learned and drive continuous improvement.

Review Deliverables:

• Incident Timeline: A detailed, minute-by-minute chronology of the incident from initial detection through final resolution, including all actions taken, decisions made, and communications sent
• Root Cause Analysis: A thorough analysis of the root cause, contributing factors, and the chain of events that led to the incident. This should identify both technical and process failures
• Impact Assessment: A quantified assessment of the incident's impact, including:
  • Number of affected merchants and end-customers
  • Categories and volume of data potentially exposed
  • Duration of service disruption
  • Financial impact (direct costs, remediation expenses, potential regulatory fines)
  • Reputational impact
• Response Evaluation: An honest assessment of the effectiveness of the response, including what worked well, what could be improved, and any gaps in procedures or capabilities that were identified
• Recommendations: Specific, actionable, and prioritized recommendations for preventing similar incidents, including:
  • Technical remediation (code changes, infrastructure improvements, new security controls)
  • Process improvements (updated procedures, additional training, tool enhancements)
  • Policy updates (changes to this Policy or related security policies)
• Action Items: Each recommendation is assigned an owner, a priority level, and a target completion date. Action items are tracked to completion in subsequent review meetings

Post-incident review reports are retained for a minimum of five (5) years and are available to regulators and auditors upon request.

6. Notification and Communication

Timely and transparent communication is essential during a security incident. Gemhubx maintains strict notification timelines for both internal and external stakeholders.

6.1 Internal Notification Timelines

6.2 External Notification Requirements

Shopify: Gemhubx will notify Shopify Partner Support within twenty-four (24) hours of confirming a security incident that affects merchant data processed through the Shopify integration. This notification includes the nature of the incident, categories of data affected, and remediation steps taken. This obligation applies to all Level 1 and Level 2 incidents involving Shopify merchant data.

Affected Merchants: Merchants whose data has been or may have been compromised will be notified within seventy-two (72) hours of incident confirmation, consistent with GDPR Article 34 requirements. The notification will include:

• A plain-language description of the nature of the security incident
• The categories and approximate volume of personal data affected
• The likely consequences of the breach
• A description of measures taken or proposed to address the incident, including mitigation of adverse effects
• Contact information for the Gemhubx security team for follow-up questions
• Recommended actions the merchant should take (e.g., credential rotation, customer notification)

Regulatory Authorities: Where required by applicable law (including GDPR Article 33), Gemhubx will notify the relevant supervisory authority within seventy-two (72) hours of becoming aware of a personal data breach. The notification will contain the information required by Article 33(3) of the GDPR or the equivalent requirements of the applicable jurisdiction.

Law Enforcement: Gemhubx will cooperate with law enforcement authorities when the incident involves suspected criminal activity, including unauthorized access to computer systems, data theft, fraud, or ransomware. The Incident Commander, in consultation with legal counsel, determines when and how to engage law enforcement.

Security Researchers: If the incident was reported through responsible disclosure by an external security researcher, Gemhubx will acknowledge the report, provide updates on remediation progress, and publicly credit the researcher (with their consent) once the vulnerability has been fully resolved.

7. Data Breach Procedures

This section provides specific procedures for incidents involving the unauthorized access, disclosure, or loss of personal data.

7.1 Personal Data Inventory

Gemhubx processes the following categories of personal data, each with specific handling and breach notification requirements:

7.2 Breach Assessment Criteria

When a potential data breach is identified, the following criteria are used to assess whether the breach triggers notification obligations:

• Nature of the data: Does the breach involve personal data, sensitive personal data, financial data, or authentication credentials?
• Volume of data: How many data records and individuals are affected?
• Identifiability: Can the exposed data be used to identify specific individuals, either alone or in combination with other available information?
• Risk to individuals: What is the likelihood and severity of adverse effects on the affected individuals (identity theft, financial loss, discrimination, reputational damage)?
• Encryption status: Was the affected data encrypted at rest and in transit? If encrypted, were the encryption keys also compromised?
• Containment status: Has the breach been fully contained, or is there ongoing risk of further data exposure?
• Attacker motivation: Is there evidence of targeted, intentional exploitation versus accidental exposure?

If the assessment concludes that the breach is likely to result in a risk to the rights and freedoms of natural persons, regulatory notification is required under GDPR Article 33. If the breach is likely to result in a high risk, direct notification to affected individuals is also required under GDPR Article 34.

7.3 Data Retention and Disposal Schedule

8. Threat Response Playbooks

The following playbooks provide step-by-step response procedures for specific, high-probability threat scenarios. These playbooks supplement the general response phases described in Section 5 and should be executed in conjunction with the overall incident response framework.

8.1 Playbook A: Compromised API Credentials

Trigger: Discovery or report that Shopify API tokens, OAuth secrets, database credentials, or other API keys have been exposed, leaked, or used by an unauthorized party.

Severity: Level 1 (Critical) if production credentials; Level 2 (High) if staging/development credentials.

Response Steps:

1. Immediately identify all credentials that are confirmed or suspected to be compromised
2. Revoke the compromised credentials at the source:
   • Shopify API tokens: Revoke via Shopify Partner Dashboard and regenerate
   • Database credentials: Change MySQL user passwords, update .env, restart the application
   • SSH keys: Remove compromised public keys from authorized_keys, generate new key pairs
   • Application secrets: Rotate APP_KEY (note: this invalidates all encrypted data; re-encryption may be required)
3. Search all code repositories, logs, and configuration files for instances of the compromised credentials
4. Audit access logs for any unauthorized usage of the compromised credentials (unusual API calls, data exports, configuration changes)
5. If Shopify merchant tokens were compromised, notify affected merchants and instruct them to reinstall the app to generate fresh tokens
6. If credentials were committed to a public or shared repository, immediately remove them, rotate all affected secrets, and consider the entire repository history compromised
7. Update credential storage procedures to prevent recurrence (e.g., enhanced secret management, pre-commit hooks to detect credential leaks)

8.2 Playbook B: Unauthorized Database Access

Trigger: Evidence of unauthorized queries, data exports, or structural modifications to production MySQL databases.

Severity: Level 1 (Critical) if personal data was accessed; Level 2 (High) if access was limited to non-sensitive data.

Response Steps:

1. Immediately change all database user credentials and update application configuration
2. Review MySQL general query log and slow query log to identify unauthorized queries, their timestamps, and the data accessed
3. Determine the attack vector (SQL injection, credential compromise, direct server access, application vulnerability)
4. Assess the scope of data exposure: which tables were accessed, how many records were queried, and whether data was exported
5. If SQL injection was the vector, identify the vulnerable endpoint, deploy an immediate fix (parameterized queries, input validation), and scan the entire codebase for similar vulnerabilities
6. Restrict database network access to only the application server IP addresses
7. Verify database integrity: check for unauthorized modifications, inserted records, or deleted data. Compare against the most recent clean backup
8. If personal data was accessed, initiate breach notification procedures per Section 7

8.3 Playbook C: Server Compromise

Trigger: Evidence that an attacker has gained unauthorized access to a production server, including discovery of unauthorized processes, modified system files, unauthorized user accounts, or reverse shells.

Severity: Level 1 (Critical).

Response Steps:

1. Create a forensic snapshot of the compromised server's disk and memory state before any remediation actions
2. Immediately isolate the compromised server from the network (disable all network interfaces except a dedicated forensic management interface)
3. Revoke all credentials stored on or accessible from the compromised server
4. Analyze the forensic snapshot to determine:
   • Method of initial compromise (SSH brute force, application vulnerability, supply chain attack, social engineering)
   • Actions taken by the attacker (data access, lateral movement, persistence establishment, malware installation)
   • Duration of unauthorized access
   • Data potentially exfiltrated
5. Provision a new, clean server from a verified base image. Do NOT attempt to clean the compromised server
6. Deploy the application to the new server from a verified source (Git repository), applying all security patches and hardening measures
7. Restore data from the most recent backup verified to predate the compromise
8. Implement additional access controls: review and restrict SSH access, enable fail2ban, update firewall rules
9. Conduct a thorough security audit of all remaining infrastructure to check for lateral movement

8.4 Playbook D: Webhook Forgery

Trigger: Receipt of webhook payloads that fail HMAC signature validation, or evidence that forged webhook data has been processed by the application.

Severity: Level 2 (High) if forged data was processed; Level 3 (Medium) if forgery was detected and blocked.

Response Steps:

1. Immediately verify that HMAC signature validation is correctly implemented and enforced on all webhook endpoints (Shopify webhooks, GDPR webhooks, supplier webhooks)
2. Review webhook processing logs to identify any forged payloads that may have been processed before detection
3. If forged data was processed, assess the impact:
   • Were product records modified based on forged data?
   • Were order records or fulfillment statuses altered?
   • Were customer records created or modified?
   • Were app uninstall or data deletion jobs triggered?
4. Reverse any data modifications that resulted from processing forged webhooks. Restore affected records from backup if necessary
5. Block the source IP addresses of the forged webhook requests at the Cloudflare and server firewall levels
6. Implement additional webhook security measures: IP allowlisting for Shopify webhook sources, request rate limiting on webhook endpoints, webhook replay prevention (nonce/timestamp validation)
7. Rotate webhook signing secrets via the Shopify Partner Dashboard

8.5 Playbook E: DDoS Attack

Trigger: Sustained, abnormal traffic volume causing service degradation or unavailability, or notification from Cloudflare of an ongoing DDoS attack.

Severity: Level 2 (High).

Response Steps:

1. Verify that Cloudflare DDoS protection is active and operating. Escalate the protection level to "Under Attack" mode in the Cloudflare dashboard
2. Analyze traffic patterns to identify attack characteristics (source IPs/ranges, request patterns, target endpoints, protocol)
3. Implement targeted Cloudflare WAF rules to block or challenge attack traffic while allowing legitimate merchant and customer access
4. If the attack bypasses Cloudflare (e.g., targeting the origin IP directly):
   • Verify that the origin server IP is not publicly disclosed
   • Implement server-level rate limiting using UFW or iptables
   • Consider provisioning a new server with a fresh IP and updating Cloudflare DNS
5. Monitor server resource utilization (CPU, memory, disk I/O, network bandwidth) and scale resources if necessary
6. Notify merchants if service availability is significantly impacted, providing estimated restoration timelines
7. After the attack subsides, analyze attack data to improve future DDoS resilience (enhanced WAF rules, origin IP protection, rate limiting thresholds)

8.6 Playbook F: Ransomware

Trigger: Discovery of encrypted files, ransom demands, or evidence of ransomware execution on any Company system.

Severity: Level 1 (Critical).

Response Steps:

1. DO NOT pay the ransom. There is no guarantee of data recovery, and payment funds criminal activity
2. Immediately isolate all affected systems from the network to prevent lateral spread. Disconnect backup storage to protect backup integrity
3. Create a forensic image of affected systems for law enforcement and forensic analysis
4. Identify the ransomware variant and infection vector. Check public ransomware decryption resources (No More Ransom project) for available decryption tools
5. Determine the scope of encryption: which systems, databases, and files are affected
6. Verify the integrity of offline and off-site backups. Confirm that backups predate the ransomware infection
7. Provision new, clean infrastructure from verified base images
8. Restore data from verified clean backups to the new infrastructure
9. Deploy the application from a verified Git source with all security patches applied
10. Conduct a thorough investigation to determine the initial infection vector and remediate the underlying vulnerability
11. Report the incident to law enforcement authorities
12. Implement enhanced anti-malware controls, including endpoint protection, restricted execution policies, and enhanced backup isolation

9. Business Continuity

Gemhubx maintains business continuity and disaster recovery capabilities to ensure the rapid restoration of services following a security incident or other disruptive event.

9.1 Backup Strategy

9.2 Recovery Time Objectives

9.3 Disaster Recovery Procedures

• Server Failure: Provision a replacement server on Contabo VPS, restore from the most recent full database backup and incremental backups, redeploy the application from Git, and update DNS records via Cloudflare
• Database Corruption: Restore the MySQL database from the most recent verified backup. Apply incremental backups to minimize data loss. Validate data integrity before returning to production
• Complete Infrastructure Loss: Provision new infrastructure, restore from off-site backups, redeploy from Git, reconfigure DNS, and re-establish SSL certificates via Let's Encrypt. Target: return to operation within the RTO defined above

10. Compliance

Gemhubx is committed to complying with all applicable data protection and privacy regulations. This incident response policy is designed to meet the requirements of the following frameworks:

10.1 General Data Protection Regulation (GDPR)

• Article 33 — Notification to Supervisory Authority: In the event of a personal data breach, Gemhubx will notify the competent supervisory authority without undue delay and, where feasible, no later than seventy-two (72) hours after becoming aware of the breach. Where notification is not made within 72 hours, it will be accompanied by reasons for the delay
• Article 34 — Communication to Data Subjects: When a personal data breach is likely to result in a high risk to the rights and freedoms of natural persons, Gemhubx will communicate the breach to affected individuals without undue delay, describing the nature of the breach, the likely consequences, and the measures taken to address it
• Article 32 — Security of Processing: Gemhubx implements appropriate technical and organizational measures to ensure a level of security appropriate to the risk, including encryption, pseudonymization, ongoing confidentiality, integrity, availability testing, and regular security assessments
• Article 5(1)(f) — Integrity and Confidentiality: Personal data is processed in a manner that ensures appropriate security, including protection against unauthorized or unlawful processing, accidental loss, destruction, or damage

10.2 California Consumer Privacy Act (CCPA)

• Gemhubx maintains reasonable security procedures and practices appropriate to the nature of the personal information collected to protect it from unauthorized access, destruction, use, modification, or disclosure
• In the event of a breach of security involving personal information as defined under California Civil Code Section 1798.82, Gemhubx will comply with applicable notification requirements, including notifying affected California residents in the most expedient time possible and without unreasonable delay
• Gemhubx maintains an up-to-date inventory of the categories of personal information collected, disclosed, and sold (if applicable) to facilitate breach impact assessment

10.3 Shopify Partner Program Requirements

• Gemhubx complies with the Shopify Partner Program Agreement and the Shopify API Terms of Use
• Mandatory GDPR webhooks are implemented and functional:
  • customers/data_request — handled by CustomersDataRequestJob
  • customers/redact — handled by CustomersRedactJob
  • shop/redact — handled by ShopRedactJob
• The app/uninstalled webhook is implemented via AppUninstalledJob, which securely deletes merchant tokens and associated data upon app uninstallation
• All webhook payloads are validated against HMAC signatures before processing
• Gemhubx uses the current stable Shopify API version (2026-01) and does not rely on deprecated API endpoints
• Security incidents affecting Shopify merchant data are reported to Shopify within twenty-four (24) hours of confirmation

11. Policy Maintenance

This Security Incident Response Policy is maintained as a living document and is subject to regular review and updates to ensure its continued effectiveness.

11.1 Review Schedule

11.2 Version History

12. Contact

If you have questions about this Security Incident Response Policy, wish to report a security vulnerability, or need to report a suspected security incident, please contact us using the information below:

Security Team
Gemhubx, operated by Frenchy Digital L.L.C.
Email: [email protected]

General Support
Email: [email protected]
Website: https://gemhubapp.com

Responsible Disclosure: If you are a security researcher and have discovered a vulnerability in Gemhubx, please report it to [email protected]. We ask that you provide us with a reasonable amount of time to address the issue before making any public disclosure. We are committed to acknowledging valid reports, working with you to understand and resolve the issue, and crediting you (with your permission) for your contribution to the security of our platform.

Emergency Reporting: For urgent security incidents requiring immediate attention (Level 1 or Level 2), send an email with the subject line "URGENT: Security Incident" to [email protected]. Include as much detail as possible about the nature of the incident, affected systems, and observed indicators of compromise.

Terms of Service · Privacy Policy · Data Processing Agreement · Information Security Policy · Security Policy · Data Loss Prevention · Cookie Policy · Support