Macct er ikke ISO 27001-sertifisert. Vi arbeider likevel systematisk med tekniske og organisatoriske tiltak for å beskytte regnskapsdataene kundene betror oss. Her beskriver vi hvilke tiltak som faktisk er på plass, hvilke som bare delvis er det, og hva som gjenstår.
Sist gjennomgått 19.10.2026. Grunnlaget er en intern gjennomgang av kildekode, konfigurasjon og driftslogger. Det er ikke en ekstern revisjon eller sikkerhetstest.
Daglige sikkerhetskopier i et annet datasenter, med gjenoppretting som testes hver uke. Kontrollert endringsløp med testmiljø og menneskelig godkjenning. Tilgangskontroll per selskap, sikkerhetslogg og HTTPS.
Kryptering av lagrede data, sårbarhetshåndtering for programvarebiblioteker, styring av underleverandører, hendelseshåndtering og personvernrutiner.
Et formelt styringssystem for informasjonssikkerhet, med skriftlig policy, risikovurdering og internrevisjon. Det finnes heller ingen ekstern revisjon eller sikkerhetstest.
ISO/IEC 27001 er den internasjonale standarden for styringssystemer for informasjonssikkerhet. Gjeldende utgave er fra 2022. Standarden har to deler som ofte blandes sammen.
En sertifisering betyr at et akkreditert sertifiseringsorgan har revidert at styringssystemet faktisk fungerer over tid. Den sier ikke hvilke teknologier man bruker. HTTPS, kryptering og sikkerhetskopier er viktige tiltak, men de er ikke et styringssystem.
For et regnskapsprogram betyr dette mye. Regnskapet ditt inneholder bilag, lønn, bankopplysninger og personopplysninger om ansatte. Spørsmålet er ikke bare om systemet er sikkert i dag, men om noen har oversikt over risikoene og følger dem opp systematisk.
Derfor er vi ikke sertifisert. Macct utvikles og drives av Malloc AS, et lite selskap. Vi har prioritert tekniske tiltak som beskytter dataene direkte. Det formelle styringssystemet standarden krever, med skriftlig policy, dokumentert risikovurdering, erklæring om anvendelighet, internrevisjon og ledelsens gjennomgang, er ikke på plass. Vi påstår derfor ikke at Macct oppfyller standarden, og vi har ikke satt noen dato for sertifisering.
Vi har bare tatt med tiltak vi har funnet konkrete bevis for i kildekode, konfigurasjon eller driftslogger. Under hvert tiltak står det hva som ikke er på plass.
Macct kjører hos Hetzner i Helsinki (Finland). Sikkerhetskopiene lagres i et annet datasenter i Falkenstein (Tyskland). Regnskapsdataene lagres i EU/EØS.
Bare tjenestene som må nås fra internett, er åpne. Databasen og hemmelighetslageret kan ikke nås utenfra. Administrativ tilgang til serveren krever en kryptografisk nøkkel; innlogging med passord og direkte innlogging som rotbruker er slått av. Gjentatte mistenkelige forsøk blokkeres automatisk.
Fysisk sikring av datasentrene ivaretas av Hetzner. Den har vi ikke vurdert selv.
Tofaktorinnlogging er frivillig, også for administratorer. Det er et bevisst valg: du slår den på og av selv under Sikkerhet, og ti gjenopprettingskoder dekker en mistet telefon. Vi anbefaler at alle med administratorrolle slår den på.
Alle selskaper ligger i samme database. Hvert oppslag avgrenses til selskapet den innloggede brukeren har tilgang til. I tillegg har databasen regler som hindrer at opplysninger i ett selskap kobles til et annet. Automatiske tester og kodevakter i byggeløpet kontrollerer skillet, og det kontrolleres på nytt hver uke i en gjenopprettet kopi.
Skillet håndheves av applikasjonen og av regler i databasen, ikke av en egen database per kunde. Egne gjennomganger har tidligere avdekket svakheter her, og de ble rettet. Ingen ekstern part har testet skillet.
All trafikk til macct.no går over HTTPS med automatisk fornyede sertifikater, og nettleseren blir bedt om aldri å bruke ukryptert forbindelse (HSTS). E-post fra Macct sendes kryptert til e-posttjeneren. Trafikken mellom applikasjonen og databasen går ikke over internett.
Databasekopiene krypteres før de sendes ut av driftsdatasenteret. Nøkkelen som trengs for å lese dem, finnes ikke på driftsserveren. Enkelte særlig sensitive felt krypteres i applikasjonen, blant annet hemmeligheten bak tofaktorinnloggingen og påloggingsopplysninger til tilkoblede kassesystemer.
Databasen og opplastede bilag er ikke kryptert på disknivå på selve driftsserveren. Der beskyttes de av tilgangskontroll og leverandørens fysiske sikring. Kopiene av opplastede bilag krypteres ennå ikke på samme måte som databasekopiene.
Passord og nøkler til databasen og eksterne tjenester som Altinn, bank og betaling ligger i et eget hemmelighetslager, ikke i kildekoden. Testmiljøet får ikke produksjonens nøkler.
Databasen og opplastede bilag kopieres hver dag, og kopiene sendes til et annet datasenter i et annet land. Serverleverandøren tar i tillegg daglige øyeblikksbilder av hele serveren.
En sikkerhetskopi er bare verdt noe hvis den kan gjenopprettes, så det testes automatisk hver uke. En kopi hentes fra det andre datasenteret, dekrypteres og gjenopprettes på en egen server. Deretter kontrolleres det at alle tabeller og databaseregler er med, at bilagene balanserer og at hvert selskap kan leses tilbake. I tillegg gjenopprettes en vasket kopi til testserveren hver natt.
Målene våre er at tjenesten skal være oppe igjen innen 8 timer, og at vi ikke skal miste mer enn 1 time med data. Det er mål, ikke garantier. Selve gjenopprettingen av databasen tar sekunder, og en full gjenoppretting på en annen server tar noen minutter.
Databasen og nye eller endrede vedlegg kopieres hver time, kryptert, til et annet datasenter, og hver kopi hentes tilbake og kontrolleres. Datamålet er dermed nådd.
En full ombygging på en ny server er ikke øvd ennå.
Sikkerhetsloggen registrerer innlogginger og mislykkede forsøk, nektet tilgang, nøkler som opprettes og trekkes tilbake, og når et regnskapsbyrå går inn i eller ut av et selskap. Databasen avviser endring og sletting av loggradene, og selve programmet kan ikke slå av det vernet: det har egen databasebruker uten eierrettigheter, mens tabellene eies av en egen rolle ingen logger inn som. En databaseadministrator kan fortsatt endre loggingen. Administratoren i selskapet kan lese selskapets egen sikkerhetslogg i Macct.
Bokførte bilag endres ikke i det stille. En feil rettes med en motpostering, og endringer i stamdata som kunder, leverandører, ansatte og innstillinger logges med verdien før og etter.
Operativsystemet på serverne installerer sikkerhetsoppdateringer automatisk. Applikasjonen og bibliotekene den bygger på, oppdateres gjennom det samme kontrollerte endringsløpet som alle andre endringer.
Vi har ennå ikke automatisk og systematisk skanning av programvarebibliotekene etter kjente sårbarheter.
Ingen endring går rett i produksjon. Hver endring bygges i en egen gren og prøves på en egen testserver mot en fersk kopi av databasen. Den kjøres gjennom automatiske tester mot en ekte database og legges fram som en pull request, som et menneske godkjenner. Først da setter et automatisk løp den i drift, med en selvtest etterpå; feiler den, blir forrige versjon stående. Databaseendringer prøvekjøres mot en kopi før de slippes. Detaljene står i Slik endres Macct.
Mye av utviklings- og driftsarbeidet gjøres av AI-agenter. De har tekniske sperrer: de kan ikke sette noe i drift selv og kan ikke slå sammen sine egne endringer. Det eneste unntaket er et snevert hasteløp for kritiske feil i produksjon. Det krever at en rekke automatiske kontroller er grønne, og det er stengt for alt som gjelder MVA, lønn, årsoppgjør, rapporter, regelsett og databasestruktur.
Systemet overvåkes døgnet rundt. Tilgjengeligheten måles utenfra flere ganger i timen, feil i produksjon fanges opp av automatiske vakter, regnskapsdataene avstemmes hver natt, og sertifikater og sikkerhetskopier kontrolleres daglig.
Macct er et lite selskap, og den menneskelige godkjenningen gjøres av én person. Arbeidsdelingen er derfor mer begrenset enn i en større organisasjon.
Malloc AS er behandlingsansvarlig for kontoopplysningene dine og databehandler for regnskapsdataene du legger inn. Rollene og underleverandørene står i brukervilkårene. Du kan når som helst eksportere alle data selskapet ditt har i Macct. Bilag du ber AI-funksjonene lese, sendes til leverandøren av språkmodellen for tolkning.
Testmiljøet får en vasket kopi. E-postadresser erstattes, telefonnumre fjernes, nøkler og bankkoblinger slettes, og miljøet kan ikke sende e-post.
Testkopien inneholder fortsatt regnskaps- og lønnsopplysninger, og den er derfor ikke anonym. Databehandleravtale inngås i dag på forespørsel, og vi har ikke en egen personvernerklæring utover brukervilkårene. Det finnes ingen ferdig rutine for sletting av et selskaps data etter at oppbevaringsplikten er utløpt.
Feil i produksjon fanges opp automatisk, registreres i en logg som ikke kan endres, og rettes med en sporbar endring som kan kobles til den opprinnelige feilmeldingen. Sårbarheter kan meldes til oss etter fremgangsmåten under, og adressen står i security.txt.
Vi har en skriftlig prosedyre for sikkerhetsbrudd: hvem som gjør hva, hvordan skaden begrenses, og hvordan bruddet vurderes og varsles. Som databehandler for regnskapet ditt varsler vi deg uten ugrunnet opphold, så du kan vurdere om Datatilsynet skal varsles innen 72 timer. Prosedyren ble øvd på testserveren 23.10.2026 med et lekket API-token.
Øvelsen viste at vi ikke logger hvilke data et API-token har lest, bare når det sist ble brukt. Ved et lekket token må vi derfor anta at alt tokenet ga tilgang til, er lest.
Tabellene viser hvordan tiltakene i Macct forholder seg til temaer i ISO/IEC 27001:2022. Teksten i kolonnen «Hva standarden omhandler» er vår egen oppsummering, ikke standardens ordlyd. Kartleggingen er gjort av oss selv og er ikke vurdert av et sertifiseringsorgan. At en kontroll er «på plass», betyr ikke at Macct samsvarer med standarden.
På plass = konkrete bevis for at tiltaket finnes og virker (ikke revidert av andre). Delvis = noe er på plass, men vesentlige deler mangler. Ikke på plass = mangler.
| Område | Hva standarden omhandler | Hva Macct faktisk gjør | Status |
|---|---|---|---|
| Kontekst og omfangPunkt 4 | Forstå krav og interessenter, og avgrense hva styringssystemet omfatter. | Lovkravene til regnskapsdata er kartlagt punkt for punkt, men det finnes ingen skriftlig avgrensning av et styringssystem for informasjonssikkerhet. | Ikke på plass |
| Ledelse og policyPunkt 5 | Ledelsen forplikter seg, fastsetter en sikkerhetspolicy og fordeler ansvar. | Ansvaret ligger hos ledelsen i Malloc AS, og AI-agentenes fullmakter er definert og teknisk avgrenset. Det finnes ingen skriftlig sikkerhetspolicy. | Delvis |
| RisikovurderingPunkt 6 | Fast metode for å vurdere og behandle risiko, sikkerhetsmål og erklæring om anvendelighet. | Risikoer håndteres fortløpende som saker i en prioritert arbeidsliste. Det finnes ingen dokumentert risikovurdering eller erklæring om anvendelighet. | Ikke på plass |
| Støtte og dokumentasjonPunkt 7 | Ressurser, kompetanse, bevissthet, kommunikasjon og styrt dokumentasjon. | Drifts-, gjenopprettings- og endringsprosedyrer er skrevet ned og versjonert. Det finnes ingen opplæringsplan eller formell dokumentstyring. | Delvis |
| DriftPunkt 8 | Gjennomføre tiltakene som er planlagt, og styre endringer og eksterne leveranser. | Tekniske tiltak er i drift og testes jevnlig. De er ikke knyttet til en dokumentert plan for risikobehandling. | Delvis |
| EvalueringPunkt 9 | Overvåking og måling, internrevisjon og ledelsens gjennomgang. | Omfattende teknisk overvåking og flere interne gjennomganger av sikkerheten. Det finnes ikke et fast revisjonsprogram eller en formell gjennomgang i ledelsen. | Delvis |
| ForbedringPunkt 10 | Håndtere avvik, fjerne årsaken og forbedre kontinuerlig. | Hver feil registreres, rettes med en test som beviser feilen, og gjentatte lærdommer skrives ned som faste regler. Sikkerhetsavvik har ingen egen formell behandling. | Delvis |
| Område | Hva standarden omhandler | Hva Macct faktisk gjør | Status |
|---|---|---|---|
| TilgangsstyringA.5.15, A.5.18, A.8.3 | Tilgang gis etter behov, styres gjennom hele livsløpet og avgrenses til riktig informasjon. | Roller per selskap. Byrå-tilgang kontrolleres ved hver forespørsel og kan trekkes tilbake. Hvert oppslag avgrenses til eget selskap. Det gjøres ingen faste, periodiske gjennomganger av tilganger. | Delvis |
| AutentiseringA.5.17, A.8.5 | Sikker innlogging og forsvarlig håndtering av passord og nøkler. | Passord lagres som bcrypt-hash. Kontolås og begrensning av antall forsøk. Tofaktorinnlogging er tilgjengelig, men frivillig. Nøkler lagres bare som hash. | På plass |
| Privilegert tilgangA.8.2 | Administrative rettigheter begrenses og kontrolleres særskilt. | Servertilgang krever nøkkel. Plattformadministrasjon er avgrenset i koden. AI-agentenes rettigheter er teknisk sperret. Tofaktor er frivillig, også for administratorer, og anbefales. | Delvis |
| KryptografiA.8.24 | Regler for og bruk av kryptering for å beskytte informasjon. | HTTPS og HSTS. Kryptert e-postoverføring. Databasekopier krypteres før de sendes ut. Utvalgte felt krypteres i applikasjonen. Det er ingen kryptering på disknivå og ingen skriftlige regler for kryptering. | Delvis |
| SikkerhetskopiA.8.13 | Sikkerhetskopier tas og testes etter fastsatte regler. | Daglige kopier i et annet datasenter. Gjenoppretting testes automatisk hver uke. | På plass |
| KontinuitetA.5.29, A.5.30, A.8.14 | IT-beredskap og evne til å opprettholde sikkerhet og drift under forstyrrelser. | Gjenoppretting fra et annet datasenter testes ukentlig, og nye versjoner rulles ut uten nedetid. Mål er satt (oppe igjen innen 8 timer, maks 1 time datatap) og en gjenopprettingsplan er skrevet, databasen og nye vedlegg kopieres hver time, men det finnes ingen reserveserver i drift. | Delvis |
| Logging og overvåkingA.8.15, A.8.16 | Hendelser logges, loggene beskyttes, og systemene overvåkes for avvik. | Sikkerhetslogg som databasen ikke tillater endret. Programmet selv kan ikke slå av vernet, fordi tabellene eies av en egen rolle. Ekstern måling av oppetid. Automatiske feilvakter og nattlige kontroller. | På plass |
| Vern av regnskapsmaterialeA.5.33 | Registreringer beskyttes mot tap, forfalskning og uautorisert endring. | Bokførte bilag rettes bare med motpostering, endringer i stamdata logges, og alle data kan eksporteres. | På plass |
| Sikker utvikling og testingA.8.25, A.8.29 | Sikkerhet ivaretas gjennom hele utviklingsløpet, og endringer testes før de tas i bruk. | Automatiske tester mot en ekte database og kodevakter for kjente feiltyper. Hver feilretting starter med en test som viser feilen. Det er ikke gjort ekstern sikkerhetstesting. | På plass |
| EndringsstyringA.8.32 | Endringer i systemer styres, godkjennes og kan spores. | Testserver, pull request med menneskelig godkjenning og automatisk utrulling med selvtest. Det finnes et snevert, kontrollert hasteløp for kritiske feil. | På plass |
| Atskilte miljøer og testdataA.8.31, A.8.33 | Utvikling, test og produksjon holdes atskilt, og testdata beskyttes. | Test og produksjon kjører på hver sin server med egne nøkler. Testkopien er pseudonymisert: navn, fødselsnummer, adresser, kontonumre og fritekst er byttet ut, og vedleggene er erstattet. AI-agentene kan ikke lese de uvaskede sikkerhetskopiene. Utviklingsarbeidet er ennå ikke like strengt atskilt fra driften. | Delvis |
| SårbarheterA.8.8 | Tekniske sårbarheter oppdages, vurderes og rettes i tide. | Operativsystemet installerer sikkerhetsoppdateringer automatisk. Programvarebibliotekene skannes ikke automatisk for sårbarheter. | Delvis |
| NettverkA.8.20 | Nettverk sikres og styres for å beskytte systemene. | Bare nødvendige tjenester er åpne mot internett. Databasen kan ikke nås utenfra, og gjentatte angrepsforsøk blokkeres automatisk. | På plass |
| HendelseshåndteringA.5.24–A.5.27 | Hendelser forberedes, vurderes, håndteres og brukes til læring. | Feil oppdages automatisk og rettes sporbart. Skriftlig prosedyre for sikkerhetsbrudd og varsling, øvd 23.10.2026. API-tokens lesing logges ikke per kall. | Delvis |
| Leverandører og skytjenesterA.5.19–A.5.23 | Sikkerhet ivaretas i avtaler med og oppfølging av leverandører. | Underleverandørene står på denne siden, med hva de gjør og hvor. Servere og database er i EU; AI-leverandørene er i USA. Avtalene og overføringsgrunnlaget er ikke gjennomgått systematisk. | Delvis |
| PersonvernA.5.34 | Personopplysninger vernes i tråd med regelverket. | Rollefordelingen er beskrevet, og dataene kan eksporteres. Det finnes ingen egen personvernerklæring, ingen standard databehandleravtale og ingen slette-rutine. | Delvis |
| Fysisk sikkerhetA.7 | Lokaler og utstyr beskyttes mot uautorisert tilgang og skade. | Macct har ikke egne serverlokaler. Fysisk sikring ivaretas av Hetzner, og den har vi ikke vurdert selv. | Delvis |
| Policy og uavhengig gjennomgangA.5.1, A.5.35 | Skriftlige sikkerhetsregler og jevnlig gjennomgang av en uavhengig part. | Det finnes ingen skriftlig policy for informasjonssikkerhet, og ingen uavhengig part har gått gjennom sikkerheten. | Ikke på plass |
Kontrollnumrene viser til vedlegg A i ISO/IEC 27001:2022. Tabellen er et utvalg. Kontroller vi ikke har vurdert, er ikke tatt med, og at en kontroll mangler i tabellen, er ingen påstand om at den er på plass.
Tekniske tiltak er bare en del av informasjonssikkerheten. Her er det som faktisk finnes på den organisatoriske siden, og det som ikke finnes.
Vi har med vilje utelatt tekniske detaljer som kunne hjelpe noen som vil angripe systemet.
Dette er leverandørene som behandler data for oss i driften av Macct, per 23.10.2026. Lista viser bare integrasjoner som er slått på i produksjon. Bankkobling (PSD2) gjennom Neonomics eller Finshark og kasseintegrasjonene mot Zettle og Front Systems finnes i koden, men er ikke i ordinær drift.
| Leverandør | Hva vi bruker den til | Hvilke data | Hvor |
|---|---|---|---|
| Hetzner Online GmbH | Servere, database og sikkerhetskopier | Alle data i Macct. Sikkerhetskopiene som lagres utenfor serveren, er kryptert. | Finland og Tyskland (EU) |
| Domene.no | E-post: utsending av fakturaer, lønnsslipper og varsler, og mottak av bilag på e-post | E-postene og vedleggene | Norsk leverandør |
| Anthropic | AI: kontering, lesing av bilag og bank-PDF, assistenten. Også utviklingsverktøyet vårt, som arbeider mot en pseudonymisert testkopi | Innholdet i dokumentet eller bilaget som leses, og det du skriver til assistenten | USA |
| Innlogging med Google (om du velger det), sidestatistikk uten informasjonskapsler, kartet i reiseregningen | Navn og e-post ved Google-innlogging, sidestier uten id-er, adresser du skriver i kartet | USA | |
| Stripe Payments Europe | Kortbetaling og automatisk fornyelse av abonnementet | Navn, e-post og betalingsstatus. Kortopplysningene håndteres bare av Stripe | Irland (EU) |
| Klarna Bank AB | Betaling med Klarna (via Stripe) | Det Klarna trenger for betalingen | Sverige (EU) |
| Recommand | Peppol-aksesspunkt for elektroniske fakturaer (EHF) | Fakturaene du sender og mottar via Peppol | EU |
Altinn, Maskinporten, Skatteetaten, Brønnøysundregistrene og Norges Bank mottar opplysninger når du ber om en innsending eller et oppslag. De behandler opplysningene på eget ansvar og er ikke underleverandører.
Vi har ennå ikke gått gjennom databehandleravtalene og grunnlaget for overføring til USA (Anthropic og Google) systematisk. Lista i brukervilkårene er kortere enn denne og oppdateres i neste utgave av vilkårene.
Hver feil og svakhet vi finner, enten gjennom automatiske kontroller, egne gjennomganger eller tilbakemeldinger fra kunder, havner i den samme prioriterte arbeidslisten. Den rettes gjennom det samme kontrollerte løpet som alle andre endringer, og rettingen starter med en test som viser at feilen finnes. Lærdom som går igjen, skrives ned som faste regler.
Manglene som er beskrevet på denne siden, står på den samme listen. Når et tiltak endrer status, oppdaterer vi siden. Vi lover ingen dato for sertifisering.
Har du funnet noe du mener er en sikkerhetssvakhet i Macct, skriv til firmapost@macct.no. Beskriv hva du fant, hvordan det kan gjenskapes, og hvilken side eller funksjon det gjelder. Adressen står også i security.txt (RFC 9116).
Når du undersøker: bruk bare din egen konto eller en testkonto. Ikke se på, endre eller slett andres data, ikke belast tjenesten (tjenestenekt eller massiv automatisk skanning), og ikke prøv å lure kunder eller oss til å gi fra seg opplysninger. Gi oss rimelig tid til å rette feilen før du offentliggjør den.
Vi bekrefter at vi har mottatt rapporten innen fem virkedager, vurderer hvor alvorlig den er, og retter etter alvorlighetsgrad gjennom det samme kontrollerte løpet som alle andre endringer. Vi gir deg beskjed når feilen er rettet. Vi har ingen dusørordning.
God tro: Undersøker du i god tro og innenfor rammene over — uten å se på andres data utover det som trengs for å påvise feilen, uten tjenestenekt, og med beskjed til oss straks — anmelder vi deg ikke og krever ikke erstatning for undersøkelsen.
Har du spørsmål om sikkerhet, personvern eller databehandleravtale, eller har du funnet noe du mener er en sikkerhetssvakhet? Skriv til oss på firmapost@macct.no.
Brukervilkår og personvern · Slik endres Macct · Oppfyller Macct lovkravene?