Sluttbrukeravtale
Sluttbrukeravtale
KLF Produksjonskontroll for Egg- og slaktekylling
Gjeldende f.o.m: 14. august 2024
3. Definisjoner og formålet med Prodkontroll 2
3.2.3 Fjørfe Generell - KSL punkt 50.1.1: 3
3.2.4 Registrering og datautveksling 4
4. Tjenesteeierens ansvar og myndighet 5
4.1.1 Informasjonssikkerhetskontroller 5
4.1.2 Retningslinjer for databrudd 5
4.1.3 Prosedyrer for hendelseshåndtering 5
5.1 Oversikt brukerroller og tilganger 5
6. Tjenestebrukerens ansvar, plikter og rettigheter 6
6.1 Slakteri/eggpakkeri -administrator 6
6.2 Slakteri/eggpakkeri -bruker 6
7. Personvern, behandling og deling av data, eiendomsrett til data 7
7.2 Datakilder og utlevering 7
7.5 Aktøroversikt datadeling 8
11. Ansvarsbegrensning og erstatning 9
13. Gjeldende lov og jurisdiksjon 10
Denne avtalen regulerer forholdet mellom KLF Servicekontor AS, heretter betegnet
<Tjenesteeier>, xxx.xx. 917957495, som leverandør av tjenesten "KLF
Produksjonskontroll for Egg og slaktekylling" (heretter betegnet <Tjeneste>), og slakterier, egg- og kyllingprodusenter, rådgivere og veterinærer som registrerer seg som brukere av tjenesten (heretter betegnet <Tjenestebruker>).
Sluttbrukeravtalen for Prodkontroll omfatter alle forhold knyttet til registrering av brukere, samt registrering og bearbeiding av produksjonsdata som oppstår i fjørfenæringen, herunder egg- og kyllingprodusenter. Avtalen regulerer formål,
brukerrettigheter, ansvar og plikter, kildeoversikt med bestemmelser for utveksling, bruk og eierskap av dataene, samt andre relevante forhold som følger med ved registrering i Prodkontroll.
3. Definisjoner og formålet med Prodkontroll
• <Tjenesteeier> - refererer til KLF Servicekontor AS, som er den juridiske enheten ansvarlig for utvikling, drift og vedlikehold av tjenesten "KLF Produksjonskontroll for Egg og slaktekylling" (heretter kalt <Prodkontroll>). Tjenesteeier har også
eierskap til databasen, applikasjonene og grensesnittet som utgjør Prodkontroll, og er ansvarlig for å sikre at tjenesten er sikker, oppdatert og tilgjengelig for
brukerne i samsvar med gjeldende lover og reguleringer.
• <Tjenestebruker> - refererer til enhver juridisk eller fysisk person som har registrert seg for å bruke tjenesten Prodkontroll. Dette inkluderer, men er ikke begrenset til, slakterier, egg- og kyllingprodusenter, rådgivere, veterinærer og andre eksterne brukere som får tilgang til tjenesten. Tjenestebrukere har ulike
roller og tilganger avhengig av deres funksjon og ansvarsområder, og de må godta sluttbrukeravtalen før de får tilgang til Prodkontroll.
• <Tjeneste> - er en it tjeneste levert av KLF Servicekontor AS som gir verktøy for registrering, bearbeiding og overvåking av produksjonsdata i fjørfenæringen, spesielt for egg- og slaktekyllingproduksjon. Tjenesten inkluderer funksjoner for lagring, visning og utveksling av data med relevante aktører, samt beregning og
dokumentasjon av produksjonsstatus. Prodkontroll bidrar til å oppfylle offentlige krav og sikrer at produksjonsdata kan rapporteres og brukes til forskningsformål og statistikk.
Dokumentere etterlevelse av krav i Forskrift om hold av høns og kalkun, bransjeretningslinjer, KSL og varemottaker.
I henhold til bransjeretningsline for verpehøns og for slaktekylling skal driftsenheter være medlem i og registrere nødvendige produksjonsdata for hvert innsett i en
elektronisk produksjonskontroll levert av eller godkjent av Nortura SA eller KLF.
Nødvendige produksjonsdata slaktekylling: Det skal hvert innsett føres «førsteukesvekt» (g), «førsteukedødelighet» (%), total dødelighet (%) og andel avlivet av total dødelighet (%).
Kylling: I henhold til forskrift om hold av høns og kalkun skal dyreholder ved hvert innsett fortløpende dokumentere skriftlig
• antall dyr ved innsett
• bruksareal
• hybrid
• hvor mange dyr som ved hver kontroll er funnet døde eller er blitt avlivet, med angivelse av dødsårsak dersom det er mulig, eller avlivingsgrunn
• antall dyr ved slakting.
Dokumentasjonen skal oppbevares i minimum 3 år og være tilgjengelig ved inspeksjoner eller andre forespørsler fra Mattilsynet.
3.2.3 Fjørfe Generell - KSL punkt 50.1.1:
Minstekrav til dokumentasjon er:
• dato for innsett
• dyras opprinnelse
• egg: rugeri og oppaler
• fjørfekjøtt og oppal av unghøner: rugeri antall innsatte dyr bruksareal
• ytelse egg: totalt antall egg og antall gulvegg
• fjørfekjøtt og oppal av unghøner: dyras vektutvikling antall døde dyr – om mulig med angivelse av dødsårsak antall avlivede dyr – med oppføring av avlivingsårsak (før opp sykdom og/eller hvilken skade)
• fôrleverandør dato for leveranse av innkjøpt fôr fôrforbruk (eventuelt fôrkjøp dersom du ikke har fôrvekt)
• vannforbruk
• fôring med andre fôrmidler
• endring av lysdag og justering av lysstyrke
• logg over alle besøk
• hakking, fjørplukking og andre adferdsproblemer
• egg: tidspunkt for etterfylling av strø, åpning og lukking av sandbad i innredede bur
• teknisk inspeksjon og funksjonstesting av ventilasjonsanlegg, alarmsystem og nødstrømsaggregat
• eventuell innsending av blodprøver eller døde dyr for obduksjon – ta vare på
obduksjonsrapporter og prøvesvar veterinærbesøk, behandling og forebyggende helsearbeid eventuell bruk av medisiner, vaksiner, vitamintilsetning eller liknende
• dato for innsending av salmonellaprøver
• fjørfekjøtt: dato for innsending av Campylobacter-prøver
• dokumentasjon på antall dyr som er i flokken til enhver tid, for eksempel ved delt utslakting
3.2.4 Registrering og datautveksling
Regelmessig registrering av produksjonsparametere i Prodkontroll. Eventuelle avvik skal også registreres og følges opp i Prodkontroll. Prodkontroll lagrer og viser registreringer, beregner og dokumenterer en produksjonsstatus på bakgrunn av registreringene, og
utveksler data med relevante aktører (se punkt 7.5).
4. Tjenesteeierens ansvar og myndighet
• <Tjenesteeier> har den sentrale administrasjonen av Prodkontroll, med ansvar for drift og utvikling.
• <Tjenesteeier> eier rettighetene til Prodkontroll sin database, applikasjoner, fremgangsmåter, og brukergrensesnitt.
• <Tjenesteeier> skal tilby en sikker, brukervennlig, oppdatert og tilgjengelig tjeneste i tråd med generell IT-utvikling.
• <Tjenesteeier> skal sørge for sikkert mottak, lagring og formidling av data og ha gode rutiner for sikkerhetskopiering.
• <Tjenesteeier> skal legge til rette for at tjenesten i så stor grad som mulig oppfyller offentlige krav og at pålagte data kan rapporteres fortløpende.
<Tjenesteeier> plikter å opprettholde et rimelig og forsvarlig nivå i samsvar med kravene til behandling av personopplysninger og alminnelig bransjestandard i markedet for
sikring av de data som innhentes, deles og behandles. Det vises til følgende
informasjonssikkerhetskontroller, retningslinjer for databrudd og prosedyrer for hendelseshåndtering.
4.1.1 Informasjonssikkerhetskontroller
Vedlegg-1-KLF-information-security-controls-140824
4.1.2 Retningslinjer for databrudd
Vedlegg-2-KLF-Data-Breach-Response-Policy-140824
4.1.3 Prosedyrer for hendelseshåndtering
Vedlegg-3-KLF-Procedure-for-Incident-Management-140824
For å kunne tilby tjenester til brukere av Prodkontroll kan det opprettes ulike tilganger for eksterne brukere, f.eks. rådgivere. Alle brukerne må godta denne sluttbrukeravtalen før de får tilgang til Prodkontroll. For fullstendig oversikt over hvilke brukerroller som finnes i Prodkontroll, og hva slags tilgang de har, se punkt 5.1.
5.1 Oversikt brukerroller og tilganger
Se punkt 6.
6. Tjenestebrukerens ansvar, plikter og rettigheter
Alle brukere skal rapportere inn feil ved tjenesten. Avløser/rådgiver rapporterer feil til produsentbruker/produsentadministrator. Produsent/produsentadministrator
rapporterer feil til tilhørende eggpakkeri/slakteri. Eggpakkeri/slakteri rapporterer feil til KLF.
6.1 Slakteri/eggpakkeri -administrator
Administrator ved eggpakkeri/slakteri skal ta ansvar for å administrere brukerne av
kontrollen ved eget eggpakkeri/slakteri. Dette inkluderer å inaktivere brukere når disse endrer stilling og ikke skal ha tilgang til kontrollen. Administrator skal sammen med
ordinær slakteribruker/eggpakkeribruker innrullere og inaktivere egne produsenter i
kontrollen, sånn at denne til enhver tid er oppdatert og korrekt. Administrator skal også bistå egne produsenter i bruken av kontrollen og har tilgang til egne produsenters data.
6.2 Slakteri/eggpakkeri -bruker
Slakteribruker/eggpakkeribruker skal sammen med slakteri/eggpakkeri-administrator innrullere og inaktivere egne produsenter i kontrollen, sånn at denne til enhver tid er oppdatert og korrekt. Slakteri/eggpakkeri-bruker skal også bistå egne produsenter i bruken av kontrollen og har tilgang til egne produsenters data.
Produsent-administrator kan opprette produsentbrukere, avløsere og rådgivere og gi tilgang til egen kontroll som beskrevet under. Produsentadministrator skal også
avslutte/fjerne brukere som ikke lenger skal ha tilgang. Produsentadministrator skal føre inn nødvendige produksjonsdata løpende.
Produsent-bruker kan opprette flere produsentbrukere, avløsere og rådgivere og gi tilgang til egen kontroll. Produsentadministrator skal føre inn nødvendige
produksjonsdata løpende.
Avløser har tilgang til å føre inn nødvendige produksjonsdata etter invitasjon fra produsentbruker. Avløser har ikke tilgang til rapportfunksjoner.
Rådgiver har ikke skrivetilgang, men har lesetilgang til registreringer og rapportfunksjoner etter invitasjon fra produsentbruker.
7. Personvern, behandling og deling av data, eiendomsrett til data
Registrering i, og bruk av, Prodkontroll innebærer behandling av personopplysninger.
<Tjenesteeier> er behandlingsansvarlig for disse opplysningene, og brukeravtalen utgjør det rettslige grunnlaget. Prodkontroll behandler data relatert til driftsenhetens egg- og slaktekyllingproduksjon. Driftsinformasjon er i seg selv ikke å anse som
personopplysninger, men da dette knyttes til enkeltpersonsforetak og derigjennom også enkeltmennesker, anses driftsinformasjonen også som personopplysninger.
Prodkontroll inneholder følgende opplysninger som kan knyttes til enkeltpersoner:
• Navn
• Telefonnummer
• E-postadresse
• Produsentnummer
• Driftsinformasjon om egg- og slaktekyllingproduksjon i landbruksforetaket som er spesifisert i punkt 3.2.1, 3.2.2 og 3.2.3 av denne avtalen.
Formålet med behandlingen av personopplysninger er sammenfallende med formålet med Prodkontroll som beskrevet ovenfor i punkt 3. Alle innlogginger i Prodkontroll logges med brukernavn, tidspunkt og IP-adresse. Formålet med loggen er å avdekke mulige
sikkerhetsbrudd og uønskede hendelser. Loggen tas vare på i opptil seks måneder.
Prodkontroll behandler ikke særlige kategorier av personopplysninger (tidligere kalt
sensitive personopplysninger). <Tjenesteeier> sørger for et forsvarlig sikkerhetsnivå på tjenesten i tråd med gjeldende regelverk.
Prodkontroll utveksler data med flere aktører. For fullstendig oversikt over aktører og hvilke data som innhentes og utveksles, se punkt 7.5. Formålet med de ulike
integrasjonene er å forenkle registreringsarbeidet, forbedre datakvaliteten, samt gjøre relevant data tilgjengelig for bruker, varemottaker og andre aktuelle aktører. Data fra Prodkontroll kan bli utlevert til offentlige myndigheter på grunnlag av lovbestemt
utleveringsplikt. Ved slik utlevering holdes produsent underrettet.
Data relatert til driftsenhetens produksjon kan stilles til rådighet for forskningsformål. Ved slik datautlevering kreves avtale med forskningsinstitusjon om tiltak for
anonymisering og sikker oppbevaring av data. Så langt det er mulig anonymiseres data før utlevering. Spørreundersøkelser som vurderes relevante for brukergruppen, utført av ikke-kommersielle aktører eller forskningsinstitusjoner, vil kunne bli formidlet til brukere.
Prodkontroll innhenter, lagrer, bearbeider og formidler data relatert til driftsenhetens egg- og slaktekyllingproduksjon. Relevant data er alltid tilgjengelig for bruker i
Prodkontroll. Data knyttet til avtaleforhold er redigerbart for bruker, øvrig data med
opphav i Prodkontroll er redigerbart for system- og slakteriadministrator. Data som er innhentet fra andre aktører må redigeres i de andre aktørenes applikasjoner (f.eks. kontaktopplysninger fra Landbrukets Dataflyt, Klimakalkulator, fôr-produsenter).
Av hensyn til statistiske og historiske formål slettes ikke data relatert til driftsenhetens egg- og slaktekyllingproduksjon i Prodkontroll. Når andre tjenesteleverandører behandler data på <Tjenesteeier>s vegne, inngås det en skriftlig databehandleravtale for oppdraget i tråd med gjeldende personvernregelverk.
Den enkelte produsent eier sine data i Prodkontroll. Produsenten gir ved å benytte tjenesten <Tjenesteeier> rett til å forvalte, herunder å registrere, lagre, anvende og utlevere produsentens data relatert til egg- og slaktekyllingproduksjon til tjenestens
angitte formål, slik som forskning og statistikk m.m. Dette gjelder også etter oppsigelse av denne avtalen.
All informasjon lagret i Prodkontroll skal kunne brukes til forskning, statistikk og andre formål relatert til fjørfenæringen. Ved annen bruk kan <Tjenesteeier> kun bruke
informasjonen i en slik form at produsent ikke kan identifiseres hvis ikke annet er avtalt med produsent. <Tjenesteeier> kan fritt bruke data i Prodkontroll i aggregert form.
Opplysningene forvaltes i samsvar med denne sluttbrukeravtalen for Prodkontroll. Offentliggjøring av resultater eller andre forhold som kan knyttes til den enkelte bruker krever produsentens samtykke. Personell som arbeider med Prodkontroll, kan ikke
informere uvedkommende om forhold angående den enkelte bruker.
<Tjenesteeier> og/eller andre aktører som får tilgang til dataene i tråd med
bestemmelsene i denne avtalen, får rettighetene til sammenstillinger og/eller analyser mv. de utfører på grunnlag av dataene. Indirekte eller direkte kommersiell bruk av data fra Prodkontroll skal avklares med produsentene.
Vedlegg-4-KLF-Aktøroversikt-datadeling-140824
Partene forplikter seg til å opprettholde full konfidensialitet om opplysninger av fortrolig forretningsmessig eller personlig karakter som de får kjennskap til som følge av
avtaleforholdet. Konfidensialitetsplikten gjelder alle rettighetselementer, inkludert forretningshemmeligheter, samt det som kan beskyttes gjennom firma-, varemerke-, mønster-, patent-, åndsverk-, markedsførings- og annen relevant lovgivning. Dette
omfatter også rettigheter eller forretningshemmeligheter som kan være beskyttet gjennom avtale, uavhengig av om formelt beskyttelsestiltak er iverksatt eller ikke.
Konfidensialiteten innebærer en plikt til å avstå fra å bruke enhver informasjon eller
dokumentasjon man har fått tilgang til, for egne eller andres formål. Partene forplikter seg videre til å iverksette nødvendige tiltak i egen organisasjon for å sikre at
konfidensialiteten ivaretas av alle som handler på vegne av parten eller som parten har ansvar for, slik at uvedkommende ikke får tilgang til informasjonen.
Hvis en av partene blir klar over at utenforstående har fått tilgang til eller kjennskap til konfidensielle opplysninger, skal vedkommende umiddelbart varsle den andre parten.
Plikten til konfidensiell behandling begrenser ikke <Tjenesteeier> sin rett til å bruke data fra eller om <Tjenestebruker> og tilhørende landbruksforetak til tjenestens formål i henhold til punkt 3 i denne avtalen.
<Tjenesteeier> har rett til når som helst å foreta endringer i Prodkontrolls funksjonalitet, integrasjoner, grensesnitt og tilhørende brukervilkår dersom det anses hensiktsmessig eller nødvendig for å forbedre tjenesten eller for tilpassing til endrede tekniske, juridiske, bransjespesifikke eller økonomiske rammevilkår. Endringer som medfører endring i
denne sluttbrukeravtalen skal varsles bruker via en eller en kombinasjon av følgende kommunikasjonskanaler: i Prodkontroll, e-post, SMS eller nyhetsbrev. Endringer skal varsles innen rimelig tid, dog senest innen 30 dager etter endringer trer i kraft.
Eventuelle tvister, uenigheter eller krav som oppstår i forbindelse med denne avtalen, inkludert spørsmål knyttet til dens gyldighet, brudd, opphør eller ugyldighet, skal først forsøkes løst gjennom forhandlinger mellom partene. Dersom partene ikke kommer til enighet gjennom forhandlinger innen 90 dager, skal tvisten avgjøres av de ordinære
domstoler. Partene vedtar Oslo tingrett som verneting.
11. Ansvarsbegrensning og erstatning
• <Tjenesteeier> er ikke ansvarlig for indirekte tap eller følgeskader, inkludert tapt fortjeneste, som følge av bruk av Prodkontroll.
• <Tjenesteeier> er ikke ansvarlig for tap eller skade som følge av brudd på sikkerhetstiltak som skyldes forhold utenfor <Tjenesteeier>s kontroll.
• <Tjenestebruker> er ansvarlig for korrekt bruk av tjenesten i samsvar med instruksjoner og retningslinjer gitt av <Tjenesteeier>.
• Erstatningsansvar for <Tjenesteeier> er begrenset til direkte tap som følge av grov uaktsomhet eller forsettlig handling fra <Tjenesteeier>s side.
Ingen av partene skal holdes ansvarlig for manglende oppfyllelse av sine forpliktelser i henhold til denne avtalen dersom dette skyldes forhold utenfor partens rimelige
kontroll, inkludert, men ikke begrenset til, naturkatastrofer, krig, streik, pandemi eller andre forhold som kvalifiserer som force majeure.
13. Gjeldende lov og jurisdiksjon
Denne avtalen er underlagt og skal tolkes i samsvar med norsk lovgivning. Tvister som oppstår i forbindelse med avtalen skal løses ved Oslo tingrett.
KLF information security controls
Vulnerability Management Server Management
Application vulnerabilities Access control
Communications security Service exposure
Information Security Management ISO 27001 certification
Introduction
This document describes information security controls applied to KLF related services supplied by Systor Trondheim AS (Systor) for KLF. The following services are covered:
Implementation, operation and maintenance of the production control solution for KLF, including: Infrastructure and KLF servers hosted at Systor's data centers in Norway
Vulnerability Management
Server Management
All servers are protected with anti-malware software. The servers are patched regularly, and ad-hoc if necessary. Only system operators at Systor Trondheim AS are allowed to access the KLF servers directly.
Remote access to servers is only allowed from specific jump hosts
All servers are members of an Active Directory domain and user access is managed via Active Directory groups Active Directory group memberships are authorized per user on a "need to know" basis
Application vulnerabilities
Users connecting from the Internet (refer to the section about service exposure below) can log into the application using PIN from e-mail and SMS or using single sign on via “Produsentregisteret”. The user has to be a registered user, and first time login will take the user through a user registration process.
Machine-to-machine users authenticate using client id and password. Passwords are stored as hash values of the cleartext password.
A daily backup is stored in an offline backup repository, in addition to the regular backup. This repository is not available via the regular network access and will serve as the "last resort" for recovery in case of a ransomware attack.
Disaster recovery
The primary Internet connection for the secondary site goes through the primary site
BGP routing is established between the Internet connections on the primary and secondary sites The secondary site has a backup Internet connection
The disaster recovery procedure depends on the architecture of the system. The KLF Production control solution is not set up as a “dual site” solution and servers on the primary site are not replicated to hot standby servers on the secondary site. Hence, the KLF Production control solution has to be reconstructed on the secondary site based on database backups in case of a disaster.
Power
All servers are equipped with redundant power supplies and one of these are connected to an UPS source in Systor’s data centers. The UPS can provide power for at least 30 minutes. Another main power source can be engaged in case of a longer power outage.
Communications security
Service exposure
KLF Production control: the service is available via the Internet and without IP screening.
Encryption
All data in transit are encrypted:
Security zones
Database server zone Application server zone
There is no external access from the Internet and to the Database server zones.
The next-generation firewall is equipped with Intrusion Prevention System features and uses deep packet inspection to analyze the data inside each packet. It can identify - and block or allow specific applications and protocols.
Systor buys advanced DDoS protection from the Internet Service Provider and the Internet access at both sites are protected. Internet traffic is analysed and handled with one of the following mechanisms in case of a DDoS attack:
Traffic can be filtered via a flowcheck process to allow "normal" traffic to proceed
Traffic can be geo-blocked, meaning that traffic from specific geographical regions is blocked or whitelisted Traffic can be silently discarded (blackhole filtering or null routing)
Which of the mechanisms to apply will depend on the type and volume of the DDoS attack.
Note that this handling takes place before the traffic reaches the firewall at Systor. This means that the firewall does not have to deal with the DDoS load itself and can handle internal traffic as normal.
Information Security Management
ISO 27001 certification
The first year of a 3-year cycle is a re-certification which concludes with the issue of a new (updated) ISO 27001 certificate The second and third years of a 3-year cycle is a periodic audit where compliance with the standard is verified
Findings from an external audit has to be handled within 3 months.
Security testing
Systor welcomes security testing, both network security testing and application security testing. All such testing shall be agreed and coordinated with KLF.
Policy acknowledgement and awareness Procedures
Assessment of Data Breaches Containment and Mitigation
Investigation and Documentation Review and Improvement
Introduction
Scope and purpose
Data Breach: A data breach is the accidental or unauthorized access, acquisition, disclosure, or use of personal data that compromises its confidentiality, integrity, or availability.
Personal Data: Any information that can be used to identify an individual, including but not limited to names, addresses, email addresses, Social Security numbers, and financial information.
Data Controller: The natural or legal person, public authority, agency or other body which, alone or jointly with others, determines the purposes and means og the processing of personal data; where the purposes and means of such processing are determined by Union or Member State law, the controller or specific criteria for its nomination may be provided for by Union or Member State law (GDPR Article 4, definition 7)
Data Processor: A natural or legal person, public authority, agency or other body which processes personal data on behalf of the controller (GDPR Article 4, definition 7)
Roles
At Systor Trondheim, the Security Manager assumes the responsibilities of the Data Protection Officer (DPO) and is the designated owner of this policy.
Depending on the specific data processing activity, Systor Trondheim may function either as a Data Controller or as a Data Processor.
Policy acknowledgement and awareness
All employees must confirm their understanding of and adherence to this policy, and they will receive training on the data breach response procedures and their roles in reporting and responding to incidents.
All employees must immediately report any suspected or confirmed data breach or privacy security incident to the Data Protection Officer (DPO) and assist the DPO in creating an incident report containing:
A description of the incident, The type of data involved, The affected individuals,
Any known or suspected causes.
Employees must not attempt to investigate the breach themselves, unless expressly instructed to do so.
If Systor Trondheim acts as the Data Processor for a given data processing task, the DPO shall report any data breach to the Data Controller promptly and involve the Data Controller in the following part of the procedure, in accordance with the terms set out in the relevant Data Processing Agreement (DPA).
Assessment of Data Breaches
The DPO and/or the designated team will assess the data breach to determine its scope, impact, and severity. This assessment will include:
Containment and Mitigation
The DPO and/or the designated team will take immediate steps to contain and mitigate the data breach to prevent further unauthorized access or disclosure. Actions may include:
Temporarily shutting down affected systems,
Changing access credentials and/or blocking access to services, Implementing security patches.
If the data breach poses a risk to individuals' rights and freedoms, the following actions will be taken:
The Data Controller will notify affected individuals,
The Data Controller will notify the national supervisory authority ("Datatilsynet" in Norway) within 72 hours,
The Data Controller will communicate the breach to affected third parties, as required by contracts or applicable laws,
The Data Controller will coordinate with its public relations and legal teams to manage external communications regarding the breach. A spokesperson will be designated to handle media inquiries and provide accurate and consistent information.
The notification will include:
Details about the breach, Its potential impact,
Recommended actions for affected individuals.
Investigation and Documentation
The desginated team will conduct a thorough investigation to understand the cause of the breach and prevent recurrence. Detailed records of the breach, response actions, and communications will be maintained for regulatory compliance and accountability.
After resolving the breach, Systor Trondheim will conduct a post-mortem incident review according to the Procedure for Incident Management to assess the response and identify opportunities for improvement in security measures and incident response procedures.
Procedure for Incident Management
Introduction
Purpose
The main objective of the Incident Management process is to restore a normal service function as quickly as possible and to minimize the impact on business operations, thus ensuring that the best possible level of service quality and availability is maintained.
Roles
Customer: The Customer may also be an internal stake holder, for example the CEO
Incident Manager: The Project Manager serves as the Incident Manager by default. The Project Manager may elevate the role to the Security Manager
Project Member: Operations personnel or developer who is able to assess and solve the incident
Revision and approval
This procedure is approved by the CEO of Systor Trondheim AS. The procedure is revised by the Security Manager.
Work flow process
Activities
Report the incident in the service portal
The Customer or Systor (as Vendor) shall report the incident in the service portal: xxxxx://xxxxxxxxxxx.xxxxxxxxxxxxx.xx
Classification of incidents
Issues are classified as an incident if there is an unplanned outage in an IT service or a reduction in the quality of an IT service or an error in a configuration element (CI) that has not yet affected an IT service (for example, a disk failure).
If the Incident Manager suspects that someone has committed a security breach then the Disciplinary procedure in case of security breach
shall be followed.
Prioritization of incidents
The actual Incident Manager (Security Manager or Project Manager) will prioritize the incident based on the following definitions:
Priority code | Description | Definition |
A | Critical | One or more of the criteria are met: Possible significant damage / loss caused by the incident Work that can not be performed by the customer, which is very time sensitive A minor event that can prevent a major incident by acting immediately More than one service is affected A significant proportion of users are affected Security incident that affects one or more users and threatens to affect the availability and / or data integrity of the service The customer's defined service manager, technical or commercial representatives consider the incident to be critical. |
B | High | Two or more of the criteria are met: The damage caused by the incident increases significantly over time One service and / or location is affected A moderate number of users are affected Only moderate parts of the use of the service are affected Business is moderately affected |
C | Medium | One of the criteria is met: The damage caused by the incident increases significantly over time A moderate number of users and departments are affected Only moderate parts of the use of the service are affected Business is moderately affected |
D | Low | All other |
Collect evidence
Logs with details that may be related to the incident shall be identified, collected and preserved as soon as possible because log data may be lost due to capping of log files or restart/reinstallation of services.
Data Breach
If the incident has caused data breach, refer to Data Breach Response Policy .
Postmortem report
If the incident has priority critical, a post mortem report shall be created.
The Security Manager shall then arrange a postmortem meeting and include personnel from management, operations and development.
The Security Manager is responsible for ensuring that the incident postmortem is available no later than three days after the incident has been resolved, in the relevant Jira issue. This involves coordination between stakeholders where this is a need. As a minimum, the event postmortem shall include:
Time of the incident Participants in postmortem Description and cause
Consequences and affected parties
Measures to solve the incident / prevent it from happening again. Tell what went wrong and what you do to avoid the incident in the future.