Data Breach Response Plan
Data Breach Response Plan
Organization: ALAI Holding AS — Drop Payment App Document Number: IRP-DROP-BREACH-001 Version: 1.0 Date: 2026-02-23 Author: ALAI Security Team Status: Draft — Approved for use (requires named contacts when team is hired) Reviewers: CISO, DPO, Legal Counsel Next Review: 2027-02-23 (annual) or after any P1/P2 incident Classification: Confidential — Restricted Distribution
Document History
| Version | Date | Author | Changes |
|---|---|---|---|
| 0.1 | 2026-02-12 | Compliance Agent (ALAI) | Initial plan (legal/hendelseshaandtering.md, legal/beredskapsplan.md) |
| 1.0 | 2026-02-23 | Security Architect (ALAI) | English compliance template format |
Sources: legal/hendelseshaandtering.md (IRP-DROP-001), legal/ikt-sikkerhetspolicy.md §9, legal/personvernerklaering.md
IMPORTANT — Keep This Document Accessible
This plan must be accessible even when systems are down. Maintain:
- Offline copy in printed form at office location
- Encrypted copy in a non-Drop system (personal email / offline storage) Offline copy last updated: 2026-02-23
1. Incident Classification
Drop processes sensitive financial data (fødselsnummer, bank accounts, transaction data) regulated by GDPR, DORA, and Hvitvaskingsloven. Classification determines urgency and regulatory notification obligations.
| Severity | Definition | Response Team | Max Time to Classify |
|---|---|---|---|
| P1 — Critical | Confirmed breach of financial/PII data; full service outage; active cyberattack; encryption key compromise; incident affecting >10% of users | Full IRT + Management + Legal | 1 hour |
| P2 — High | Suspected breach with evidence; confirmed internal data breach; compromised admin account; unauthorized production access; critical vendor incident | Core IRT + CISO | 2 hours |
| P3 — Medium | Security event with breach potential; precautionary containment; high CVSS vulnerability in production | Security team | 8 hours |
| P4 — Low | Security anomaly; no confirmed breach; elevated monitoring | Security team | Next business day |
GDPR notification trigger: P1 and P2 incidents MUST be assessed for 72-hour Datatilsynet notification obligation. DORA notification trigger: P1 and major P2 incidents MUST be assessed for Finanstilsynet reporting (initial: 4h, intermediate: 72h, final: 1 month).
Source: legal/hendelseshaandtering.md §3
2. Detection Mechanisms
| Detection Method | Tool | Responsible | Alert Channel |
|---|---|---|---|
| Error monitoring | Sentry | Platform team | Sentry alerts → email |
| SIEM alerts | TBD (Phase 3) | Platform team | PagerDuty (planned) |
| Anomalous API traffic | Rate limiting logs, WAF (Phase 2) | Platform team | Slack #security-alerts |
| Failed authentication spike | Auth service logs + rate limit table | Platform team | Manual monitoring |
| AML transaction flagging | Transaction monitoring rules | Compliance team | Compliance dashboard |
| Third-party notification | Vendor contacts Drop | CISO email | [email protected] |
| User-reported | Support ticket / App contact form | Support team | Escalate to CISO |
| Penetration test finding | External pen tester | Security team | Direct report to CISO |
| Sumsub KYC alert | Sumsub webhook | Platform team | Sumsub dashboard |
| BankID anomaly | BankID Norge AS notification | CISO | Direct notification |
24/7 security contact: Alem Bašić (CISO) — +47 40 47 42 51 | [email protected] Security email: [email protected] (planned — forward to [email protected])
3. Response Team Roles & Contacts
| Role | Primary | Contact | Backup |
|---|---|---|---|
| Incident Commander | Alem Bašić (CEO/CISO) | +47 40 47 42 51 / [email protected] | TBD |
| Security Lead / CISO | Alem Bašić | +47 40 47 42 51 / [email protected] | TBD |
| Engineering Lead | TBD (hire required) | TBD | TBD |
| DPO (GDPR) | TBD (appointment required) | [email protected] | TBD |
| Legal Counsel | TBD (engagement required) | TBD | TBD |
| Communications Lead | Alem Bašić (until comms hire) | [email protected] | TBD |
| AML Compliance Officer | TBD (appointment required) | TBD | TBD |
External contacts:
| Party | Contact | When |
|---|---|---|
| Datatilsynet (GDPR supervisory authority) | www.datatilsynet.no / telefon: 22 39 69 00 | P1 within 72h if breach |
| Finanstilsynet (PSD2/DORA authority) | [email protected] | P1 within 4h if major incident |
| EFE (Enheten for finansiell etterretning — AML) | Via Altinn | Suspicious transactions |
| NorCERT / NCSC | www.nsm.no | P1 cyberattacks |
| FinansCERT | finanscert.no | Financial sector incidents |
| Cyber insurance | TBD — policy not yet obtained | P1/P2 |
| Forensics firm | TBD — retainer not yet in place | P1 |
| Police (Kripos cybercrime) | 02800 | Confirmed criminal activity |
4. Response Procedures by Phase
Phase 1: Detection & Identification (0–1 hour)
Goal: Confirm whether a breach occurred and scope it.
Step 1.1 — ALERT RECEIVED
□ Log initial alert time: ________________
□ Assign to on-call engineer (Alem Bašić until team hired)
□ Create incident channel: #incident-{DATE}-{N} (Slack)
□ Start incident log — chronological, everything in the log
Step 1.2 — INITIAL ASSESSMENT (within 30 minutes)
□ What triggered the alert?
□ Is this a false positive? (if YES → close P4, document)
□ What systems are affected? (authentication, transactions, KYC, AML data)
□ Is the attack/leak ongoing?
□ What data categories potentially affected?
- Fødselsnummer (national ID)? → CRITICAL — Datatilsynet notification likely
- Bank account data? → CRITICAL
- Transaction data? → HIGH
- Email/phone only? → MEDIUM
Step 1.3 — CLASSIFY INCIDENT (P1/P2/P3/P4)
□ Assign severity using criteria in §1
□ If P1/P2: Notify all IRT roles immediately
□ If P3/P4: Notify CISO
Step 1.4 — EVIDENCE PRESERVATION (CRITICAL — before containment if safe)
□ Export Sentry events for the incident time window
□ Export database query logs
□ Take snapshot of application logs
□ Screenshot system state
□ Export AWS CloudTrail logs (Phase 2 — when on AWS)
□ DO NOT wipe or restart affected systems until evidence collected
Exit criteria: Incident classified, IRT assembled, evidence preserved.
Phase 2: Containment (1–4 hours)
Goal: Stop the bleeding. Prevent further data exposure.
Step 2.1 — IMMEDIATE CONTAINMENT
□ Revoke compromised user sessions (server-side session revocation)
□ Revoke compromised API keys / JWT_SECRET rotation if compromised
□ Block malicious IP addresses at WAF/Cloudflare (Phase 2)
□ Disable vulnerable endpoint if applicable (feature flag or route removal)
□ If active exfiltration: take service offline temporarily
Step 2.2 — DROP-SPECIFIC CONTAINMENT ACTIONS
□ If auth compromise: Revoke ALL active sessions (UPDATE sessions SET revoked=1)
□ If KYC data breach: Notify Sumsub (legal/dpa-sumsub.md contact)
□ If banking data breach: Notify Neonomics/Swan (legal/dpa-swan.md contact)
□ If BankID compromise: Contact BankID Norge AS immediately
□ If AML data involved: Preserve for EFE — do NOT delete
Step 2.3 — SCOPE ASSESSMENT
□ Which data was accessed/exfiltrated?
□ Which data subjects are affected? (query users table for affected records)
□ What time period does the breach cover? (from ___ to ___)
□ Was data transferred outside Norway/EEA?
□ Draft scope statement for DPO/legal review
Exit criteria: Active threat contained, no ongoing exfiltration, scope defined.
Phase 3: Eradication (4–24 hours)
Goal: Remove the root cause entirely.
Step 3.1 — ROOT CAUSE ANALYSIS
□ How did the attacker gain access? (entry vector)
□ What vulnerability was exploited?
- Auth bypass?
- SQL injection? (all queries are parameterized — check for gaps)
- Compromised credential?
- Dependency vulnerability?
- Insider threat?
□ How long did the attacker have access?
□ Were other systems reachable from compromised system?
Step 3.2 — REMEDIATE ROOT CAUSE
□ Apply security patch or configuration fix
□ Remove unauthorized accounts or session tokens
□ Rotate: JWT_SECRET, database passwords, all API keys
□ Update vulnerable dependency (per remediation SLAs: Critical → 24h, High → 7 days)
Step 3.3 — VERIFICATION
□ Security team confirms no persistence mechanisms remain
□ Re-run security audit on affected components
□ Review similar endpoints for same vulnerability pattern
Exit criteria: Root cause identified and eliminated. No attacker persistence.
Phase 4: Recovery (24–72 hours)
Goal: Restore systems to full operation safely.
Step 4.1 — SAFE RESTORATION
□ Restore from known-good state or deploy fresh build
□ Rotate ALL credentials (JWT_SECRET, DB passwords, third-party API keys)
□ Verify data integrity against backups
□ Re-enable services incrementally (not all at once)
□ Deploy with enhanced logging verbosity
Step 4.2 — ENHANCED MONITORING (30 days post-incident)
□ Increase Sentry alert sensitivity
□ Add specific rate limit rules for repeat attack patterns
□ Daily security check for 7 days post-recovery
□ AML review of all transactions during breach window
Step 4.3 — STAKEHOLDER UPDATES
□ Update incident channel with recovery progress
□ Brief management (Alem Bašić)
□ Prepare user communication if applicable (see §6.2)
□ Prepare Finanstilsynet notification if DORA-reportable (see §5.1)
Exit criteria: Systems operational. Enhanced monitoring in place. Notifications sent.
Phase 5: Post-Incident (72 hours — ongoing)
Goal: Learn, prevent recurrence, meet legal obligations.
Step 5.1 — POST-MORTEM (within 5 business days for P1/P2)
□ Blameless post-mortem meeting
□ Complete timeline of events (minute-by-minute)
□ Root cause analysis (5 Whys)
□ What went well?
□ What failed? (detection gaps, response gaps, communication gaps)
□ Action items with owners and deadlines
□ Publish post-mortem report
Step 5.2 — REGULATORY COMPLIANCE (see §5)
□ Datatilsynet notification (GDPR — 72h deadline)
□ Finanstilsynet notification (DORA — if major ICT incident)
□ Data subject notifications (if high risk — without undue delay)
□ AML notification to EFE if breach involved AML-relevant data
Step 5.3 — REMEDIATION TRACKING
□ All action items in issue tracker
□ Weekly review for 4 weeks
□ Update threat model with new attack vector
□ Update this plan based on lessons learned
5. Notification Requirements
5.1 Datatilsynet — GDPR Supervisory Authority (72 hours)
Legal basis: GDPR Art. 33 / Personopplysningsloven
Deadline: Within 72 hours of becoming aware of the breach
Required only if: Breach is likely to result in risk to rights and freedoms of data subjects
What to report (GDPR Art. 33(3)):
- Nature of breach: categories and approximate number of data subjects and records
- Contact details of DPO
- Likely consequences of the breach
- Measures taken or proposed to address the breach
Partial notification allowed: Submit what's known within 72h, supplement later.
5.2 Finanstilsynet — DORA ICT Incident Reporting
Legal basis: DORA Art. 19 (applicable in Norway est. 2026 H2) / IKT-forskriften
Reporting thresholds (when an incident is "major"):
- Affects critical payment services
- Affects significant number of users
- Causes or may cause significant economic loss
- Causes data loss or confidentiality compromise
- Has reputational consequences
| Report | Deadline | Content |
|---|---|---|
| Initial | 4 hours after classification as major | Incident type, affected services, initial scope, measures taken |
| Intermediate | 72 hours | Updated scope, preliminary root cause, containment status |
| Final | 1 month | Full description, root cause, consequences, lessons learned |
Contact: [email protected]
5.3 GDPR — Data Subject Notification
Legal basis: GDPR Art. 34
Required if: Breach is likely to result in HIGH risk to data subjects
Timeline: Without undue delay (immediate after confirming high risk)
Method: Email to affected users + in-app push notification + SMS if available
Not required if: Data was encrypted and key not compromised OR post-breach measures ensure high risk no longer likely
5.4 AML — EFE Notification
When: If breach involved AML-relevant data (transaction data, KYC records) and there is suspicion of money laundering or terrorist financing
Contact: EFE (Enheten for finansiell etterretning) via Altinn
Important: Do NOT inform the customer if STR (suspicious transaction report) has been or will be filed — TIPPING OFF is prohibited (hvvl. §28)
5.5 Contractual Obligations
| Obligation | Parties | Timeline | Method |
|---|---|---|---|
| Sumsub DPA notification | Sumsub | Per DPA — see legal/dpa-sumsub.md |
Direct via Sumsub support |
| Swan DPA notification | Swan | Per DPA — see legal/dpa-swan.md |
Direct via Swan support |
| BankID notification | BankID Norge AS | Immediate if BankID data involved | Direct contact |
| Neonomics notification | Neonomics | Per DPA | Direct contact |
6. Communication Templates
6.1 Internal Incident Alert
Subject: [INCIDENT P{SEVERITY}] Security Incident — {DATE} {TIME} UTC
Team,
We have identified a security incident. Details:
Incident ID: INC-{DATE}-{N}
Severity: P{SEVERITY}
Detected: {DATE} {TIME} UTC
Status: ACTIVE — Containment in progress
Incident Commander: Alem Bašić
Incident channel: #incident-{DATE}-{N} (Slack)
DO NOT discuss this incident on public channels, with users, or on social media.
All external communications go through the Incident Commander.
Next update: {TIME} UTC
6.2 Data Subject Notification Template (GDPR Art. 34)
Subject: Important security notice regarding your Drop account
Dear {FIRST_NAME},
We are writing to inform you of a security incident that may have affected your account.
What happened:
On approximately {DATE}, we became aware of a security incident involving unauthorized
access to systems containing personal information associated with your Drop account.
What information was involved:
The following information may have been accessed: {DATA_CATEGORIES}
[e.g., name, email address, phone number, transaction history]
What we have done:
- Contained the security incident and eliminated the threat
- Revoked all active sessions (you will need to log in again)
- Notified the Norwegian Data Protection Authority (Datatilsynet)
- Enhanced monitoring and security measures
What you should do:
- Log back into your Drop account and verify your account details
- Monitor your bank accounts for any unauthorized transactions
- Contact your bank if you notice any suspicious activity
- If you have concerns: contact [email protected]
For more information:
Data Protection Officer: [email protected]
Privacy Policy: https://getdrop.no/personvern
Datatilsynet: www.datatilsynet.no
We take the security of your information very seriously and sincerely apologize for
any concern this may cause.
Regards,
Drop — ALAI Holding AS
Data Protection Officer: {DPO_NAME}
6.3 Datatilsynet Notification Draft (GDPR Art. 33)
To: Datatilsynet
From: {DPO_NAME}, DPO — ALAI Holding AS (Drop)
Date: {DATE} {TIME} UTC
NOTIFICATION OF PERSONAL DATA BREACH (GDPR Art. 33)
Organization: ALAI Holding AS, org.nr. 932 516 136
Product: Drop (getdrop.no)
1. Nature of the breach:
On {DATE}, we became aware of {unauthorized access to / accidental disclosure of}
personal data. The breach {is/was} {ONGOING/CONTAINED}.
2. Categories and approximate number of data subjects concerned:
- Categories: {DATA_CATEGORIES — e.g., name, email, transaction data, fødselsnummer}
- Estimated affected data subjects: {NUMBER}
- Estimated affected records: {NUMBER}
3. Categories and approximate number of personal data records:
{RECORD_CATEGORIES_AND_COUNTS}
4. Contact details of DPO:
Name: {DPO_NAME}
Email: [email protected]
Phone: {DPO_PHONE}
5. Likely consequences of the breach:
{CONSEQUENCES — e.g., identity theft risk, financial harm, reputational damage}
6. Measures taken or proposed:
- Immediate: {MEASURES — e.g., sessions revoked, systems patched, credentials rotated}
- Ongoing: Enhanced monitoring for 30 days
- Planned: {PLANNED_MEASURES}
7. Note: This is a {complete / preliminary — supplementary notification to follow} report.
[DPO Signature]
6.4 Finanstilsynet Initial Report Template (DORA Art. 19)
To: [email protected]
From: CISO — ALAI Holding AS (Drop)
Date: {DATE} {TIME} UTC
INITIAL REPORT — IKT-HENDELSE (DORA Art. 19)
Organization: ALAI Holding AS, org.nr. 932 516 136
Product: Drop (betalingsformidling og pengeoverføringer)
1. Hendelsestype: {TYPE — sikkerhetshendelse/databrudd/DDoS/etc.}
2. Tidspunkt oppdaget: {DATE TIME}
3. Berørte tjenester: {betalingstjenester/AISP/PISP/KYC}
4. Innledende konsekvens: {beskrivelse}
5. Iverksatte tiltak: {containment-tiltak}
6. Status: {Pågående/Inneholdt}
7. Kontaktperson: Alem Bašić, CISO — [email protected] / +47 40 47 42 51
Intermediær rapport følger innen 72 timer.
7. Evidence Preservation Procedures
Principle: COLLECT BEFORE CONTAIN — evidence collection priority unless ongoing harm is severe.
Evidence collection checklist:
□ Export Sentry error events: Full time window + 24h before incident
□ Export application logs: Authentication, transaction, API access logs
□ Export rate_limits table snapshot
□ Export sessions table: All active sessions during incident window
□ Export affected users/transactions: Scoped to breach window
□ Export AWS CloudTrail logs (Phase 2 — when on AWS)
□ Network traffic capture (tcpdump) if attack is ongoing
□ Screenshot: System state, Sentry dashboard, affected endpoints
Chain of custody:
- All evidence files: SHA-256 hash computed immediately after collection
- Hash log: evidence/chain-of-custody.txt
- Storage: Write-protected encrypted volume, access logged
- Custody transfers: Documented with timestamps
8. Forensic Analysis Requirements
| Incident Level | Forensic Approach | Provider |
|---|---|---|
| P1 (Critical) | External forensics firm engaged within 4 hours | TBD — retainer required |
| P2 (High) | Internal log analysis + external if complex | Internal first, escalate |
| P3 (Medium) | Internal log analysis | Security team |
| P4 (Low) | Root cause review | Security engineer |
Evidence retention: All forensic evidence retained minimum 5 years post-incident (per legal/hendelseshaandtering.md §8.3).
9. Lessons Learned Process
Post-mortem deadline: 5 business days for P1/P2; 15 business days for P3/P4
Mandatory post-mortem components:
- Complete incident timeline (minute-by-minute)
- Root cause analysis (5 Whys)
- What went well (preserve these practices)
- What went poorly (specific improvement areas)
- Action items (specific, assigned, time-bound)
- Detection gap analysis (how long before detection?)
- Response gap analysis (where did we slow down?)
- Prevention roadmap (systemic fixes)
- Was this response plan adequate? Update if not.
10. Drill Schedule
| Drill Type | Frequency | Participants | Scenario |
|---|---|---|---|
| Tabletop exercise | Quarterly | Full IRT + management | Ransomware / Data breach / Insider threat |
| GDPR 72h notification drill | Semi-annual | DPO + Legal + Communications | Practice full Datatilsynet notification flow |
| DORA notification drill | Semi-annual | CISO + Engineering | Practice Finanstilsynet initial/intermediate/final report |
| Technical response drill | Annual | Engineering + Security | Live simulation on isolated environment |
Last drill: Not yet conducted — schedule first tabletop within 30 days of team formation Drill coordinator: Alem Bašić (until dedicated security team hired)
Approval
| Role | Name | Date | Signature |
|---|---|---|---|
| Author | ALAI Security Team | 2026-02-23 | |
| DPO | TBD — appointment required | ||
| CISO | Alem Bašić | ||
| Legal Counsel | TBD | ||
| CEO | Alem Bašić |