Audit-ready-garantin: villkor i klartext

1. Dokumentstatus och förhållande till övriga villkor

Detta dokument utgör en juridiskt bindande bilaga till Sprint-avtalet mellan Mindverk AB (organisationsnummer 559582-5570, 125 52 Älvsjö, Sverige), nedan Leverantören, och Kunden. Bilagan refereras i avsnitt 2.1 av användarvillkoren och i Sprint- avtalets garantiparagraf. Vid motstridighet mellan denna bilaga och marknadsföringstext på /audit-ready-garanti eller annan publik sida har denna bilaga företräde.

Bilagan är skriven så att alla mätbara påståenden står i 1:1-överensstämmelse med plattformens kod (filerna src/lib/billing/audit-criteria.ts, src/lib/billing/evaluate-audit-ready.ts, src/lib/billing/audit-ready-deadline.ts och src/lib/billing/refund.ts). Ändras dessa filer uppdateras bilagan i samma utgivning.

2. Produkten som omfattas

Garantin gäller endast Sprint-avgiften om 79 000 kr exklusive moms. Always-On-prenumerationen och tillägg (AI-kompetens-tracker, AI-systemregister) omfattas inte av denna garanti och regleras separat i användarvillkoren.

Sprint-perioden är 60 kalenderdagar räknat från den dag Stripe-fakturan skickas. Klockan startar samma dag oavsett när fakturan landar i kundens bokföring.

3. De tio audit-ready-kriterierna

Sprint utvärderas mot tio kriterier. Listan nedan är autogenererad från src/lib/billing/audit-criteria.ts och kan inte avvika från koden:

1. Kriterium 1. Styrelsen har antagit cybersäkerhetspolicyn
   • Definition. Cybersäkerhetspolicy formellt antagen av styrelsen med dokumenterat beslutsdatum.
   • Rättslig grund. Cybersäkerhetslagen (SFS 2025:1506) 3 kap. 2 §, Art. 21.2(a) NIS2
   • Vad som mäts. En policy med policy_type = "cybersecurity" har status = "adopted" och board_resolution_date är satt.
   • Identifierare i kod. c1_cybersecurity_policy_adopted_by_board
2. Kriterium 2. Riskbedömning klar för kritiska system
   • Definition. Alla risker med likelihood × impact ≥ 12 har dokumenterad mitigation.
   • Rättslig grund. Art. 21.2(a) NIS2, ISO 27005
   • Vad som mäts. Inga risks-rader med risk_score ≥ 12 saknar mitigation_plan.
   • Identifierare i kod. c2_risk_assessment_complete_for_critical
3. Kriterium 3. Leverantörsregister komplett
   • Definition. Minst 95 procent av aktiva leverantörer är klassificerade (inte status "unqualified").
   • Rättslig grund. Art. 21.2(d) NIS2 — supply chain security
   • Vad som mäts. Andel aktiva suppliers med assessment_status ≠ "unqualified" är ≥ 95 procent.
   • Identifierare i kod. c3_vendor_register_complete
4. Kriterium 4. Incidentprocess testad mot CERT-SE
   • Definition. Minst en testrapport till CERT-SE med diary-id finns dokumenterad.
   • Rättslig grund. Art. 23 NIS2, Cybersäkerhetslagen 4 kap.
   • Vad som mäts. incident_reports har minst en rad med is_test = TRUE och cert_se_diary_id satt.
   • Identifierare i kod. c4_incident_process_tested
5. Kriterium 5. Styrelseprotokoll undertecknat
   • Definition. Senaste styrelserapporten är undertecknad inom innevarande kvartal.
   • Rättslig grund. Art. 20 NIS2 — styrelsens ansvar
   • Vad som mäts. board_reports har minst en rad med signed_at inom de senaste 90 dagarna.
   • Identifierare i kod. c5_board_minutes_signed
6. Kriterium 6. AI Literacy Statement genererat
   • Definition. AI Literacy Statement (artikel 4) har genererats inom 90 dagar.
   • Rättslig grund. AI Act Art. 4
   • Vad som mäts. audit_log har minst en rad med action = "ai_literacy.statement_exported" inom 90 dagar.
   • Identifierare i kod. c6_ai_literacy_statement_generated
7. Kriterium 7. AI-systemregister med baseline-klassificering
   • Definition. Minst ett AI-system inventerat och ≥ 80 procent av systemen är klassificerade.
   • Rättslig grund. AI Act Art. 26
   • Vad som mäts. ai_systems-tabellen har ≥ 1 rad och andelen rader med status ≠ "pending_classification" är ≥ 80 procent.
   • Identifierare i kod. c7_ai_inventory_baseline
8. Kriterium 8. Leverantörsbedömning genomförd
   • Definition. Minst 80 procent av aktiva leverantörer har vendor_assessment.status = "complete".
   • Rättslig grund. Art. 21.2(d) NIS2
   • Vad som mäts. Andel suppliers med vendor_assessments.status = "complete" är ≥ 80 procent.
   • Identifierare i kod. c8_supplier_assessment_done
9. Kriterium 9. Kontinuitetsplan uppladdad
   • Definition. Affärskontinuitetsplan (BCP) är godkänd och har innehåll.
   • Rättslig grund. Art. 21.2(c) NIS2
   • Vad som mäts. bcp_plans-tabellen har minst en rad med status = "approved" och content är inte tom.
   • Identifierare i kod. c9_continuity_plan_uploaded
10. Kriterium 10. Audit-logg utan kritiska luckor
    • Definition. Inga olösta kritiska incidenter äldre än 30 dagar; inga audit-luckor större än 24 timmar.
    • Rättslig grund. Cybersäkerhetslagen 4 kap. (24 mån spårbarhet)
    • Vad som mäts. Ingen rad i incidents med severity = "critical" och status ≠ "resolved" är äldre än 30 dagar. audit_log har ingen lucka > 24h.
    • Identifierare i kod. c10_audit_log_no_critical_gaps

Kriterierna fryses vid Sprint-start. Eventuella ändringar i kriterierna under pågående Sprint är inte gällande mot den specifika Sprinten, endast den version som låstes vid start används vid utfallsbedömningen på dag 60.

Notera kriterium 4: incidentprocessen testas mot CERT-SE (CSIRT-funktionen vid Myndigheten för civilt försvar, MCF) och spåras via fältet cert_se_diary_id. Plattformen använder aldrig msb_diary_id, Myndigheten för samhällsskydd och beredskap (MSB) bytte namn till MCF den 1 januari 2026. Sektorvis tillsyn (PTS, Finansinspektionen, sex länsstyrelser m.fl.) är inte mottagare av incidentrapporter i denna mening.

4. Mätmetod: deterministisk eller bedömning

Samtliga tio kriterier är deterministiska. Varje kriterium är formulerat som en SQL-fråga mot plattformsdatabasen och utvärderas till exakt en av två utfall: passerat (TRUE) eller icke passerat (FALSE). Ingen subjektiv bedömning, manuell granskning eller skönsmässig tolkning ingår i utfallsbedömningen.

Utvärderingsmotorn ligger i src/lib/billing/evaluate-audit-ready.ts och kallas funktionerna evaluateC1 till evaluateC10. Resultatet sparas som boolean- snapshot i kolumnerna c1_cybersecurity_policy_adopted_by_board till c10_audit_log_no_critical_gaps i tabellen audit_ready_assessments, samt som immutabel rad i tabellen assessment_runs (append-only via databastrigger).

Utvärderingen körs en gång per dygn klockan 02:00 svensk tid under hela Sprint-perioden, samt en sista gång på dag 60. Snapshot-raden från dag 60 är den juridiskt bindande utfallsbedömningen.

5. Utfall på dag 60

Logiken på dag 60 ligger i funktionen processOverdueAssessments i src/lib/billing/audit-ready-deadline.ts. Tre utfall är möjliga:

• Tio av tio kriterier passerade. Assessment sätts till status passed. Kunden får audit-ready-bevis som tidsstämplad PDF med kryptografisk hash av snapshot-raden, kopplad till append-only-loggen i databasen. Always-On-prenumerationen kan därefter aktiveras separat.
• Färre än tio kriterier passerade. Default-utfallet är automatisk 30-dagars-förlängning utan extra avgift (se avsnitt 6). Kunden har under en 14-dagarsperiod rätt att i stället begära refund (se avsnitt 7).
• Pausat eller force majeure. Om klockan har pausats enligt avsnitt 11 räknas pausperioden inte mot de 60 dagarna och utfallsbedömningen senareläggs motsvarande.

6. Automatisk 30-dagars-förlängning

Förlängningen är default-utfallet vid färre än tio passerade kriterier på dag 60. Aktivering sker automatiskt utan att kunden behöver göra något. Den dygnscron som ligger i processOverdueAssessments anropar markAuditReadyExtended, vilken sätter assessment-status till extended, sparar ursprunglig deadline i fältet original_deadline och förlänger audit_ready_deadline med 30 kalenderdagar. Plattformsåtkomsten är oförändrad och nattliga utvärderingar fortsätter på samma kodväg.

Förlängningen kostar inget. Kunden kan när som helst under förlängningen avbryta och begära refund enligt avsnitt 7, eller fortsätta arbetet och stänga kvarvarande kriterier.

Vid förlängningens slut (60 + 30 = 90 kalenderdagar från Sprint-start) körs en sista utvärdering. Tio gröna kriterier ger samma utfall som i avsnitt 5 (passed). Färre än tio gröna utlöser automatisk refund av Sprint-avgiften via triggerSprintRefund, utan att kunden behöver klicka på något, under förutsättning att cirkulärbrytaren och 100 000 kr-tröskeln (avsnitt 9) inte är aktiva.

7. Refund-fönster och refund-form

Audit-ready-garantins refund-fönster är 14 kalenderdagar räknat från dag 60. Inom detta fönster (alltså senast på dag 74) har kunden ovillkorlig rätt att begära full refund av Sprint-avgiften om något av de tio kriterierna inte är grönt vid utfallsbedömningen på dag 60. Begäran kräver ingen motivering och inget möte.

Begäran sker via knappen Avsluta och få refund i dashboard, under /installningar/abonnemang. Knappen anropar funktionen triggerSprintRefund med anledning customer_opt_out. Att begära refund inom 14-dagars-fönstret avbryter den automatiska förlängningen.

Refund-form. Hela Sprint-avgiften (79 000 kr exklusive moms, 98 750 kr inklusive moms) återbetalas via Stripe till samma betalningsmetod som Sprint-fakturan betalades med, bankkort, autogiro eller företagskonto via Stripe Invoice. Idempotensnyckeln sprint_refund:{org_id}:{assessment_id} garanterar att en assessment endast kan refunderas en gång, även vid retries.

Tidsfönster för utbetalning. Stripe behandlar refund inom 5 till 10 bankdagar beroende på utfärdande bank. Bekräftelsemejl med Stripe-referens och lista över ej passerade kriterier skickas till kontaktperson omedelbart vid trigger.

Kund-driven refund utanför 14-dagars-fönstret. Knappen Avsluta och få refund är tekniskt aktiv så länge assessment har status in_progress eller extended (alltså upp till och med dag 90). Refund som triggas mellan dag 75 och dag 90 sker på samma villkor som inom 14-dagars-fönstret, men är att betrakta som kundens eget beslut att avbryta förlängningen snarare än som ett anspråk under garantin.

Effekt av refund. Vid refund avslutas Sprint-fönstret omedelbart: organizations.audit_ready_status sätts till refunded och organizations.sprint_active_until sätts till null. Plattformsåtkomsten stängs av 14 kalenderdagar efter refund-bekräftelsen. Kundens data exporteras dessförinnan som strukturerad JSON plus PDF-protokoll. Always-On-prenumerationen startar inte automatiskt.

8. Vad räknas som customer-side blocking

Garantin förutsätter att Kunden levererar de inputs som behövs för att kriterierna ska kunna uppfyllas. Följande händelser räknas som customer-side blocking och pausar 60-dagars-klockan tills hindret är åtgärdat:

• Försenat svar på input-förfrågan. Utebliven respons mer än 5 arbetsdagar på Leverantörens förfrågan om riskbedömnings-input, leverantörsbedömnings- input eller annan obligatorisk komplettering.
• Saknad styrelsesignering. Avsaknad av signerat styrelseprotokoll inom 10 arbetsdagar från utkast, om signeringen krävs för kriterium 1 eller 5.
• Försenade obligatoriska steg. Icke genomförda steg i plattformen som krävs för utvärderingen: policy-antagande (kriterium 1), riskbedömning (kriterium 2), leverantörsregister (kriterium 3), incidentprocesstest mot CERT-SE (kriterium 4), AI-systemregister (kriterium 7) eller kontinuitetsplan (kriterium 9).
• Avsaknad av kontaktperson. Ingen utsedd kontaktperson med beslutsmandat på exekutiv nivå, eller vägran att utse sådan person inom 5 arbetsdagar från Sprint-start.
• Avsiktliga blockeringar. Avsiktlig undanhållande av underlag, vägran att svara på kompletteringsförfrågningar eller annan handling som förhindrar kriterieutvärderingen.

Pausmekaniken loggas append-only i audit_log med entry audit_ready.clock_paused. Återupptagning loggas som audit_ready.clock_resumed. Under pausad klocka räknas tiden inte mot 60-dagars- eller 14-dagars- fönstret. Garantin förlängs i motsvarande mån.

9. Interna säkerhetsmekanismer mot felutbetalning

Två mekanismer kan blockera den automatiska refunden från att gå direkt mot Stripe. Båda är dokumenterade i koden i src/lib/billing/refund.ts:

• Cirkulärbrytare per organisation. Om organizations.refund_circuit_breaker_paused är satt till TRUE blockeras automatisk refund och assessment går till status manual_review. Loggas som audit_ready.refund_blocked_breaker. Mekanismen finns för att skydda mot felaktigt utlöst refund vid bekräftade datafel.
• Belopps-tröskel om 100 000 kr. Refunds över 100 000 kr (10 000 000 öre) markeras automatiskt som manual_review och kräver manuellt godkännande av admin. Loggas som audit_ready.refund_requires_approval med belopp i öre. Sprint-avgiften 79 000 kr ligger under tröskeln, så vanlig Sprint refunderas automatiskt.

Vid manual_review påverkas inte kundens juridiska rätt till refund, endast utbetalningstidpunkten. Manuell granskning ska vara avslutad inom 5 arbetsdagar från flagging. Om granskningen leder till att refund godkänns utbetalas Stripe-refunden senast 10 bankdagar därefter.

10. Force majeure

Tre situationer kan motivera att Sprint-klockan pausas utöver customer-side blocking. Varje paus kräver dokumenterad anledning, admin-godkännande och loggas i audit_log:

1. CERT-SE-nedtid. Längre period då CERT-SE inte tar emot diary-anmälningar, vilket gör kriterium 4 tekniskt omöjligt att uppfylla. Pausen pågår tills CERT-SE bekräftar att kanalen är öppen igen.
2. Kundens egna dataavbrott. Längre IT- incident hos Kunden som blockerar import av leverantörsdata, AI-systemkartläggning eller signering av styrelseprotokoll. Kräver incidentrapport från Kunden som underlag för pausen.
3. Regulatoriskt klargörande. Bindande klargörande från PTS, IMY eller annan tillsynsmyndighet som direkt påverkar något av kriterierna. Pausen pågår tills tolkningen är inarbetad i plattformen.

11. Eskalering, support och tvistelösning

Frågor, anspråk eller invändningar avseende denna garanti hanteras enligt följande kanal-trappa. Inga säljsamtal, inga möten, ingen telefon, all kommunikation sker via mejl och plattformen.

11.1 Steg ett, primärkanal

Skicka ett mejl till support@cyberklar.se med ärendetypen Audit-ready-garanti och referens till assessment-id (syns i dashboard). Leverantören bekräftar mottagandet inom 1 arbetsdag och lämnar substantiellt svar inom 5 arbetsdagar. Med arbetsdag avses helgfri vardag måndag till fredag i Sverige, exklusive svenska röda dagar och klämdagar enligt kollektivavtal.

11.2 Steg två, formellt anspråk

Om svaret från steg ett inte löser ärendet kan Kunden lämna ett formellt anspråk per mejl till samma adress, märkt Formellt anspråk under audit-ready-garantin. Anspråket ska innehålla:

• Assessment-id och organisations-id
• Vilket eller vilka av de tio kriterierna som är ifrågasatta
• Underlag eller hänvisning till plattformens evidens
• Önskad åtgärd (refund, förlängning, annat)

Leverantören svarar formellt inom 10 arbetsdagar från mottagandet. Svaret är skriftligt och hänvisar till tillämpliga paragrafer i denna bilaga, kodreferenser och relevanta entries i audit_log.

11.3 Steg tre, tvistelösning

Tvist som inte löses i steg två avgörs av allmän domstol med Stockholms tingsrätt som första instans, enligt avsnitt 10 i användarvillkoren. Svensk rätt tillämpas. Tjänsten riktar sig endast till juridiska personer i näringsverksamhet (se avsnitt 1 i användarvillkoren), Konsumentkopplingslagens forumregler är därför inte tillämpliga.

12. Audit-logg och bevarande

Alla händelser kring garantin loggas append-only i audit_log. Tabellen är skyddad av databastrigger (migration 021_audit_log_append_only) som blockerar både UPDATE och DELETE. Relevanta entries:

• audit_ready.evaluation_completed, varje nattlig utvärdering plus den slutliga utvärderingen på dag 60 och dag 90.
• audit_ready.passed, utfallsbedömning där samtliga tio kriterier är gröna.
• audit_ready.extension_started, automatisk 30-dagars-förlängning aktiverad.
• audit_ready.refund_triggered, refund utbetald via Stripe.
• audit_ready.refund_blocked_breaker, refund blockerad av cirkulärbrytaren.
• audit_ready.refund_requires_approval, refund över 100 000 kr som kräver admin-godkännande.
• audit_ready.clock_paused / audit_ready.clock_resumed, pausad och återupptagen klocka enligt avsnitt 8 eller 10.

Loggen bevaras i 24 månader (Cybersäkerhetslagen 4 kap. spårbarhetskrav). Sektorvis tillsynsmyndighet eller annan myndighet med rättslig grund kan begära ut loggen som signerad CSV-export. Kunden kan när som helst själv exportera loggen från dashboard.

13. Bevisbörda och immutabilitet

Vid tvist om huruvida ett kriterium var grönt på dag 60 eller dag 90 är raden i assessment_runs det avgörande beviset. Raden hashas och tidsstämplas vid skrivning och kan inte ändras. Hashen kan på begäran verifieras av tredje part mot kodreleasen som körde utvärderingen.

Kundens egna evidence (policydokument, riskposter, styrelseprotokoll, incident-test-rapporter, AI-system- klassificeringar och kontinuitetsplan) lagras i sina respektive tabeller med versionshistorik. Vid uppgradering eller ändring bevaras tidigare versioner.

14. Ändringar av denna bilaga

Bilagan kan uppdateras när koden uppdateras. Väsentliga ändringar kommuniceras till administratörer med minst 30 dagars varsel enligt avsnitt 9 i användarvillkoren. Pågående Sprint-avtal omfattas av den version av bilagan som var gällande vid Sprint-start; senare ändringar gäller endast nytecknade Sprint-avtal.

Aktuell version och tidigare versioner av bilagan finns versionerade i Leverantörens publika repository. Versions- datum framgår av sidfoten.