Data Breach Response Plan
Data Breach Response Plan
Organization:
ALAI Holding ASBilko —DropBalkanPaymentAccountingAppSaaS Document Number: IRP-DROP-BILKO-001 Version: 1.0 Date: 2026-02-23 Author:SecurityCompliance Architect Status: Draft Reviewers: DPO,CISO,Legal Counsel, Engineering Lead, CEO Next Review:2027-02-2026-08-23 Classification: Confidential — Restricted Distribution
Document History
| Version | Date | Author | Changes |
|---|---|---|---|
| 0.1 | 2026-02-23 | Initial draft — |
IMPORTANT — Keep This Document Accessible
This plan must be accessible even when systems are down. Maintain
andprintedoffline copiesin:ensure
[email protected] | [email protected]ALAIkeyHoldingcontactsASareoffice (physical location on file with CEO)- |
Secure offline storage (password-protected PDFsaved in personalsafe)phones.OfflineKeycopyofflinelastcontacts:printed:[email protected]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; or confirmed breach of |
Core IRT + Security Lead |
2 hours |
| P3 — Medium | Security event with potential for breach; precautionary |
Security team | 8 hours |
| P4 — Low | Security anomaly, no confirmed |
Security team | Next business day |
GDPR72-hour notification trigger (personopplysningsloven § 30 / GDPR Art. 33):trigger: P1 and P2 incidents MUST be assessed for 72-hour Datatilsynetregulatory notification obligation across all active jurisdictions (HR: AZOP; RS: Poverenik; BA: AZLP). Clock starts when incident is first detected, not confirmed.
AML/FinanstilsynetFinancial trigger:data sensitivity note: Bilko handles invoices with national tax IDs (PIB/JMBG/OIB/JIB) and IBAN numbers. Any breach exposing these fields is automatically P1 incidents— involvingtax paymentidentity systemtheft compromisehas MUSTsevere beconsequences reportedfor todata Finanstilsynet without undue delay (betalingstjenesteloven § 4-30 analog; IKT-forskriften § 8).subjects.
2. Detection Mechanisms
| Detection Method | Tool | Responsible | Alert Channel |
|---|---|---|---|
| Sentry | |||
| Platform team | |||
| Failed authentication spike (>10 in 1h) | |||
| Cloudflare |
Platform team | ||
| Security team | |||
| Third-party notification |
Vendor contacts |
Security email | |
| User-reported | Support ticket | Support team | Escalate to security |
| Penetration test finding | External pen tester | Security team | Direct report |
24/7 security contact: [email protected][email protected] CEO| direct escalation: +47 40 47 42 51 (Alem Bašić)
DPO contact: [email protected][email protected]
3. Response Team Roles & Contacts
| Role | Primary | |||
|---|---|---|---|---|
| Incident Commander | CEO ( |
[email protected] | ||
| Security Lead |
||||
| Engineering Lead | ||||
| DPO ( | TBD | [email protected] | ||
| Legal Counsel | ||||
| Communications |
CEO |
[email protected] |
External contacts:regulatory contacts (72-hour notification recipients):
| Authority | Contact | When | |||
|---|---|---|---|---|---|
| AZOP — Agencija za zaštitu osobnih podataka | [email protected] / https://azop.hr/prijavapovrede | P1/P2 within 72h (GDPR | |||
| P1/P2 |
|||||
| [email protected] / https://www.azlp.ba | P1/P2 | within ||||
Notify ALL jurisdictions where affected data subjects reside. If a breach affects data from multiple countries, notify all relevant authorities simultaneously.
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):time: ________________
□ Assign to on-call security engineer or CEO
□ Create incident channel: Slack #incident-{DATE}-{DATE}}N}
OR□ emailAssign threadto security lead
□ 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? (Appapi.bilko.io, RunnerRailway /DB, SQLite-DBCloudflare /R2, AWSSEF/HR-FISK S3 / BankID integration)connections)
□ Is the attack/leak ongoing?
□ InitialWhat data categories potentially affected? -(tax Fødselsnummer?IDs, IBAN, invoice data, user credentials)
□ Which jurisdictions are affected? (RestrictedRS, —BA, L4HR, →or 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)multiple)
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 ← CRITICALimmediately
□ If P3/P4: Notify Security Lead only
Step 1.4 — EVIDENCE PRESERVATION (CRITICAL — do before containment if safe)
□ Export AWS CloudTrailRailway logs (last30-day 30window days)around incident)
□ Export Cloudflare logs
□ Export Sentry error logstimeline
□ ExportQuery BetterStackLoggedAction: accessSELECT logs* FROM logged_actions WHERE action_timestamp > [incident_start]
□ SnapshotScreenshot Cloudflareanomalous 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 logmetrics
□ DO NOT wipe or restart affected systems until evidenceforensics preservedcomplete
Exit criteria: Incident classified, IRT assembled (for P1/P2),assembled, evidence preserved.preserved, 72h clock started if P1/P2.
Phase 2: Containment (1–4 hours)
Goal: Stop the bleeding.breach. Prevent further data exposure.
Step 2.1 — IMMEDIATE CONTAINMENT
□ Revoke compromisedall credentials:JWT -refresh Iftokens JWT_SECRET(DELETE compromised:FROM rotaterefresh_tokens immediately,— forces re-login for 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 connectionsusers)
□ Block malicious IP addresses at Cloudflare WAF
□ Disable vulnerablecompromised API endpoint if applicable
□ Rotate JWT_SECRET and JWT_REFRESH_SECRET (returnall 503)active sessions invalidated)
□ Rotate FIELD_ENCRYPTION_KEY if activelydatabase exploitedfield encryption compromised
□ IfIsolate affected Railway services if active data exfiltration: restrict App Runner egress
□ Suspend affected user accounts if account compromise suspectedexfiltration
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 databaseLoggedAction audit+ Railway logs)
□ Which data subjects are affected? (query: SELECT COUNT(*) FROMand affected_records)list affected organizationIds)
□ What jurisdictions affected? (RS data subjects? BA? HR?)
□ What time period does the breach cover?
□ Was fødselsnummer accessed?period? (L4from: data___ →to: MANDATORY Datatilsynet notification)___)
□ Were transactiontax records accessed?IDs (AMLPIB/JMBG/OIB/JIB) notificationor assessment)IBAN exposed?
□ Were authentication credentials (password hashes) exposed?
□ Draft scope statement for DPO/LegalDPO and legal review
Step 2.3 — ASSESS CONTAINMENT IMPACT
□ What services are disrupted by containment actions?
□ Inform support team of expected user disruption
□ Prepare user communication if service unavailability expected
Exit criteria: Active threat contained, no ongoing exfiltration, scope defined.defined, 72h countdown tracked.
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 injectioninjection? /JWT credentialbypass? stuffingCompromised /credentials? supplyCloudflare chain / insider / misconfiguration / BankID session hijack)misconfiguration?)
□ WhatWas there a vulnerability wasin exploited?Prisma query construction?
□ Was org-scoping WHERE clause bypassed?
□ How long didwas theaccess attacker have access?maintained?
□ Were other ALAIorganizations' systemsdata accessible?
Step 3.2 — REMEDIATE ROOT CAUSE
□ Apply security patch
or□ configurationFix fixvulnerability (e.g., missing org-scope, Zod bypass, rate limit bypass)
□ Remove malwareany unauthorized database entries or attacker-installed backdoors
□ RemoveRotate unauthorizedall databasesecrets recordsand orAPI user accounts
□ Fix the vulnerability that enabled the breach
□ If SQLite database compromised: rebuild from last known-good backupkeys
Step 3.3 — FORENSIC PRESERVATIONVERIFICATION
□ MaintainRun chainPlaywright ofsecurity custodytest for all evidence
□ Do not alter forensic evidence (disk images, log snapshots)
□ If criminal activity: coordinate with Kripos before any cleanup
Step 3.4 — VERIFICATIONsuite
□ Verify rootorg-scoping causeisolation eliminatedtests □ Security scan of application (run full security test suite)pass
□ Verify RBAC tests pass
□ Confirm 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 withpatched enhanced monitoring and loggingversion
□ Rotate ALL credentials andon secretsaffected acrosssystems
Drop□ infrastructureEnable enhanced monitoring for 30 days post-recovery
□ Verify data integrity (compare restored dataLoggedAction against backupexpected checksums)state)
□ 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 logchannel andwith brief all team membersprogress
□ Regulatory:Brief DatatilsynetCEO
□ Prepare regulatory notifications (72h deadline — see §5)
□ Regulatory:Prepare Finanstilsynet (if payment system affected)
□ Customers: Per DPO/Legal approval (seecustomer communication templates §6)
□ Affected users: Direct notification if high risk to data subjects (GDPR Art. 34)applicable
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 blamelessBlameless post-mortem meeting
□ Complete minute-by-minute timeline of events
□ Root cause analysis (5 Whys)
□ What went well?well (preserve/ thesewhat practices)
□ What failed? (specific improvement areas)failed
□ Action items with owners and deadlines
□ Publish post-mortem report (internal)
Step 5.2 — REGULATORY COMPLIANCE
□ DatatilsynetAll notificationregulatory notifications filed (GDPR Art. 33 — see §5.1)5)
□ Data subject notifications sent if required
(GDPR Art. 34 — see §5.2)
□ FinanstilsynetDPA notificationcustomer if payment operations affected
□ EFE (Økokrim) notification if AML-relevant data compromisednotifications
□ 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
□ SecurityUpdate architectureDPIA updated based onwith 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 GDPRCroatia — Datatilsynet NotificationAZOP (GDPR Art. 33 — 72 hours)
Legal basis: GDPR Art. 33; personopplysningslovenRegulation (LOV-2018-06-15-38)EU) §2016/679, 32
33
Timeline:Required if: Breach likely to result in a risk to rights and freedoms of natural persons
Deadline: Within 72 hours of becoming aware of the breach (not when confirmed — whenaware)
firstPartial detected)notification allowed: Submit what's known within 72h, supplement later
Required only if: Breach is likely to result in a risk to the rights and freedoms of natural persons
What to report:information:
- Nature of
thebreach (datacategories,approximatenumber of data subjects,approximatenumber of records) ContactDPO contact detailsof 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 GDPRSerbia — DataPoverenik Subject(ZZPL NotificationArt. 56 — 72 hours)
Legal basis: Zakon o zaštiti podataka o ličnosti, Article 56 Required if: Breach likely to result in risk to rights and freedoms of individuals Deadline: Within 72 hours of becoming aware
5.3 Bosnia & Herzegovina — AZLP (72 hours — best practice)
Legal basis: Zakon o zaštiti ličnih podataka BiH — breach notification not explicitly mandated in same detail as GDPR, but best practice is 72-hour notification following GDPR standard. Deadline: 72 hours (voluntary/best practice)
5.4 Data Subject Notification (GDPR Art. 34;34 personopplysningsloven/ §ZZPL 33Art. 57)
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:Method: Direct (email or in-app push notification to affected users)users — individual, not mass public announcement unless direct communication impossible
Template:Financial Seedata §6.2
Not— requiredassess HIGH risk if:
- Tax
properly encryptedIDs (AES-256-GCMPIB/JMBG/OIB/JIB) exposed — identity theft risk - IBAN exposed — financial fraud risk
- Password hashes exposed (weak hashing) — credential stuffing risk
- Note: bcrypt-hashed passwords with
keycost=12notarecompromised);computationallyORinfeasiblepost-breachtomeasurescrackensure—highassess as LOW risknoevenlongeriflikely5.3 Finanstilsynet NotificationLegal basis:IKT-forskriften § 8; betalingstjenesteloven (when licensed)When required:Security incident affecting payment system availability or integrityTimeline:Without undue delay; DORA Art. 19 (when applicable in Norway ~2026 H2): initial notification within 4 hours, intermediate within 72 hours, final within 1 monthContact:[email protected] / Finanstilsynet, Revierstredet 3, 0151 Oslo5.4 AML ReportingWhen required:If security breach relates to AML-relevant data (transaction monitoring data, KYC datahashes exposed
Contact: EFE (Enheten for finansiell etterretning) via Altinn portal
5.5 LawMulti-Jurisdiction EnforcementNotification Checklist
When
any users → notify affected users directly (no undue delay)
□ If □ Identify all affected data subjects by country
□ If Croatian users affected → notify AZOP within 72h
□ If Serbian users affected → notify Poverenik within 72h
□ If BiH users affected → notify AZLP within 72h (best practice)
□ If HIGH risk to notify:criminalDPA activitycustomers suspectedaffected (ransomware,→ deliberatenotify intrusion,per dataDPA theftcontract forterms
fraud)□ Contact:Document Kriposall (Norwegian National Criminal Investigation Service) — cyberteam: 800 40 082
Caution: Coordinatenotifications with legaltimestamp counseland beforereference contactingnumber
law enforcement — evidence preservation requirements apply.
6. Communication Templates
6.1 Internal Incident Alert
Subject: [INCIDENT P{{SEVERITY}}] Security Incident — {Bilko — {DATE}} {TIME}
Team,
Security incident detected. Details:
Incident ID: INC-BILKO-{DATE}-{N}
Severity: P{SEVERITY}
Detected: {DATE} {TIME}} UTC
Team,Jurisdictions Vipotentially haraffected: identifisert{RS en/ sikkerhetshendelse.BA Detaljer:/ Hendelse-ID:HR}
INC-Data potentially affected: {tax IDs / IBAN / credentials / invoice data}
Status: ACTIVE — Containment in progress
Incident Commander: Alem (CEO)
Incident channel: #incident-{DATE}}-{{N}}
Alvorlighetsgrad:72h P{{SEVERITY}}regulatory Oppdaget:notification clock started: {{DATE}} {{TIME}} UTC
Status:Notification AKTIVdeadlines:
—- InneslutningAZOP pågår
Hendelsesansvarlig:(HR): {DATE+72h}
- Poverenik (RS): {NAME}}DATE+72h}
Hendelseskanal:- SlackAZLP #incident-(BA): {{DATE}}DATE+72h}
/Do e-postNOT IKKEdiscuss diskuteron dennepublic hendelsenchannels, påwith offentligecustomers, kanaler,or medsocial kunder eller i sosiale medier.media.
All kommunikasjoncommunications koordineresthrough gjennomAlem.
hendelsesansvarlig.Next Neste oppdatering:update: {{TIME}} UTC
6.2 Data Subject Notification Template(Croatian / English)
Subject: ViktigVažna sikkerhetsvarselsigurnosna angåendeobavijest dino Drop-kontovašem Kjæreračunu / Important security notice
Poštovani {IME} / Dear {FIRST_NAME}},
ViBilko skriver(bilko.io) tilvas degobavještava foro åsigurnosnom informereincidentu omkoji enje sikkerhetshendelsemogao somutjecati
kanna havaš berørtračun.
dinŠto Drop-konto.se Hvadogodilo skjedde:/ RundtWhat happened:
Dana {{DATE}}DATUM}, blesaznali vismo oppmerksommeza påneovlašteni uautorisertpristup tilgangnašim tilsustavima vårekoji systemerje sommogao
kanizložiti havaše eksponertosobne noepodatke.
avKoji dinpodaci personligesu informasjon.zahvaćeni Hvilken/ informasjonData varpotentially involvert:
Følgende informasjon kan ha blitt berørt:affected:
{{DATA_CATEGORIES}}KATEGORIJE_PODATAKA}
HvaŠto vismo gjør:poduzeli Vi/ harWhat gjennomførtwe følgende tiltak:did:
- {{ACTION_1}}MJERA_1}
- {{ACTION_2}}MJERA_2}
Što trebate učiniti / What you should do:
- {{ACTION_3}}Promijenite Hvalozinku duna børbilko.io gjøre:/ Change your password at bilko.io
- ByttOmogućite passordetdvofaktorsku dittautentikaciju på/ getdrop.noEnable two-factor authentication
- OvervåkPratite kontoensumnjive dinaktivnosti / Monitor for mistenkeligsuspicious aktivitetactivity
-Za Kontaktviše bankeninformacija din dersom du oppdager uventede transaksjoner/ For mermore informasjon:information:
Personvernombud:DPO: [email protected][email protected]
Personvernerklæring:Privacy: https:bilko.io/privacy
Ispričavamo se za uzrokovanu neugodnost.
We sincerely apologize for any concern this may cause.
Bilko tim //getdrop.no/personvern ViBilko tarTeam
sikkerhetenDPO: til din informasjon svært alvorlig og beklager enhver
bekymring dette kan medføre.
Med vennlig hilsen,
Drop — ALAI Holding AS
Personvernombud: [email protected][email protected]
6.3 DatatilsynetRegulatory Notification Draft (GDPR Art. 33)33 — for AZOP, Poverenik, AZLP)
To: [email protected]{AUTHORITY_NAME} — {AUTHORITY_EMAIL}
From: [email protected]{DPO_NAME}, DPO — ALAI Holding ASBilko (Drop)bilko.io)
Date: {{DATE}} {{TIME}} UTC
MELDINGNOTIFICATION OMOF PERSONOPPLYSNINGSBRUDDPERSONAL (GDPRDATA Art.BREACH
331. Nature of the breach:
On {DATE}, we became aware of {unauthorized access to / personopplysningslovenaccidental §disclosure 32)of}
Behandlingsansvarlig:personal ALAIdata Holdingprocessed AS,by org.nr.Bilko. 932The 516 136, getdrop.no
1. Bruddets art:breach {is/was} {DATE}}: Vi ble oppmerksomme på [uautorisert tilgang til / utilsiktet utlevering av]
personopplysninger. Bruddet er [pågående / inneholdt]ONGOING/CONTAINED}.
2. KategorierCategories ogof omtrentligdata antallsubjects berørteand registrerte:approximate numbers:
- Kategorier:Data subjects: {{DATA_CATEGORIES}}NUMBER} (estimated)
- Estimert antall berørte personer:Categories: {{NUMBER}}user account data / tax IDs (PIB/JMBG/OIB/JIB) / IBAN / invoice data}
- Estimert antall berørte opplysninger:Records: {NUMBER} (estimated)
- Countries of affected data subjects: {NUMBER}}RS / BA / HR}
3. KontaktopplysningerContact details of DPO:
Name: {DPO_NAME}
Email: [email protected]
Organization: Bilko (bilko.io)
4. Likely consequences:
{ASSESSMENT — personvernombud:e.g., Navn:"Tax {{DPO_NAME}}ID E-post:exposure [email protected]creates Telefon:risk {{DPO_PHONE}}of 4.identity Sannsynligetheft; konsekvenser:IBAN {{CONSEQUENCES_FOR_DATA_SUBJECTS}exposure creates risk of financial fraud"}
5. GjennomførteMeasures ellertaken planlagteor tiltak:proposed:
- Umiddelbart:Immediate: {{IMMEDIATE_MEASURES}}CONTAINMENT_MEASURES}
- Pågående:Ongoing: {{ONGOING_MEASURES}}
- Planlagt:Planned: {REMEDIATION_MEASURES}
6. Note: This is a {PLANNED_MEASURES}}
Merknad: Dette er en [fullstendigcomplete / foreløpigpreliminary — supplerendesupplementary meldingnotification følger]to rapport.follow} report.
[DPO signatur]Signature]
{DPO_NAME}
[email protected]
7. Evidence Preservation Procedures
Principle: COLLECT BEFORE CONTAIN — evidence collection takes priority over containment unless ongoing harm is severe and imminent.
Evidence collection checklist:
□ AWSRailway CloudTraillog logs:export: Exportall fromservices, AWS30-day Consolewindow →around S3 (last 30 days minimum)incident
□ Cloudflare log export: WAF logs:events, Exportaccess last 30 dayslogs
□ SentrySentry: error events:events Exportexport
□ LoggedAction query: all mutations during incident window
SELECT * FROM logged_actions WHERE action_timestamp BETWEEN '{start}' AND '{end}'
□ BetterStackPostgreSQL: pg_stat_activity snapshot, connection history
□ Authentication logs: Exportfailed incidentlogin windowattempts, □token 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)usage
Chain of custody:
- All evidence files: SHA-256 hash computedall andexported recordedfiles immediately after collection
- HashRecord: log:filename, custody/chain-of-custody-{{DATE}}.txthash, —collector, signed by collectortimestamp
- Storage: Encryptedencrypted S3archive, bucketaccess (read-onlyrestricted afterto creation)
- Custody transfers: Documented with timestamps
- Retention: Minimum 5 years (hvitvaskingsloven § 30)IRT
8. Forensic Analysis Requirements
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 practicesWhat went poorly — specific improvement areasAction items: specific, assigned, time-boundDetection 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 | Full IRT + CEO | ||
| Notification drill | DPO + Legal |
72-hour |
|
| Technical response |
Annual | Engineering + Security | |
Last drill: Not yet conducted — schedule beforewithin production30 days of product launch
Next drill: Pre-production (target: before Finanstilsynet license application)
Drill coordinator: SecurityCompliance LeadArchitect / CEO([email protected])
Approval
| Role | Name | Date | Signature |
|---|---|---|---|
| Author | 2026-02-23 | ||
| DPO | |||
| Legal Counsel | |||
| CEO |