Folkekirkens It s arkitekturprincipper

Relaterede dokumenter
Arkitekturprincipper for Kirkenettet - Bilag 2 til It-Strategi

IT-ARKITEKTURPRINCIPPER 2018

ATP s digitaliseringsstrategi

NOTAT. ITafdelingen. IT og sikkerhedsmæssige udbudskrav ved indkøb af fagsystemer

Hillerød Kommune. It-sikkerhedspolitik Bilag 9. Udvikling, anskaffelse og vedligeholdelse

Oversigt over kriterier for klarmelding af bølge 2-løsninger i 2013

It-principper. Bilag 1 til It- og Digitaliseringsstrategi for Sønderborg Kommune

Dnr FOLKEKIRKENS IT HANDLINGSPLAN V FEBRUAR 2017

Vejman.dk mobile løsninger. Ved. Paul Stühler

Strategi Danmarks Miljøportal

FULD DIGITAL KOMMUNIKATION I 2015

Roadmap for VERA Q Q Q Q Rettighed. Klassifikation. Organisation. Beskedfordeler. Serviceplatform

Brug af digitale medier

Den samlede erhvervsløsning i næste generation af NemID og NemLog-in3

Arkitekturprincipper. Kirkenettet

Løsningsbeskrivelse. Den fælleskommunale Serviceplatform

Velkommen til Virk.dk

360 eworker. App en, der gør det endnu lettere at arbejde i Arbejd med sagsbehandlingsopgaver, dokumenter og information fra din ipad

Kravspecifikation tværga ende sundhedsplatform

It-arkitekturprincipper. Version 1.0, april 2009

Velfærd gennem digitalisering

Arkitekturprincipper for Sundhedsområdet

Indhold. Grundmodul. Tillægsmoduler. Teknologisk opbygning og indhold. Mulighed for udbygning. Forretningsmæssig funktionalitet

Understøttelse af LSS til NemID i organisationen

Velkomst og dagens formål Stine Hegelund, kontorchef, Digitaliseringsstyrelsen, præsenterede dagens program.

IT-sikkerhedspolitik S i d e 1 9

F remtidens Digital Post

It-delstrategi for administrativ it-anvendelse

Notat om Single sign-on for kliniske brugere af telemedicinsk sårvurdering i det nationale projekt for udbredelse af telemedicinsk sårvurdering

Det sikre kommunikationsknudepunkt for tandlægeinformation. Nem og sikker elektronisk kommunikation på tværs af sundhedsvæsenet

KRAVSPECIFIKATION. Kravspecifikation - blanketsystem. januar DATO 2. januar 2014 SAGS NR Kon takt.

Aftale om digitaliseringsklar lovgivning

Overordnet Informationssikkerhedsstrategi. for Odder Kommune

Bilag 1: Teknisk dialogmøde for udformningen af Digital Post

Ringkøbing-Skjern Kommune. Informationssikkerhedspolitik

Overordnet Informationssikkerhedspolitik

OS2faktor. Brugervejledning. Version: Date: Author: BSG

Integration SF1920 NemLogin / Digital fuldmagt Integrationsbeskrivelse - version 1.0.0

Hillerød Kommunes Kanalstrategi

Præsentation af Curanets sikringsmiljø

DEN FÆLLESKOMMUNALE RAMMEARKITEKTUR

Programbeskrivelse - Sammenhængende Digital Borgerservice. 1. Formål og baggrund NOTAT

DIGITALISERINGSSTRATEGI April 2016 BRØNDBY KOMMUNE

Overordnet informationssikkerhedsstrategi

IT-SIKKERHEDSPOLITIK UDKAST

Privatlivs og Persondatapolitik for Evangelisk Luthersk Netværk

Minikonference om Sag og Dokumentstandarder 15. juni 2011, Odense

Serviceaftale. Serviceaftale vedr. digitale løsninger. mellem. CompanYoung ApS. Vestre Havnepromenade 1B, 3. Sal, 9000 Aalborg. CVR-nr.

D e n fælleskommunale digit a- l i s e r i ngsstrategi

Fredericia Kommunes Informationssikkerhedspolitik 1 FREDERICIA KOMMUNE AFDELING TITEL PÅ POWERPOINT

Skaber nemt og hurtigt overblik over data fra automatiserede anlæg

RX WEB. online og fleksibel adgangskontrol

Præsentation af Aula. Juni 2018

Databeskyttelsespolitik for DSI Midgård

UNDGÅ DÅRLIGE IT-LØSNINGER

It arkitektur- og sikkerhedskrav Løn og personalesystemsudbud. Region Midtjylland 2010.

IT- og informationssikkerheds- politik (GDPR) For. Kontrapunkt Group

Den fællesoffentlige digitaliseringsstrategi Oplæg Ved Charlotte Münter, Direktør, Digitaliseringsstyrelsen

IT-arkitekturstyring i Syddjurs Kommune

Introduktion til ændringerne ifm. overgangen til MitID og NemLog-in3

EasyIQ ConnectAnywhere Release note

Bilag 5: Kundens It-Miljø. Version 0.6 Bilag til dagsordenspunkt 9: Krav til kommunernes it-miljø.

For at en virksomheds hovedformål og drift kan fungere optimalt, er der en lang række af underliggende servicefunktioner der skal være på plads.

Ringkøbing-Skjern Kommune. Informationssikkerhedspolitik

WHITEPAPER DokumentBroker

Vi har etableret et brancheledende informationssikkerhedsprogram. vores kunder den bedste beskyttelse og højeste grad af tillid.

Guide til kravspecifikation

STRATEGIENS SAMMENHÆNG

Interessentforum for næste generation NemID

Aalborg Kommune IT-arkitetkur i Aalborg - maal

Overordnet It-sikkerhedspolitik

Hjørring Kommune. Overordnet I-sikkerhedspolitik for Hjørring Kommune

Bilag 6: Servicemål. Udbud af løn- og personalesystem. Side 1 af 9

Beslutningsstøtte i bløderbehandlingen Arkitektur: Slutprodukter i fase 3

Vejledning om Digitaliseringsklar Lovgivning

Privatlivspolitik. 1. Dataansvarlig. 2. Hvordan indsamler vi personoplysninger?

BILAG 14 TIL KONTRAKT OM EPJ/PAS IT-SIKKERHED OG DATABEHANDLERAFTALE

ReportLoq Miljørapportering: når du vil, hvor du vil

Til høringsparterne Se vedlagte liste

Kravspecification IdP løsning

1.3.c. Hjælp at hente: Afprøvning af fælles telefonsupport på obligatorisk selvbetjening

Kulturministeriets it-arkitekturpolitik

Bilag 6: Servicemål. Udbud af E-rekrutteringssystem. Side 1 af 9

Effektiv sagsbehandling og hurtig borgerservice

Rigsrevisionens notat om beretning om brugervenlighed og brugerinddragelse. digitale løsninger

Arkitekturrapport: MDB Min Digitale Byggesag

Principper for digitalisering og ny teknologi i Brønderslev Kommune

It-anvendelsen i Langeland Kommune har til formål at understøtte kommunens overordnede visioner.

Intro til Client Management

Organisering og styring af informationssikkerhed. I Odder Kommune

OPTION TIL RM OG RN BILAG 14 TIL KONTRAKT OM EPJ/PAS IT-SIKKERHED OG DATABEHANDLERAFTALE

Arbejdsgruppen peger endvidere på, at der er særlig behov for yderligere at analysere arbejdet med faglig progression og it-understøttelsen heraf.

Peter Thrane Enterprisearkitekt KL+KOMBIT. Den fælleskommunale Rammearkitektur - Inspiration

Ved aftaleindgåelse drøftes de konkrete behov for specificering af app en med afsæt i nedenstående.

White paper IMS DigitalPost IMS A/S Oktober Ansvarlig Henrik Rabæk Poulsen IMS A/S Åbogade 25A 8200 Aarhus N

CLOUD COMPUTING VEJLEDNING I STORT OG SMÅT NÅR DU OVERVEJER AT GÅ I SKYEN

FÆLLESKOMMUNALE ARKITEKTURMÅL, -PRINCIPPER OG -REGLER

Bedre brugeroplevelser! Hvad gør Erhvervsstyrelsen i Danmark? Altinndagen 1.december 2014

Overordnet organisering af personoplysninger

AFSKAF PASSWORDS. - lige så nemt som det lyder.

Transkript:

Folkekirkens It s arkitekturprincipper Arkitekturprincipperne består af 11 principper, som skal anvendes ved alle nyanskaffelser og større ændringer af eksisterende it systemer. Arkitekturprincipperne skal sikre, at ændringer og nyanskaffelser sker i henhold til den fælles it arkitektur, så der sikres en fælles ramme for alle it tiltag. Principperne skal anvendes ud fra et følg eller forklar princip. I udgangspunktet skal alle tiltag leve op til de krav som de enkelte principper stiller, med mindre der er klare behov for at afvige. I så fald skal det klart beskrives hvordan der afviges fra principperne, og hvad de positive og negative konsekvenser ved dette vil være. Afvigelserne skal godkendes af de ansvarlige for det konkrete tiltag. 1. BEHOV FOR IT UNDERSTØTTELSE VURDERES I FORHOLD TIL EKSISTERENDE SYSTEMER... 2 2. ANVEND STANDARDSYSTEMER OG PLATFORME... 3 3. UDNYT DEN FÆLLESOFFENTLIGE INFRASTRUKTUR... 4 4. DEN ANVENDTE SIKKERHEDSMODEL TILPASSES DATAS KATEGORISERING... 5 5. ALTID FOKUS PÅ DATASIKKERHED... 7 6. ANVEND FÆLLES DATAMODEL... 9 7. FOKUS PÅ BRUGERVENLIGHED... 10 8. UNDERSTØT PLATFORMSUAFGÆNGIGHED... 11 9. MAKSIMAL ÅBENHED I APPLIKATIONERNE... 12 10. FÆLLES SINGLE SIGN ON OG BRUGERADMINISTRATION... 13 11. PERFORMANCEKRAV TIL ALLE SERVICES OG APPLIKATIONER... 14

1. BEHOV FOR IT UNDERSTØTTELSE VURDERES I FORHOLD TIL EKSISTERENDE SYSTEMER Ved behov for ny eller forbedret it understøttelse vurderes dette altid i forhold de eksisterende centrale og lokale it løsningers funktionalitet, brugerflader og integrationsmuligheder. Vi ønsker at udnytte de it løsninger vi har mest muligt, fremfor at købe nyt. Samtidig ønsker vi at sikre størst mulig genanvendelighed i de nye løsninger, for løbende at skabe et fleksibelt, sammenhængende og ensartet miljø. Dette muliggør, at Folkekirkens og ministeriets opgaver i stadig stigende grad kan løses mere sammenhængende og samtidig lette drift, administration og vedligehold af løsningerne. Ved identifikationen af nye eller ændrede behov vurderes: Hvilken funktionalitet der ønskes til at imødekomme behovet? I hvilken grad funktionaliteten eller dele af funktionaliteten findes i de eksisterende applikationer og services? Det tilstræbes at nye løsninger er opbygget i moduler da dette giver mindre kompleksitet. Modulopbygning letter testarbejdet ved ændringer da der ikke er så stor afhængighed til den samlede løsning. Ved udarbejdelse af projektoplæg skal det beskrives hvilken funktionalitet der findes i eksisterende moduler. Hvis der sker genanvendelse af eksisterende moduler, bør det sikres at modulerne er tidssvarende, både teknisk og ift. brugeren. Det skal vurderes om videreudvikling eller nyudvikling vil være mest fordelagtigt. Ved nyudvikling opbygges applikationer i moduler, der skaber størst mulig konfigurerbarhed og muliggør genanvendelse.

2. ANVEND STANDARDSYSTEMER OG PLATFORME Ved behov for funktionalitet foretrækker vi at basere os på anerkendte og udbredte løsninger. Hvis det ikke er muligt, skal udvikling baseres på anerkendte og udbredte udviklingsværktøjer. Vi ønsker at sikre et robust og ensartet miljø. Dette gøres ved i størst muligt omfang at basere os på velafprøvet teknologi og anvendelse af platforme, der muliggør ensartethed på tværs af løsningerne. Samtidig vil det lette drift, administration og vedligehold af løsningerne. Ved anskaffelser foretrækkes anerkendte og udbredte løsninger. Når disse ikke kan opfylde de væsentligste behov, så udvikling er påkrævet, anvendes anerkendte og udbredte udviklingsværktøjer til levering af nye services og applikationer. Ved anskaffelser stilles krav om, at anerkendte og udbredte løsninger foretrækkes. Når udvikling er nødvendig anvendes anerkendte og udbredte udviklingsværktøjer.

3. UDNYT DEN FÆLLESOFFENTLIGE INFRASTRUKTUR Vi udnytter den fælles offentlige infrastruktur til at sikre en effektiv understøttelse af brugerne og borgere, og vi lever op til de fællesoffentlige krav om digitalisering. Ved at anvende fælles kilder og komponenter undgår vi at skulle egenudvikle komponenter på de relevante områder. Anvendelse af fælles datakilder sikrer samtidigt at vi ikke skal vedligeholde og opbevare data der er tilgængelige ved fælles kilder. Anvendelsen af fællesoffentlige komponenter (fx NemID, Digital Post) giver størst mulig genkendelighed for brugerne. Ved at genbruge og udnytte eksisterende offentlig infrastruktur spares ressourcer på nyudvikling og vedligehold. Vi skal leve op til fællesoffentlige krav vedr. digitalisering. Den fælles offentlige infrastruktur, både data og fælleskomponenter, skal anvendes i størst muligt omfang. Ved udvikling af nye systemer eller væsentlige ændringer i eksisterende systemer skal det undersøges, hvilke fællesoffentlige data eller komponenter der kan indgå i løsningen. Ved anskaffelse eller udvikling af nye løsninger, skal der stilles krav om anvendelse af de fællesoffentlige løsninger og infrastrukturkomponenter, herunder NemKonto, NemID, NemLog In, Digital Post, CPR, CVR.

4. DEN ANVENDTE SIKKERHEDSMODEL TILPASSES DATAS KATEGORISERING Vi anvender en differentieret sikkerhedsmodel som understøtter den passende sikkerhedsniveau for den konkrete løsning, og balancerer behovet for henholdsvis fleksibel og sikker adgang til applikationer og services på tværs af platforme. [UBK1] Vi vil sikre at der anvendes passende sikkerhedsforanstaltninger til den enkelte løsning. For at kunne understøtte ændret brugeradfærd med anvendelse af applikationer og services på tværs af platforme og deraf øget behov for udveksling af data anvendes en differentieret sikkerhedsmodel. Da datas integritet og tilgængelighed altid er vigtigt, sikres dette uanset sikkerhedsmodel. Sikkerhedskrav tilpasses de data der behandles i det enkelte system, service og applikation. Ved behov for ny eller forbedret it understøttelse gennemføres en vurdering af data i løsningen, hvilket bestemmer niveauet for datasikkerheden, som behandles jf. nedenstående datakategorier Højere sikkerhed Lavere sikkerhed Ministerbetjening Personregistrering Sagsbehandling Journalisering Løn og personaleadministration Bogføring Økonomistyring Generelle dokumenter, regneark og præsentationer m.m. E mails og sms Generel information Det skal sikres, at enhver service eller applikation kan overholde det valgte sikkerhedsniveau.

I starten af ethvert projekt laves en vurdering af data i løsningen. Resultatet af vurderingen indarbejdes i projekt set up et. Den systemansvarlige foretager regelmæssigt(baseret på risikobilledet) en vurdering af, om det sikkerhedsmæssige niveau for det enkelte system, service eller applikation er passende.

5. ALTID FOKUS PÅ DATASIKKERHED Vi har gennem hele en applikations eller services livscyklus fokus på at sikre den krævede datasikkerhed. Opretholdelse af et tilstrækkeligt niveau for datasikkerhed for at hindre misbrug er afgørende for at overholde gældende lovgivning og sikre tillid til de it services, som vi leverer således, at vi er forberedte til at efterleve nye krav ved lovgivning eller regulering, fx via persondataforordningen. Ved større ændringer i en service eller applikation sikres, at kun nødvendige data indsamles, og kategorien af disse data vurderes. Der skal samtidig altid gennemføres specifik risikovurdering for det enkelte projekt. På baggrund af datas kategori og risikovurderingen vælges det rette niveau for beskyttelse af data. Desuden fastlægges: Hvilke sikkerhedszoner som kan anvendes? Hvilket sikkerhedsniveau for kommunikation og evt. kryptering af data der kræves? Hvilke krav der skal stilles til adgangskontrol? Hvilket niveau af sporbarhed, fx i form af logning, der behøves? Den systemansvarlige foretager regelmæssigt opfølgning på hvilke data, der anvendes i systemet og vurderer på baggrund heraf, om systemet lever op til de nødvendige datasikkerhedsmæssige krav. I starten af ethvert projekt laves en risikovurdering vurdering af løsningen. Resultatet af vurderingen indarbejdes i projekt set up et. Ved indgåelse af aftaler med leverandører der håndterer personhenførbare data, indgås Databehandleraftale. En gang om året går de systemansvarlige alle systemer igennem, herunder eksterne for at se om de er klassificeret rigtigt i forhold til om der er fortrolige data på systemet.

Hver 1 år sikrer Folkekirkens It at der laves scanning af alle systemer og services der er tilgængelige uden for Kirkenettet. Alle eksterne leverandører skal gennemgås for valid databehandleraftale hvert år. Alle leverandører skal tiltræde Governance i Kirkenettet

6. ANVEND FÆLLES DATAMODEL Vi anvender vores fælles datamodel for at sikre ajourførte og konsistente masterdata på tværs af alle applikationer og services. Ved at sikre ajourførte og konsistente masterdata på tværs af alle applikationer og services, sikres det, at brugere altid har adgang til den korrekte information. Samtidigt tydeliggør den fælles datamodel, hvor masterdata er placeret og dermed, hvor data fødes, samt hvem der har til ansvar at sikre opdatering af data. Den fælles datamodels rammer for indhold og ansvar skal overholdes ved al udvikling af nye systemer eller væsentlige ændringer. Nye løsninger må ikke rumme proprietære masterdata, der allerede findes et andet sted. Folkekirkens It's krav til anvendelse af masterdata skal overholdes.. Ved anskaffelse og udvikling skal datamodellen anvendes så nye applikationer og services overholder krav til anvendelse og vedligehold af masterdata. Ved anskaffelse og udvikling af nye applikationer og services skal datamodellen opdateres, og evt. ændringer skal godkendes af de ansvarlige for den fælles datamodel.

7. FOKUS PÅ BRUGERVENLIGHED Vi har altid fokus på at sikre høj brugervenlighed i vores løsninger ved at sikre brugerinvolvering og udvikle brugerflader målrettet den enkelte bruger og sikre sammenhæng og ensartethed på tværs af vores løsninger. Brugerinddragelse giver bedre løsninger slutbrugerne ved løbende at anvende deres viden og respons i it projekterne. Fokus på optimalt design af brugergrænsefladen vil sikre brugeren af systemet en væsentlig bedre oplevelse. For den enkelte bruger vil enkle og ensartede brugerflader på tværs af systemerne betyde mindre oplæring, en lettere arbejdssituation og større effektivitet. Særlig for brugere med begrænset anvendelse er enkelhed og overskuelighed afgørende. Et brugervenligt design vil give færre kilder til fejl ved brug af systemet. Brugergrænsefladen er en mindst lige så væsentlig del af it systemer som selve kodningen. Ved udvikling af nye systemer eller væsentlige ændringer i eksisterende systemer skal det sikres, at brugergrænsefladen får en optimal udformning. Dette sker ved at sikre løbende brugerinddragelse, og ved at overholde de fælles rammer, der eksisterer for brugervenlighed ved Folkekirken It. Brugere skal altid inddrages i behovsafklaring og design af løsninger. For alle websteder og selvbetjeningsløsninger skal Digitaliseringsstyrelsens proceskrav til God selvbetjening anvendes efter følg eller forklar princippet. For øvrige projekter er de til inspiration. Kravene til god selvbetjening findes her: http://arkitekturguiden.digitaliser.dk/godselvbetjening Alt udvikles som udgangspunkt til web.

8. UNDERSTØT PLATFORMSUAFGÆNGIGHED Vi foretrækker platformsuafhængige applikationer og løsninger på såvel pc/mac, tablets og smartphones, inden for de it sikkerhedsmæssige rammer. Hvis dette ikke er muligt, skal applikationer og services være tilgængelige på de gængse platforme og i det omfang, det er relevant for brugerne. Vi ønsker at understøtte brugernes behov for adgang til it understøttelse på de enheder, hvor de finder det fordelagtigt og med den funktionalitet der er relevant, og dermed tilbyde en mere fleksibel adgang til it løsningerne. Ved udvikling eller anskaffelse af nye applikationer eller services skal det kortlægges, hvilke brugerbehov der er ift. it understøttelse på forskellige typer af enheder. Der foretrækkes applikationer og services, som kan gøres tilgængelige for brugerne på alle gængse platforme. Ved nyudvikling og anskaffelser har vi en præference for systemer, der har en platformsuafhængig brugergrænseflade. Vi vurderer at webbaserede og responsive brugerflader giver den største platformsuafhængighed. Ved nyudvikling og anskaffelser skal det tydeligt beskrives, hvilken funktionalitet der er tilgængelig og reelt anvendelig på de brugerflader der tilbydes de forskellige enhedstyper, herunder pc/mac, tablet, smartphone. For hvert projekt specificeres en konkret liste over de browsere (inkl. mobil browser) der skal understøttes. Som udgangspunkt understøller vi på PC og mac altid IE i de to sidste versioner, Edge i den nyeste version, Chrome, Safari og Firefox i den nyeste version.

9. MAKSIMAL ÅBENHED I APPLIKATIONERNE Vi anvender åbne standarder og adgang til data i vores applikationer via velbeskrevne snitflader. Ved at anvende åbne standarder til kommunikation mellem vores applikationer og sikre adgang til alle data i den enkelte applikation via velbeskrevne snitflader sikres størst mulig fleksibilitet i udviklingen af it understøttelsen, og risikoen for afhængighed til leverandører eller proprietære standarder mindskes. Ved alle nyanskaffelser stilles klare krav til fri adgang til alle data i applikationen via velbeskrevne snitflader og at snitflader og integrationer baseres på åbne standarder, således at vi sikrer maksimal fleksibilitet i forhold til den fremtidige udvikling af vore services Ved anskaffelse og udvikling stilles krav til fri og ubegrænset adgang til alle data i applikationen via velbeskrevne snitflader. Ved anskaffelse og udvikling stilles krav om, at snitflader og integrationer baseres på åbne standarder. Vi benytter grænseflader baseret på REST og SOAP.

10. FÆLLES SINGLE SIGN ON OG BRUGERADMINISTRATION Vi anvender fælles single sign on og brugeradministration for alle applikationer. Det er afgørende for brugerne at skulle logge ind færrest mulige gange. For at sikre størst mulig effektivitet for brugerne er det målsætningen, at alle kun skal signe ind én gang på den samme enhed. Fælles brugeradministration gør det mere sikkert og effektivt at administrere de mange tusinde brugere af Folkekirkens og ministeriets systemer. Folkekirkens It stiller en service til rådighed for interne og eksterne leverandører som gør det nemt at implementere ud fra gængse standarder. Alle nye applikationer og services skal kunne anvende den fælles single sign on og fælles brugeradministration. Ved anskaffelse og udvikling stilles krav om anvendelse af Folkekirkens It's service for at sikre understøttelse af single sign on.

11. PERFORMANCEKRAV TIL ALLE SERVICES OG APPLIKATIONER Folkekirkens It opstiller individuelle performancekrav til alle sine services og applikationer. Performancekravene som beskrives er: Svartid: Fra brugeren aktiverer funktionen til resultatet er tilgængeligt for brugeren. Driftstid: Det tidsrum på døgnet, hvor servicen eller applikationen er tilgængelig. Oppetid: Den procentdel af åbningstiden, hvor servicen skal svare, og den andel af klienterne, som dette skal gælde for. Retableringstid: Den tid, der må gå, inden servicen eller systemet fungerer igen i tilfælde af nedbrud (katastrofe). Anvendelse af performancekrav sikrer forventningsafstemning mellem it leverandører og it brugere om vigtigheden af den enkelte service eller applikation set i forhold til omkostningerne ved at levere den valgte performance. Dette er for at sikre dels at applikationerne fungerer tilfredsstillende i den daglige drift, dels at der er taget højde for retableringstiden jf. den overordnede risikoanalyse for Kirkenettet. Folkekirkens It s krav for enhver service eller applikation skal overholdes. Krav vedrørende svartider, driftstid (tilgængelighed) og retableringstid skal leve op til risikovurderingen. Det aftales, hvordan der måles og rapporteres på de valgte performancekrav. Baseret på en vurdering af den enkelte applikation eller service defineres kravene til: Svartid, Driftstid, Oppetid og Retableringstid. For alle applikationer og services, både internt og eksternt drevne, fastlægges det hvordan måling vil finde sted, og hvordan og med hvilket interval rapportering skal finde sted.