Norwegian Data Inspectorate



Similar documents
Data Processing Agreement for Oracle Cloud Services

Recommendations for companies planning to use Cloud computing services

Data Protection Act Guidance on the use of cloud computing

Supplier IT Security Guide

INFORMATION TECHNOLOGY MANAGEMENT CONTENTS. CHAPTER C RISKS Risk Assessment 357-7

Briefly summarised, SURFmarket has submitted the following questions to the Dutch DPA:

Data controllers and data processors: what the difference is and what the governance implications are

technical factsheet 176

The potential legal consequences of a personal data breach

Privacy and Electronic Communications Regulations

The supplier shall have appropriate policies and procedures in place to ensure compliance with

BRITISH COUNCIL DATA PROTECTION CODE FOR PARTNERS AND SUPPLIERS

Third Party Security Requirements Policy

Summary of responses to the public consultation on Cloud computing run by CNIL from October to December 2011 and analysis by CNIL

AIRBUS GROUP BINDING CORPORATE RULES

Astaro Services AG Rheinweg 7, CH-8200 Schaffhausen. Supplementary data protection agreement. to the license agreement for license ID: between

Align Technology. Data Protection Binding Corporate Rules Processor Policy Align Technology, Inc. All rights reserved.

Cloud computing and the legal framework

Article 29 Working Party Issues Opinion on Cloud Computing

NYSED DATA DASHBOARD SOLUTIONS RFP ATTACHMENT 6.4 MAINTENANCE AND SUPPORT SERVICES

SHARPCLOUD SECURITY STATEMENT

VPO NOK Rules. Rules for the Central Securities Settlement. in Norwegian Kroner

University of Liverpool

WEST LOTHIAN COUNCIL INFORMATION SECURITY POLICY

This Amendment consists of two parts. This is part 1 of 2 and must be accompanied by and signed with part 2 of 2 (Annex 1) to be valid.

Big Data for Mutuals. Marc Dautlich 25 November 2013

Decision on adequate information system management. (Official Gazette 37/2010)

CCBE RESPONSE REGARDING THE EUROPEAN COMMISSION PUBLIC CONSULTATION ON CLOUD COMPUTING

Microsoft Online Services - Data Processing Agreement

FIRST DATA CORPORATION PROCESSOR DATA PROTECTION STANDARDS

Federal Act on Combating Money Laundering and Terrorist Financing in the Financial Sector 1

Act no 41 on Insurance Mediation ( )

This interpretation of the revised Annex

SERVICE SCHEDULE INFRASTRUCTURE AND PLATFORM SERVICES

HIPAA BUSINESS ASSOCIATE AGREEMENT

Data Protection Policy.

How To Protect Decd Information From Harm

Pursuant to Convention No. 108 of the Council of Europe for the protection of persons with regard to the automated processing of personal data;

Caedmon College Whitby

Spillemyndigheden s Certification Programme Information Security Management System

Coláiste Pobail Bheanntraí

Estate Agents Authority

Practical Overview on responsibilities of Data Protection Officers. Security measures

Corporate Information Security Policy

STRATEGIC POLICY REQUIRED HARDWARE, SOFTWARE AND CONFIGURATION STANDARDS

PRIVACY REGULATIONS regarding the Web Health History ("W.H.H.") Service called LifepassportPRO provided by Meshpass SA

Records Management Policy.doc

Processor Binding Corporate Rules (BCRs), for intra-group transfers of personal data to non EEA countries

ADRI. Advice on managing the recordkeeping risks associated with cloud computing. ADRI v1.0

Clause 1. Definitions and Interpretation

Office 365 Data Processing Agreement with Model Clauses

DBC 999 Incident Reporting Procedure

Cork ETB Data Breach Management Policy and Procedures

BRING YOUR OWN DEVICE

White Paper Security. Data Protection and Security in School Management Systems

GRTGAZ NETWORK TRANSMISSION CONTRACT

RS Official Gazette, No 23/2013 and 113/2013

TERMS & CONDITIONS of SERVICE for MSKnote. Refers to MSKnote Limited. Refers to you or your organisation

<Choose> Addendum Windows Azure Data Processing Agreement Amendment ID M129

Transition Guidelines: Managing legacy data and information. November 2013 v.1.0

CAVAN AND MONAGHAN EDUCATION AND TRAINING BOARD. Data Breach Management Policy. Adopted by Cavan and Monaghan Education Training Board

IBX Business Network Platform Information Security Controls Document Classification [Public]

How To Use A Minicloud Server On An Ovh Cloud (For Free) For A Long Time

DATA SECURITY BREACH MANAGEMENT POLICY AND PROCEDURE

Regulations concerning measures to combat money laundering and the financing of terrorism, etc.

INSURANCE ACT 2008 CORPORATE GOVERNANCE CODE OF PRACTICE FOR REGULATED INSURANCE ENTITIES

ATMD Bird & Bird. Singapore Personal Data Protection Policy

Distribution Agreement for the ENC Service by and between Norwegian Hydrographic Service and. Agreement No.:.. Version No.: 1.0

THE BUDAPEST STOCK EXCHANGE LTD. REGULATIONS ON THE USE OF REMOTE TRADING

INFORMATION TECHNOLOGY SECURITY STANDARDS

The Anti-Corruption Compliance Platform

Data Management Policies. Sage ERP Online

Heslop & Platt Solicitors Limited

Enrollment for Education Solutions Addendum Microsoft Online Services Agreement Amendment 10 EES

Rules for the admission of shares to stock exchange listing (Listing Rules)

Data Transfer Policy. Data Transfer Policy London Borough of Barnet

CODE OF CONDUCT as adopted by the Board of Directors on 20 February 2015

HICAPS. Provider Agreement. Terms and Conditions

1. Scope of application

PAYMENT SERVICES AND SYSTEMS ACT (ZPlaSS) CHAPTER 1 GENERAL PROVISIONS SUBCHAPTER 1 CONTENT OF THE ACT. Article 1. (scope)

Microsoft Online Subscription Agreement/Open Program License Amendment Microsoft Online Services Security Amendment Amendment ID MOS10

EURODAC Central Unit. Inspection Report

Quality Assurance Agreement (QAA)

Finansinspektionen s Regulatory Code

Using AWS in the context of Australian Privacy Considerations October 2015

INFORMATION SECURITY MANAGEMENT SYSTEM. Version 1c

Transcription:

Norwegian Data Inspectorate Narvik kommune Postboks 64 8501 NARVIK Norway Your reference Our reference (please quote in any reply) Date 1111/1210-6/PEJA 11/00593-7/SEV 16 January 2012 Notification of decision New e-mail solution within Narvik local authority (Narvik kommune) Google Apps 1 Reference is made to the Norwegian Data Inspectorate s letter of 30 June 2011, the local authority s letter of 8 July 2011, the Data Inspectorate s letter of 1 August 2011, and the local authority s statement received on 2 September 2011. The matter concerns the local authority s existing, and planned extended, use of the product Google Apps. In the Data Inspectorate s letter of 30 June 2011, a statement was requested from the local authority concerning the following points: 1. An account of the personal data that the local authority will process in Google Apps. 2. The risk assessment that the local authority has carried out in respect of the processing of personal data in Google Apps; cf. Section 13 of the Norwegian Personal Data Act and Section 2-4 of the Norwegian Personal Data Regulations. 3. A copy of any agreement that the local authority has entered into with Google, together with an overview of the security measures that Google has implemented in the solution that the local authority has decided to use. 4. A copy of any processor agreement between the local authority and Google, as well as a description of the information system s design and physical location. 5. A description of how the following problems have been clarified with Google: Back-up Who at Google has access to the local authority s personal data? How will the local authority conduct a security audit of Google? Cf. Section 2-5 of the Personal Data Regulations. Postal address: Office address: Telephone: Fax: Company reg. no.: Website: Postboks 8177 Dep Tollbugt 3 (+47) 22 39 69 00 (+47) 22 42 23 50 974 761 467 www.datatilsynet.no 0034 OSLO Norway 1 The translation is unofficial. Should any doubt arise, only the Norwegian text of the decision is valid and binding.

Assessment of the local authority s statement Point 1 An account of the personal data that the local authority will process in Google Apps. The regulatory requirements Section 13 of the Personal Data Act states that the controller must ensure a satisfactory level of information security with regard to confidentiality, integrity and availability in connection with the processing of personal data through the use of planned and systematic measures. Section 2-11 third paragraph of the Personal Data Regulations states that personal data that is transferred electronically with the aid of a transfer medium that is outside the controller s physical control shall be encrypted or otherwise secured when confidentiality is necessary. The local authority s statement The local authority states that only an e-mail solution has so far been taken into use. However, it is stated that the organisation is also considering using other services that are offered via Google Apps. The local authority justifies this through a need for efficient internal cooperation through the sharing of documents, presentations, spreadsheets, forms or drawings. The local authority then gives some examples of areas where it may be appropriate to use the other tools. Common to these examples is the fact that the processing of personal data will, as regards the employees, be limited to name, telephone number, e-mail address and organisational affinity. The local authority furthermore states that all this information is already published on the local authority s website. The Data Inspectorate s assessment The Data Inspectorate restricts its assessment to the specified area of use: e-mail to/from and between the local authority s employees. The local authority describes clarity in the regulations, which state that no sensitive personal information must be sent by e-mail. Much of the work that is carried out within the local authority is linked to the provision of services to the inhabitants of the municipality, and it is therefore natural that much of the communication to/from the local authority and between the local authority s employees contains personal data. From a purely practical perspective, the Data Inspectorate believes that the local authority faces challenges in preventing sensitive data being sent by e-mail, either to/from or between the local authority s employees. However, the local authority can limit the risks through systematic training and the repeated communication of applicable routines. The Data Inspectorate believes that the risk of unauthorised sending of sensitive or confidential personal data will apply both between employees and between the local authority and the public. The Data Inspectorate does not however consider this to be a problem that is limited to Google Apps alone. The reason that this point is highlighted is that, with the specified solution, such information will be processed in systems that are not under the direct control of the controller. The Data Inspectorate s experience suggests that unauthorised communication (e.g. e-mail that contains sensitive personal data) will be stored on the processor s server for a long period of time, even after the user has actively deleted messages. This is due to the replication of content, among other things. 2

The local authority draws an analogy with Norway Post s distribution system as regards the opportunity for the public to assess the level of security in the communication between the local authority and the public regardless of whether this takes place via e-mail or via the post. The Data Inspectorate does not support such an argument. The security level and organisation of Norway Post s distribution system is subject to strict regulation through the Norwegian Postal Services Act and associated regulations. Letters with private or confidential content will be sent in sealed envelopes, where necessary as a registered consignment. The level of security for unencrypted e-mail is however based on a standard protocol called Simple Mail Transfer Protocol (SMTP). In practice, this protocol does not afford the content of the communication any protection. The Data Inspectorate s conclusion The local authority cannot exclude the possibility that sensitive personal data will be processed in the solution, and must therefore take into account the fact that both sensitive and general personal data will be processed in the system. The Data Inspectorate does not believe that the local authority has implemented adequate measures (cf. Section 2-11 of the Personal Data Regulations), given that confidential information will be processed in the solution. The local authority must take this into consideration in connection with an assessment of information security; cf. the discussion in the points below. Point 2 A statement with regard to the risk assessment that the local authority has carried out in respect of the processing of personal data in Google Apps; cf. Section 13 of the Norwegian Personal Data Act; cf. Section 2-4 of the Norwegian Personal Data Regulations. The regulatory requirements Section 13 of the Personal Data Act states that the controller must ensure a satisfactory level of information security with regard to confidentiality, integrity and availability in connection with the processing of personal data through the use of planned and systematic measures. Section 2-4 second paragraph of the Personal Data Regulations states that the controller must carry out a risk assessment in order to assess the probability and consequences of security breaches. The local authority s statement The local authority states that an overall risk analysis has been carried out as regards the introduction of a new ICT system. The analysis was enclosed with the local authority s letter. According to the analysis, the use of Google Apps will in most cases give a risk picture similar to that of the local authority s old system with certain exceptions. The local authority notes that the existing challenge of a lack of space and access to technological resources constituted an important factor in the choice of solution. The local authority furthermore refers to the risk of the existing organisation being unable to obtain and maintain specialist expertise to operate yet another specialised IT system. The local authority states that that due to the lack of space it would not be desirable to further burden the local authority s IT centre. 3

The local authority furthermore states that a new IT system is to be added. It has been found that it would be appropriate to replace some of the systems that the local authority currently uses with a system that requires fewer operating resources. As the Data Inspectorate understands the situation, the local authority must completely phase out use of the old solution in order to switch to the new one. In connection with such migration, it would be natural for both hardware and physical space to be released. The local authority states that it is believed that Google Apps solution is adequate with regard to availability, integrity and security. Nevertheless, the local authority acknowledges that it is worth noting that in many cases no probability/frequency can be described, as there is no usable reference material for this type of incident. The local authority also gives an account of how it will audit its processor. This will take place through a third party company, which the processor hires, conducting an audit based on the ISAE3402 standard and making available its findings in an audit report. The local authority will have access to this report and will be able to bring up issues within the local authority s information security committee. The Data Inspectorate s assessment Despite the absence of any basis, the local authority has decided to set values for defining the probability in its risk assessment. The Data Inspectorate notes that in the analyses very low probabilities are set for data intrusion, failure in continuity and lack of monitoring in Google Apps solution as mentioned previously without having any usable reference material at its disposal. The Data Inspectorate believes that the uncertainty linked to the probability should be stated much more clearly in the analysis. As regards failure in continuity, the local authority cannot exclusively consider the processor s uptime, but must also consider the uptime of the infrastructure from the local authority s network to the processor. It is unclear to the Data Inspectorate how the local authority will be able to alter the way in which the processor processes its data through the abovementioned audit reports. It appears to the Data Inspectorate that the local authority will only be able to alter how they themselves use the solution, and will have little influence over the design of the solution itself. The latter view is based on observations that the Data Inspectorate has made generally with regard to agreements between organisations. An audit report, based on the ISAE3402 standard, otherwise normally constitutes confirmation or rejection that the organisation complies with a given standard, its own security regime and any certificates that the solution is required to have. Such reports will therefore give little indication as to whether the local authority s standard with regard to security measures is met. The local authority can of course choose a different supplier if the results in the audit report are unsatisfactory, but it must thus be assumed that forcing the existing supplier to implement direct changes will be a challenging process. The Data Inspectorate is aware that changing supplier can lead to major challenges with regard to lock-in effects. There could for example be a contract period and added work involved in the migration process. In the best case scenario, the local authority must verify that this can be done in purely practical terms should a dispute arise. 4

The Data Inspectorate s conclusion The Data Inspectorate does not believe that the risk assessment gives a complete picture of the risks associated with the solution chosen by the local authority. The type of risk assessment that the local authority carried out in this case is not sufficient according to Section 2-4 of the Personal Data Regulations. Points 3 and 4 A copy of any agreement that the local authority has entered into with Google, including: An overview of the security measures that Google has implemented in the solution that the local authority has decided to use. A description of the information system s design and physical location. The regulatory requirements Processor agreement Section 15 of the Personal Data Act states that a processor cannot process personal data in any manner other than as agreed in writing with the controller. In addition, the data cannot be transferred to any other party for storage or processing without such an agreement. The agreement with the controller must also state that the processor is obliged to carry out such security measures as follow from Section 13. The information system s design and security measures Section 13 first paragraph of the Personal Data Act states that the controller must ensure a satisfactory level of information security with regard to confidentiality, integrity and availability in connection with the processing of personal data through the use of planned and systematic measures. Section 13 third paragraph of the Personal Data Act states that a controller that permits another party to gain access to personal data, e.g. a processor or other party that is carrying out an assignment in connection with the information system, must ensure that the party concerned fulfils the requirements in the first and second paragraphs. Physical location Section 29 of the Personal Data Act states that personal data can only be transferred to States that ensure appropriate processing of the information. States that have implemented Directive 95/46/EC on the protection of individuals with regard to the processing of personal data and on the free movement of such data, fulfil the requirement for appropriate processing. The local authority s statement The local authority has not entered into any mutual agreement with Google concerning the delivery of a solution for e-mail, but has, through system integrator Avalon Information Systems AB, been referred to Google s document which describes the service level and customer support. The local authority states that, as the solution is based on Cloud computing, no additional agreement concerning support from the supplier is necessary, other than the service levels that are listed in the standard agreement from Google. The local authority gives an account of the security measures that Google has described in the Security Whitepaper: Google Apps Messaging and Collaboration Products. In other contexts, the Data Inspectorate has found that such documents are often subject to revision by 5

the supplier without negotiation. In such a case, the local authority would have to accept such changes or choose a different supplier. The local authority refers to security mechanisms that Google describes in its Whitepaper. This Whitepaper refers to a number of security adaptations and options that the controller can implement through the solution. The local authority has not explained whether they have chosen any of these adaptations and options. The local authority believes that the supplier s Whitepaper, Google s affiliation to the Safe Harbor agreement and the fact that the local authority has access to the audit reports, should be sufficient to satisfy the authorities requirements concerning a processor agreement. The local authority states that for security reasons Google does not wish to release details concerning the supplier s IT centres. Google also does not wish to publish technical details which could compromise security. The Data Inspectorate s assessment On its website, the Data Inspectorate has presented a proposal for a processor agreement which contains the points that the Data Inspectorate believes should be included in a processor agreement. These points are: the aim and purpose of the agreement, the processor s obligations, the use of subcontractors, security, security audits, duration of the agreement, in the event of termination, communication, and choice of law and legal venue. As the processor does not wish to release information concerning the countries in which their IT centres are located, this presents challenges with regard to the requirements in a processor agreement; cf. Sections 15 and 29 of the Personal Data Act. The local authority will not be able to adequately clarify the level of security in the solution without knowing that the States to which information is transferred have an adequate level of protection for personal data. States that have implemented Directive 95/46/EC on the protection of individuals with regard to the processing of personal data and on the free movement of such data fulfil the requirement for appropriate processing. Google is an American company and it is therefore possible that information that is processed in the local authority s e-mail solution will be stored in the USA and elsewhere. The USA is currently not included in the list of countries that the Commission recognises as ensuring adequate protection for personal data. In order to remedy this, the Safe Harbor scheme was established in 2000. This scheme means that US companies can be considered as providing adequate protection for personal data that they receive from the EU/EEA if they voluntarily implement a set of rules for processing of the information. Since Safe Harbor was established, the USA has introduced a law entitled Uniting and Strengthening America by Providing Appropriate Tools Required to Intercept and Obstruct Terrorism Act, abbreviated to the USA Patriot Act, as a result of the terrorist attacks on 11 September 2001. This act is extremely complicated and comprehensive. The act gives US authorities the right to monitor terrorist suspects without charge or legal proceedings. In connection with this, the Data Inspectorate wishes to note that the USA Patriot Act must be considered as representing a challenge with regard to the safeguarding of personal privacy, even within the Safe Harbor scheme. The Data Inspectorate s conclusion 6

On the basis of the above, the Data Inspectorate does not believe that Google s standard agreement is sufficient in relation to what is expected of a processor agreement; cf. Section 15 of the Personal Data Act. In the opinion of the Data Inspectorate, the absence of a processor agreement will constitute a deviation in relation to the requirements in Section 15 of the Personal Data Act. The Data Inspectorate does not believe that the local authority has the opportunity to use a processor which, among other things, does not state which country the information will be processed in and, as a consequence of this, does not provide an adequate account of security measures; cf. Section 29 of the Personal Data Act. Point 5 A description of how the following problems have been clarified with Google: Backup Who at Google has access to the local authority s personal data? How will the local authority conduct a security audit at Google? Cf. Section 2-5 of the Personal Data Regulations. The regulatory requirements Section 2-12 fourth paragraph of the Personal Data Regulations states that personal data and other information that is necessary for the restoration of normal use must be backed up. Section 2-8 of the Personal Data Regulations states that employees of the controller must only use the information system in order to carry out assigned tasks, and must themselves be authorised for such use. The employees must possess the knowledge necessary to use the information system in accordance with the established routines. Section 2-5 of the Personal Data Regulations states that security audits of the use of the information system must be conducted regularly. The security audit must include an assessment of the organisation, security measures and use of communication partners and suppliers. If the security audit identifies unforeseen use of the information, this must be treated as a deviation; cf. Section 2-6. The local authority s statement The local authority refers to Google s Whitepaper, which states that the data will be stored on several systems at the same IT centre and simultaneously replicated to a secondary IT centre. There is no description of how Google has designed their backup system, except that it is presupposed that no data will ever be lost. As regards disposal, the Whitepaper describes how the file will be de-indexed and eventually written over by other data. Google also does not state who has access to the local authority s information, but states that this information is covered by Google s system for authorisation and access control. No statement is given of how many people this concerns and the specific job positions or access requirements that this covers is not defined. The reply concerning security audits is given with under question 2. The Data Inspectorate s assessment and conclusion The local authority has accepted Google s description of the solution. The Data Inspectorate does not believe that the local authority has any opportunity to influence how this solution is put together. On the basis of this, the Data Inspectorate does not believe that the local authority has demonstrated that the conditions in Chapter 2 of the Personal Data Regulations are met. 7

Other circumstances On pages 11, 13 and 15 of the appendix entitled Risk and vulnerability analysis for the implementation of a new e-mail system within Narvik local authority Google Apps (the analysis document), it is stated that Google has recently introduced an additional function which can be activated by the local authority in order to reject the sending of e-mail which contains words or expressions that could indicate sensitive or unacceptable content under current guidelines. The Data Inspectorate does not believe that the introduction of such an additional function will overcome the abovementioned challenges on its own. It is possible that such a solution could, depending on how it is practised, be problematic when viewed in context with Chapter 9 of the Personal Data Regulations. On page 13 of the analysis document, it is stated that an additional layer of security can be added through requiring each individual employee who sends e-mail to confirm that the e- mail does not contain sensitive personal data by typing the text Does not contain sensitive personal data in the message. The Data Inspectorate does not believe that this routine will necessarily add an extra layer of security in reality. We believe that this could be automated by the users in order to send e-mail. This is therefore a measure which can easily be circumvented and which is little suited to preventing undesirable behaviour. Segmentation of different controllers A processor cannot process personal data on behalf of a controller unless a processor agreement has been established; Section 15 of the Personal Data Act. In practice, this means that if personal data is processed on behalf of several controllers, the processor must process the personal data for each individual controller with an adequate degree of separation. In its documents, Google has not explained how this requirement is adequately met in the solution. It is however explained that the overall system will ensure that it is not be possible to extract the controller s data from a location. This could involve the mixing of information belonging to different controllers. The level of information security is common to all controllers, based on guidelines established by the processor. Such a practice could come into conflict with the role of Google as processor for different parties, which could each have differing requirements concerning security. The problem of such sequential storage becomes of even greater relevance in connection with the need to delete information from the solution. This must be done in accordance with the guidelines that different controllers establish. The problem is also of relevance in connection with the question of deletion in backup copies; cf. Section 28 of the Personal Data Act concerning deletion. In the case of a sequential database, every single entry in the database must be reviewed in order to assess whether it should be deleted, unlike a segmented database for each individual processor s data where one can go in and delete elements that are no longer relevant. This can be done in the form of segmentation of the database. Such a solution means that data from different controllers is not mixed together in a large database, but kept sufficiently separate. Segmentation will be necessary for all activity that can be attributed to a controller. This also includes copies of communicated content, logs, etc. The Data Inspectorate s conclusion In accordance with the regulations, the local authority must implement a satisfactory logical or physical segmentation of the information system, so that the requirements for a satisfactory 8

level of information security and different needs with regard to deletion between different controllers can be safeguarded; cf. Sections 13 and 15 of the Personal Data Act. Summary Given the above, the Data Inspectorate does not believe that the local authority has adequately ensured that the use of Google Apps is in line with the Personal Data Act. This particularly applies to the establishment of a valid processor agreement in accordance with Section 15 of the Personal Data Act, requirements concerning the transfer of personal data abroad (cf. Section 29) and fulfilment of the requirements concerning information security in accordance with Section 13 of the Personal Data Act. Against the background of the Data Inspectorate s conclusion, the decision is notified to the local authority. Reference is made to the following section. Notification of decision This is notification that the Data Inspectorate, pursuant to Section 46 of the Personal Data Act, will reach a decision concerning the following instruction: 1. Narvik local authority s use of Google Apps must cease, unless the processing of personal data in the solution can be brought into line with the requirements of the Personal Data Act; cf. Sections 13, 15 and 29 of the Personal Data Act. Deadline for replies Any comments concerning this notification should be sent to the Data Inspectorate as soon as possible and by 1 March 2012 at the latest. It is recommended that the company send the Data Inspectorate a proposal for a schedule for eliminating the deviations described in the control report. The Data Inspectorate will consider this schedule when it sets a deadline for the organisation s implementation of the decision. Notwithstanding the above, the Data Inspectorate will not adopt the decision referred to here if by the same deadline the organisation is able to document that the deviations described in the control report have been closed. Yours sincerely, Bjørn Erik Thon Director Stein Erik Vetland Chief Engineer 9

10