Data Processing Agreement

1. Parties and background

This Data Processing Agreement is entered into between the harbour (the "controller") and Seait AS (org. no. 930 847 763) (the "processor" / "Seait"). It governs the processor's processing of personal data on the controller's behalf in connection with use of the service, and supplements the parties' other agreement. In case of conflict, this agreement prevails on data protection matters.

The agreement ensures that processing complies with the General Data Protection Regulation (GDPR) and the Norwegian Personal Data Act.

2. Purpose and instructions

The processor processes personal data only to deliver the service and on the controller's documented instructions, including this agreement and the use of the service's features and settings. The processor informs the controller if, in the processor's opinion, an instruction infringes the rules.

The processor does not process the personal data for its own purposes and does not disclose it to others except as permitted by this agreement.

The exception is usage data about how the service is used — which pages and features are used, technical information and error messages. Seait processes this as an independent controller to operate, secure and improve the service, as described in the privacy policy. It is linked to a user account only through a pseudonymous user ID, and only when the user has consented. Sessions are recorded only with the user's consent, with typed-in values masked, and recordings are deleted after 30 days. What appears on screen in a recording is used only to troubleshoot and improve the service and never for any other purpose. Pages for signing, shared tasks and payments are not recorded.

3. Nature, duration and categories (Appendix A)

Nature and purpose of processing: operating a web-based harbour management service, including storage, organisation, display, sending notifications and invoicing. Where the controller has enabled the AI assistant, processing also includes machine-generated answers to the harbour's own questions about its own data, see clause 7.

Duration: for as long as the service agreement is in effect, with subsequent deletion/return under section 10.

Data subjects: the harbour's members and their co-owners, staff/board, guests and contact persons.

Categories of personal data: identification and contact details, boat and berth data, financial references, usage and activity data, communication, meeting and voting data, snapshots of the harbour map (boat position at a given time, linked to the member number), and data from optional modules (access, power, images). No special categories are processed.

4. Obligations of the processor

• Process personal data only on documented instructions from the controller.
• Ensure that persons with access are bound by confidentiality.
• Implement appropriate technical and organisational security measures under Art. 32 (Appendix B).
• Assist the controller in responding to data subjects exercising their rights.
• Assist the controller with security, incident handling, breach notification and data protection impact assessments (Art. 32–36).
• Make available the information necessary to demonstrate compliance, and allow for audits (section 9).
• Delete or return personal data at the end of the agreement (section 10).

5. Security (Appendix B)

The processor implements security measures appropriate to the risk, including:

• Encryption of personal data in transit (TLS) and at rest.
• Role-based access control enforced at the database level and the principle of least privilege.
• Secure authentication and access logging.
• Administrative access to hosting providers and systems is not tied to any single individual; at least two people hold such access, so that operation and incident handling do not stall if one person becomes unavailable.
• Access to personal data is granted only to the people and systems with a work-related need for it.
• Backups and recovery procedures, see section 6.
• Ongoing logging and monitoring of access and events.
• Security patching of the service and its components, including updates to third-party dependencies when vulnerabilities become known.
• Storage in the EEA and internal routines for confidentiality and incident handling.
• A standing security programme: security audits of routines, systems and access, risk assessments, vulnerability assessments of the systems, gap analyses against applicable requirements and standards, and penetration tests. Vulnerability assessments are run continuously and after every significant change; risk assessment, gap analysis and security audit at least annually; penetration testing at least every second year and on significant architectural change. Findings are followed up with measures, and summaries of the results are made available to the controller on request.

6. Backups and recovery

The database is backed up automatically once every 24 hours. Copies are stored encrypted in the EEA and retained for seven days, and data can be restored from any of them. Since copying is not continuous, a serious technical incident may cost up to 24 hours of data.

In addition, the processor takes its own independent copy of the database once every 24 hours, stored encrypted with a dedicated sub-processor in the EEA (Appendix C) and protected against change and deletion for the first 30 days. Daily copies are deleted automatically after at most 35 days; one copy per month is kept for up to twelve months. This copy means data can be restored even if the main database provider is unavailable.

Recovery is tested at least annually by restoring a copy into a separate test environment (GDPR Art. 32(1)(d)); the result is documented and made available to the controller on request.

The database is shared by all harbours, with logically separated data. The whole database is rolled back only in an incident affecting the service as a whole; where a single harbour loses data, the processor recovers it from a copy on request, within the last seven days.

The controller may itself take snapshots of the harbour map (drawn layers, berth geometry and boat positions), manually or automatically, and roll the map back to a snapshot without assistance from the processor; a rollback is written to the change log, and the change log can also be used to undo individual changes and to bring deleted rows back. The change log is immutable: entries are neither modified nor deleted, not by the processor either, and may therefore contain personal data about a person later deleted or anonymised — on the same terms as the backup copies under section 10: the log serves accountability, security and recovery and is not read in ordinary operation. The log is deleted with the harbour's data on termination; a time-based rotation of old entries may be introduced later. Snapshots hold no personal data beyond the member number and internal references to boat and berth, and are covered by the extract and the deletion under section 10. Automatic snapshots rotate on a fixed retention schedule of up to twelve monthly copies; manual ones are kept until the controller deletes them. Snapshots are stored as files within the service, never leave it, and are included in the backup described above.

Backups are a security measure and are not an absolute guarantee that all data can be restored.

No recovery time is guaranteed; availability of the service otherwise follows the service agreement. A loss of availability affecting personal data is handled as a personal data breach under section 9.

The backup covers the database, not uploaded files. Documents, images and signed agreements are stored in the EEA in redundant object storage with very high durability, but a file that has been deleted or overwritten cannot be rolled back. The controller may at any time download its own copies of data and files through the extract in section 10, without assistance from the processor, and is encouraged to do so for critical documentation.

Signed agreements are not deleted in the service — they are ended or set aside, but retained. When signing is complete, an immutable backup copy of the agreement and its signatures is taken, stored encrypted in the EEA with a dedicated sub-processor (Appendix C), where files can only be added and can neither be changed nor deleted — not by the processor either — until the retention period in section 10 has run out. The copy is used only for recovery.

7. Use of sub-processors (Appendix C)

The controller gives general prior authorisation for the processor to engage the sub-processors below. The processor enters into an agreement with each sub-processor imposing equivalent data protection obligations, and remains responsible for the sub-processor's performance.

The "When it applies" column shows which sub-processors are always in use, and which engage only when the controller takes up the feature they belong to. A sub-processor marked "optional" receives no personal data while that feature is off; the controller can therefore decline it by leaving the feature off. Providers listed as alternatives that are not in use receive no personal data and will not be engaged without prior notice under the paragraph below.

Planned changes to or additions of sub-processors are notified to the controller in reasonable time, so that it is possible to object to the change.

8. Transfers outside the EEA

Storage and core processing take place in EEA regions, and where a sub-processor offers a choice of region the EEA is selected. Email and SMS are sent through providers in the EEA. Some sub-processors are nonetheless established outside the EEA, so data may be processed in third countries — for example logs, metadata and support access, and for controllers using the AI assistant the questions and the data that answers them. Any such transfer occurs only on a valid transfer basis under Chapter V of the Regulation — the EU Standard Contractual Clauses (SCCs) with any necessary supplementary measures, or an adequacy decision, including the EU–US Data Privacy Framework. The basis per sub-processor is shown in Appendix C.

9. Personal data breaches and audits

The processor notifies the controller without undue delay after becoming aware of a personal data breach, and assists with information so the controller can meet its notification obligations to the Data Protection Authority and any data subjects.

On a personal data breach the processor investigates the incident, limits its consequences, takes the necessary measures and documents the incident — the facts, its effects and the remedial action taken — cf. GDPR art. 33(5).

The controller has the right to verify that processing complies with this agreement. The processor makes the necessary documentation available and contributes to audits, including by an independent auditor bound by confidentiality, within reasonable limits.

10. Termination, deletion and return

At any time during the agreement, the controller may download a complete extract of the harbour's data directly from the service, without assistance from the processor. The extract is provided in machine-readable format (CSV or JSON), covers every register the harbour holds in the service and is accompanied by a manifest of what was included; at the controller's choice it also includes uploaded files (harbour documents, signed agreements, signature images, boat photos and power reading photos). The right to return of data under GDPR Art. 28(3)(g) can therefore be exercised by the controller on its own, regardless of whether the processor is reachable. For security reasons, fields that constitute credentials rather than records are omitted — signing links, share links and access card numbers; which fields these are is stated in the manifest accompanying the extract.

On termination of the agreement, the processor shall, at the controller's choice, delete or return all personal data. The controller has at least 30 days from termination to extract data before deletion is carried out. Deletion in production systems is carried out within 30 days of termination, or without undue delay on the controller's instruction, and is confirmed in writing if the controller so requests. Personal data may thereafter remain in backups until the copies rotate out — in the rolling copy for up to seven days, and in the independent copy for up to 35 days for daily copies and up to twelve months for the monthly copies, see section 6; the same applies where a data subject requests erasure during the agreement. Backups are used only for recovery and are not read in ordinary operation; if a copy is restored, the deletion is carried out again.

Data the processor is required by law to retain, including under the Norwegian Bookkeeping Act, is kept for as long as the obligation lasts and deleted thereafter.

Signed agreements and their signatures are contracts of legal significance to the controller, and the processor does not delete them on its own initiative — nor after a set period. How long an ended agreement is kept is for the controller to decide, as the party responsible for retention, within what the Bookkeeping Act and limitation rules require, cf. GDPR Art. 17(3)(b) and (e). An erasure request from a data subject is carried out in the production systems as far as possible without the agreement losing its evidential value; the signed agreement itself is retained. On termination of the service agreement, signed agreements are included in the extract and thereafter treated like other personal data under this section.

The immutable backup copy under section 6 is locked for at least five years from signing, is renewed for as long as the agreement is in force, and cannot be deleted earlier — not by the processor and not on termination of the service agreement. Once the lock has run out, the copy is deleted only once the agreement has been deleted in the service.

11. Liability, governing law and venue

The parties' liability follows from the data protection rules and the underlying service agreement. This Data Processing Agreement is governed by Norwegian law, with the same venue as the service agreement. The Norwegian Data Protection Authority (Datatilsynet) is the supervisory authority.