Data Breach Response Plan
Data Breach Response Plan
Organization: ALAI Holding AS — Drop Payment App Document Number: IRP-DROP-001 Version: 1.0 Date: 2026-02-23 Author: Security Architect Status: Draft Reviewers: DPO, CISO, Legal Counsel, CEO Next Review: 2027-02-23 Classification: Confidential — Restricted Distribution
Document History
| Version | Date | Author | Changes |
|---|---|---|---|
| 0.1 | 2026-02-23 | Security Architect | Initial draft — Drop incident response |
IMPORTANT — Keep This Document Accessible
This plan must be accessible even when systems are down. Maintain printed copies in:
- ALAI Holding AS office (physical location on file with CEO)
- Secure offline storage (password-protected PDF in personal safe) Offline copy last printed: 2026-02-23
1. Incident Classification
| Severity | Definition | Response Team | Max Time to Classify |
|---|---|---|---|
| P1 — Critical | Confirmed breach of fødselsnummer, KYC documents, transaction data, BankID tokens, or JWT_SECRET; OR system-wide compromise affecting payment processing | Full IRT + CEO + Legal + DPO | 1 hour |
| P2 — High | Suspected breach with evidence; confirmed breach of session data or contact information; targeted attack in progress; AML data exposure | Core IRT + Security Lead + DPO | 2 hours |
| P3 — Medium | Security event with potential for breach; precautionary containment; failed authentication spike; Sentry anomaly | Security team | 8 hours |
| P4 — Low | Security anomaly, no confirmed breach, monitoring escalated; Dependabot critical CVE discovered | Security team | Next business day |
GDPR notification trigger (personopplysningsloven § 30 / GDPR Art. 33): P1 and P2 incidents MUST be assessed for 72-hour Datatilsynet notification obligation. Clock starts when incident is first detected, not confirmed.
AML/Finanstilsynet trigger: P1 incidents involving payment system compromise MUST be reported to Finanstilsynet without undue delay (betalingstjenesteloven § 4-30 analog; IKT-forskriften § 8).
2. Detection Mechanisms
| Detection Method | Tool | Responsible | Alert Channel |
|---|---|---|---|
| Application error spike | Sentry | Engineering | Sentry Slack integration + email |
| Uptime monitoring | BetterStack | Platform | BetterStack alerts → email/SMS |
| Failed authentication spike | Custom middleware metric + Sentry | Engineering | Sentry alert |
| Anomalous API traffic / rate limit hits | Cloudflare WAF + App metrics | Platform | Cloudflare alert |
| JWT_SECRET access (unauthorized) | AWS CloudTrail | Security | AWS alarm |
| Vulnerable dependency CVE | Dependabot / npm audit (CI) | Engineering | GitHub notification |
| Third-party notification (BankID/Sumsub/AWS) | Vendor contacts [email protected] | Security | [email protected] |
| User-reported | Support ticket | Support | Escalate to security immediately |
| Penetration test finding | External pen tester | Security | Direct report to CISO |
24/7 security contact: [email protected] CEO direct escalation: +47 40 47 42 51 (Alem Bašić) DPO contact: [email protected]
3. Response Team Roles & Contacts
| Role | Primary | Phone | |
|---|---|---|---|
| Incident Commander | CEO (Alem Bašić) | +47 40 47 42 51 | [email protected] |
| Security Lead / CISO | [To be appointed] | TBD | [email protected] |
| Engineering Lead | [To be appointed] | TBD | [email protected] |
| DPO (GDPR) | [To be appointed] | TBD | [email protected] |
| Legal Counsel | [To be engaged] | TBD | [email protected] |
| Communications Lead | CEO / Incident Commander | +47 40 47 42 51 | [email protected] |
External contacts:
| Party | Contact | When |
|---|---|---|
| Datatilsynet (GDPR supervisory authority) | [email protected] / +47 22 39 69 00 | P1 — within 72 hours |
| Finanstilsynet (financial regulator) | [email protected] | P1 — payment system compromise |
| Cyber insurance | [Policy to be obtained] | P1/P2 immediately |
| Forensics firm | [Retainer to be obtained] | P1 immediately |
| Norwegian police / Kripos (cybercrime) | 02800 | If criminal activity suspected |
| AWS Security | [email protected] / AWS Support | P1 if AWS infrastructure compromised |
| BankID Norge AS | [Contact from BankID DPA] | P1 if BankID data compromised |
| Sumsub | [Contact from Sumsub DPA] | P1 if KYC data compromised |
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 (UTC): ________________
□ Assign to on-call security engineer or CEO
□ Create incident channel: Slack #incident-{{DATE}} OR email thread
□ Start incident log (chronological — everything goes in the log)
□ Do NOT post on public channels, social media, or with customers
Step 1.2 — INITIAL ASSESSMENT (within 30 minutes)
□ What triggered the alert? (Sentry / BetterStack / Cloudflare / user report)
□ Is this a false positive? (if YES → close P4, document)
□ What systems are affected? (App Runner / SQLite-DB / AWS S3 / BankID integration)
□ Is the attack/leak ongoing?
□ Initial data categories potentially affected?
- Fødselsnummer? (Restricted — L4 → immediate Datatilsynet assessment)
- KYC documents? (Restricted — L4 → immediate Datatilsynet assessment)
- Transaction data? (Confidential — AML reporting may be required)
- Contact data only? (Standard — assess risk to data subjects)
- JWT_SECRET? (All sessions compromised — mass revocation required)
Step 1.3 — CLASSIFY INCIDENT
□ Assign severity: P1 / P2 / P3 / P4
□ Notify Incident Commander (CEO)
□ If P1/P2: Activate full IRT immediately, notify DPO
□ If P1: Start 72-hour Datatilsynet clock ← CRITICAL
□ If P3/P4: Notify Security Lead only
Step 1.4 — EVIDENCE PRESERVATION (CRITICAL — do before containment if safe)
□ Export AWS CloudTrail logs (last 30 days)
□ Export Sentry error logs
□ Export BetterStack access logs
□ Snapshot Cloudflare WAF logs
□ Export SQLite/PostgreSQL audit logs (if available)
□ Document exact system state (screenshots, API responses, timestamps)
□ SHA-256 hash all evidence files immediately — record in custody log
□ DO NOT wipe or restart affected systems until evidence preserved
Exit criteria: Incident classified, IRT assembled (for P1/P2), evidence preserved.
Phase 2: Containment (1–4 hours)
Goal: Stop the bleeding. Prevent further data exposure.
Step 2.1 — IMMEDIATE CONTAINMENT
□ Revoke compromised credentials:
- If JWT_SECRET compromised: rotate immediately, all active sessions invalidated
- If BankID certificate compromised: contact BankID Norge AS immediately
- If AWS credentials compromised: revoke via IAM, rotate Secrets Manager
- If database credentials compromised: rotate password, audit connections
□ Block malicious IP addresses at Cloudflare WAF
□ Disable vulnerable endpoint (return 503) if actively exploited
□ If active data exfiltration: restrict App Runner egress
□ Suspend affected user accounts if account compromise suspected
Step 2.2 — ASSESS CONTAINMENT IMPACT
□ What payment operations are affected by containment?
□ Communicate service status to customers (generic: "We are investigating a technical issue")
□ NO details about security incident in public communications until DPO/Legal approved
Step 2.3 — PREVENT LATERAL MOVEMENT
□ Rotate ALL AWS credentials on affected services
□ Check for unauthorized AWS IAM users or roles
□ Verify no new admin users created in Drop application
□ Check AWS CloudTrail for unusual API calls
□ Verify BankID integration not used with stolen tokens
Step 2.4 — SCOPE ASSESSMENT
□ Which data was accessed/exfiltrated? (query database audit logs)
□ Which data subjects are affected? (SELECT COUNT(*) FROM affected_records)
□ What time period does the breach cover?
□ Was fødselsnummer accessed? (L4 data → MANDATORY Datatilsynet notification)
□ Were transaction records accessed? (AML notification assessment)
□ 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. Ensure the attacker is completely out.
Step 3.1 — ROOT CAUSE ANALYSIS
□ How did the attacker gain access? (XSS / SQL injection / credential stuffing /
supply chain / insider / misconfiguration / BankID session hijack)
□ What vulnerability was exploited?
□ How long did the attacker have access?
□ Were other ALAI systems accessible?
Step 3.2 — REMEDIATE ROOT CAUSE
□ Apply security patch or configuration fix
□ Remove malware or attacker-installed backdoors
□ Remove unauthorized database records or user accounts
□ Fix the vulnerability that enabled the breach
□ If SQLite database compromised: rebuild from last known-good backup
Step 3.3 — FORENSIC PRESERVATION
□ Maintain chain of custody for all evidence
□ Do not alter forensic evidence (disk images, log snapshots)
□ If criminal activity: coordinate with Kripos before any cleanup
Step 3.4 — VERIFICATION
□ Verify root cause eliminated
□ Security scan of application (run full security test suite)
□ Verify no persistence mechanisms remain (backdoors, unauthorized accounts)
□ Review similar endpoints/patterns for same vulnerability
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 backup (verify backup integrity before restore)
□ Deploy with enhanced monitoring and logging
□ Rotate ALL credentials and secrets across Drop infrastructure
□ Verify data integrity (compare restored data against backup checksums)
□ Re-enable services in stages — auth first, then read-only, then write operations
□ Require all users to re-authenticate (force session revocation)
Step 4.2 — ENHANCED MONITORING
□ Increase Sentry alert sensitivity for 30 days
□ Enable detailed Cloudflare WAF logging
□ Daily security review for 7 days post-recovery
□ Monitor for re-attack patterns
Step 4.3 — STAKEHOLDER UPDATES
□ Internal: Update incident log and brief all team members
□ Regulatory: Datatilsynet (72h deadline — see §5)
□ Regulatory: Finanstilsynet (if payment system affected)
□ Customers: Per DPO/Legal approval (see communication templates §6)
□ Affected users: Direct notification if high risk to data subjects (GDPR Art. 34)
Exit criteria: Systems operational. Enhanced monitoring active. Regulatory 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)
□ Schedule blameless post-mortem meeting
□ Complete minute-by-minute timeline of events
□ Root cause analysis (5 Whys)
□ What went well? (preserve these practices)
□ What failed? (specific improvement areas)
□ Action items with owners and deadlines
□ Publish post-mortem report (internal)
Step 5.2 — REGULATORY COMPLIANCE
□ Datatilsynet notification (GDPR Art. 33 — see §5.1)
□ Data subject notifications if required (GDPR Art. 34 — see §5.2)
□ Finanstilsynet notification if payment operations affected
□ EFE (Økokrim) notification if AML-relevant data compromised
□ Insurance claim filed (when cyber policy obtained)
□ Forensic evidence retained minimum 5 years (hvitvaskingsloven § 30)
Step 5.3 — REMEDIATION TRACKING
□ All action items in issue tracker with deadlines
□ Weekly review of remediation progress for 4 weeks
□ Security architecture updated based on lessons learned
□ Update threat model with new attack vector
Step 5.4 — POLICY UPDATE
□ Update this response plan based on lessons learned
□ Update security-architecture.md
□ Update security testing to include new attack scenario
□ Add scenario to next incident response drill
5. Notification Requirements
5.1 GDPR — Datatilsynet Notification (72 hours)
Legal basis: GDPR Art. 33; personopplysningsloven (LOV-2018-06-15-38) § 32
Timeline: Within 72 hours of becoming aware of the breach (not when confirmed — when first detected)
Required only if: Breach is likely to result in a risk to the rights and freedoms of natural persons
What to report:
- Nature of the breach (data categories, approximate number of data subjects, approximate number of records)
- Contact details of DPO ([email protected])
- Likely consequences of the breach
- Measures taken or proposed to address the breach
Partial notification allowed: If full information not available within 72 hours, submit what's known. Supplementary notification within a reasonable timeframe.
Automatic trigger (no assessment needed): Breach of fødselsnummer, bank account data, KYC documents, or transaction history — always notify.
5.2 GDPR — Data Subject Notification
Legal basis: GDPR Art. 34; personopplysningsloven § 33
Required if: Breach is likely to result in HIGH risk to data subjects (unauthorized access to fødselsnummer, bank details, transaction history)
Timeline: Without undue delay
Communication method: Direct (email or in-app push notification to affected users) — not mass public announcement unless direct communication impossible
Template: See §6.2
Not required if: Data was properly encrypted (AES-256-GCM with key not compromised); OR post-breach measures ensure high risk no longer likely
5.3 Finanstilsynet Notification
Legal basis: IKT-forskriften § 8; betalingstjenesteloven (when licensed)
When required: Security incident affecting payment system availability or integrity
Timeline: Without undue delay; DORA Art. 19 (when applicable in Norway ~2026 H2): initial notification within 4 hours, intermediate within 72 hours, final within 1 month
Contact: [email protected] / Finanstilsynet, Revierstredet 3, 0151 Oslo
5.4 AML Reporting
When required: If security breach relates to AML-relevant data (transaction monitoring data, KYC data exposed to unauthorized parties)
Contact: EFE (Enheten for finansiell etterretning) via Altinn portal
5.5 Law Enforcement
When to notify: If criminal activity suspected (ransomware, deliberate intrusion, data theft for fraud) Contact: Kripos (Norwegian National Criminal Investigation Service) — cyberteam: 800 40 082 Caution: Coordinate with legal counsel before contacting law enforcement — evidence preservation requirements apply.
6. Communication Templates
6.1 Internal Incident Alert
Subject: [INCIDENT P{{SEVERITY}}] Security Incident — {{DATE}} {{TIME}} UTC
Team,
Vi har identifisert en sikkerhetshendelse. Detaljer:
Hendelse-ID: INC-{{DATE}}-{{N}}
Alvorlighetsgrad: P{{SEVERITY}}
Oppdaget: {{DATE}} {{TIME}} UTC
Status: AKTIV — Inneslutning pågår
Hendelsesansvarlig: {{NAME}}
Hendelseskanal: Slack #incident-{{DATE}} / e-post
IKKE diskuter denne hendelsen på offentlige kanaler, med kunder eller i sosiale medier.
All kommunikasjon koordineres gjennom hendelsesansvarlig.
Neste oppdatering: {{TIME}} UTC
6.2 Data Subject Notification Template
Subject: Viktig sikkerhetsvarsel angående din Drop-konto
Kjære {{FIRST_NAME}},
Vi skriver til deg for å informere om en sikkerhetshendelse som kan ha berørt
din Drop-konto.
Hva skjedde:
Rundt {{DATE}} ble vi oppmerksomme på uautorisert tilgang til våre systemer som
kan ha eksponert noe av din personlige informasjon.
Hvilken informasjon var involvert:
Følgende informasjon kan ha blitt berørt: {{DATA_CATEGORIES}}
Hva vi gjør:
Vi har gjennomført følgende tiltak:
- {{ACTION_1}}
- {{ACTION_2}}
- {{ACTION_3}}
Hva du bør gjøre:
- Bytt passordet ditt på getdrop.no
- Overvåk kontoen din for mistenkelig aktivitet
- Kontakt banken din dersom du oppdager uventede transaksjoner
For mer informasjon:
Personvernombud: [email protected]
Personvernerklæring: https://getdrop.no/personvern
Vi tar sikkerheten til din informasjon svært alvorlig og beklager enhver
bekymring dette kan medføre.
Med vennlig hilsen,
Drop — ALAI Holding AS
Personvernombud: [email protected]
6.3 Datatilsynet Notification Draft (GDPR Art. 33)
To: [email protected]
From: [email protected] — ALAI Holding AS (Drop)
Date: {{DATE}} {{TIME}} UTC
MELDING OM PERSONOPPLYSNINGSBRUDD (GDPR Art. 33 / personopplysningsloven § 32)
Behandlingsansvarlig: ALAI Holding AS, org.nr. 932 516 136, getdrop.no
1. Bruddets art:
{{DATE}}: Vi ble oppmerksomme på [uautorisert tilgang til / utilsiktet utlevering av]
personopplysninger. Bruddet er [pågående / inneholdt].
2. Kategorier og omtrentlig antall berørte registrerte:
- Kategorier: {{DATA_CATEGORIES}}
- Estimert antall berørte personer: {{NUMBER}}
- Estimert antall berørte opplysninger: {{NUMBER}}
3. Kontaktopplysninger — personvernombud:
Navn: {{DPO_NAME}}
E-post: [email protected]
Telefon: {{DPO_PHONE}}
4. Sannsynlige konsekvenser:
{{CONSEQUENCES_FOR_DATA_SUBJECTS}}
5. Gjennomførte eller planlagte tiltak:
- Umiddelbart: {{IMMEDIATE_MEASURES}}
- Pågående: {{ONGOING_MEASURES}}
- Planlagt: {{PLANNED_MEASURES}}
Merknad: Dette er en [fullstendig / foreløpig — supplerende melding følger] rapport.
[DPO signatur]
7. Evidence Preservation Procedures
Principle: COLLECT BEFORE CONTAIN — evidence collection takes priority over containment unless ongoing harm is severe and imminent.
Evidence collection checklist:
□ AWS CloudTrail logs: Export from AWS Console → S3 (last 30 days minimum)
□ Cloudflare WAF logs: Export last 30 days
□ Sentry error events: Export incident window
□ BetterStack logs: Export incident window
□ Application logs (App Runner): Export from AWS CloudWatch
□ Database audit log: Export if audit_log table implemented
□ Session table: Export active + recently-expired sessions
□ Network traffic: AWS VPC Flow Logs (if enabled)
Chain of custody:
- All evidence files: SHA-256 hash computed and recorded immediately
- Hash log: custody/chain-of-custody-{{DATE}}.txt — signed by collector
- Storage: Encrypted S3 bucket (read-only after creation)
- Custody transfers: Documented with timestamps
- Retention: Minimum 5 years (hvitvaskingsloven § 30)
8. Forensic Analysis Requirements
| Incident Level | Forensic Approach | Provider |
|---|---|---|
| P1 (Critical) | External forensics firm engaged immediately | [Retainer to be obtained — NorSIS / Mnemonic recommended] |
| P2 (High) | Internal log analysis + external if complex | Internal first, escalate if needed |
| P3 (Medium) | Internal log analysis | Security team |
| P4 (Low) | Root cause review | Security engineer |
Forensics firm retainer: Not yet in place — obtain before production launch Evidence retention: All forensic evidence retained minimum 5 years post-incident (financial sector requirement)
9. Lessons Learned Process
Post-mortem deadline: Within 5 business days of incident closure
Mandatory post-mortem components:
- Complete incident timeline (minute-by-minute from first alert to resolution)
- Root cause analysis (5 Whys methodology)
- 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
Action item tracking: GitHub Issues labeled security-incident-followup + Mission Control task
10. Drill Schedule
| Drill Type | Frequency | Participants | Scenario |
|---|---|---|---|
| Tabletop exercise | Semi-annual | Full IRT + CEO | BankID token theft / Database exfiltration / Insider threat |
| Notification drill | Annual | DPO + Legal + CEO | 72-hour Datatilsynet notification dry run |
| Technical response drill | Annual | Engineering + Security | Live simulation on staging environment |
| Communication tree test | Annual | All IRT members | Phone chain + escalation path verification |
Last drill: Not yet conducted — schedule before production launch Next drill: Pre-production (target: before Finanstilsynet license application) Drill coordinator: Security Lead / CEO
Approval
| Role | Name | Date | Signature |
|---|---|---|---|
| Author | Security Architect | 2026-02-23 | |
| DPO | |||
| CISO | |||
| Legal Counsel | |||
| CEO |