Tillid
Vi driver StandardOS på StandardOS
Den stærkeste påstand, et complianceprodukt kan komme med, er, at dem der laver det, betror det deres egen compliance. Vores ISO 27001-ledelsessystem, med afgrænsning, risici, foranstaltninger, audits og evalueringer, ligger i StandardOS selv. I stedet for at bede dig tro på et mærke står her præcis, hvordan tjenesten sikres og drives, og hvordan du kontrollerer den vigtigste del uden os.
Listen over underdatabehandlere nedenfor blev sidst ændret den 2026-09-27; alt andet på denne side kan kontrolleres via de links, den indeholder.
Infrastruktur og hosting
Oppetid
Overvåges løbende uden for vores egen infrastruktur, og resultatet er offentligt, også når det er dårligt.
Læs mere
Vi vil hellere have, at du ser en hændelse her, end at du hører om den fra os bagefter.
Hvor data ligger
Alle kundedata ligger i EU (Supabase, regionen Irland).
Læs mere
Vi vælger EU-regioner overalt, hvor tjenesten rører kundedata.
Levering
Applikationerne leveres udelukkende over TLS 1.2+, med HSTS.
Læs mere
Statiske filer via CDN; ingen kundedata i kanten.
Sikkerhedskopier
Administrerede daglige sikkerhedskopier af den primære database i samme EU-region, med automatisk alarm, hvis en planlagt kopi udebliver.
Læs mere
En ugentlig krypteret kopi ligger desuden uden for databaseleverandøren, så et svigt på den konto ikke tager alle kopier med sig.
Gendannelse
Kontrollerbar frem for påstået. Fordi jeres compliance-registreringer ligger i en hashkæde, og dagens rødder offentliggøres, kan en gendannet database holdes op mod en kopi, vi ikke råder over.
Læs mere
Det er den samme kontrol, vi giver jeres auditor. En ændret gendannelse ville ikke passe, og vi ville vide det i stedet for at antage det.
Registreringernes integritet, vores forskel
1. Manipulationssikkert revisionsspor
Hver ændring i jeres registreringer (dokumenter, risici, anvendelseserklæringen, dokumentation, afvigelser, audits, evalueringer og tildelt adgang) skrives til en log, der kun kan tilføjes til, og som ligger i en hashkæde.
Læs mere
Hver post forsegler den foregående sammen med den, der foretog ændringen, så det at omskrive historikken eller flytte ophavet bryder kæden synligt. Indloggede brugere har kun læseadgang til loggen på databaseniveau; UPDATE og DELETE er trukket tilbage på loggen, også for den servicerolle vi driver platformen med, så der findes ingen slettevej for nogen. Kæden hænges på tabel for tabel og ikke på skemaniveau: registreringerne ovenfor ligger i kæden, platformens egne driftstabeller gør ikke.
2. Forankring, mindst ugentligt
Hver nat registrerer vi hovedet af hver kæde.
De offentliggjorte daglige rødderLæs mere
Mindst ugentligt (mandag som standard; dagligt eller månedligt hvis jeres ejere vælger det) mailer vi det til organisationens ejere og administratorer, med antallet af poster tilføjet siden sidste kvittering; en uge hvor kæden ikke flyttede sig giver ingen mail. Når en kvittering ligger i jeres postkasse, ligger den på en server vi ikke driver, så en senere omskrivning ville give et hoved, der ikke længere matcher det, I allerede har. De daglige rødder offentliggøres også åbent, så enhver kan arkivere dem. Det gør manipulation ikke umulig. Det gør den synlig for den, der gemte sin mail.
3. Kontrollerbarhed
Eksporter indeholder hashene og det indhold, de er beregnet over, plus den præcise hashregel.
Specifikationen og scriptetLæs mere
Du kan genberegne hele kæden selv, i et hvilket som helst sprog, uden at StandardOS kører. Specifikationen og et afhængighedsfrit script, der gør det på omkring hundrede linjer, er offentliggjort, og det er netop det script, vores egen CI kører mod en rigtig kæde ved hvert push. Vi har ikke fundet et andet værktøj på dette marked, der lader en kunde kontrollere historikken uden at stole på leverandøren. Kender du et, så sig til, og vi retter denne side.
Adgangsstyring
Adskillelse mellem organisationer
Sikkerhed på rækkeniveau på hver tabel, håndhævet i selve databasen frem for i applikationskoden, og testet i CI (pgTAP) ved hver ændring.
Godkendelse
Login med adgangskode og moderne hashing, login via Microsoft og Google, eller single sign-on med SAML 2.0 gennem organisationens egen identitetsudbyder, som en ejer sætter op på siden Sikkerhed og kan gøre obligatorisk for alle medlemmer.
Læs mere
Sessioner er kortvarige og fornys. Enhver kan tilføje en anden faktor (TOTP) på sin egen konto, og en ejer kan kræve det: for login med adgangskode eller for alle logins uanset udbyder. Begge krav håndhæves i databasen, ikke i grænsefladen: en session, der ikke opfylder dem, ser slet ingen organisationsdata.
Vores egen adgang
Medarbejderroller med færrest mulige rettigheder.
Læs mere
Hver handling, en operatør foretager hos en kunde, skrives til et register, der kun kan tilføjes til, og som vi hverken kan redigere eller slette, og som kunden læser på sin egen side med revisionsspor under handlinger foretaget af StandardOS-personale. Hvem af vores medarbejdere der handlede, oplyses ikke, fordi det er vores ansattes personoplysninger; posten siger altså hvad der skete, hvornår, og hvad der blev ændret. Registret kan kun tilføjes til og ligger ikke i en hashkæde: kæden og dens forankringer beskytter jeres registreringer, ikke vores adgangslog, og vi siger hellere hvad der gælder hvad.
Udviklingspraksis
Ændringsstyring
Hver ændring går gennem CI: typekontrol, tests, tests af databasepolitikker og scanning for hemmeligheder ved hvert commit.
Kontrolleret uden for produktet
Hvert push bygger en rigtig hashkæde i Postgres, eksporterer den og kontrollerer den igen med det samme afhængighedsfrie script, vi offentliggør, kørt med ren Node og uden StandardOS.
Læs mere
En ændring af hashreglen, der glemte at opdatere specifikationen, får vores build til at fejle i stedet for jeres audit.
Adskillelse testet i databasen
Sikkerheden på rækkeniveau kontrolleres med pgTAP mod en kørende Postgres ved hvert push.
Læs mere
Politikkerne testes dér, hvor de håndhæves, i stedet for at blive læst igennem i applikationskoden.
Hemmeligheder
Scannes i CI og igen af en git-hook, før kode forlader en udviklingsmaskine, og hele repositoriets historik er scannet ren.
Afhængigheder
Låst og gennemgået; automatiske sårbarhedsvarsler på hele afhængighedsgrafen.
Disciplin omkring AI
AI-understøttet output i produktet er altid et tydeligt markeret udkast, indtil et menneske bekræfter det.
Læs mere
Samme regel gælder for, hvordan vi bygger.
Privatliv og databeskyttelse
GDPR
Dansk dataansvarlig. Vores databehandleraftale efter artikel 28 er offentliggjort i fuld længde på getstandardos.com/legal/dpa, for alle kunder på alle abonnementer, uden underskrift og uden salgsmøde.
Læs mere
Hvad vi behandler og hvorfor står i detaljer i privatlivspolitikken.
Ingen sporing
Ingen analyse- eller annoncesporing på dette websted; ingen cookiebanner, fordi der ikke er noget at samtykke til.
Diagnostik
E-mailadresser, IP-adresser, post-id'er, cookies og autorisationsheadere fjernes fra fejlrapporter, før de forlader vores servere.
Læs mere
Konfigureret i koden og gennemgået ved hver ændring frem for lovet i en politik.
Exit
Fuld eksport med ét klik i åbne formater når som helst: i prøveperioden, mens abonnementet løber, og 90 dage efter en opsigelse.
Læs mere
Indelåsning er ikke vores måde at fastholde kunder på.
Underdatabehandlere
Bevidst få. Ændringer varsles her med forudgående besked til kunderne. Denne liste og den i vores privatlivspolitik(på engelsk) er den samme liste, vist to gange. Senest ændret 2026-09-27.
Supabase
Database, authentication, file storage
Behandlingssted: EU (Ireland)
Vercel
Application hosting & delivery; cookieless traffic analytics (no cookies, no cross-site identifiers)
Behandlingssted: EU serving; global CDN for static assets
Sentry
Error monitoring, diagnostics only; email addresses, IP addresses and record identifiers are stripped before events leave our servers
Behandlingssted: EU region (Frankfurt)
Paddle
Merchant of record: checkout, payment, VAT & invoicing (card data never touches our servers)
Behandlingssted: UK, under the EU adequacy decision
Resend
Transactional email
Behandlingssted: EU region
Annoncerede ændringer
De er besluttet og annonceret, men endnu ikke i brug. Ingen af dem behandler data, før vi slår dem til, og denne meddelelse kommer først.
ZeroBounce
Annonceret 2026-09-27, gælder når den slås tilEmail address verification for outreach prospects: a company role address is checked for deliverability before a first letter is sent, so the sending domain is not spent on dead mailboxes and spam traps. Only the address is sent, never a name, and the answer we keep is the service's own status word
Behandlingssted: EU. ZeroBounce states it hosts its servers in the EU and that data sent for processing is transmitted, stored and processed only on servers in the EU, on its own hardware rather than a public cloud, and it offers an EU data processing addendum incorporating the Commission's standard contractual clauses (zerobounce.net/gdpr and its EU DPA, read 2026-09-27). We call the EU-only endpoint api-eu.zerobounce.net, which its documentation describes as the endpoint where validations occur only within the EU; the global endpoint is not used
Ansvarlig sårbarhedsmelding
Fundet en sårbarhed? Skriv til os på security@getstandardos.com så bekræfter vi modtagelsen inden for to hverdage.
Læs mere
Vi går ikke rettens vej mod forskning i god tro, vi holder dig orienteret undervejs, og vi krediterer dem, der ønsker det. Undgå venligst at tilgå andre organisationers data. Sikkerheden på rækkeniveau bør gøre det umuligt, og vi vil oprigtigt gerne vide det, hvis den ikke gør.
Til en sikkerhedsgennemgang
Vores databehandleraftale(på engelsk) er offentliggjort i fuld længde, så der er ikke noget at bede om. Mangler du andet til en sikkerhedsgennemgang, spørgeskemaer eller arkitekturdetaljer? Skriv til security@getstandardos.com. Besvaret inden for én hverdag af StandardOS selv, så svaret kommer fra koden og ikke fra en brochure.
Se også:Om osKontaktÆndringslogEfterprøv jeres registreringer