Data Breach Response Plan
Data Breach Response Plan
Organization:
{{ORG_NAME}}ALAI Holding AS — Drop Payment App Document Number: IRP-{{NUMBER}}DROP-001 Version:{{VERSION}}1.0 Date:{{DATE}}2026-02-23 Author:{{AUTHOR}}Security Architect Status: Draft| Approved | ActiveReviewers:{{REVIEWERS}}DPO, CISO, Legal Counsel, CEO Next Review:{{REVIEW_DATE}}2027-02-23 Classification: Confidential — Restricted Distribution
Document History
| Version | Date | Author | Changes |
|---|---|---|---|
| 0.1 | Initial draft | ||
IMPORTANT — Keep This Document Accessible
This plan must be accessible even when systems are down. Maintain printed copies in:
{{PHYSICAL_LOCATION_1}}ALAI Holding AS office (physical location on file with CEO){{PHYSICAL_LOCATION_2}}Secure offline storage (password-protected PDF in personal safe) Offline copy last printed:{{DATE}}2026-02-23
1. Incident Classification
| Severity | Definition | Response Team | Max Time to Classify |
|---|---|---|---|
| P1 — Critical | Confirmed breach of |
Full IRT + |
1 hour |
| P2 — High | Suspected breach with evidence; |
Core IRT + Security Lead + DPO | 2 hours |
| P3 — Medium | Security event with potential for breach; precautionary |
Security team | 8 hours |
| P4 — Low | Security anomaly, no confirmed breach, monitoring |
Security team | Next business day |
GDPR notification trigger:trigger (personopplysningsloven § 30 / GDPR Art. 33): P1 and P2 incidents MUST be assessed for 72-hour supervisory authorityDatatilsynet notification obligation.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 |
|---|---|---|---|
| Platform |
|||
| Failed authentication spike | |||
| Platform | Cloudflare alert | ||
| JWT_SECRET access (unauthorized) | AWS CloudTrail | Security |
|
| Vulnerable dependency CVE | Dependabot / npm audit (CI) | Engineering | GitHub notification |
| Third-party notification (BankID/Sumsub/AWS) | Security |
||
| User-reported | Support ticket | Support |
Escalate to security immediately |
| Penetration test finding | External pen tester | Security |
Direct report |
24/7 security contact: {{SECURITY_PHONE}} | {{SECURITY_EMAIL}}[email protected]
EscalationCEO pager:direct escalation: {{PAGERDUTY_SERVICE}}+47 40 47 42 51 (Alem Bašić)
DPO contact: [email protected]
3. Response Team Roles & Contacts
| Role | Primary | Phone | ||
|---|---|---|---|---|
| Incident Commander | ||||
| Security Lead / CISO | ||||
| Engineering Lead | ||||
| DPO (GDPR) | ||||
| Legal Counsel | ||||
| Communications Lead | ||||
External contacts:
| Party | Contact | When |
|---|---|---|
| P1 — within |
||
| Finanstilsynet (financial regulator) | [email protected] | P1 — payment system compromise |
| Cyber insurance | P1/P2 immediately | |
| Forensics firm | P1 immediately | |
| If criminal activity suspected | ||
| P1 if |
||
| 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.
Trigger: Security alert, user report, or suspicious activity detected.
Step 1.1 — ALERT RECEIVED
□ Log initial alert time:time (UTC): ________________
□ Assign to on-call security engineer or CEO
□ Create incident channel: Slack #incident-{{DATE}}-{{N}} 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 immediatelyimmediately, (pagenotify allDPO
roles)□ 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)
□ TakeExport memoryAWS dumpCloudTrail oflogs affected(last system(s)30 days)
□ PreserveExport Sentry error logs
—□ snapshotExport beforeBetterStack anyaccess containmentlogs
changes□ Snapshot Cloudflare WAF logs
□ Export SQLite/PostgreSQL audit logs (if available)
□ Document exact system state (screenshots, commandsAPI run)responses, timestamps)
□ IsolateSHA-256 buthash all evidence files immediately — record in custody log
□ DO NOT wipe or restart affected systems until forensicsevidence completepreserved
Exit criteria: Incident classified, IRT assembled,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
□ Isolate affected systems (network segment or shutdown if necessary)
□ 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 (APIcompromised: keys,revoke uservia accounts,IAM, OAuthrotate tokens)Secrets Manager
- If database credentials compromised: rotate password, audit connections
□ Block malicious IP addresses at WAF/firewallCloudflare WAF
□ Disable vulnerable endpoint or(return feature503) if applicableactively exploited
□ If active data exfiltration: cutrestrict networkApp connectionRunner toegress
□ Suspend affected serviceuser accounts if account compromise suspected
Step 2.2 — ASSESS CONTAINMENT IMPACT
□ What servicespayment operations are affected by containment actions?containment?
□ Communicate service impactstatus to supportcustomers team(generic: "We are investigating a technical issue")
□ AssessNO whetherdetails customersabout needsecurity toincident bein warnedpublic ofcommunications temporaryuntil degradationDPO/Legal approved
Step 2.3 — PREVENT LATERAL MOVEMENT
□ Rotate allALL AWS credentials on affected systems (assume all compromised)services
□ Check for persistenceunauthorized mechanismsAWS (newIAM users,users scheduledor tasks, webhooks)roles
□ Verify backup/DRno systemsnew areadmin users created in Drop application
□ Check AWS CloudTrail for unusual API calls
□ Verify BankID integration not alsoused compromisedwith □stolen Review access logs for other potentially compromised accountstokens
Step 2.4 — SCOPE ASSESSMENT
□ Which data was accessed/exfiltrated? (query database audit logs)
□ Which data subjects are affected? (query: SELECT COUNT(*) affected)FROM affected_records)
□ What time period does the breach cover?
(from: ___ to: ___)
□ Was fødselsnummer accessed? (L4 data exfiltrated→ externally,MANDATORY orDatatilsynet accessednotification)
internally?□ Were transaction records accessed? (AML notification assessment)
□ Draft scope statement for legal/DPODPO/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? (entryXSS vector)/ SQL injection / credential stuffing /
supply chain / insider / misconfiguration / BankID session hijack)
□ What vulnerability was exploited?
□ How long did the attacker have access?
□ What was the full extent of access?
□ Were other ALAI systems accessible from the compromised system?accessible?
Step 3.2 — REMEDIATE ROOT CAUSE
□ Apply security patch or configuration fix
□ Remove malware or attacker-installed toolsbackdoors
□ Remove unauthorized accountsdatabase records or accessuser grantsaccounts
□ Fix the vulnerability that enabled the breach
□ If SQLite database compromised: rebuild from last known-good backup
Step 3.3 — FORENSIC PRESERVATION
□ Hand forensic images to {{FORENSICS_FIRM}} or internal team
□ Maintain chain of custody documentationfor 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 has been eliminated
□ Security teamscan confirmsof application (run full security test suite)
□ Verify no persistence mechanisms remain (backdoors, unauthorized accounts)
□ Review similar systemsendpoints/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 systems from known-good backup or(verify rebuildbackup fromintegrity IaCbefore restore)
□ Deploy with enhanced monitoring and logging
□ Rotate ALL credentials and secrets across affectedDrop systems (not just compromised ones)infrastructure
□ Verify data integrity (compare restored data against backups)backup checksums)
□ Re-enable services in stages (not— auth first, then read-only, then write operations
□ Require all atusers once)to re-authenticate (force session revocation)
Step 4.2 — ENHANCED MONITORING
□ Increase loggingSentry verbosityalert on recovered systemssensitivity for 30 days
□ SetEnable updetailed specificCloudflare alertsWAF for repeat attack patternslogging
□ Daily security review for 7 days post-recovery
□ Monitor for re-attack patterns
Step 4.3 — STAKEHOLDER UPDATES
□ Internal: Update incident channellog withand recoverybrief progressall team members
□ BriefRegulatory: executiveDatatilsynet team(72h deadline — see §5)
□ PrepareRegulatory: customer communicationFinanstilsynet (if applicable)payment system affected)
□ InternalCustomers: announcementPer ofDPO/Legal resolutionapproval (see communication templates §6)
□ Affected users: Direct notification if high risk to data subjects (GDPR Art. 34)
Exit criteria: Systems operational. Enhanced monitoring inactive. place.Regulatory Nonotifications re-infection.sent.
Phase 5: Post-Incident (72 hours – ongoing)
Goal: Learn from the incident.Learn. Prevent recurrence. Meet legal obligations.
Step 5.1 — POST-MORTEM (within 5 business days)
□ Schedule blameless post-mortem meeting
(blameless culture)
□ 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
□ Supervisory authorityDatatilsynet notification (ifGDPR GDPRArt. 33 — see §5)5.1)
□ Data subject notifications (if required (GDPR Art. 34 — see §5)5.2)
□ ContractualFinanstilsynet notificationsnotification if payment operations affected
□ EFE (customerØkokrim) DPAs)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
□ ConfirmSecurity allarchitecture actionsupdated closedbased 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 documentationsecurity-architecture.md
□ Update teamsecurity trainingtesting materialsto include new attack scenario
□ Add scenario to next incident response drill
5. Notification Requirements
5.1 GDPR — Supervisory AuthorityDatatilsynet Notification (72 hours)
Legal basis: GDPR Art. 3333; personopplysningsloven (LOV-2018-06-15-38) § 32
Timeline: Within 72 hours of becoming aware of the breach (not when confirmed — when aware)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 knownknown. andSupplementary supplementnotification later.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. 3434; 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) — nonot mass public announcement unless direct communication impossible
Template: See §6.2
Not required if: Data was properly encrypted and(AES-256-GCM with key not compromised;compromised); OR post-breach measures ensure high risk no longer likely; OR disproportionate effort (→ public communication instead)likely
5.3 ContractualFinanstilsynet ObligationsNotification
Timeline: Without undue delay; DORA Art. 19 (when applicable in Norway ~2026 H2): initial notification | |||
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 is suspected (ransomware, deliberate intrusion)intrusion, data theft for fraud)
Contact: {{LOCAL_CYBERCRIME_UNIT}}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,
WeVi havehar identifiedidentifisert aen securitysikkerhetshendelse. incident.Detaljer:
Details:
Incident Hendelse-ID: INC-{{DATE}}-{{N}}
Severity:Alvorlighetsgrad: P{{SEVERITY}}
Detected:Oppdaget: {{DATE}} {{TIME}} UTC
Status: ACTIVEAKTIV — ContainmentInneslutning inpågår
progress
Incident Commander:Hendelsesansvarlig: {{NAME}}
IncidentHendelseskanal: channel:Slack #incident-{{DATE}}-{{N}} Do/ NOTe-post
discussIKKE thisdiskuter incidentdenne onhendelsen publicpå channels,offentlige withkanaler, customers,med orkunder oneller sociali media.sosiale medier.
All communicationskommunikasjon gokoordineres throughgjennom {{COMMUNICATIONS_LEAD}}.hendelsesansvarlig.
NextNeste update:oppdatering: {{TIME}} UTC
6.2 Data Subject Notification Template
Subject: ImportantViktig securitysikkerhetsvarsel noticeangående aboutdin yourDrop-konto
account
DearKjære {{FIRST_NAME}},
WeVi areskriver writingtil todeg informfor youå ofinformere aom securityen incidentsikkerhetshendelse thatsom maykan haveha affectedberørt
yourdin account.Drop-konto.
WhatHva happened:skjedde:
On approximatelyRundt {{DATE}}, weble becamevi awareoppmerksomme ofpå unauthorizeduautorisert accesstilgang totil ourvåre systemssystemer thatsom
maykan haveha exposedeksponert somenoe ofav yourdin personalpersonlige information.informasjon.
WhatHvilken informationinformasjon wasvar involved:involvert:
TheFølgende followinginformasjon informationkan mayha haveblitt been accessed:berørt: {{DATA_CATEGORIES}}
WhatHva wevi aregjør:
doing:Vi Wehar havegjennomført [taken/arefølgende taking] the following steps to address this incident:tiltak:
- {{ACTION_1}}
- {{ACTION_2}}
What- you{{ACTION_3}}
shouldHva do:du bør gjøre:
- ChangeBytt yourpassordet passwordditt atpå {{URL}}getdrop.no
- EnableOvervåk two-factorkontoen authenticationdin for mistenkelig aktivitet
- MonitorKontakt yourbanken accountsdin fordersom suspiciousdu activityoppdager -uventede [If financial data: Monitor your bank statements / Contact your bank]transaksjoner
For moremer information:informasjon:
ContactPersonvernombud: our[email protected]
DataPersonvernerklæring: Protectionhttps://getdrop.no/personvern
Officer:Vi {{DPO_EMAIL}}tar Privacysikkerheten notice:til {{PRIVACY_POLICY_URL}}din Weinformasjon takesvært thealvorlig securityog ofbeklager yourenhver
informationbekymring seriouslydette andkan sincerelymedføre.
apologizeMed forvennlig anyhilsen,
concernDrop this— mayALAI cause.Holding Regards,AS
{{COMPANY_NAME}}Personvernombud: Data Protection Officer: {{DPO_NAME}}[email protected]
6.3 RegulatoryDatatilsynet Notification Draft (GDPR Art. 33)
To: {{DPA_AUTHORITY}}[email protected]
From: {{DPO_NAME}}, DPO[email protected] — {{ORG_NAME}}ALAI Holding AS (Drop)
Date: {{DATE}} {{TIME}} UTC
NOTIFICATIONMELDING OFOM PERSONAL DATA BREACHPERSONOPPLYSNINGSBRUDD (GDPR Art. 33)33 / personopplysningsloven § 32)
Behandlingsansvarlig: ALAI Holding AS, org.nr. 932 516 136, getdrop.no
1. NatureBruddets of the breach:
Onart:
{{DATE}},: weVi becameble awareoppmerksomme ofpå [unauthorizeduautorisert accesstilgang totil / accidentalutilsiktet disclosureutlevering of]av]
personalpersonopplysninger. data.Bruddet The breacher [is/was]pågående {{ONGOING/CONTAINED}}/ inneholdt].
2. CategoriesKategorier andog approximateomtrentlig numberantall ofberørte data subjects concerned:registrerte:
- Categories:Kategorier: {{DATA_CATEGORIES}}
- EstimatedEstimert affectedantall databerørte subjects:personer: {{NUMBER}}
- EstimatedEstimert affectedantall records:berørte opplysninger: {{NUMBER}}
3. CategoriesKontaktopplysninger and— approximatepersonvernombud:
number of personal data records concerned:
{{RECORD_CATEGORIES_AND_COUNTS}}
4. Contact details of DPO:
Name:Navn: {{DPO_NAME}}
Email:E-post: {{DPO_EMAIL}}[email protected]
Phone:Telefon: {{DPO_PHONE}}
5.4. LikelySannsynlige consequences of the breach:konsekvenser:
{{CONSEQUENCES}CONSEQUENCES_FOR_DATA_SUBJECTS}}
6.5. MeasuresGjennomførte takeneller orplanlagte proposed:tiltak:
- Immediate:Umiddelbart: {{IMMEDIATE_MEASURES}}
- Ongoing:Pågående: {{ONGOING_MEASURES}}
- Planned:Planlagt: {{PLANNED_MEASURES}}
7.Merknad: Note:Dette Thiser is aen [completefullstendig / preliminaryforeløpig — supplementarysupplerende notificationmelding tofølger] follow] report.rapport.
[DPO Signature]signatur]
7. Evidence Preservation Procedures
Principle: COLLECT BEFORE CONTAIN — evidence collection takes priority over containment unless ongoing harm is severe.severe and imminent.
Evidence collection checklist:
□ MemoryAWS dump:CloudTrail stringslogs: /proc/{{PID}}/memExport >from evidence/memory-{{TIMESTAMP}}.dumpAWS Console → S3 (last 30 days minimum)
□ NetworkCloudflare traffic:WAF tcpdumplogs: -wExport evidence/traffic-{{TIMESTAMP}}.pcaplast 30 days
□ RunningSentry processes:error psevents: auxExport >incident evidence/processes-{{TIMESTAMP}}.txtwindow
□ Open connections: netstat -an > evidence/connections-{{TIMESTAMP}}.txt
□ SystemBetterStack logs: cpExport -rincident /var/log/ evidence/system-logs-{{TIMESTAMP}}/window
□ Application logs:logs {{LOG_COLLECTION_COMMAND}}(App Runner): Export from AWS CloudWatch
□ Database audit log: {{DB_AUDIT_EXPORT_COMMAND}}Export if audit_log table implemented
□ CloudSession providertable: logs:Export {{CLOUD_LOG_EXPORT_COMMAND}}active (CloudTrail,+ Azurerecently-expired Monitor, etc.)sessions
□ SIEMNetwork events:traffic: ExportAWS 30-dayVPC windowFlow aroundLogs incident(if enabled)
Chain of custody:
- All evidence files: SHA-256 hash computed and recorded immediately
after collection
- Hash log: evidence/custody/chain-of-custody.custody-{{DATE}}.txt — signed by collector
- Storage: Write-protectedEncrypted encryptedS3 volume,bucket access(read-only loggedafter creation)
- Custody transfers: Documented with signaturestimestamps
- Retention: Minimum 5 years (hvitvaskingsloven § 30)
8. Forensic Analysis Requirements
| Incident Level | Forensic Approach | Provider |
|---|---|---|
| P1 (Critical) | External forensics firm engaged immediately | |
| P2 (High) | Internal |
Internal first, escalate if needed |
| P3 (Medium) | Internal log analysis | Security team |
| P4 (Low) | Root cause review | Security engineer |
Forensics firm retainer: {{RETAINER_STATUS}}Not yet in place — {{FIRM}}obtain ({{CONTACT}})before production launch
Evidence retention: All forensic evidence retained for minimum {{RETENTION_PERIOD}}5 years post-incident (financial sector requirement)
9. Lessons Learned Process
Post-mortem template: {{LINK_TO_POSTMORTEM_TEMPLATE}}
Deadline:deadline: Within 5 business days of incident closure
Mandatory post-mortem components:
- Complete incident timeline (minute-by-
minute)minute from first alert to resolution) - Root cause analysis (5 Whys
or fishbone diagram)methodology) - What went well
(— preserve thesepractices)practices - What went poorly
(— specific improvementareas)areas - Action
itemsitems:(specific, assigned, time-bound)bound - Detection gap
analysisanalysis:(howHow long before detection?) - Response gap
analysisanalysis:(whereWhere did we slow down?) - Prevention
roadmaproadmap:(systemicSystemicfixes)fixes
Action item tracking: AllGitHub items in {{ISSUE_TRACKER}}Issues labeled security-incident-followup + Mission Control task
10. Drill Schedule
| Drill Type | Frequency | Participants | Scenario |
|---|---|---|---|
| Tabletop exercise | Full IRT + |
||
| Notification drill | DPO + Legal + |
72-hour |
|
| Technical response drill | Annual | Engineering + Security | Live simulation on |
| Communication tree test | Annual | All IRT members | Phone chain + escalation path verification |
Last drill: {{DATE}}Not yet conducted — Scenario:schedule {{SCENARIO}}before —production Outcome: {{OUTCOME}}launch
Next drill: {{DATE}}Pre-production (target: before Finanstilsynet license application)
Drill coordinator: {{NAME}}Security ({{EMAIL}})Lead / CEO
Approval
| Role | Name | Date | Signature |
|---|---|---|---|
| Author | Security Architect | 2026-02-23 | |
| DPO | |||
| CISO | |||
| Legal Counsel | |||
| CEO |