Kravliste for Noark 5
=====================

Last ned som tabulatorseparert liste (kan limes inn i regneark): :download:`krav.tsv <krav.tsv>`.

.. list-table:: Kravliste for Noark 5
   :header-rows: 1

   * - Krav nr.
     - Krav
     - Type
     - Merknad
   * - 2.1
     - For at en systemløsning skal være i overensstemmelse med Noark 5, må det være mulig å lage en avbildning av systemets fysiske datamodell mot standardens logiske datamodell, slik denne er beskrevet i Vedlegg 2: *Metadata gruppert på objekter*
     - O
     - Kan gjøres i forbindelse med systemdesign, eller i ettertid for system som allerede er utviklet
   * - 2.2
     - Det skal være mulig å opprette, lese, endre og slette metadata og utvalg av metadata i henhold til metadatabeskrivelsene i Vedlegg 1: *Metadatakatalog*, knyttet til arkivenheter og andre objekter i slik de er beskrevet i Vedlegg 2: *Metadata gruppert på objekter*
     - O
     - 
   * - 2.3
     - All opprettelse, lesing, endring og sletting av metadata og utvalg av metadata på arkivenheter og andre objekter skal logges i henhold til Vedlegg 3: *Logging av endringer*
     - O
     - 
   * - 2.4
     - Arkivdokumenter skal inngå i en arkivstruktur som minst inneholder følgende arkivenheter:

       arkiv, arkivdel, registrering, dokumentbeskrivelse og dokumentobjekt.
     - O
     - 
   * - 2.5
     - Journalføringspliktige saksdokumenter skal inngå i en arkivstruktur som minst skal inneholde følgende arkivenheter:

       arkiv, arkivdel, klassifikasjonssystem, klasse, mappe, registrering, dokumentbeskrivelse og dokumentobjekt.
     - O
     - Denne arkivstrukturen omtales som sakarkiv
   * - 2.6
     - For fysiske arkiv kan dokumentobjekt utgå
     - V
     - 
   * - 2.7
     - Alle arkivenheter skal kunne identifiseres entydig innenfor et arkiv.
     - O
     - 
   * - 2.8
     - Det skal være mulig å avslutte arkivenheter.
     - O
     - 
   * - 2.9
     - Det skal ikke være mulig å legge til flere underliggende arkivenheter dersom en arkivenhet er avsluttet.
     - O
     - 
   * - 2.10
     - Det skal ikke være mulig å slette arkivenheter som har aktive eller avsluttede underliggende arkivenheter.
     - O
     - 
   * - 2.11
     - Det bør være mulig å slette arkivenheter som ikke har aktive eller avsluttede underliggende arkivenheter.
     - V
     - 
   * - 2.12
     - Det bør være mulig å endre en arkivenhets tilknytning til overordnet arkivenhet
     - V
     - 
   * - 2.13
     - Det skal ikke være mulig å endre en arkivenhets tilknytning til overordnet arkivenhet dersom den har koblinger til andre arkivenheter som brytes ved endringen. Dersom dette forsøkes skal brukeren få melding om hvilke koblinger som sperrer mot endringen.
     - B
     - Obligatorisk dersom det er mulig å endre arkivenheters tilknytning til overordnet arkivenhet
   * - 2.14
     - Arkivenhetene mappe og registrering skal kunne være av forskjellig type.

       Dette er i Vedlegg 2 *Metadata gruppert på objekter* løst gjennom spesialisering, ved at spesialiseringen har egne metadata i tillegg til arkivenheten
     - O
     - 
   * - 2.15
     - Journalføringspliktige saksdokumenter skal registreres som registreringstype journalpost i en mappe av typen saksmappe
     - B
     - Obligatorisk for løsninger med journalføring
   * - 2.16
     - Det bør være mulig for spesielt autoriserte brukere å opprette egne spesialiseringer av mappe og registrering, i tillegg til spesialiseringene som er definert i Vedlegg 2: *Metadata gruppert på objekter*.
     - V
     - 
   * - 2.17
     - Det bør være mulig å definere relevante tilleggsmetadata på alle arkivenheter og tilhørende objekt, utover det som er dokumentert i Vedlegg 2: *Metadata gruppert på objekter.*
     - V
     - 
   * - 2.18
     - Arkivenheter på de øverste nivåene av arkivstrukturen (arkiv, underarkiv, arkivdel, klassifikasjonssystem og klasse) skal kun opprettes og endres av brukere som er spesielt autorisert for det.
     - O
     - 
   * - 2.19
     - Systemløsningen skal legge til rette for forvaltning og vedlikehold av ett eller flere klassifikasjonssystem
     - B
     - Obligatorisk for sakarkiv
   * - 2.20
     - Dersom det benyttes flere klassifikasjonssystem for en arkivdel, skal ett av klassifikasjonssystemene defineres som primært klassifikasjonssystem som styrer arv av skjerming og bevaring og kassasjon.
     - B
     - Obligatorisk for sakarkiv
   * - 2.21
     - Det skal være mulig for spesielt autoriserte brukere å angi regler for når dokumentfiler skal konverteres til arkivformat
     - B
     - Obligatorisk ved arkivering av dokumentfiler
   * - 2.22
     - Det skal være mulig for autoriserte brukere å angi hvilke filformater som skal brukes som arkivformater for ulike typer dokumenter
     - B
     - Obligatorisk ved arkivering av dokumentfiler
   * - 2.23
     - Det skal ikke være mulig å slette den siste, endelige versjonen av et arkivert dokument
     - B
     - Obligatorisk ved arkivering av dokumentfiler
   * - 2.24
     - Det bør være mulig for spesielt autoriserte brukere å slette inaktive versjoner, varianter og formater av arkiverte dokumenter
     - V
     - 
   * - 2.25
     - Sletting av inaktive versjoner, varianter og formater skal logges
     - B
     - Obligatorisk ved arkivering av dokumentfiler
   * - 2.26
     - Det skal være mulig å få en oversikt over hvilke filformater som er lagret i løsningen, inkludert hvilke mapper, registreringer og/eller dokumentbeskrivelser som inneholder dokumenter som ikke er lagret i arkivformat.
     - B
     - Obligatorisk ved arkivering av dokumentfiler
   * - 2.27
     - Det bør være mulig å kjøre teknisk test av filformater som er lagret i løsningen, for å avgjøre om de oppfyller krav til arkivformat
     - V
     - 
   * - 3.1
     - Det skal finnes funksjonalitet for fangst av digitale dokumenter uavhengig av filformat, metoder for teknisk koding, kilder eller andre tekniske egenskaper.
     - O
     - 
   * - 3.2
     - Ved fangst av dokumenter skal det være mulig å knytte obligatoriske metadata til dokumentet, enten ved at de følger dokumentet fra et produksjonssystem, eller ved at de registreres manuelt i etterkant.
     - O
     - 
   * - 3.3
     - Dokumentfangsten skal skje på en slik måte at innholdsintegriteten blir opprettholdt for dokument og metadata.
     - O
     - 
   * - 3.4
     - Ved fangst av tekstdokumenter bør løsningen sørge for at dokumentenes visuelle integritet blir oppretthold
     - V
     - 
   * - 3.5
     - Ved fangst av bilde-, lyd- eller videofiler bør løsningen sørge for at opprettholdelse av dokumentenes lyd- og billedintegritet
     - V
     - 
   * - 3.6
     - Etter fangst eller opprettelse av dokumenter skal løsningen legge til rette for kontrollmekanismer for endring av metadata og dokumenter i henhold til regler fastsatt av virksomheten, for eksempel at visse metadata ikke skal kunne endres etter gitte hendelser utført på en registrering eller en mappe.
     - O
     - 
   * - 3.7
     - Ved fangst av dokumenter som består av flere komponenter (meldinger med vedlegg, innebygde objekt som video eller bilde, mv.), skal løsningen sørge for at dokumentene håndteres som en enhet, hvor dokumentenes indre struktur og relasjonen mellom komponentene opprettholdes
     - B
     - Obligatori sk for løsninger som håndterer sammensatte dokumenter
   * - 3.8
     - Ved fangst av dokumenter som har tilleggsmekanismer for verifikasjon av integritetssikring (digital signatur, sjekksum, mv.), skal løsningen kunne verifisere metoden for integritetssikring og ta vare på metadata om verifikasjonen.
     - O
     - 
   * - 3.9
     - Løsningen bør legge til rette for fangst og bevaring av metadata om bruk av digital signatur (dato, tidsstempel, verifikasjon)
     - V
     - 
   * - 3.10
     - Det bør være mulig å arkivere dokumenter i forskjellige versjoner, varianter og formater
     - V
     - 
   * - 4.1
     - Løsningen skal sikre at dokumenter og tilhørende metadata er lagret bestandig og sikkert, og at de forblir tilgjengelig og kan hentes frem over tid, i tråd med definert bevaringstid
     - O
     - 
   * - 4.2
     - Det bør være mulig å definere regler for at løsningen skal generere sjekksummer eller andre mekanismer for integritetskontroll på dokumentene i løsningen.
     - V
     - 
   * - 4.3
     - Brukere som skal ha tilgang til arkivenheter, objekter og dokumenter i en Noark 5-løsning, skal identifiseres, autentiseres og autoriseres i tilstrekkelig grad før de blir gitt tilgang
     - O
     - En bruker kan være en person eller et system
   * - 4.4
     - Det bør være mulig å identifisere, autentisere og autorisere brukere via en ekstern katalog eller et eksternt system som definerer hvilke rettigheter brukeren skal ha
     - V
     - 
   * - 4.5
     - Brukere bør kunne autoriseres på grunnlag av administrativ tilhørighet
     - V
     - 
   * - 4.6
     - Løsningen skal kunne gjenkjenne hvilken administrativ sammenheng eller rolle brukeren har og opptrer i til enhver tid
     - O
     - 
   * - 4.7
     - En bruker som ikke lenger skal ha tilgang til arkivenheter, objekter og dokumenter i en Noark 5-løsning, skal fortsatt være identifisert i løsningen, men med en status som indikerer at den er passiv, som hindrer brukeren i å få tilgang til løsningen
     - O
     - 
   * - 4.8
     - Det skal finnes en oversikt over hvilket eller hvilke tidsrom hver bruker har vært aktiv
     - O
     - 
   * - 4.9
     - Det bør være mulig å endre en brukers navn uten å endre brukerens identifikasjon i løsningen.
     - V
     - 
   * - 4.10
     - All redigerings- og skrivetilgang i Noark 5-løsningen skal være basert på et “need to know” grunnprinsipp
     - O
     - 
   * - 4.11
     - Et “need to protect” grunnprinsipp kan velges for lesetilganger
     - V
     - 
   * - 4.12
     - Det skal ikke være mulig å opprette roller som opphever de generelle begrensninger som er definert i løsningen
     - O
     - 
   * - 4.13
     - Ulike kombinasjoner av funksjonelle krav som stilles til brukerens autorisasjon bør kunne settes sammen til forskjellige funksjonelle roller, som uttrykker typiske stillingskategorier eller oppgaveporteføljer i virksomheten
     - V
     - 
   * - 4.14
     - For hver funksjonell rolle bør det være mulig å definere et regelsett for prosessrelaterte rettigheter
     - V
     - 
   * - 4.15
     - Det bør være mulig å definere eller avgrense en rolles nedslagsfelt, for eksempel til angitte arkivenheter med underliggende arkivenheter, angitte organisatoriske grenser, visse typer mapper eller registreringer, gitte skjermings- eller graderingskoder, egenskaper ved registrerte parter, eller andre definerte kriterier som finnes i løsningen.
     - V
     - 
   * - 4.16
     - En bruker bør kunne ha ulike roller
     - V
     - 
   * - 4.17
     - Innenfor hver av rollene som en bruker har, bør det kunne defineres en tilgangsprofil som utgjøres av rollens funksjonelle rettigheter i kombinasjon med nedslagsfeltet for rollen
     - V
     - 
   * - 4.18
     - Det skal lagres informasjon om hvilke tilgangsrettigheter en bruker har hatt, og når de var gyldige
     - O
     - 
   * - 4.19
     - Tilgangsrettigheter for en identifisert bruker skal kunne begrenses i tid, rettighetene må kunne gjelde fra dato til dato
     - O
     - 
   * - 5.1
     - Noark 5-løsningen bør inneholde funksjonalitet som henter eller mottar dokumenter fra en angitt plassering eller et eksternt system eller en modul, og knytte disse til klasser, mapper, registreringer eller dokumentbeskrivelser.
     - V
     - 
   * - 5.2
     - Noark 5-løsningen bør kunne hente eller motta metadata knyttet til alle dokumentene som overføres, automatisk. Det bør være mulig å overstyre dette ved manglede eller feil metadata.
     - V
     - 
   * - 5.3
     - Ved import av dokumenter og metadata skal det være funksjonalitet for å validere metadata med tilhørende dokumenter automatisk, for å sikre opprettholdt dataintegritet.
     - B
     - Obligatorisk ved integrasjoner
   * - 5.4
     - Ved import skal det være mulig å importere logginformasjon om de importerte dokumentene, og logginformasjonen skal inngå i importen som eget (egne) dokument eller som virksomhetsspesifikke metadata.
     - B
     - Obligatorisk ved integrasjoner
   * - 5.5
     - Alle moduler eller systemer utenfor Noark 5-løsningen, som skal kommunisere med eller ha tilgang til objekter i Noark 5-løsningen, skal være identifisert og gjenkjennes av Noark 5-løsningen
     - B
     - Obligatorisk ved integrasjoner
   * - 5.6
     - En ekstern modul som ikke lenger skal ha tilgang til tjenester skal fortsatt være identifisert i Noark 5-løsningen, men med en status som indikerer at den er «passiv»
     - B
     - Obligatorisk ved integrasjoner
   * - 5.7
     - Det skal finnes en oversikt over hvilket eller hvilke tidsrom hver ekstern modul har vært aktiv
     - B
     - Obligatorisk ved integrasjoner
   * - 5.8
     - Det skal finnes en oversikt over hvilke arkivenheter med underliggende arkivenheter en ekstern modul har eller har hatt lesetilgang til
     - B
     - Obligatorisk ved integrasjoner
   * - 5.9
     - Det skal finnes en oversikt over hvilke arkivenheter med underliggende arkivenheter en ekstern modul har eller har hatt skrivetilgang til
     - B
     - Obligatorisk ved integrasjoner
   * - 5.10
     - For løsninger hvor Noark-kjernen skal ha en fullstendig integrasjon med fagsystemet bør Noark 5 tjenestegrensenitt brukes.
     - V
     - 
   * - 6.1
     - Det skal være mulig å søke i og gjenfinne dokumenter og metadata i løsningen
     - O
     - 
   * - 6.2
     - Det skal være mulig å søke i ulike kombinasjoner av metadata
     - O
     - 
   * - 6.3
     - Løsningen skal sørge for at sikkerhet og tilgangsrestriksjoner blir ivaretatt, slik at kun autoriserte brukere får tilgang på informasjon i henhold til definerte tilgangsrettigheter
     - O
     - 
   * - 6.4
     - Løsningen skal hente, vise og tilgjengeliggjøre dokumenter og metadata i anvendbare format
     - O
     - 
   * - 6.5
     - Løsningen bør legge til rette for at dokumenter og metadata kan gjøres tilgjengelig for søk via eksterne tjenester, plattformer, nettverk eller samhandlingsløsninger.
     - V
     - 
   * - 6.6
     - Løsningen bør legge til rette for at metadata og dokumenter som er godkjent for det, kan høstes av eller deles med eksterne tjenester og applikasjoner som åpne data.
     - V
     - 
   * - 6.7
     - Løsningen skal støtte funksjoner som gjør det mulig å kopiere eller trekke ut dokumenter og metadata til bruk i andre løsninger i eller utenfor virksomheten i henhold til regler fastsatt av virksomheten
     - O
     - 
   * - 6.8
     - Løsningen bør legge til rette for at det kan lages uttrekk av et utvalg dokumenter og metadata basert på definerte kriterier, hvor skjermet informasjon er fjernet eller skjult
     - V
     - 
   * - 6.9
     - Det skal være mulig å hente ut en rapport kalt Løpende journal, som viser en kronologisk oversikt over alle journalførte dokumenter for hver dag. Rapporten skal kunne selekteres på grunnlag av journaldato, løpenummer (intervall), journalposttype og administrativ enhet. Det bør også være mulig å hente ut rapporten basert på andre kriterier.
     - B
     - Obligatorisk for arkiv med journalføringspliktige dokumenter
   * - 6.10
     - Rapporten Løpende journal skal vise hvilken sak journalposten inngår i, med informasjon om:

       - saksnummer,
       - sakens tittel,
       - administrativ enhet,
       - saksansvarlig og
       - hvilken arkivdel saken inngår i,

       i tillegg til sakens klassifikasjon, samt at den skal vise opplysninger om journalpostens identifikasjon:

       - journalpostens løpenummer i saken,
       - journaldato,
       - dokumentets dato,
       - administrativ enhet,
       - journalposttittel, samt
       - korrespondansepartens navn og type,

       i tillegg til opplysninger om eventuell tilgangsrestriksjon”
     - B
     - Obligatorisk for arkiv med journalføringspliktige dokumenter
   * - 6.11
     - Det skal være mulig å hente ut en rapport kalt Offentlig journal, som er en versjon av Løpende journal hvor taushetsbelagte opplysninger enten er skjermet eller utelatt, og som kan tilgjengeliggjøres for allmennheten. Rapporten skal inneholde alle journalposttyper, og skal kunne selekteres på grunnlag av journaldato, administrativ enhet eller dato for når journalposten er offentlighetsvurdert. Det bør være mulig å hente ut en tilsvarende rapport basert på andre kriterier.
     - B
     - Obligatorisk for arkiv med journalføringspliktige dokumenter
   * - 6.12
     - Rapporten Offentlig journal skal vise hvilken sak journalpostene inngår i, med informasjon om:

       - saksnummer
       - sakens offentlige tittel,

       i tillegg til sakens klassifikasjon, samt at den skal vise opplysninger om journalpostens identifikasjon, som:

       - journalpostens løpenummer i saken,
       - journaldato,
       - dokumentets dato,
       - administrativ enhet,
       - dokumentets offentlige tittel, samt
       - korrespondansepartens navn (med mindre navnet skal skjermes) og korrespondanseparttype (avsender eller mottaker, mv.),
       - opplysninger om innkomne dokumenters behandlingsoppfølging,

       i tillegg til opplysninger om eventuell hjemmel for skjerming av journalopplysninger

       Det er tillatt å tilgjengeliggjøre andre opplysninger om dokumentene”
     - B
     - Obligatorisk for arkiv med journalføringspliktige dokumenter
   * - 6.13
     - For en part som krever innsyn etter forvaltningsloven skal det kunne gis utskrift av alle metadata og dokumenter i den bestemte saken. Opplysninger skal vises selv om de er påført tilgangskoder
     - B
     - Obligatorisk for arkiv med partsinformasjon etter forvaltningsloven
   * - 6.14
     - For en person som krever innsyn etter personopplysningsloven skal det kunne gis utskrift av alle metadata om de saker hvor vedkommende er part i saken, og de registreringer med tilhørende dokumenter og merknader der vedkommende selv er avsender eller mottaker. Eventuelle skjermede opplysninger om andre parter i saken skal skjermes i utskriften
     - B
     - Obligatorisk for arkiv med personopplysninger
   * - 7.1
     - Det bør være mulig å knytte arbeidsflyter til registreringer, for eksempel godkjenningsflyter på egenproduserte registreringer.
     - V
     - 
   * - 7.2
     - Metadata om arbeidsflyter skal normalt bevares
     - B
     - Obligatorisk ved bruk av arbeidsflyter
   * - 7.3
     - Det bør være mulig å knytte definerte oppgaver til visse typer registreringer, for eksempel at innkomne dokumenter eller visse typer organinterne dokumenter skal settes i restanse.
     - V
     - 
   * - 7.4
     - Det bør være mulig å få en oversikt over restanser og andre ventende oppgaver i løsningen, for eksempel en restanseliste eller en forfallsliste for enkelte brukere eller enheter
     - V
     - 
   * - 7.5
     - Det bør finnes funksjoner får å markere en oppgave som utført, for eksempel ved å avskrive en restanse
     - V
     - 
   * - 7.6
     - Metadata om gjennomføring av oppgaver, for eksempel avskrivning av restanse, skal normalt bevares
     - B
     - Obligatorisk ved funksjoner for oppgaver eller restanseoppfølging
   * - 7.7
     - Det bør være mulig å knytte merknader, nøkkelord og referanser til arkivenheter
     - V
     - 
   * - 7.8
     - Det bør være mulig å opprette en presedens knyttet til en sak eller en journalpost
     - V
     - 
   * - 7.9
     - Det bør være mulig å opprette et register over hvilke verdier man skal kunne velge presedenshjemmel fra
     - V
     - 
   * - 7.10
     - Det skal ikke være mulig å slette eller kassere en presedens, selv om presedensen er foreldet, eller klassen som presedensen tilhører skal kasseres
     - B
     - Obligatorisk ved registrering av presedens
   * - 8.1
     - Løsningen skal ha funksjoner for å registrere metadata om bevaringstid og bevarings- eller kassasjonsvedtak på arkivenheter.

       Vedtaket fastsetter hva som skal skje med dokumentene knyttet til arkivenheten når bevaringstiden opphører. Kassasjonsvedtaket kan si at dokumentene enten skal bevares, kasseres eller at de skal vurderes senere.
     - O
     - 
   * - 8.2
     - Det bør være mulig å definere regler som automatisk knytter bevaringstid og kassasjonsvedtak til en type arkivenhet, en bestemt spesialisering av en arkivenhet, eller en bestemt type av en spesialisering av en arkivenhet.
     - V
     - 
   * - 8.3
     - Bevaringstid og kassasjonskode skal arves til underliggende arkivenheter ned til dokumentbeskrivelse. Det skal være mulig å overstyre arv.
     - O
     - 
   * - 8.4
     - Løsningen bør legge til rette for at autoriserte brukere kan definere regler for fastsetting av kassasjonsdato på grunnlag av oppbevaringstid. For eksempel kan oppbevaringstid beregnes fra:

       - Dato for opprettelse av arkivenhet
       - Avslutning av arkivenhet
       - Dato for siste bruk av arkivenhet
       - Dato for definerte hendelser, som

       klientens fødsel eller dødsfall, ødeleggelse av et objekt (f.eks. bygning, skip), eller andre hendelser som kan forutsette virksomhetsspesifikt datofelt
     - V
     - 
   * - 8.5
     - Løsningen bør legge til rette for at definerte brukere får varsling når oppbevaringstiden nærmer seg, med oversikt over arkivenheter som skal kasseres eller vurderes senere.
     - V
     - 
   * - 8.6
     - Løsningen skal ha funksjoner for å gjennomføre kassasjon av de dokumenter som har passert kassasjonsdato. Det skal være mulig å velge delmengder av dokumenter når kassasjon skal gjennomføres.
     - O
     - 
   * - 8.7
     - Bare autoriserte brukere skal kunne gjennomføre kassasjon.
     - O
     - 
   * - 8.8
     - Kassasjon innebærer sletting av arkivenheten dokumentobjekt. I tillegg skal dokumentfila som arkivenheten har referanse til slettes, med mindre den er knyttet til andre arkivenheter som skal bevares. Metadata på overliggende arkivenheter skal i som hovedregel bevares. Arkivenheten dokumentbeskrivelse skal ha metadata om utført kassasjon.
     - O
     - 
   * - 8.9
     - Det skal være mulig å lage en kassasjonsliste på grunnlag av kassasjonsdato, kassasjonsvedtak og administrativ enhet.

       Kassasjonslisten skal gi en oversikt over arkivenheter, med identifikasjon og tittel for arkivenheten, administrativ tilhørighet og eventuell klassifikasjon, samt kassasjonsvedtak og kassasjonsdato.
     - O
     - 
   * - 8.10
     - Løsningen skal legge til rette for at det er mulig å sette kontrollerte tidsskiller i arkiv. Det innebærer at autoriserte brukere kan definere regler for hvordan mapper og registreringer skal opprettes og avsluttes i overgangen mellom to arkivperioder. Avsluttede og uaktuelle mapper og registreringer skal kunne skilles ut fra aktive til avsluttede arkivdeler, slik at de kan klargjøres for eksport, enten som migrering, overføring, avlevering eller andre former for datauttrekk.
     - O
     - 
   * - 8.11
     - Løsningen skal legge til rette for eksport av metadata med tilhørende dokumenter for:

       - migrering til andre løsninger for videre forvaltning av dokumentasjonen internt i virksomheten,
       - overføring til løsninger i andre virksomheter som skal overta dokumentasjonen,
       - datauttrekk i systemuavhengige format som støtter bevaring utover systemets levetid, for eksempel basert på avleveringsformatet.
     - O
     - 
   * - 8.12
     - Løsningen skal sikre at et datauttrekk for eksport:

       - er komplett, dvs. inneholder alle arkivenheter og dokumenter som skal være med,
       - inneholder alle obligatoriske og andre relevante metadata for arkivenhetene, inkludert metadata om godkjenningsflyter eller arbeidsflyter, samt virksomhetsspesifikke metadata ved behov
       - inneholder arkivenhetenes loggemetadata og løsningens endringslogg.
     - O
     - 
   * - 8.13
     - Datauttrekk for eksport skal skje på en slik måte at

       - innhold og struktur på dokumenter og metadata ikke medfører utilsiktet svekkelse av dokumentasjonens tilsiktede egenskaper, inkludert dens dokumentasjons- og informasjonsverdi,
       - koblingen mellom dokumenter og metadata opprettholdes, og at
       - koblinger opprettholdes mellom ulike komponenter i et dokument, mellom ulike dokumenter, og mellom ulike sammenstillinger av dokumenter, slik at logisk struktur kan gjenopprettes i mottakende løsning
     - O
     - 
   * - 8.14
     - Det skal være mulig å teste og verifisere at eksporten ikke har svekket dokumentenes og metadataenes integritet, og at datauttrekket ikke mangler obligatoriske og andre nødvendige metadata i henhold til standarden og/eller øvrige juridiske krav og behov.
     - O
     - 
   * - 8.15
     - Et datauttrekk som skal inngå i en avleveringspakke kalles et arkivuttrekk, og skal inneholde følgende filer:

       - addml.xml (dokumentasjon av innholdet i arkivuttrekket)
       - arkivstruktur.xml (metadata om dokumentene)
       - endringslogg.xml (logging av endrede metadata)

       Dersom avleveringspakken inneholder arkivuttrekk med journalføringspliktig informasjon, skal den i tillegg inneholde følgende filer:

       - loependeJournal.xml
       - offentligJournal.xml

       XML-skjemaene til alle XML-filer i avleveringspakken skal også være inkludert. Dokumentene skal ligge i en underkatalog kalt DOKUMENT. Denne katalogen kan struktureres i nye underkataloger etter fritt valg.
     - O
     - 
   * - 8.16
     - XML-filene i arkivuttrekket skal valideres mot medfølgende XML-skjema på følgende måte:

       - addml.xml valideres mot addml.xsd
       - arkivstruktur.xml valideres mot arkivstruktur.xsd og metadatakatalog.xsd
       - endringslogg.xml valideres mot endringslogg.xsd og metadatakatalog.xsd
       - loependeJournal.xml valideres mot loependeJournal.xsd og metadatakatalog.xsd
       - offentligJournal.xml valideres mot offentligJournal.xsd og metadatakatalog.xsd

       For virksomhetsspesifikke metadata skal det medfølge egne XML-skjemaer.
     - O
     - 
   * - 8.17
     - XML-skjemaene skal følge XML skjema-standarden XML Schema 1.0.
     - O
     - 
   * - 8.18
     - Et arkivuttrekk skal omfatte en avtalt arkivperiode, og bestå av innholdet i en eller flere arkivdeler og alle underliggende arkivenheter
     - O
     - 
   * - 8.19
     - Alle metadataelementer som er merket med “A” i kolonnen “Avl.” i Vedlegg 2 Metadata gruppert på objekter skal være med i arkivuttrekket, såfremt de er tilordnet verdier.
     - O
     - 
   * - 8.20
     - Metadataelementer som ikke har verdi, skal ikke være med i uttrekket. Det skal ikke forekomme tomme elementer med kun start- og slutt-tagg, og det skal ikke legges inn dummyverdier.
     - O
     - 
   * - 8.21
     - Dokumentfilene i arkivuttrekket skal være i avtalt filformat.
     - O
     - 
   * - 8.22
     - For arkivuttrekk fra Noark 5-løsninger skal addml.xml inneholde (med navn i addml.xml i parentes):

       - Arkivskapernavn (recordCreator)
       - Navn på systemet/løsningen (systemName)
       - Navn på arkivet (Archive)
       - Start- og sluttdato for arkivuttrekket (archivalPeriod – startDate og archivalPeriod endDate)
       - Hvilken type periodisering som er utført i forrige periode og denne periode (periode – inngaaendeSkille og periode – utgaaendeSkille)
       - Opplysning om det finnes skjermet informasjon i uttrekket (inneholderSkjermetInformasjon)
       - Opplysning om uttrekket omfatter dokumenter som er kassert (omfatterDokumenterSomErKassert)
       - Opplysning om uttrekket inneholder dokumenter som skal kasseres på et senere tidspunkt (inneholderDokumenterSomSkalKasseres)
       - Opplysning om det finnes virksomhetsspesifikke metadata i arkivstruktur.xml (inneholderVirksomhetsspesifikkeMetadata)
       - Antall mapper i arkivstruktur.xml (numberOfOccurrences – mappe)
       - Antall registreringer i arkivstruktur.xml, loependeJournal.xml og offentligJournal.xml (numberOfOccurrences – registrering)
       - Antall dokumentfiler i uttrekket (antallDokumentfiler)
       - Sjekksummer for alle XML-filer og XML-skjemaer i arkivuttrekket, unnttatt addml.xml og addml.xsd (checksum)
     - O
     -