> For the complete documentation index, see [llms.txt](https://docs.cerrix.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.cerrix.com/cerrix-documentation-no/beste-praksiser-og-guider/how-cerrix-apis-fit-into-your-grc-architecture.md). # Hvordan CERRIX-API-er passer inn i GRC-arkitekturen din CERRIX er utformet som en **modulær og åpen GRC-plattform** som integreres sømløst i organisasjonens eksisterende IT-, risiko-, finans- og revisjonslandskap. De fleste organisasjoner bruker allerede dusinvis av systemer som inneholder relevante data om styring, risiko og etterlevelse: IT-tjenestehåndtering, økonomi, HR, identitet, leverandørplattformer, overvåkingsverktøy og revisjonsprogramvare. For å etablere effektiv, sporbar og skalerbar GRC må disse dataene utveksles på en **sikker, strukturert og automatisert** måte. CERRIX bruker API-er på tvers av alle kjerne-moduler for å gjøre dette mulig. Disse API-ene gjør det mulig for CERRIX å fungere som **det sentrale registreringssystemet for GRC**, mens data fortsatt flyter mellom operative systemer, rapporteringsverktøy, revisorer og regulatorer. ## Hva CERRIX API-er brukes til CERRIX API-er støtter et bredt spekter av GRC-brukstilfeller. Sammen muliggjør de automatisering, datakonsistens og løpende bekreftelse gjennom hele GRC-livssyklusen. ### Datauttrekk for rapportering og analyse CERRIX tilbyr API-er på tvers av alle kjerne-moduler, inkludert: * Risikoer * Kontroller, oppgaver og tester * Forbedringstiltak * Avvik * Tredjepart Disse API-ene gjør det mulig for organisasjoner å hente ut data til eksterne systemer som for eksempel: * Business intelligence-verktøy * Datalagre * Revisjons- og bekreftelsesverktøy Dette gjør at CERRIX kan fungere som **én sannhetskilde for GRC-data**, mens rapportering og analyse kan utføres i organisasjonens foretrukne verktøy. I tillegg til modulspecifikke API-er tilbyr CERRIX kombinerte API-er som henter data fra flere moduler i én forespørsel. For eksempel: * Risikoer, kontroller og forbedringstiltak i forhold til hverandre * Avvik knyttet til underliggende risikoer og kontroller Dette støtter integrert rapportering og gjør det enklere å vise hvordan risikoer, kontroller og oppfølgingshandlinger henger sammen. Alle API-er for rapportering og uttrekk bruker **GET** forespørsler. ### Brukerklargjøring og tilgangsstyring (SCIM) CERRIX støtter automatisert brukerklargjøring og autorisasjonsadministrasjon gjennom **SCIM** integrasjoner med identitetsplattformer for virksomheter. Dette gjør det mulig for organisasjoner å: * Opprette og oppdatere brukere automatisk * Tilordne riktige profiler og roller * Håndheve prosesser for innrullering, flytting og avgang Bruk av SCIM reduserer manuell administrasjon betydelig, minimerer risikoen for feil tilgang og styrker revisjonssporbarheten i brukerhåndteringen. ### Kontrollsikring gjennom automatisering CERRIX støtter både automatisert kontrolltesting og kontinuerlig kontrollovervåking gjennom API-er. #### Automatisert kontrolltesting For kvantitative kontroller kan CERRIX selv generere testutvalg fra en definert populasjon. API-er brukes til å automatisere denne arbeidsflyten: * Populasjonen leveres gjennom en integrasjon * CERRIX genererer et utvalg * De valgte elementene returneres til kildesystemet * Dokumentasjon hentes og lagres automatisk i CERRIX Dette fjerner manuell utvalgsinnsamling, reduserer administrativt arbeid og sikrer at testingen er objektiv, reproducerbar og fullt revisjonssporbar. Begge **GET** og **POST** API-er brukes i denne prosessen. #### Kontinuerlig kontrollovervåking For kvantitative kontroller kan CERRIX selv generere testutvalg fra en definert populasjon. API-er brukes til å automatisere denne arbeidsflyten: * Populasjonen leveres gjennom en integrasjon * CERRIX genererer et utvalg * De valgte elementene returneres til kildesystemet * Dokumentasjon hentes og lagres automatisk i CERRIX Dette fjerner manuell utvalgsinnsamling, reduserer administrativt arbeid og sikrer at testingen er objektiv, reproducerbar og fullt revisjonssporbar. Begge **GET** og **POST** API-er brukes i denne prosessen. ### Tredjeparts- og ekstern revisjonssikring CERRIX støtter eksterne revisorer gjennom API-basert Tredjepartssikring. Ved bruk av API-er kan et eksternt revisjonsselskap sikkert koble verktøyene sine til kundens CERRIX-miljø og få tilgang til: * Risikoer * Kontroll * Testresultater * Forbedringstiltak Dette fjerner behovet for manuelle forberedelsestrinn som: * Levering av kontrolloversikter * Sammenstilling av revisjonsbevis * Tilpasse omfang og definisjoner Resultatet er at revisjoner blir raskere, mer konsistente og mer pålitelige. Disse integrasjonene bruker hovedsakelig **POST** API-er. Du kan lese mer om eksterne tilkoblinger for Tredjepartssikring her: [Eksterne tilkoblinger](/cerrix-documentation-no/cerrix-funksjoner/admin-settings/external-connections.md) ### Automatisert datainnsamling for KRI-er og KPI-er CERRIX inkluderer en KRI- og KPI-modul for overvåking av risikoindikatorer og ytelsesindikatorer mot terskler og risikovilje. Dataene som kreves for disse indikatorene, kommer ofte fra flere kildesystemer, som for eksempel: * IT-tjenestehåndtering * Økonomi * HR * Sikkerhetsverktøy Via API-er kan disse dataene leveres automatisk til CERRIX, noe som muliggjør: * Kontinuerlige oppdateringer av KRI-er og KPI-er * Nær sanntidsinnsyn i avvik * Eliminering av manuelle registreringsfeil Dette støtter datadrevet risikostyring og tidsriktig eskalering. Disse integrasjonene bruker **POST** API-er. ### Avviks- og varslingsrapportering I CERRIX Forms-modulen er API-er tilgjengelige for å sende skjemadata direkte fra eksterne systemer. Dette muliggjør brukstilfeller som: * Automatisk registrering av IT-avvik med høyeste prioritet fra et ITSM-verktøy * Sikker mottak av anonyme varslingsmeldinger fra eksterne rapporteringskanaler Ved å motta disse rapportene via API-er kan CERRIX umiddelbart: * Registrere avviket * Knytte det til relevante risikoer og kontroller * Utløse oppfølgingshandlinger Disse integrasjonene bruker **POST** API-er. ### Tredjeparts risikostyring og leverandørdata CERRIX støtter registrering og overvåking av leverandører, med særlig fokus på kritiske og outsourcede tredjepartsaktører. Mange organisasjoner vedlikeholder allerede leverandørdata i dedikerte leverandørstyringssystemer. Fra Q1 2026 vil CERRIX støtte synkronisering av leverandørdata via API-er, noe som muliggjør: * én sannhetskilde for leverandørinformasjon * Automatisert overvåking av leverandørrisikoer og -kontroller * Oppdaterte og konsistente leverandørdata Dette støtter regulatoriske krav som **DORA, NIS2 og utkontrakteringsregler**. Disse integrasjonene bruker **POST** API-er. ## Rapportering på tvers av objekter: bygging av en risiko–kontroll-matrise Et vanlig rapporteringsbehov er én samlet oversikt som kombinerer risikoer, deres tilknyttede kontroller og resultater fra kontrolltesting — for eksempel for å erstatte en regnearkbasert risiko-kontroll-matrise, eller for å svare på en regulatorisk spørreundersøkelse. CERRIX tilbyr ikke én innebygd rapport eller Workspace-forhåndsinnstilling som samler alt dette i én eksport: Workspace-eksporter er organisert per objekttype. Det finnes imidlertid flere støttede måter å bygge denne visningen på. ### Bruk den kombinerte risiko-API-en Endepunktet `GET /riskdata/v1/riskassessmentperorganization` returnerer organisasjonene dine med alle tilknyttede risikoer, og for hver risiko vurderingsinformasjonen samt tilknyttede kontroller, hendelser og MoI-er — i én forespørsel. Du kan filtrere svaret etter organisasjon, eller utelate filteret for å hente alle risikoer du har tilgang til. Dette gjør det til det naturlige utgangspunktet for rapportering «fra risikoperspektivet», inkludert elementer som er knyttet gjennom andre objekter. ### Bygg din egen rapport på API-ene Hent data inn i ditt eget Power BI-miljø (eller Power Query i Excel) ved å bruke CERRIX API-ene, og modeller rapporten der. DirectData API-ene beskrevet tidligere på denne siden eksponerer de underliggende enhetene, mens de kombinerte API-ene allerede relaterer dem for deg. ### Kombiner Workspace-eksporter med oppslag Lag flere eksporter fra CERRIX og koble dem sammen med formler som VLOOKUP eller med Power Query. For eksempel kan du eksportere Kontroller-Workspace som din primære tabell og koble Risiko-eksporten til den, ved å matche på de delte identifikatorene — den samme koblingsmetoden fungerer også for å legge til testinformasjon. ### Innebygd Power BI-rapport bygget av CERRIX CERRIX kan bygge og vedlikeholde en innebygd Power BI-rapport i ditt eget CERRIX-miljø, som kombinerer risikoer med tilknyttede kontroller og testresultater i ett dashboard. Se [Rapportering (innebygd Power BI)](/cerrix-documentation-no/cerrix-funksjoner/module-overview/reporting-embedded-power-bi.md) for hva disse rapportene dekker, og kontakt CERRIX-support via servicedesken for å diskutere behovene dine. ## Tekniske prinsipper ### REST-basert arkitektur Alle CERRIX API-er er implementert som **REST API-er** ved bruk av standard webteknologier. Dette sikrer at integrasjonene er: * Lettvekts * Skalerbare * Sikre * Enkle å implementere med eksisterende IT-verktøy Denne tilnærmingen passer naturlig inn i moderne virksomhetsarkitekturer. ### Ingen forespørselsbegrensning CERRIX API-er er utviklet for bruk i virksomhetsklassen. Ingen forespørselsbegrensning er aktivert, noe som gjør det mulig for organisasjoner å: * Kjøre kontinuerlige synkroniseringer * Utføre rapportering og eksport i stor skala * Støtte automatisering og revisjon i høyt volum Dette gjør API-ene egnet for både operative og analytiske brukstilfeller. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.cerrix.com/cerrix-documentation-no/beste-praksiser-og-guider/how-cerrix-apis-fit-into-your-grc-architecture.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.