Summerbase

Incident Response Plan

Last updated: October 22, 2026

Security incidents are reported at once, triaged by severity, contained and fixed, and personal data breaches are reported to Datatilsynet within 72 hours and to affected customers without undue delay.

Scope

Any event that threatens the confidentiality, integrity or availability of company or customer data or systems, including suspected events.

Severity

Severity Definition
SEV1 – Critical Confirmed customer data breach, or full production outage
SEV2 – High Suspected breach, compromised account with production access, partial outage
SEV3 – Medium Contained malware, lost encrypted laptop, vulnerability under active exploitation elsewhere
SEV4 – Low Phishing attempt with no click, policy violation without impact

Incidents are handled in order of severity. Personal data breaches follow the notification deadlines in the Notify step below.

Process

  1. Report. Anyone who suspects an incident, including customers and security researchers, reports it to security@summerbase.com at once.
  2. Triage. The Security Officer (or CTO as backup) assigns severity and an incident lead, and opens a written incident record.
  3. Contain. Limit damage: revoke credentials, isolate systems, block traffic, preserve logs and evidence.
  4. Eradicate and recover. Remove the cause, restore from clean sources (Business Continuity and Disaster Recovery Plan), and confirm normal operation.
  5. Notify.
    • Customers: affected customers are notified without undue delay after becoming aware of a breach affecting their data, as the DPA requires.
    • Datatilsynet: when Summerbase is controller, personal data breaches are reported within 72 hours of becoming aware, unless unlikely to result in risk (GDPR Art. 33). When processor, it notifies the customer so they can meet their own deadline.
    • Data subjects, police (for crimes) and other authorities as required.
  6. Review. SEV1 and SEV2 incidents get a written post-incident review within 30 days, with root cause and actions tracked to completion.
  7. Records. All incidents and breaches are logged, including those not reported to authorities (GDPR Art. 33(5)).

Testing

The plan is tested at least yearly through a tabletop exercise, and updated with what was learned.