PyneHub logoPyneHub
All legal documents

PyneHub Incident Response Plan

Last updated: July 18, 2026

This plan covers security incidents affecting PyneHub, including malware found in an app, account compromise, data breach, or platform vulnerability. Security contact: [email protected].

1. Roles

  • Incident Lead — coordinates response and decisions.
  • Maintainers / Engineers — investigate, quarantine, remediate.
  • Comms/Legal — handle notifications, regulators, and takedowns. (Operators: assign named owners; see Follow-up actions.)

2. Severity levels

  • SEV-1 (Critical): active malware distributed to users, or confirmed breach of personal data.
  • SEV-2 (High): exploitable vulnerability, suspected malware, or account compromise without confirmed data loss.
  • SEV-3 (Low/Moderate): limited-impact issue, no active exploitation.

3. Playbook (timeline steps)

T0 — Detect & triage (immediately).

  1. Record the report (source, time, affected app/version/account).
  2. Assign a severity and an Incident Lead. Open an incident record.

T+ (within ~1 hour for SEV-1/2) — Contain. 3. Emergency removal/quarantine of affected artifact(s): make non-downloadable and flag the version (see Terms Part C.1). 4. Suspend compromised accounts; revoke sessions/tokens; force password/2FA reset as needed. 5. Preserve evidence: capture file hashes, logs, timestamps, IPs, device ids before any cleanup. Do not delete logs (place a legal/incident hold).

Investigate. 6. Determine root cause, scope (who downloaded the malicious version and when — use audit logs), and whether personal data was affected.

Notify (see templates and legal timelines below). 7. Notify affected developers and users. Notify regulators if required.

Remediate & recover. 8. Remove malicious content, patch vulnerabilities, rotate secrets, and restore service. Re-review before restoring any developer content.

Post-incident. 9. Write a post-mortem (timeline, root cause, actions, prevention). Track follow-ups to closure.

4. Regulatory notification timelines (advisory)

  • GDPR / UK GDPR: if a personal-data breach is likely to result in a risk to individuals, notify the relevant supervisory authority without undue delay and where feasible within 72 hours of becoming aware; notify affected individuals without undue delay if the risk is high.
  • US / California: notify affected residents in the most expedient time possible and without unreasonable delay, consistent with applicable state breach-notification law.

Confirm exact obligations with legal counsel for each incident.

5. Notification templates

5.1 To developers (app quarantined / removed)

Subject: [PyneHub Security] Action taken on your app: <APP_NAME> v<VERSION>

Hi <DEVELOPER_NAME>,

As part of a security response (incident <INCIDENT_ID>), we have
<quarantined/removed> <APP_NAME> version <VERSION> (SHA-256 <HASH>) on
<DATE/TIME UTC>. Reason: <short reason, e.g., suspected malware / policy
violation>.

What this means: the affected version is no longer downloadable. Your account
status: <active / restricted>.

What we need from you: <remediation steps / respond by DATE>. After you
remediate, reply to this email and we will re-review before any restoration.

Questions: [email protected] (reference <INCIDENT_ID>).

— PyneHub Security

5.2 To users (potentially affected by a malicious/vulnerable app)

Subject: [PyneHub Security] Important: <APP_NAME> <VERSION> — please take action

We are writing to inform you of a security issue involving <APP_NAME>
version <VERSION>, distributed via PyneHub between <START> and <END> (UTC).

What happened: <plain-English description>.
Risk: <what could be affected on your device/data>.
What to do: <uninstall / update to vX.Y.Z / rotate credentials / run scan>.
How to verify: check the app's SHA-256 checksum matches the value published
at <URL> before reinstalling.

We removed the affected version on <DATE/TIME UTC> and are taking steps to
prevent recurrence. Questions: [email protected].

— PyneHub Security

5.3 To a regulator (data breach — skeleton)

Subject: Personal data breach notification — PyneHub — <INCIDENT_ID>

Controller: PyneHub (<contact>)
Date/time of awareness: <...>   Nature of breach: <...>
Categories & approx. number of data subjects: <...>
Categories & approx. number of records: <...>
Likely consequences: <...>
Measures taken/proposed: <containment, remediation, mitigation>
DPO/contact point: <...>

6. Evidence retention

  • Preserve all incident-related logs and artifacts (hashes, IPs, device ids, timestamps, quarantined files) for 730 days (security_incident_logs_days in legal/pynehub.config.yaml), overriding the standard 90-day log purge for those records.
  • Store evidence with restricted (admin-only) access; log all access.
  • Maintain chain-of-custody notes (who collected what, when) for potential legal proceedings.
  • Do not modify original evidence; work on copies.

7. Contacts

Security/incidents: [email protected] Legal/privacy/regulator comms: [email protected]