Fra AI-bygget prototype til et værktøj, andre kan bruge

Hvornår bruger man hvad?

De fleste apps kombinerer flere emner. Start med det problem, I skal løse, og vælg kun de teknologier, som passer til jeres data, brugere og eksisterende miljø.

Brugerne ved ikke, om appen er nede, eller om de selv gør noget forkert

Giv dem én tilgængelig statuskanal med berørte funktioner, sikre handlinger og tidspunkt for næste opdatering. Varsl planlagt vedligeholdelse med tidszone og påvirkning, og meld først normal drift efter en rigtig brugerrejse er testet.

Brugerne melder fejl i private beskeder, og ingen ved hvad der haster

Saml henvendelser i én kø med sagsnummer og ejer. Brug en sikker rapportskabelon, prioritér efter konsekvens og omfang, forbind sagen med logs via en reference, og eskalér straks ved mulig data- eller sikkerhedspåvirkning.

Vi beskytter alle data ens og ved ikke, hvad der er mest kritisk

Saml appens vigtigste datatyper, og vurder konsekvensen ved tab af fortrolighed, integritet og tilgængelighed hver for sig. Knyt derefter niveauet til konkrete regler for adgang, testkopier, logs, backup, deling og sletning.

Vi kan ikke samlet forklare, hvilke persondata appen bruger og hvorfor

Lav en behandlingsfortegnelse pr. forståelig aktivitet, og kontrollér formål, persongrupper, datakategorier, modtagere, overførsler, slettefrister og sikkerhed mod den faktiske database, filer, login, logs og integrationer.

Udvikling eller staging bruger en kopi af rigtige kunder og medarbejdere

Byg et genskabeligt sæt syntetiske data med de relationer og grænsetilfælde, testen kræver. Hvis produktionsdata undtagelsesvis er nødvendige, så begræns udsnittet, reducér identifikation, beskyt miljøet efter risikoen og sæt automatisk udløb.

Appen bruger cookie-login, men vi ved ikke, om et fremmed website kan udløse ændringer

Kortlæg alle ændrende endpoints, brug frameworkets servervaliderede CSRF-kontrol, og test manglende tokens, simple cross-site requests, SameSite, CORS og Fetch Metadata i den faktiske arkitektur.

Vi ved ikke, om gamle brugere, administratorer og integrationer stadig har adgang

Tag et samlet øjebliksbillede af mennesker, grupper og maskinidentiteter. Bekræft ejer, formål og nødvendigt omfang, og gennemfør fjernelse eller begrænsning som små, testede driftsændringer.

Appen bruger persondata på en måde, der kan få store konsekvenser for mennesker

Afgræns den konkrete behandling, kontrollér Datatilsynets liste og risikokriterierne, og lav en DPIA før drift, hvis behandlingen sandsynligvis indebærer høj risiko. Knyt hver væsentlig risiko til en testbar ændring og en ansvarlig beslutning.

En kunde eller sikkerhedsresearcher finder en mulig sårbarhed, men ved ikke hvordan den kan meldes privat

Opret en overvåget kontaktvej med en navngiven ejer, udgiv security.txt og en kort rapporteringspolicy, og øv hvordan et fund registreres, genskabes sikkert, eskaleres og besvares.

Appen indsamler persondata, men privatlivsteksten er en gammel standardskabelon

Kortlæg hvert formål, datakilde, grundlag, modtager og slettefrist. Vis den relevante forklaring ved formularen eller flowet, gør den fulde tekst let at finde i appen, og kontrollér den ved ændringer.

En bruger logger ud, men browseren kan stadig huske kundedata

Kortlæg localStorage, sessionStorage, IndexedDB, service-worker-cache, HTTP-cache og auth-persistens. Vælg hvad der må overleve, og test delt enhed, åbne faner, offline-visning og kontoskift.

Appen bruger flere cloud- og AI-tjenester, men ingen har samlet leverandørkæden

Følg persondata gennem hosting, database, login, mail, logs, support og AI-kald. Registrér roller, aftaler, underdatabehandlere og behandlingssteder, og gør ændringsvarsler og risikobaseret tilsyn til en fast driftsopgave.

En kunde eller medarbejder beder om indsigt, rettelse eller sletning

Registrér fristen, kontrollér identiteten og find personen på tværs af app, filer, logs og leverandører. Vurder hver datakilde, beskyt andre personers oplysninger, og verificér udleveringen eller ændringen før sagen lukkes.

Appen virker, men vi er ikke klar til at åbne for alle medarbejdere eller kunder

Kør en afgrænset pilot med repræsentative brugere, kendte data og en tydelig supportvej. Aftal målinger, stopkriterier og alternativ arbejdsgang, så brugen kan udvides eller stoppes på baggrund af beviser.

Vi vil bruge AI direkte i kodeprojektet

Cursor kan hjælpe med at forstå og ændre kode. Brug Git som sikkerhedsnet, giv små afgrænsede opgaver, beskyt følsomme filer, og gennemgå altid diff og tests før udgivelse.

Webappen skal kunne installeres og håndtere ustabilt netværk

PWA-guiden hjælper med installation, app-shell, cache, service worker og opdateringer. Vælg native app, hvis kernefunktionen kræver dyb platform- eller hardwareadgang.

Medarbejdere gemmer data uden net, men vi ved ikke hvad der sker ved næste synkronisering

Skeln mellem lokal kladde, afventende kø og serverbekræftet data. Brug stabile operation-id'er, vælg konflikt- og sletteregler, kontrollér adgang igen ved sync, og test afbrydelser på tværs af enheder og appversioner.

Vi skal vælge, hvor webappen skal hostes

Netlify passer ofte til enkel frontendhosting, Vercel til Next.js, Firebase Hosting til Firebase-apps og Azure til Microsoft-miljøer. Vælg først efter appens runtime, backend og driftskrav.

Vi kan ikke se, om en fejl pludselig gør appen dyr

Kortlæg de handlinger, der driver database, compute, filer, netværk og eksterne API-kald. Kombinér budgetalarmer med tekniske forbrugsmål og afgrænsede grænser i appen.

Login virker, men vi kan ikke lukke stjålne sessioner eller gendanne en konto sikkert

Kortlæg MFA, sessioners levetid, genbekræftelse, tilbagekaldelse og kontogendannelse. Test også mistet enhed, flere aktive enheder og fratrådte brugere.

Medarbejdere eller kunder skal inviteres ind i den rigtige virksomhed

Behandl invitationen som en adgangsbeslutning. Serveren skal binde den inviterede identitet til virksomhed og rolle, mens linket skal udløbe, kunne tilbagekaldes og kun kunne bruges én gang.

Vi skal købe domæne eller forbinde web, mail og hosting

Start med korrekt ejerskab og DNS. Dokumentér records, vælg forhandler, beskyt kontoen, og flyt aldrig navneservere uden at sikre mail og verifikationer.

Vi skal kunne genskabe appen efter sletning, fejl eller nedbrud

Lav en samlet plan for kode, data, filer, konfiguration og adgang. En backup giver først ro, når en gendannelse er afprøvet i et sikkert miljø og dokumenteret.

Vi skal kunne flytte appen eller skifte leverandør

Lav en exit-pakke med kode, data, filer, brugere og nødvendig konfiguration. Kontrollér platformens eksportgrænser, og test at materialet kan forstås og genbruges uden adgang til produktion.

Medarbejdere henter rapporter til CSV eller Excel

Behandl downloadknappen som en dataadgang: afgræns omfang og felter på serveren, håndtér regnearksformler, og test den færdige fil i de programmer, virksomheden bruger.

Vi har API-nøgler, tokens eller databaseadgange i projektet

Kortlæg hvad der reelt er hemmeligt, hold secrets ude af frontend og Git, adskil miljøer, begræns rettigheder, og dokumentér rotation og lækhåndtering. Vælg opbevaring efter den cloud og hosting, appen allerede bruger.

Vi opdager først fejl, når en bruger fortæller os det

Kortlæg kritiske handlinger, brug hostingens logs, kontrollér appen udefra, og send få alarmer til en navngiven ansvarlig. Vælg værktøjer efter den stack, appen allerede bruger.

Vi har overvågning, men intet fælles mål for hvornår appen virker godt nok

Vælg kritiske brugerrejser, mål deres faktiske resultat, og aftal realistiske SLI'er og SLO'er. Hold interne driftsmål adskilt fra eksterne SLA-løfter.

Brugeren møder en blank side eller ved ikke, om arbejdet blev gemt

Skeln mellem kendte og uventede fejl, giv et sikkert og handlingsklart svar, bevar input, og forbind brugerens reference med den tekniske hændelse uden at vise interne detaljer.

Alarmen er kommet, men ingen ved hvem der beslutter eller informerer

Lav et lille driftsberedskab med kriterier, roller, hændelseslog, sikre stabiliseringsvalg, fast statusrytme og kontrol af data og brugerrejser før hændelsen lukkes.

Loginlinks, kvitteringer eller andre vigtige app-mails forsvinder

Godkend afsenderdomænet, skeln mellem accepteret og leveret, beskyt tokens, håndtér bounces og suppression, og overvåg hele forløbet fra brugerhandling til modtagersystem.

Vi kan se den aktuelle værdi, men ikke hvem der ændrede eller slettede den

Et revisionsspor gemmer de kritiske forretningshændelser med aktør, objekt, resultat og relevante ændringer. Hold det adskilt fra almindelige fejllogs, og beskyt historikken mod fri redigering.

Kun én person ved, hvordan appen drives og overtages

Saml et systemkort, ansvar, deployment, rollback, runbooks og adgangsveje i versionsstyret dokumentation, og lad en anden person afprøve den uden mundtlige genveje.

Cloudmiljøet er bygget med manuelle klik, som ingen kan genskabe sikkert

Kortlæg de faktiske ressourcer og skjulte indstillinger, vælg infrastruktur som kode efter stacken, overtag eksisterende produktion uden uventede ændringer, og bevis opsætningen i et isoleret miljø.

GitHub, cloud eller domænet hænger på én privat konto

Kortlæg platformenes ejer- og recovery-model, flyt ressourcer til virksomhedens organisation eller team, begræns daglig adminadgang, og lad en anden person afprøve login, deployment, fakturering og nødvej.

Pakker og runtime bliver ældre, men ingen ejer opdateringerne

Kortlæg manifest, lockfile, runtime og deployment, aktivér sikkerhedsalarmer, og send hver opdatering gennem risikovurdering, review, test og en kontrolleret udgivelse.

Hver ændring går direkte live, og vejen tilbage er uklar

Adskil testdata og produktionsdata, brug platformens preview eller staging efter appens risiko, kør et fast smoke test, og dokumentér rollback for både deploy og data.

Appen kan kun udgives fra én computer med en gemt produktionsnøgle

Kortlæg den faktiske deploymentvej, adskil buildkontrol fra produktionsadgang, brug en afgrænset maskinidentitet, undgå overlappende releases, og forbind hver live-version med commit, workflow og smoke test.

Den nye version virker, men gamle faner får blank side eller kan ikke åbne en funktion

Lad HTML genvalidere, behold eller håndtér gamle lazy-loaded filer, afgræns SPA-fallback, og test service worker og tidligere frontend mod den nye release.

En risikabel funktion skal kunne åbnes gradvist eller stoppes uden nyt deploy

Brug et feature flag med en sikker standard, tydelig ejer, afgrænset målgruppe og målbare stopkriterier. Håndhæv stadig adgang på serveren, og øv nødstop for app, API og igangværende jobs.

Vi ved ikke, om en ændring har brudt en vigtig arbejdsgang

Lav en risikobaseret teststrategi for de kritiske brugerrejser. Vælg det rette testniveau, brug kontrollerede testdata, og kør de vigtigste kontroller automatisk før udgivelse.

Integrationen er grøn, men appen og det eksterne system viser forskellige data

Vælg en sandhedskilde for hvert vigtigt faktum, sammenlign stabile id’er og sluttilstande på en tidsplan, og send uafklarede eller risikable forskelle til kontrolleret behandling.

Appen virker i vores Chrome, men medarbejderne bruger også Safari, Firefox og telefoner

Aftal en realistisk supportmatrix, kontrollér kritiske flows i flere browsermotorer, og supplér mobil simulering med de rigtige enheder, når kamera, filer, touch eller firmapolitikker har betydning.

Appen virker for én person, men vi kender ikke kapaciteten

Belastningstest efterligner et kritisk brugerforløb med realistisk samtidighed. Sæt mål ud fra arbejdsdagen, mål hele kæden, og kontrollér både svartid, fejl og data efter testen.

Appen er hurtig med testdata, men lister og søgning bliver langsomme, når data vokser

Find skærme, der henter hele datasættet, og giv hver query et loft, filtre og stabil sortering. Brug datalagerets pagination og optællinger, mål indeks, og test med en realistisk datamængde.

En administrator kan slette eller ændre mange data på én gang

Beregn en konkret forhåndsvisning på serveren, vis mål og følgevirkning, kontrollér rettighed og omfang igen ved udførelse, og planlæg atomisk ændring eller et sikkert job med revisionsspor og gendannelse.

To brugere kan redigere, booke eller gemme de samme data samtidig

Beskriv den forretningsregel, der ikke må brydes, og beskyt den med en atomisk kontrol. Brug transaktioner til samlet læsning og skrivning, versionskontrol mod overskrivning og idempotens mod gentagne requests.

En sag, ordre eller booking kan springe over godkendelser eller ende i en umulig status

Beskriv tilladte overgange med aktør og betingelser, håndhæv dem ved server eller dataregler, og registrér eksterne sideeffekter som sikkert genkørbart arbejde efter statusskiftet.

Én konto kan alene ændre bankoplysninger, give adminadgang eller udføre andre kritiske handlinger

Udvælg handlinger efter reel konsekvens, og lad én person oprette et præcist beslutningsgrundlag, som en anden godkender. Bind beslutningen til dataene, afvis self-review på serveren, og kontrollér alt igen før udførelse.

Bookinger, deadlines eller planlagte jobs kan ramme forkert omkring sommertid

Skeln mellem et præcist øjeblik, en lokal aftale, en ren dato og en gentagelse. Bevar den navngivne tidszone, vælg lokal tid eller fast kadence bevidst, og test manglende, dobbelte og forsinkede kørsler.

Vi skal flytte Excel-, CSV- eller gamle systemdata ind i appen

Kortlæg felter og stabile kildenøgler, valider i et mellemområde, gør importen sikker at genkøre, og afstem antal, summer og relationer før brugerne overtager data.

Vi skal ændre tabeller eller kolonner, mens appen er i drift

Læg skemaændringen i Git, hold gammel og ny kode kompatibel, flyt eksisterende data i kontrollerede batches, og mål låse og køretid før den gamle struktur fjernes.

Brugerne kan logge ind, men vi ved ikke præcist, hvem der må se og ændre hvad

Lav en adgangsmatrix for roller, virksomheder og dataposter. Håndhæv den ved API, database eller Security Rules, og test også de handlinger, som skal afvises.

Flere virksomheder bruger samme app, og deres data må aldrig blandes

Forbind den indloggede bruger med en serververificeret virksomhed, og håndhæv grænsen på tværs af API, database, filer, cache, jobs og eksport. Bevis afslag med to realistiske testvirksomheder.

Support skal kunne se brugerens problem uden permanent adgang til hele produktionen

Start med dataminimeret diagnostik, og åbn kun en navngiven, tidsbegrænset supportsession med konkret sag, mål og omfang. Bevar den virkelige aktør, vis supporttilstanden tydeligt, og log start, handlinger og afslutning.

Koden er AI-bygget, men ingen har systematisk kontrolleret den for lækkede secrets og sårbarheder

Baselinér eksisterende fund, og brug secret scanning, dependency review og statisk kodeanalyse efter projektets sprog og risiko. Lad stabile kontroller vise nye fund i pull requests, og giv hver alarm en ejer og dokumenteret vurdering.

Vi ved ikke, hvor appens pakker, kodeudsnit, fonte og ikoner kommer fra, eller hvilke vilkår der følger med

Lav et versionsbundet komponentinventar med kilde, licens og ansvarlig vurdering. Brug en SBOM til registrerede dependencies, gennemgå også manuelle kode- og assetkilder, og afklar ukendt oprindelse før kundelevering.

Scanningerne er grønne, men ingen har prøvet appens adgangsgrænser som en angriber

Afgræns en autoriseret sikkerhedstest med repræsentative roller, tenants og testdata. Prøv både tekniske kontroller og forretningslogik, og luk fund med årsagsrettelse, regressionstest og retest.

Vi har mange sikkerhedsråd, men ved ikke hvilke risici der er vigtigst i vores app

Afgræns en kritisk brugerrejse, tegn dataflow og tillidsgrænser, beskriv konkrete misbrugsscenarier, og forbind de vigtigste risici med en ejer, beslutning og testbart bevis.

API'et kan kaldes uden om formularen, og vi mangler grænser for input og misbrug

Kortlæg endpoints og webhooks, valider input og tilladte felter på serveren, vælg korrekt CORS- og CSRF-beskyttelse, og begræns størrelse, frekvens og dyre handlinger efter den konkrete stack.

En ny backend kan ramme gamle browsertabs, mobilapps eller integrationer

Beskriv API'ets requests, svar og adfærd som en kontrakt. Bevar gammel form under overgangen, test tidligere klient mod ny backend, og versionér kun når et reelt brud ikke kan undgås.

Offentlige formularer, bookinger eller dyre kald kan automatiseres og misbruges

Vurder skaden i hvert forretningsflow, og kombiner passende grænser pr. konto, virksomhed, session, flow og eventuelt IP. Håndhæv dem på serveren, brug botkontrol som ekstra lag, og mål både afvisninger, omkostning og legitime brugere, der rammes.

AI-funktionen læser tekst eller filer og kan bruge værktøjer i andre systemer

Behandl eksternt indhold som ubetroet, begræns data og værktøjer, validér modellens forslag på serveren, og kræv en konkret godkendelse før sletning, betaling, adgangsændring eller ekstern kommunikation.

Data fra brugere eller integrationer bliver vist i browseren, men vi har ikke gennemgået XSS og headers

Kortlæg hvor ubetroede værdier bliver til tekst, HTML, links eller scripts. Bevar frameworkets sikre rendering, sanitér nødvendig formateret tekst, og afprøv en tilpasset Content Security Policy før håndhævelse.

Appens server henter filer, previews eller webhookadresser fra en URL

Fjern den frie URL, når behovet kan løses med upload eller et kendt leverandør-id. Ellers skal protokol, destination, opløst IP og redirects kontrolleres, mens netværk, tid, størrelse og samtidighed afgrænses.

Betalings-, booking- eller statushændelser kommer via webhooks

Kontrollér leverandørens signatur på den rå request, gem eventet før kvittering, og gør behandlingen sikker ved dubletter, forsinkelse, forkert rækkefølge og genbehandling. Vælg endpoint og kø efter appens eksisterende stack.

Kunder skal betale i appen uden falsk status eller dobbelt levering

Lad betalingsudbyderen indsamle kortoplysninger, beregn ordren på serveren, behandl retur-siden som status, bekræft med signerede webhooks, og afstem lokale ordrer med de faktiske betalinger.

Et abonnement skal åbne og lukke de rigtige funktioner på det rigtige tidspunkt

Adskil faktura, abonnementsstatus og produktadgang. Skriv regler for prøveperiode, fornyelsesfejl, planskift og opsigelse, opdatér gennem verificerede webhooks, og afstem løbende mod betalingsudbyderen.

Priser, rabatter, moms eller totaler kan afvige med få øre mellem appen og bogføringen

Vælg hele minor units eller en egnet decimaltype, saml serverens beregning og afrundingsregel, bevar godkendte beløb som historik, og afstem hver systemgrænse på både værdi og valuta.

Appen kalder et eksternt system, men kan hænge eller gentage handlingen ved fejl

Sæt en timeout på hvert kald, retry kun fejl der kan være midlertidige, brug idempotens ved skrivning, og bevar en ærlig mellemstatus, når leverandørens resultat ikke kan bekræftes.

Appen bruger persondata, men ingen har samlet overblik over formål, leverandører og sletning

Kortlæg dataflowet fra formular til database, logs, integrationer, AI-tjenester og backup. Afklar ansvar, grundlag, dataminimering, slettefrister, brugerrettigheder, risici og håndtering af sikkerhedsbrud.

Gamle kunder, filer og logs bliver aldrig slettet automatisk

Knyt hvert datasæt til en konkret starthændelse, frist og sluttilstand. Kortlæg alle kopier, og kør sletning eller anonymisering i kontrollerede batches med måling, fejlalarm og hensyn til backup.

Vi har et cookiebanner, men ved ikke om statistik og marketing faktisk venter på valget

Kortlæg cookies, pixels, browserlagring og tredjepartsrequests. Adskil formål, blokér ikke-nødvendige tags før valg, gør afvisning og tilbagetrækning brugbar, og test den faktiske netværkstrafik i en ren browser.

Vi skal eje koden og kunne rulle tilbage

Brug GitHub til kode og historik. Beskyt den stabile branch med pull requests og relevante checks, hvis ændringer ikke må kunne gå direkte i drift.

Medarbejderne skal bruge deres arbejdskonto

Vælg Microsoft Entra SSO, hvis virksomheden bruger Microsoft 365. Firebase Auth kan passe til appens egne brugerkonti.

Vi skal hoste en webapp og gemme dokumentdata

Firebase Hosting og Firestore kan være en enkel samlet løsning til en frontend og en dokumentdatabase.

Appen bruger Supabase direkte fra browseren, men vi har ikke testet dataadgangen

Kortlæg nøgletyper og eksponerede tabeller, begræns grants, håndhæv RLS pr. bruger og virksomhed, og test afslag uden om brugerfladen. Gennemgå også Storage, views, funktioner og Realtime.

Vi skal modtage webhooks eller køre backendkode i Azure

Azure Functions passer til små API'er, integrationer, køer og planlagte opgaver i et Azure-miljø.

Vi skal gemme enkle opslag eller filer i Azure

Brug Table Storage til simple poster, der findes via kendte nøgler, og Blob Storage til PDF'er, billeder og andre filer. Vælg SQL, når data kræver relationer, joins eller fri rapportering.

Vi har strukturerede relationer, rapportering eller mange sammenhængende data

En SQL-database kan være bedre end en dokumentdatabase. SQL-guiden forklarer datamodel, constraints, sikker adgang, migreringer og forbindelser med PostgreSQL som praktisk eksempel.

Serverless-appen virker i test, men får forbindelsesfejl, når flere bruger den

Kortlæg databasegrænsen, hver instans' pool og platformens samtidighed. Vælg direct, session eller transaction pooling efter runtime og opgave, og mål både poolventetid, queries og brugerflow. Guiden til databaseforbindelser viser den praktiske gennemgang.

Appen skal arbejde med en brugers Google Drive, Gmail eller Kalender

Brug Google OAuth til afgrænset samtykke uden at dele adgangskoder. Vælg målgruppe og mindst mulige scopes, beskyt callback og tokens, og adskil test- og produktionsklienter.

Medarbejdere eller kunder skal uploade dokumenter og billeder

Brug privat lager, afgræns typer og størrelse, kontrollér adgang til den enkelte fil, og læg risikable filer i karantæne før behandling eller deling. Teknologien kan være Firebase, Azure eller et andet objektlager.

Vælg den driftsopgave, der er relevant for jeres løsning

Emnerne er selvstændige opslag. Brug dem i den rækkefølge og kombination, som passer til jeres teknologi, risici og brugere.