Contingency plan

Purpose and Responsibility

This plan describes Gojambel GmbH’s response to outages, misconfiguration, data loss, unauthorised access and external-service disruptions. Management (David Klein) coordinates recovery and required escalation. Contact: hello@postbutler.ai.

The plan is not a certification, assurance of already tested fallback systems, or contractual availability guarantee. Actual backups, recovery objectives, monitoring and test evidence must be documented against the deployment.

Detection and Containment

1. Record the scope and start of the incident and appoint a responsible contact.
2. Where necessary, restrict affected functions, revoke access or halt publishing without prematurely deleting evidence or necessary data.
3. Assess application, proxy, database and external providers separately. Preserve necessary logs and status information without uncontrolled disclosure of credentials or private content.
4. Revoke and replace compromised secrets or tokens in an orderly manner, considering effects on stored encrypted LinkedIn tokens.

Recovery and Publication

• Suitable backup of the current data is required before schema changes, restoration and high-risk interventions. Persistent volumes are not independent backups.
• Backup procedures, intervals, retention, locations, encryption and restoration tests must be established and checked operationally. The application does not provide automatic encrypted full backups.
• Recovery uses suitable existing backups or controlled repair. Afterwards, verify integrity, permissions, schema, keys, deletion requests and actual availability.
• Uncertain publication outcomes are checked on LinkedIn before renewed approval; missing receipts do not justify blind retries. Local restoration cannot recall content already sent to LinkedIn.
• A precise recovery time or maximum data loss is promised only by express individual agreement. Statutory and agreed security and service duties remain unaffected.

Personal Data Breaches

A breach may involve loss, alteration, unauthorised disclosure or access, not only an external attack. Nature, affected data and people, likely consequences, measures, awareness time and decisions are documented.

Where Postbutler AI is a processor, the affected Controller is notified without undue delay after awareness under Art. 33(2) GDPR, even if information is incomplete. Information is supplemented in phases. A 72-hour period is not permission to delay this notice.

Where Postbutler AI is itself controller, required notice to the competent authority is made without undue delay and, where feasible, within 72 hours after awareness under Art. 33(1) GDPR, unless the breach is unlikely to risk individuals’ rights and freedoms. Delay must be explained. Likely high risk requires notice to affected people without undue delay under Art. 34 GDPR unless a statutory exception applies. Decisions, including not notifying, must be documented.

Communication and Maintenance

Affected customers receive information necessary for protection and further action without compromising secrets, other customers’ data or investigation security. Data protection notices follow statutory deadlines and the DPA, not merely the outage’s commercial significance.

The plan, emergency contacts, permissions and recovery procedures must be reviewed regularly and after material architecture changes. Tests and remediation must be documented. Multi-factor authentication, backup and monitoring requirements must actually be implemented; publishing this plan does not replace them.

Editorial revision: 9 October 2026.

IT-Notfallplan und Datenschutzvorfälle

1. Zweck und Verantwortung

Dieser Plan beschreibt das Vorgehen der Gojambel GmbH bei Ausfällen, Fehlkonfigurationen, Datenverlust, unbefugtem Zugriff oder Störungen externer Dienste. Die Geschäftsführung (David Klein) verantwortet Koordination, Wiederherstellung und erforderliche Eskalation. Kontakt: hello@postbutler.ai.

Der Plan ist keine Zertifizierung, keine Zusage bereits getesteter Ausweichsysteme und keine vertragliche Verfügbarkeitsgarantie. Konkrete Sicherungen, Wiederherstellungsziele, Monitoring und Prüfnachweise sind anhand der tatsächlichen Bereitstellung zu dokumentieren.

2. Erkennen und Eindämmen

1. Umfang und Beginn der Störung erfassen und einen verantwortlichen Ansprechpartner bestimmen.
2. Betroffene Funktionen gegebenenfalls begrenzen, Zugriffe sperren oder Veröffentlichungsdienst anhalten, ohne Beweise oder notwendige Daten vorschnell zu löschen.
3. Betrieb von Anwendung, Proxy, Datenbank und externer Anbieter getrennt prüfen. Technische Protokolle und Statusinformationen nur im erforderlichen Umfang sichern; Zugangsdaten und private Inhalte nicht unkontrolliert weitergeben.
4. Bei kompromittierten Geheimnissen Schlüssel oder Tokens geordnet widerrufen und ersetzen; Auswirkungen auf gespeicherte verschlüsselte LinkedIn-Tokens berücksichtigen.

3. Wiederherstellung und Veröffentlichungen

• Vor Schemaänderungen, Wiederherstellung und risikoreichen Eingriffen ist eine geeignete Sicherung des aktuellen Datenbestands erforderlich. Persistente Volumes sind keine unabhängige Sicherung.
• Sicherungsverfahren, Intervalle, Aufbewahrung, Speicherorte, Verschlüsselung und Wiederherstellungstests müssen betrieblich festgelegt und überprüft werden. Die Anwendung stellt keine automatische verschlüsselte Vollsicherung bereit.
• Wiederherstellung erfolgt aus geeigneten vorhandenen Sicherungen oder durch kontrollierte Reparatur. Nach Wiederherstellung werden Datenintegrität, Berechtigungen, Schema, Schlüssel, Löschanforderungen und tatsächliche Erreichbarkeit geprüft.
• Veröffentlichungsergebnisse mit unklarem Ausgang werden vor einer erneuten Freigabe auf LinkedIn geprüft; fehlende Belege rechtfertigen keine blinde Wiederholung. Bereits an LinkedIn gesendete Inhalte können nicht durch eine lokale Wiederherstellung zurückgerufen werden.
• Eine genaue Wiederherstellungszeit oder ein bestimmter maximaler Datenverlust wird nur bei ausdrücklicher einzelvertraglicher Vereinbarung zugesagt. Gesetzliche und vereinbarte Sicherheits- und Leistungspflichten bleiben unberührt.

4. Datenschutzverletzungen

Eine Datenschutzverletzung kann Verlust, Veränderung, unbefugte Offenlegung oder unbefugten Zugriff betreffen, nicht nur einen externen Angriff. Art, betroffene Daten und Personen, wahrscheinliche Folgen, Maßnahmen, Erkenntniszeitpunkt und Entscheidungen werden dokumentiert.

Soweit Postbutler AI Auftragsverarbeiter ist, wird der betroffene Verantwortliche nach Bekanntwerden unverzüglich nach Art. 33 Abs. 2 DSGVO informiert, auch wenn noch nicht alle Angaben feststehen. Informationen werden schrittweise ergänzt. Eine 72-Stunden-Frist ist keine erlaubte Wartezeit für diese Mitteilung.

Soweit Postbutler AI selbst Verantwortlicher ist, erfolgt eine erforderliche Meldung an die zuständige Aufsichtsbehörde unverzüglich und möglichst innerhalb von 72 Stunden nach Bekanntwerden gemäß Art. 33 Abs. 1 DSGVO, außer die Verletzung führt voraussichtlich nicht zu einem Risiko für die Rechte und Freiheiten natürlicher Personen. Eine Verzögerung ist zu begründen. Bei voraussichtlich hohem Risiko werden betroffene Personen unverzüglich nach Art. 34 DSGVO informiert, sofern keine gesetzliche Ausnahme greift. Entscheidungen und Nichtmeldungen sind nachvollziehbar zu dokumentieren.

5. Kommunikation und Pflege

Betroffene Kunden erhalten die für Schutz und weitere Maßnahmen notwendigen Informationen, ohne Geheimnisse, Daten anderer Kunden oder die Sicherheit der Untersuchung zu gefährden. Datenschutzmitteilungen richten sich nach den gesetzlichen Fristen und dem AVV; sie werden nicht allein von einer wirtschaftlichen Bedeutung des Ausfalls abhängig gemacht.

Der Plan, Notfallkontakte, Berechtigungen und Wiederherstellungsverfahren sind regelmäßig und nach wesentlichen Architekturänderungen zu prüfen. Tests und Abhilfemaßnahmen müssen dokumentiert werden. Anforderungen an Mehrfaktor-Authentifizierung, Sicherung und Monitoring sind tatsächlich umzusetzen, nicht durch diese Veröffentlichung ersetzt.

Redaktioneller Überarbeitungsstand: 9. Oktober 2026.