Data Processing Agreement

1. Background, purpose and scope

1.1 This agreement (the “Data Processing Agreement”) sets out the Parties' rights and obligations under Applicable Data Protection Law when the Processor processes personal data on behalf of the Controller as part of the deliveries under the Main Agreement, including the provision of Lectora as a cloud-based service (SaaS). The purpose of the Data Processing Agreement is to ensure that the Parties comply with Applicable Data Protection Law.

1.2 The Data Processing Agreement consists of this document and Annexes A, B, C and D.

1.3 In case of conflict between the Main Agreement and the Data Processing Agreement, the Data Processing Agreement prevails for matters concerning the processing of personal data. In case of conflict between the Data Processing Agreement and its annexes, the annexes prevail.

1.4 Annex A contains a detailed description of the processing to be carried out, including purposes, categories of personal data and data subjects, rules for deletion and return, and the underlying agreements the processing relates to.

1.5 Annex B contains the conditions for the use of Sub-processors and the list of approved Sub-processors.

1.6 Annex C contains specific instructions for the processing of personal data under the Main Agreement, including security measures, the Controller's rights of access and audit, and sector-specific provisions.

1.7 Annex D contains amendments to the standard text and any later agreed amendments to the Data Processing Agreement.

2. Definitions

The following definitions apply:

Applicable Data Protection Law: The version in force at any given time of the EU General Data Protection Regulation (EU) 2016/679 (“GDPR”) and the Norwegian Personal Data Act of 15 June 2018 with associated regulations, together with any other relevant legislation on the processing and protection of personal data specified in Annex C section C.7.

Main Agreement: One or more agreements between the Controller and the Processor for the delivery of services involving the processing of personal data, as specified in Annex A. The Data Processing Agreement may cover several underlying agreements.

Sub-processor: Another undertaking used by the Processor as a subcontractor for the processing of personal data under the Main Agreement.

Lectora: The Lectora platform (lectora.app), the cloud-based service (SaaS) that the Processor develops and operates, delivered under the Main Agreement. The service was previously referred to as “the Fjordbyte platform” in agreement documents between the Parties; it is the same service. Fjordbyte AS is the contracting party; Lectora is the service.

For other data protection terms, the definitions in GDPR Article 4 apply.

3. The Controller's obligations and rights

3.1 The Controller has the overall responsibility for ensuring that the processing of personal data complies with Applicable Data Protection Law (GDPR Art. 24).

3.2 The Controller shall, among other things, ensure that:

• the processing is lawful, purpose-limited and based on a valid legal basis
• the data subjects have received the necessary information about the processing
• adequate risk assessments, and where relevant a data protection impact assessment (DPIA), have been carried out
• the Processor has sufficient instructions and information to fulfil its obligations under the Data Processing Agreement and Applicable Data Protection Law

3.3 The Controller has the right and the duty to determine the purposes and means of the processing, including issuing documented instructions in accordance with section 4.

4. The Controller's instructions to the Processor

4.1 The Processor shall process personal data only on documented instructions from the Controller, unless required to do so by Union or national law (GDPR Art. 28(3)(a)).

4.2 The Controller's instructions to the Processor are set out in this Data Processing Agreement with annexes, in particular Annex C, including the instructions on the use of AI and automated processing in Annex C section C.1. Any changes to instructions shall be notified in writing through an update of Annex D.

4.3 The Processor shall immediately inform the Controller if, in the Processor's opinion, an instruction infringes Applicable Data Protection Law.

4.4 If changes to the Controller's instructions, or changes in Applicable Data Protection Law, require material adaptations of the Processor's systems, routines or deliveries, the Processor may claim coverage of documented additional costs, including a proportionate adjustment of the remuneration under the Main Agreement where changed instructions cause ongoing additional costs. Changes shall be implemented by the time agreed between the Parties or, absent a specific deadline, within a reasonable time.

5. Confidentiality

5.1 The Processor shall ensure that all employees and others with access to personal data are authorised to process such data on the Processor's behalf. If an authorisation expires or is withdrawn, access to the personal data shall cease without undue delay.

5.2 The Processor shall authorise only persons who need access to the personal data to fulfil the Main Agreement, the Data Processing Agreement, or obligations imposed on the Processor by applicable law (the principle of least privilege).

5.3 The Processor shall ensure that persons authorised to process personal data on behalf of the Controller are subject to a duty of confidentiality by contract or law (GDPR Art. 28(3)(b)). The duty of confidentiality survives the termination of the agreement and/or the employment relationship.

5.4 The Processor shall on request be able to document that the relevant persons are subject to the above duty of confidentiality.

5.5 On termination of the Data Processing Agreement, the Processor shall terminate all access to personal data processed under the agreement.

6. Assistance to the Controller

6.1 The Processor shall assist the Controller in fulfilling the data subjects' rights under GDPR Chapter III (access, rectification, erasure, restriction, data portability, objection) through appropriate technical and organisational measures, taking into account the nature of the processing (GDPR Art. 28(3)(e)). The duty to assist applies to the extent this is possible and appropriate having regard to the nature and scope of the processing under the Main Agreement.

6.2 The Processor shall, taking into account the nature of the processing and the information available to the Processor, assist the Controller in complying with GDPR Arts. 32–36, including security, breach notification, DPIA and prior consultations with the supervisory authority (GDPR Art. 28(3)(f)).

6.3 The Processor shall maintain a record of all categories of processing activities carried out on behalf of the Controller, containing at least the information required by GDPR Art. 30(2). The record shall on request be made available to the Controller and relevant supervisory authorities.

6.4 If the Processor receives requests from data subjects concerning the exercise of rights under GDPR Chapter III, the Processor shall forward the request to the Controller without undue delay. The Processor shall not respond to such requests directly without the Controller's written approval.

6.5 If the Controller requires assistance beyond the Processor's obligations under GDPR Art. 28(3)(e) and (f), the Processor may claim coverage of reasonable and documented additional costs. Work is covered in accordance with the pricing provisions of the Main Agreement.

7. Security of processing

7.1 The Processor shall implement appropriate technical and organisational measures to achieve a satisfactory level of security, having regard to the nature and scope of the processing, the state of the art, implementation costs, and the risks to the rights and freedoms of natural persons (GDPR Art. 32). The Processor shall as a minimum implement the measures specified in Annex C section C.2.

7.2 The Processor shall carry out risk assessments to ensure an appropriate level of security at all times, including regular testing, analysis and evaluation of the security measures — in particular to ensure ongoing confidentiality, integrity, availability and resilience of processing systems and services, and the ability to restore the availability of personal data in a timely manner in the event of an incident.

7.3 The Processor shall document its risk assessments and the technical and organisational measures implemented. The documentation shall be updated upon material changes and made available to the Controller on request.

7.4 The Processor shall, where relevant and available for the type of processing concerned, adhere to approved codes of conduct (GDPR Art. 40) and/or certification mechanisms (GDPR Art. 42) to which the Processor has committed, and shall on request be able to account for its adherence.

8. Notification of personal data breaches

8.1 The Processor shall notify the Controller in writing without undue delay of any personal data breach (GDPR Art. 33(2)), and shall otherwise provide the assistance and information necessary for the Controller to report the breach to supervisory authorities in accordance with Applicable Data Protection Law.

8.2 Notification under section 8.1 shall be given to the Controller's contact point in accordance with Annex C section C.8 and shall as a minimum:

• describe the nature of the personal data breach including, where possible, the categories and approximate number of data subjects concerned and the categories and approximate number of personal data records concerned,
• state the name and contact details of the data protection officer or other contact point where more information can be obtained,
• describe the likely consequences of the breach, and
• describe the measures taken or proposed by the Processor to address the breach, including, where relevant, measures to mitigate its possible adverse effects.

The information may, where necessary, be provided in phases without further undue delay.

8.3 The Processor shall implement all measures that can reasonably be required to remedy the breach and prevent similar breaches. The Processor shall, as far as possible, consult the Controller on the measures to be implemented, including considering the Controller's proposals.

8.4 The Controller has direct responsibility for contact and communication with supervisory authorities, including Datatilsynet, and for notifying data subjects in accordance with GDPR Arts. 33 and 34. The Processor shall not inform third parties of personal data breaches unless required by applicable law or expressly instructed in writing by the Controller.

9. Use of Sub-processors

9.1 The Processor shall not engage a Sub-processor without the Controller's prior general or specific written authorisation in accordance with Annex B.

9.2 The approved Sub-processors are listed in Annex B section B.2. The conditions for changing Sub-processors are regulated in Annex B section B.1.

9.3 The Processor shall enter into a written agreement with every Sub-processor imposing the same data protection obligations as those imposed on the Processor under this Data Processing Agreement (GDPR Art. 28(4)). See section 9.9 regarding standardised third-party services.

9.4 The Processor shall engage only Sub-processors that implement appropriate technical and organisational measures ensuring that the processing meets the requirements of Applicable Data Protection Law. The Processor shall carry out checks of Sub-processors to verify that satisfactory measures are in place, and shall be able to present reports from such checks to the Controller on request.

9.5 If the Controller objects to material changes in the use of Sub-processors under Annex B section B.1 b), the Parties shall negotiate in good faith with a view to agreeing a reasonable solution for continued delivery of the services under the Main Agreement, including the allocation of any costs between the Parties. The change may not be implemented before the Parties have reached agreement.

9.6 If a Sub-processor fails to fulfil its data protection obligations, the Processor shall remain fully liable to the Controller as if the Processor had carried out the processing itself.

9.7 Specific risk assessments and supplementary measures for individual vendors are set out in the notes in Annex B.

9.8 The Processor shall present agreements with Sub-processors to the Controller on request — the parts relevant to the processing of personal data, subject to any limitations following from law or regulation. Purely commercial terms cannot be required to be disclosed.

9.9 To the extent the Processor uses a subcontractor delivering standardised third-party services that the Controller has expressly accepted are delivered on the subcontractor's standard terms under the Main Agreement, and which the Processor follows up on the Controller's behalf, the Parties may agree that the subcontractor's standard data processing agreement applies directly vis-à-vis the Controller as a direct processor relationship (i.e. not as a Sub-processor), provided it meets the requirements of Applicable Data Protection Law. The Processor shall follow up the data processing agreement with the subcontractor on the Controller's behalf unless otherwise agreed in the individual case.

10. Transfers of personal data outside the EEA

10.1 Personal data may only be transferred to a country outside the EEA (“third country”) or to an international organisation if the Controller has approved such transfer in writing and the conditions in section 10.3 are met. A transfer includes, among other things:

• processing the personal data in data centres or similar located in a third country, or by personnel located in a third country (remote access)
• entrusting the processing to a Sub-processor in a third country
• disclosing the personal data to a controller in a third country or an international organisation

10.2 The Processor may nevertheless transfer personal data where required by law applicable within the EEA. In such cases the Processor shall inform the Controller to the extent permitted by law.

10.3 Transfers to third countries or international organisations may only take place where the necessary safeguards for an adequate level of protection exist under Applicable Data Protection Law. Unless otherwise agreed, such transfers may only be based on:

• an adequacy decision of the European Commission under GDPR Art. 45
• standard data protection clauses adopted by the European Commission under GDPR Art. 46(2)(c) or (d) (Standard Contractual Clauses)
• binding corporate rules under GDPR Art. 47

If a transfer mechanism relied on for an ongoing transfer is amended, revoked or lapses, the Processor shall inform the Controller without undue delay and implement the measures necessary to bring the transfer into compliance with Applicable Data Protection Law.

10.4 The Controller's approval of transfers to a third country or international organisation shall appear in Annex B section B.2.

11. Audit

11.1 The Processor shall make available to the Controller all information necessary to demonstrate compliance with the obligations laid down in GDPR Art. 28, and shall allow for and contribute to audits, including inspections, conducted by the Controller or an auditor mandated by the Controller (GDPR Art. 28(3)(h)).

11.2 Detailed audit routines are set out in Annex C section C.5.

11.3 The Processor shall contribute to and facilitate inspections by relevant supervisory authorities, including Datatilsynet, to the extent the inspection concerns processing under this agreement. Supervision of Sub-processors shall as a main rule take place through the Processor.

11.4 If an audit or inspection reveals deviations from this Data Processing Agreement or Applicable Data Protection Law, the Processor shall remedy the deviations within a reasonable deadline agreed with the Controller. In the event of material deviations, the Controller may demand temporary suspension of the processing concerned until remediation is completed.

11.5 Each Party bears its own costs in connection with audits and inspections. If an audit reveals material breaches of the Processor's obligations, the Processor shall nevertheless cover the Controller's reasonable and documented audit costs, capped at the total remuneration under the Main Agreement for the twelve (12) months preceding the audit claim.

12. Deletion and return of data

12.1 On termination of the Main Agreement, the Processor shall delete or return all personal data to the Controller in accordance with the instructions in Annex C section C.6, unless storage is required by law (GDPR Art. 28(3)(g)). The Processor's right to retain anonymised data for the further development of Lectora follows from Annex C section C.6 and presupposes that it is specified in the Main Agreement.

12.2 The Controller shall receive written confirmation from the Processor that all personal data has been returned or deleted in accordance with the Controller's instructions, and that the Processor has not retained copies, printouts or personal data in any other form. The confirmation shall be provided within a reasonable time after deletion or return is completed.

12.3 The Controller may require that personal data be returned in a structured, commonly used and machine-readable format. The Parties shall agree reasonable cost coverage for the return where it entails material additional costs for the Processor.

12.4 Where personal data forms part of shared infrastructure, backups or other systems where immediate deletion is not technically feasible, the Processor shall ensure the data is made unavailable and deleted at the first opportunity (e.g. at the next rotation or overwrite of backups). Such data shall not be used for any other purpose in the meantime.

13. Breach and orders to suspend processing

13.1 In the event of breach of the Data Processing Agreement and/or Applicable Data Protection Law, the Controller and relevant supervisory authorities may order the Processor to suspend all or part of the processing of personal data with immediate effect.

13.2 If the Processor fails to comply with its obligations under this Data Processing Agreement and/or Applicable Data Protection Law, this constitutes a breach of the Main Agreement, and the obligations, deadlines, sanctions and limitations of liability that follow from the Main Agreement's regulation of the Processor's breach apply, unless otherwise expressly agreed between the Parties in Annex D.

14. Duration and termination

14.1 The Data Processing Agreement applies from signature by both Parties and for as long as the Processor processes personal data on behalf of the Controller. It also applies to any personal data remaining with the Processor or any of its Sub-processors after the termination of the Main Agreement.

14.2 The termination provisions of the Main Agreement apply correspondingly to the Data Processing Agreement, to the extent appropriate. The Data Processing Agreement cannot be terminated while the Main Agreement remains in force unless it is replaced by a new data processing agreement.

14.3 On termination, section 5 (confidentiality) and section 12 (deletion and return) continue to apply.

15. Governing law and legal venue

15.1 This agreement is governed by Norwegian law.

15.2 Disputes arising in connection with the Data Processing Agreement shall be resolved in accordance with the dispute resolution provisions of the Main Agreement.

16. Assignment

16.1 If the Main Agreement is assigned to another party, this Data Processing Agreement shall be assigned correspondingly, so that the new party assumes the Controller's rights and obligations under the Data Processing Agreement.

17. Limitation of liability

17.1 Unless otherwise required by mandatory law, the Parties' total liability under this Data Processing Agreement — including damages, cost coverage and other claims — is subject to the limitations of liability set out in the Main Agreement.

17.2 To the extent the Main Agreement contains no limitation of liability, the Processor's total liability under this Data Processing Agreement shall not exceed the total remuneration under the Main Agreement for the twelve (12) months preceding the event giving rise to the claim.

17.3 This provision does not limit the Controller's right to audit and supervision under section 11, or the Processor's duty to assist with the fulfilment of data subjects' rights and claims under Applicable Data Protection Law.

Signatures

​

​

A. DETAILS OF THE PROCESSING

A.1 The Main Agreement and the purposes of the processing

The Processor's processing of personal data on behalf of the Controller relates to the delivery of services as described in the Main Agreement.

The Main Agreement means the Master Service Agreement entered into between Fjordbyte AS and the Controller, together with any other service agreements listed below. Where no separate Master Service Agreement exists, the listed agreements alone constitute the Main Agreement.

• [Fill in name and date of the Master Service Agreement and/or underlying service agreement(s)]

Where the description of the processing in an earlier Main Agreement deviates from this Data Processing Agreement with annexes, the Data Processing Agreement prevails (cf. section 1.3). This is particularly relevant where a pilot agreement describes processing in the institution's own cloud infrastructure: Lectora is delivered as SaaS from the Processor's own runtime environment within the EU/EEA, as set out in Annex C section C.4.

The processing has the following purposes:

• Delivery of Lectora, a SaaS learning platform with Canvas/LMS integration (LTI 1.3)
• AI-based assessment of and feedback on student submissions based on the assignment text, rubric and examiner guidance
• Adaptive learning and guidance (AI chat, quiz generation, study planning)
• Processing and indexing of course material for semantic search (RAG)
• Operations, support, troubleshooting, security monitoring and incident handling
• Subscription and licence administration for the institution
• Further development and improvement of Lectora's functionality within the framework of the Main Agreement, including iterative development of new learning and assessment features

Delimitation: This Data Processing Agreement covers institutional use of Lectora, i.e. use under the Main Agreement between the Parties. Fjordbyte's processing of personal data for its own purposes — account administration for private users (B2C), invoicing of private users, and sales enquiries — is carried out with Fjordbyte AS as controller and falls outside this agreement. If an employee or student of the institution also uses Lectora as a private user, that use is not covered here.

A.2 The nature of the processing

The Processor's processing comprises:

• Collection and receipt of identity, roles and course context via LTI 1.3 launch (OIDC/JWT)

• Synchronisation of courses, assignments, rubrics and course rosters from Canvas (Deep Linking, AGS, NRPS)

• Storage and organisation of submissions, assessments and feedback

• Processing of submissions and context through AI models to generate assessment proposals and feedback. The platform uses several AI vendors (cf. Annex B) via a common AI gateway layer; the choice of model and vendor may vary per assignment type.

• Write-back of assessment results/grades to Canvas via AGS (where part of the Main Agreement)

• Indexing of course material into vector embeddings for semantic search

• Document processing and text extraction from uploaded files (PDF, Word, images, etc.), including conversion, AI-based text extraction, generation of AI summaries and creation of vector embeddings for semantic search (RAG). Documents may contain personal data to the extent the uploader includes it.

• AI chat and guidance — persistent storage of chat sessions between the user and the AI model, including the user's messages (prompts), AI responses, and context calls against the user's study and course data. Chat history may contain personal data the user provides.

• Assessments and tests within the platform — quizzes, tests and exams conducted directly in Lectora (independently of Canvas), with recording of attempts, time spent, per-question scores and overall results, including AI-generated performance feedback.

• Import from external assessment systems — synchronisation of assessment metadata and student submissions from Inspera, and candidate-identity lookup via the Feide directory and Entra ID (where agreed with the Controller).

  • Role clarification: Canvas, Inspera, Feide and the institution's Entra ID are the Controller's own systems or services under the Controller's own agreements. They are not Sub-processors under this agreement, in the same way as Canvas (cf. Annex B). The Processor receives data from these systems on the Controller's instruction and processes it in its own environment. The use of Feide is further regulated in Annex C section C.7.3.

• Sending of system messages (e.g. assignment, status or sharing notifications) to data subjects via the e-mail vendor (cf. Annex B)

• Authorisation and access control (RBAC and tenancy isolation) by institution/organisation, course and role

• Operations: troubleshooting, support, observability/monitoring, security monitoring and incident handling

• Backup, restore and deletion/return on termination

A.2.1 Processing activities and data flows (Lectora)

The table below describes typical data flows in the application, as a practical specification complementing the points above.

A.2.2 Feature scope (link to roadmap)

Lectora's functionality is developed iteratively. The Processor maintains an internal product plan describing planned and ongoing feature areas that may be covered by the processing. The roadmap may be reviewed by the Controller on request.

New features operating within the existing data categories, purposes and approved Sub-processors described in Annexes A, B and C do not require an annex update; the Controller shall be informed in writing of material new features before they are made available.

Where new features introduce new categories of personal data, new processing purposes or new Sub-processors, Annexes A/B/C shall be updated before the feature is taken into use for the institution.

A.3 Categories of personal data

The processing covers the following categories of personal data (several may apply):

☒ Special categories of personal data under GDPR Article 9(1):

Processing of special categories is not intended, and Lectora does not request such data. Data subjects may nevertheless themselves enter or upload information falling under Article 9 in free-text fields — reflections, chat messages and submissions. Such data is processed with the high level of security required by Annex C section C.2 and in line with the principle of data minimisation. The Controller is responsible for assessing the need for a legal basis under Article 9(2) in its own risk assessment.

☒ Other data requiring particular protection:

• Performance assessments (grades, scores, AI-generated assessment proposals)
• Study reflections and free-text submissions (high confidentiality)
• Authentication and security data (tokens, sessions, access logs)

☒ Other personal data:

A.4 Categories of data subjects

Where data about a particularly vulnerable group is processed, this shall be listed specifically:

• Students are considered a group in an asymmetric power relationship with the institution in assessment situations, particularly for summative assessment.

A.5 Duration of the processing

The Processor's processing under the Main Agreement may commence when the Data Processing Agreement has entered into force. The processing has the following duration:

☒ The processing is not time-limited and lasts until the termination of the Main Agreement.

☐ The processing is time-limited and lasts until [date or criterion].

On termination, personal data shall be returned and deleted in accordance with section 12 of the Data Processing Agreement and the instructions in Annex C.

​

B. CONDITIONS FOR THE PROCESSOR'S USE AND REPLACEMENT OF SUB-PROCESSORS

B.1 The Controller's approval of the use of Sub-processors

By entering into the Data Processing Agreement, the Controller approves the use of the Sub-processors listed in section B.2. Parent, sister and subsidiary companies of the Processor also count as Sub-processors if they contribute to the delivery and process personal data.

The Processor may use a Sub-processor within the same group (parent/sister/subsidiary) established within the EEA, and shall inform the Controller in advance of such use.

The Processor may implement changes in the use of Sub-processors under the following differentiated model, which reflects that Lectora is under active development:

a) Like-for-like replacement within the same processing category: The Processor may replace an approved Sub-processor with another vendor within the same processing category (the “Description of processing” column in B.2), provided that: the new Sub-processor meets at least equivalent requirements for privacy, information security and GDPR compliance (including DPA, transfer mechanisms and technical/organisational measures); the processing purpose and categories of personal data remain unchanged; and the processing location does not change to a jurisdiction with a lower level of protection. The Controller shall be informed without undue delay, and no later than 5 working days after the change is implemented, with the new Sub-processor's name, confirmation that the conditions are met, and a reference to the relevant DPA.

b) Material changes: Changes involving a new processing category, extended processing purpose, new categories of personal data, or transfer to jurisdictions with a lower level of protection are material. The Controller shall be notified at least 1 month before the change takes effect and may object; an objection requires reasonable grounds.

c) Documentation: The Processor shall at all times maintain an up-to-date list of all Sub-processors (cf. B.2) and make it available on request. The public list at lectora.io/subprocessors shall at all times correspond to B.2.

Note: Changes involving transfers of personal data to third countries without a valid transfer mechanism (adequacy decision, SCCs or other basis under GDPR Chapter V) always require the Controller's prior written approval, cf. section 10 of the Data Processing Agreement.

B.2 Approved Sub-processors

The Controller has approved the use of the following Sub-processors. The table covers only vendors in use, or decided to be taken into use.

Not Sub-processors: Canvas is the Controller's own system; the integration (LTI 1.3 and the Canvas API) runs in the Processor's own environment. Authentication is handled by Better Auth, a self-hosted library storing users and sessions in the Processor's own database; no external authentication vendor is used. Self-hosted object storage (Garage) is operated by the Processor itself and involves no new Sub-processor.

Note — OpenAI: EU data residency, global endpoint and file storage

Lectora's primary setup uses the OpenAI API Platform with EU data residency (region Europe), so processing takes place within the EU/EEA. The EEA contracting party is OpenAI Ireland Limited.

File storage at OpenAI: Knowledge-base search runs against the Processor's own vector index in its own database (Supabase, Frankfurt); course material is not stored at OpenAI for search purposes. Files uploaded to the OpenAI Files API in connection with assessment and question extraction may contain personal data and involve short-lived storage at a Sub-processor; they are deleted programmatically after the run completes.

In addition, OpenAI's global API endpoint may be used for development and testing of features not yet available in the EU setup, and for models offered only via the global endpoint.

The transfer basis is the EU Standard Contractual Clauses incorporated in OpenAI's DPA. As of 24.08.2026 OpenAI does not reference the EU–US Data Privacy Framework in its DPA; the US adequacy decision may apply as an independent basis under GDPR Art. 45 where the receiving entity is certified. OpenAI's DPA includes a prohibition on model training on customer data, encryption in transit (TLS 1.2+) and at rest (AES-256).

When the global endpoint is used, the data-minimisation routines in Annex C still apply. Where a Controller requires exclusively EU processing, only the EU data residency endpoint is used.

Note — Vercel AI Gateway and model routing

Lectora uses Vercel AI Gateway as a routing layer for parts of the AI functionality — as of 24.08.2026 the editor AI features and chat-title generation in the AI assistant. The assistant and AI grading call OpenAI directly, without the gateway.

The gateway forwards prompt, context and model response to the selected model vendor and processes usage metadata. It is delivered by Vercel Inc. and covered by Vercel's existing DPA.

Available models are restricted in code to a fixed list: OpenAI (GPT-5-mini, GPT-5.2, GPT-5.4), Google (Gemini 2.5 Flash and Pro) and Anthropic (Claude Sonnet 4.6). Models outside the list are rejected by the application. Adopting a model vendor not listed in B.2 counts as a change in the use of Sub-processors under B.1.

Note — Anthropic: approved, planned

Anthropic is listed in B.2 because Claude models have been decided for adoption. The models are available in the codebase but not enabled in production as of 24.08.2026. The approval applies from contract signature, so activation requires no new approval round. On activation, the EEA contracting party is Anthropic Ireland, Limited; Anthropic's DPA includes EU SCCs, a training prohibition, and deletion of API inputs/outputs within 30 days. The Processor informs the Controller when the models enter production use.

Note — Mistral AI: OCR and image understanding

Processing takes place within the EU/EEA with no third-country transfer. Mistral's OCR endpoint extracts text, structure and figure descriptions from knowledge-base documents, which may contain personal data. Calls are stateless: the document is sent base64-encoded in the request, not via Mistral's file API, so no file objects are created at the vendor. Mistral's standard API retention is 30 days for abuse monitoring; Zero Data Retention is available for the stateless endpoints. The Processor shall ensure ZDR is enabled on the production account and shall be able to document this on request. The OCR engine is registry-based in the code and can be swapped for a self-hosted EU/EEA engine (e.g. Docling); Mistral would then be removed as a Sub-processor.

Note — Telemetry and error monitoring: Sentry and PostHog

Error monitoring (Sentry) and product analytics (PostHog) are off by default and enabled explicitly per environment. Both services are locked to EU regions in code: the application's environment validation refuses to start if the Sentry DSN does not point to Sentry's German region, or if the PostHog host is not PostHog Cloud EU. Changing region requires a code change and a new privacy assessment, not just an environment variable edit. User IDs sent to the telemetry vendors are pseudonymised with a dedicated HMAC key, separate from authentication and session keys. Session replay installs fully masked recorders with automatic sampling disabled; recording is started manually only on authentication and public pages. Logs, stack traces and tracing data shall not contain submission content or directly identifying personal data.

History: Statsig was previously the sole vendor for product analytics, feature flags and log/trace ingestion. It was replaced by Sentry (EU) and PostHog (EU) through a vendor-agnostic telemetry layer; the change is recorded in Annex D section D.2, and the public list at lectora.io/subprocessors is updated accordingly.

Note — Inngest: architecture, transfer basis, risk assessment and alternatives

Architecture — orchestration only, no content processing: Inngest Cloud acts purely as an orchestration platform. It receives minimal event payloads (internal IDs and job metadata) and calls back to the Processor's own serverless functions via HTTP webhooks. All actual data processing happens in the Processor's own runtime (Vercel in the EU). Inngest Cloud neither processes, stores nor has access to the content of the personal data. Inngest is SOC 2 Type II-certified and offers E2E encryption middleware.

Transfer basis — third-country transfer to the USA: Inngest Cloud hosts data in the USA (AWS) with no EU region. As of 24.08.2026 Inngest is not in the EU–US DPF register, and the public terms at inngest.com contain no DPA or SCC reference (verified 24.08.2026; the trust centre requires sign-in). In the interim, the following applies: (i) Inngest's general data processing terms as offered via trust.inngest.com, (ii) the data minimisation below as the primary safeguard — Inngest receives no personal data or content, only internal identifiers and job metadata — and (iii) Inngest's E2E encryption middleware. A signed DPA with EU SCCs will be concluded at a later date and recorded in Annex D section D.2. The Processor shall at the first opportunity download and archive Inngest's standard DPA from the trust centre and verify that it incorporates the EU SCCs; if it does not, the requirement of a signed DPA/SCCs before further use re-applies.

Data minimisation as a contractual premise: Inngest Cloud shall receive only internal identifiers and job metadata (assignmentId, submissionId, orgId, queueId, status, timestamps and error codes). Student content shall not be sent to Inngest Cloud.

Supplementary measures: document and verify payload minimisation through code review and tests; keep logs/traces free of content and direct identifiers; sign and authenticate calls from Inngest to the Processor's endpoint with key-rotation routines; use Inngest's E2E encryption middleware so Inngest Cloud cannot read payload contents; obtain and sign a DPA/SCCs with Inngest to cover the transfer.

Planned replacement: The Processor is working to consolidate durable background execution on an EU-resident backbone and thereby remove Inngest Cloud as a Sub-processor. Identified alternatives: DBOS Transact on EU Supabase (primary candidate); self-hosting Inngest (open source) in the EU/EEA; Vercel Workflow (WDK) under Vercel's existing DPA; Trigger.dev self-hosted in the EU/EEA. If Inngest is replaced, B.2 is updated under the B.1 change rules.

Note — Database, file storage and authentication

Primary database: Supabase (PostgreSQL) in AWS eu-central-1 (Frankfurt) is the chosen and only database vendor in B.2. Previously considered alternatives (Neon and Microsoft Azure Database for PostgreSQL) were never adopted and are therefore not listed (decision documented in the codebase, issue #753, 2 August 2026).

File storage: Course files, knowledge-base material, editor uploads and legal documents are stored in Supabase Storage (Frankfurt). Private storage areas are reachable only via short-lived signed URLs. Vercel Blob was considered in an earlier architecture decision but never adopted, and is therefore not listed as a Sub-processor.

Self-hosted storage: The application supports S3-compatible object storage (Garage) for installations requiring local storage, operated by the Processor itself.

Authentication: Sign-in and session management are handled by Better Auth, a self-hosted library storing users and sessions in the Processor's own database.

Note — Vendor details not publicly verifiable

Some fields are marked “Not publicly available” — mainly registration numbers of US companies, which are not published like Norwegian organisation numbers. The Processor obtains these when entering into the DPA with the individual vendor and updates the table per B.1 c).

The Processor may not use an individual Sub-processor for processing other than agreed, nor let another Sub-processor carry out the described processing, except as follows from Annex B section B.1 on the replacement of Sub-processors.

​

Annex C — Processing instructions (English translation)

Status: Courtesy translation, generated 25.08.2026 from the Norwegian master «Bilag C – Instruks vedrørende behandling av personopplysninger» (as corrected 25.08.2026). The Norwegian version prevails.

C. INSTRUCTIONS CONCERNING THE PROCESSING OF PERSONAL DATA

C.1 Scope and purpose of the processing

Personal data shall be processed exclusively to the extent and for the purposes described in the Main Agreement and the Data Processing Agreement with annexes. The Processor has no right of disposal over the personal data beyond what is necessary to fulfil its obligations, and may not process it for its own purposes.

Specific instructions for AI processing:

• Directly identifying data (name, e-mail) shall not be sent to AI models in the grading flow unless the Controller expressly instructs otherwise. Where submission content must be sent for assessment, internal identifiers are used instead of direct identifiers to the extent technically possible.
• AI vendors shall be configured with “no training” — customer data shall not be used to train or improve the vendor's models — for all processing.
• “Zero data retention” shall be used where the vendor's endpoint supports it. Where a feature requires storage at the AI vendor to function, the following applies: (i) the storage shall be expressly stated in Annex B section B.2; (ii) it shall be limited to what the feature requires; and (iii) the data shall be deleted when the associated object (knowledge base, course or account) is deleted, and at the latest on termination under section C.6.
• As of 25.08.2026 there is no persistent storage of course material at any AI vendor: knowledge-base search runs against the Processor's own vector index in its own database (Supabase, Frankfurt). Files uploaded to the OpenAI Files API for assessment and question extraction are transient and deleted after the run.
• For Mistral AI (OCR), calls are stateless with no file objects created at the vendor. The Processor shall ensure Zero Data Retention is enabled on the production account; the vendor's standard 30-day abuse-monitoring retention otherwise applies.
• Customer data shall not be used for model training or product development by the Processor, except for anonymised data pursuant to section C.6 and the Main Agreement.
• The choice and replacement of AI model and vendor may be carried out without a change of instructions, provided the other requirements of this section are maintained (EU processing or a valid transfer basis, no training, the retention requirements above, and data minimisation). Such changes follow the change rules in Annex B section B.1.
• Use of an AI gateway or routing service (currently Vercel AI Gateway) is permitted, provided the model selection is restricted to a fixed list in the application and every model vendor on the list appears in Annex B section B.2.

Pilot and beta functionality: The Processor may offer new or experimental functionality (“pilot” or “beta”) provided it operates within the existing data categories and purposes in Annex A; the Controller is informed in writing and actively opts in; and any extension of data scope, new categories of personal data or new Sub-processors is agreed in advance under Annex A section A.2.2 and Annex B section B.1.

C.2 Security of processing

C.2.1 Security level

Based on a concrete risk assessment of the scope, types of data and nature of the processing, it is determined that the processing:

☒ Requires a high level of security. Justification:

The processing covers performance assessments (grades), submissions and free text for potentially thousands of students per institution. Students are in an asymmetric power relationship. Free-text fields may contain data requiring particular protection. AI-based assessment in education is classified as “high-risk” under EU AI Act Annex III.

☐ Does not require a high level of security.

C.2.2 Information security management

The Processor shall maintain an appropriate information security management system and shall establish and maintain adequate security measures, including:

C.3 Documentation

The Processor shall document the routines and measures implemented to meet the requirements of Applicable Data Protection Law and the Data Processing Agreement, including information security. The documentation shall be retained and kept up to date for the duration of the agreement, and made available to the Controller and/or supervisory authorities on request.

C.4 Transfers — locations of processing and access

Processing may not, without the Controller's prior written approval, take place at or with access from locations other than those listed in Annex B section B.2. The restriction does not apply to the Processor's parent, sister and subsidiary companies established within the EEA. The Processor shall on request account for where personal data is processed at any given time. Location means: where the data can be accessed from; where it is processed; and where it is stored.

Lectora-specific (cf. Annex B section B.2): The overview below reflects the actual setup and shall at all times correspond to B.2; in case of deviation, B.2 prevails.

• Application hosting / compute: Vercel — EU region Frankfurt (fra1). Access from the USA may occur for operations, support and deployment.
• Primary database: Supabase (PostgreSQL) — EU (Frankfurt, AWS eu-central-1).
• File storage: Supabase Storage — EU (Frankfurt). Private storage areas are reachable only via short-lived signed URLs. Self-hosted S3-compatible storage (Garage) is supported for installations requiring local storage, without a new Sub-processor.
• AI processing (text and assessment): OpenAI API Platform with EU data residency (region Europe). The global endpoint may be used under EU SCCs for development/testing and features not yet in the EU setup, cf. the note in Annex B. File uploads to OpenAI are transient and deleted after the run; knowledge-base search runs in the Processor's own database, cf. section C.1.
• AI routing: Vercel AI Gateway — EU/USA per Vercel's DPA. Forwards prompt and context to the selected model vendor and processes usage metadata.
• AI models via gateway: Google (Gemini) — EU/EEA, contracting party Google Cloud EMEA Limited (Ireland). Anthropic (Claude) — approved and planned, contracting party Anthropic Ireland, Limited; not enabled in production as of 24.08.2026.
• OCR and document extraction: Mistral AI SAS — EU (France). No third-country transfer.
• Observability / product analytics: Sentry — EU (Frankfurt, Germany). PostHog — EU (Germany, AWS). Both off by default and region-locked in the application's environment validation, cf. C.2.2.
• Workflow orchestration: Inngest Cloud — USA (AWS). No EU region. Event payloads restricted to internal identifiers and job metadata, cf. DPA section 9.7. In the interim, Inngest's general processing terms apply together with data minimisation and E2E encryption; a signed DPA with EU SCCs will follow, cf. the note in Annex B — see the same note on the planned replacement with EU-resident orchestration.
• E-mail: Resend — USA. Transfers under EU SCCs per the Resend DPA.
• Payments: Stripe — contracting party Stripe Payments Europe, Limited (Ireland). Global processing per the Stripe DPA and Stripe's vendor list.
• Canvas: The Canvas integration (LTI 1.3 and the Canvas API) runs in the Processor's own runtime. Canvas is the Controller's own system and not a Sub-processor under this agreement.

C.5 Audit and inspection routines

☒ The Controller may audit the Processor to verify compliance. Audits shall: be conducted on reasonable prior notice and at most once a year (unless breaches justify more); take place within normal working hours without unnecessary disruption; be carried out by the Controller's employees or a third party approved by the Parties and bound by confidentiality; and be at the Controller's cost unless the audit reveals material deviations.

☐ The Processor shall use an external auditor to attest security measures (e.g. ISAE 3402 / ISAE 3000).

☒ For standardised third-party services (cloud services), third-party audits (e.g. SOC 2, ISO 27001) may be presented in place of a direct audit, where available.

C.6 Deletion and return of personal data on termination

☐ All personal data is deleted without undue delay and at the latest within 90 calendar days of termination of the Main Agreement.

☒ All personal data, and other relevant information managed on behalf of the Controller, shall be returned on termination of the Main Agreement.

After return, the Processor shall delete all personal data and other relevant information managed on behalf of the Controller within 30 calendar days, unless law requires otherwise. Deletion covers data stored at Sub-processors, including object storage and any vector stores at an AI vendor, cf. section C.1.

Specific agreement on anonymisation and further use: Under the Main Agreement, all data shall be transferred and made available to the Controller on termination. After return is completed, the Processor may anonymise data and retain the anonymised dataset for the further improvement and development of Lectora, provided the anonymisation is carried out so the data can no longer be linked to an identified or identifiable natural person (GDPR Art. 4(1)). This right presupposes that it is expressly agreed in the Main Agreement. The Processor does not use student submissions, assignments, rubrics, assessments or other customer content to train or fine-tune AI models; the right under this section applies exclusively to irreversibly anonymised data, which under GDPR Art. 4(1) is not personal data.

Return shall take place as follows, or as further agreed: structured export (CSV/JSON) for tabular data; original files in standard formats (PDF, DOCX, etc.); handover via a secure channel agreed in writing.

C.7 Sector-specific provisions

The following legislation and rules may apply in addition to the GDPR and the Norwegian Personal Data Act, depending on the institution's use of Lectora:

C.7.1 EU AI Act (Regulation 2024/1689) — high-risk AI in education

Lectora's AI-based assessment and feedback features are classified as high-risk AI systems under EU AI Act Annex III point 3 (education), which explicitly covers systems used to “evaluate learning outcomes” and “steer the learning process” (cf. Recital 56).

Application dates (updated August 2026): By Regulation (EU) 2026/1744 (the “Digital Omnibus on AI”), the application date for the high-risk obligations for standalone Annex III systems is postponed from 2 August 2026 to 2 December 2027 (2 August 2028 for Annex I-embedded systems). The following nevertheless already applies: the transparency obligations in Art. 50 (from 2 August 2026); the AI-literacy requirement in Art. 4 (since 2 February 2025); the Art. 5 prohibitions (since 2 February 2025); and the GPAI obligations (since 2 August 2025).

a) Provider obligations (Art. 16) — apply from 2 December 2027: risk management system (Art. 9); data and data-quality governance (Art. 10); technical documentation (Art. 11, Annex IV); automatic logging with logs retained at least 6 months (Art. 12); transparency towards deployers (Art. 13); human oversight — in Lectora: the instructor/examiner approves every assessment before publication (Art. 14); accuracy, robustness and cybersecurity (Art. 15); conformity assessment and CE marking (Art. 43, internal control per Annex VI); registration in the EU database (Art. 49).

b) Deployer obligations for the Controller (Art. 26) — apply from 2 December 2027: use the system per the provider's instructions; ensure competent human oversight; ensure relevant and representative input data; monitor operation and report risks/incidents to the provider; retain AI-generated logs at least 6 months; inform affected persons that they are subject to AI-supported decisions (already follows from Art. 50).

The DPIA requirement follows from GDPR Art. 35 and applies independently of the AI Act timeline where the processing is likely to result in high risk.

c) AI literacy (Art. 4): both provider and deployer shall ensure sufficient AI literacy in personnel who develop, operate or use the system. Already applicable.

Note: Fjordbyte carried out an internal EU AI Act risk assessment (April 2025) documenting current mitigations, including human-in-the-loop, accuracy validation, bias measures and transparency. Regardless of the postponed deadline, the Processor already maintains human-in-the-loop for all AI-assisted assessment, automatic logging with at least 6 months' retention, and transparency towards institution and student, as contractual obligations under this agreement.

C.7.2 The Norwegian Universities and Colleges Act (Act 2024-03-08 no. 9)

The Controller is subject to the Act, which sets requirements for examinations, grading and appeals: grades shall be set by qualified examiners and students are entitled to reasons (AI-generated assessments must be treated as proposals approved by the examiner); students may appeal and receive new grading, and the Controller shall ensure the data underlying an AI assessment is available in appeal proceedings; exam submissions, grades and grading records are subject to archiving obligations — the Processor shall assist with exports needed for the Controller's archiving duties.

C.7.3 Feide and Sikt — authentication and data sharing

If the Controller uses Feide towards Lectora (directly or via Canvas/LTI): the integration must meet Sikt's requirements for service providers; personal data received via Feide shall be used only for the purposes approved in the Feide customer portal; the Controller is responsible for ensuring shared Feide attributes comply with its data-sharing policy and Sikt's terms.

C.7.4 National policy for information security and privacy in higher education and research

The Controller may be subject to the national policy administered by HK-dir. The Processor shall on request assist with documentation necessary for the Controller's compliance.

C.7.5 Institution-specific provisions

[Fill in as needed. For institutions with their own information classification, e.g. UiB, the following wording is recommended:]

The Controller uses [the institution's information classification]. Data processed in Lectora is classified as [level]. The Processor shall comply with the measures following from the classification and shall document compliance on request.

C.8 Contact information

The following channels shall be used for notifications under the agreement:

​

​

Annex D — Amendments (English translation)

Status: Courtesy translation, generated 25.08.2026 from the Norwegian master «Bilag D – Endringer til standardtekst og endringer etter avtaleinngåelsen». The Norwegian version prevails. Section D.1 records deviations from the DFØ standard Norwegian template text (v01.2020) and is summarised here; the Norwegian original is the authoritative record of those deviations.

D. AMENDMENTS TO THE STANDARD TEXT AND AMENDMENTS AFTER SIGNATURE

D.1 Deviations from the DFØ standard text at signature (summary)

The agreement is based on the DFØ standard DPA v01.2020 with, among others, the following adaptations (see the Norwegian original for the full clause-by-clause record):

• Terminology: “GDPR” used throughout; a new definition of Lectora added in section 2 (Fjordbyte AS is the contracting party, Lectora the service; previously called “the Fjordbyte platform”).
• Sections 3–6: DPIA added to the Controller's duties (3.2); new 3.3 on the Controller's right and duty to determine purposes and means; cross-reference to the AI instructions in Annex C C.1 (4.2); assistance duties delimited to what is possible and appropriate (6.1); new records-of-processing (6.3), forwarding of data-subject requests (6.4) and cost provisions (6.5).
• Sections 7–8: documentation to be updated on material changes (7.3); adherence to codes of conduct/certifications where relevant (7.4); breach-notification contact point corrected to C.8 (8.2); no direct contact with supervisory authorities without clearance unless required by law (8.4).
• Section 9: negotiation duty limited to material changes under B.1 b) (9.5); vendor-specific risk assessments referenced (9.7); option for direct processor relationships for standardised third-party services (9.9).
• Section 10: new notification duty if a transfer mechanism changes, is revoked or lapses (10.3).
• Section 11: audit provisions split out (11.3–11.5); remediation within a reasonable agreed deadline; suspension right limited to material deviations; audit-cost coverage capped at 12 months' remuneration.
• Section 12: right to retain anonymised data (conditional on the Main Agreement) (12.1); confirmation that no copies are retained (12.2); backup data not to be used for other purposes pending deletion (12.4).
• Sections 13–17: breach ties to the Main Agreement's remedies (13.2); survival clause (14.3); new assignment clause (16); new limitation-of-liability clause capped at 12 months' remuneration where the Main Agreement is silent (17).
• Annex A: further development within the Main Agreement added as a purpose (A.1); new feature-scope/roadmap mechanism (A.2.2).
• Annex B: two-tier change model (like-for-like with 5-working-day notice; material changes with 1-month notice and a reasoned objection right); documentation duty; expanded vendor notes.
• Annex C: AI instructions (no training, ZDR, data minimisation) (C.1); pilot/beta provision (C.1); high security level with justification (C.2.1); concrete security-measures table (C.2.2); EEA group exception and Lectora-specific location list (C.4); anonymisation provision (C.6); new sector-specific provisions — EU AI Act, the Universities and Colleges Act, Feide/Sikt, the national HE security policy, institution-specific terms (C.7).

D.2 Amendments after signature (change log)

All amendments to the Data Processing Agreement or its annexes after signature shall be recorded here. The log also documents fulfilment of the notification duties in Annex B section B.1. Rows below concern changes made to the document set before signature with the individual institution; dates marked [Fill in] must be confirmed before the log is used towards a customer.

​