1. Parties, service and documents
The draft covers school use of 321school, with the school owner as controller and Fjord Service as processor.
- • Fjord Service Jan Hogne Christiansen (ENK), company no. 968 400 789. Address: Røysegata 19, 6003 Ålesund, Norway. Privacy and contract contact: post@321skole.no. The municipal contracting entity and responsible contacts are added to the individual agreement.
- • The school owner's registered name, organisation number and contact details are entered in the agreement. The agreement term, main contract, contacts and signatures are settled before signing.
- • Annex A describes processing, B security/operations, C sub-processors/transfers, and D retention, return and deletion. The annex sections below are working material, not completed contractual annexes.
2. Instructions and purpose limitation
For municipal school use, the intended agreement assigns purposes and legal bases to the municipality/school owner, with Fjord Service processing school data on documented instructions. Separate supplier purposes, such as billing and managing its own customer relationships, must be described separately.
- • The processor processes school data only on documented instructions, including non-EEA transfers. Mandatory legal requirements and potentially unlawful instructions are handled and reported to the municipality under applicable law.
- • School data must not be sold or used for third-party advertising or advertising profiles. Analytics, operations and any product improvement require an explicit purpose and basis; this is not general permission to reuse student work.
3. Access, confidentiality and security
Access is limited to authorised persons with a work-related need and confidentiality obligations. Technical and organisational controls are specified in annex B and kept current.
- • Agreed role policy: school administrators manage only their own school's teachers within its licence and receive aggregate school statistics. That role alone must not grant access to individual answers, AI feedback or teaching rooms. Administrators who also teach use separate teaching permissions.
- • The school boundary for new co-teacher and observer invitations to school rooms was deployed and checked on 6 November 2026. Invited teachers must have an active affiliation with the same school. The school administrator role does not itself grant access to individual student answers or the right to invite on behalf of the room owner.
- • Time-limited substitute-teacher access was deployed and checked on 7 November 2026. A school administrator can grant a teacher with an active affiliation with the same school access to a specific school room, including during teacher absence. The substitute can read assignments and student answers and provide written feedback through a dedicated, scoped view. Access can be revoked and expires automatically. Grants, expiry deadlines and revocations are logged. This does not grant ordinary room administration rights or general access to the school’s other rooms.
4. Assistance to the controller and individuals
The processor assists with rights requests, security, risk assessment/DPIA and privacy obligations, considering the nature of processing and available information.
- • Access, rectification, deletion, restriction and disclosure follow verified municipal instructions. Identity and authority to represent the municipality are checked before disclosure.
- • Contact: post@321skole.no. Response times and any assistance charges are agreed in the contract.
5. Personal data breaches
The processor notifies the municipality without undue delay after becoming aware of a breach and assists with available information about the incident, affected data, consequences and measures.
- • Notification recipients, substitutes, an alternative notification channel, escalation and incident procedures are specified and verified in annex B.
6. Sub-processors and international transfers
European storage does not establish that all processing stays in the EEA. Authentication, server processing, support, logs, AI and email require separate assessment. The contracting entity, countries, applicable transfer basis and supplementary measures must be confirmed for each provider.
- • Sub-processors require specific or general written authorisation. Under general authorisation, intended additions/replacements are notified to allow objections. Procedure, notice period and consequences are agreed before signing.
- • Relevant obligations are passed to sub-processors. Generic references to SCCs or EU storage alone do not establish that actual contracts and transfer arrangements are complete.
7. Evidence, audits and changes
The processor supplies relevant evidence and contributes to audits/inspections by the municipality or its authorised auditor. Scope, practical arrangements and protection of other customers' data are agreed.
- • Material changes to features, purposes, data categories or security are assessed against instructions and annexes before school use. Document versions and approvals must be traceable.
8. End of service, return and deletion
At the end of service, data is returned or deleted at the controller's choice and copies deleted unless law requires retention. Technical convenience or 'necessary logs' alone is not a general legal basis for continued retention.
- • Space removal, account deactivation, archiving and deletion are different actions. Access can stop while content remains. Deletion must also address attachments, references, provider copies and any old access links; archiving alone does not establish deletion.
- • The draft agreement proposes target periods to be agreed with the school owner: student work and related audio/files during active teaching, deleted within 90 days of the agreed end; operational/error logs 30 days and security logs 90 days. School instructions, earlier deletion and return are agreed in annex D. Specific incident evidence may be retained separately with a documented basis and review date. Enforcement has not been fully verified in operation; procedures, export, copies and provider periods are completed separately.
Annex A – processing description
The school purpose is teacher-led learning: sharing content, running activities, receiving work, giving feedback and administering use. Live is included in the proposed scope. AI support, analytics, publishing, reading tests and self-study require separate assessment; proposed restrictions are not automatically enforced.
- • Individuals: students, including students participating by code, teachers and school administrators; contacts/parents where the feature and purpose are agreed. Operations: registration, authentication, organisation, storage, viewing, feedback, any AI processing, support and instructed deletion.
- • Data: account/role/room data, student text/answers, results, teacher/AI feedback, audio/podcast segments, images, technical metadata and relevant logs. Features, data scope, duration, municipal legal bases and any special categories require agreement before signing.
- • When a teacher requests AI feedback, student answers, tasks, relevant reading text, results and necessary task context may be sent to OpenAI. A student not chatting directly with AI does not mean their work stays outside AI processing. Free text may contain personal data.
- • The Feide portal shows three attribute groups/scopes: names (userinfo-name), organisation user identifiers (userid-feide) and email (email). Stated purposes are recognition, correct account linking, secure sign-in, account administration and necessary communication. Actual disclosure depends on the organisation directory and configuration. The account flow can store names and email from Firebase. Any connected data-source sharing and actual field use are checked separately.
Annex B – security and operations
Access controls, private file handling and participant-link approval went live on 28 October 2026. Firestore/Storage rules and application flows were checked with synthetic accounts, a dedicated test room and rejection of unauthorised access. Old direct download tokens were revoked for the entire mapped set of 128 audio files, rechecked on 29 October. Files, submissions and memberships were preserved. The school boundary for new invitations was deployed on 6 November and time-limited substitute access on 7 November 2026, both with documented functional checks. The evidence covers the flows and file set examined.
- • The approval flow for new account links in Spaces is deployed. A personal participant code alone does not grant a new account/device access to existing participant work. A teacher with the required administrative access approves the link using the participant’s temporary confirmation code. Access can be revoked without deleting work. The flow was checked using synthetic accounts and a test room. Code/QR does not require private email, but does not mean student data is anonymised.
- • The school boundary for new co-teacher and observer invitations to school rooms was deployed and checked on 6 November 2026. Invited teachers must have an active affiliation with the same school. The school administrator role does not itself grant access to individual student answers or the right to invite on behalf of the room owner.
- • Time-limited substitute-teacher access was deployed and checked on 7 November 2026. A school administrator can grant a teacher with an active affiliation with the same school access to a specific school room, including during teacher absence. The substitute can read assignments and student answers and provide written feedback through a dedicated, scoped view. Access can be revoked and expires automatically. Grants, expiry deadlines and revocations are logged. This does not grant ordinary room administration rights or general access to the school’s other rooms.
- • Checks using synthetic accounts and test rooms confirmed rejection across the school boundary, continued ordinary student and co-teacher access, and that revocation and expiry block further substitute access. Existing student work was preserved. The evidence covers the flows tested.
- • Planner is paused in the published service. Navigation, direct pages, Planner APIs, AI/calendar entry points and ordinary client access to original plans are blocked. Independent task copies previously shared to Spaces still follow ordinary Spaces access. The pause does not delete or migrate existing content.
- • Production Vercel Functions run in Frankfurt (fra1), verified during deployment on 28 October 2026. The move does not automatically change processing locations for Firebase Authentication, OpenAI, Resend or other services, nor does it confine all logging, CDN, build and support processing to the EEA.
- • Daily backups are established for Firestore, Firebase Authentication accounts and finalised stored files, with storage in Belgium. Auth and file copies are verified separately. Failures or a missing health check trigger alerts to the operator and a designated backup contact. The first scheduled automatic Auth/file cycle completed and was independently verified on 4 November 2026. Incomplete file uploads are excluded from the file backup.
- • Scoped recovery tests for Firestore, files and Auth accounts were performed using synthetic data in isolated cloud environments. The procedure documents data and access checks before reopening. An integrated recovery of a Spaces file together with its document references remains a separate verification step. Data import does not necessarily restore previous sign-in sessions.
- • Deployed access controls, private file handling, participant linking and backups are described here. The annex must also specify operations/support access, encryption, change control, logs, breach notification and periodic checks, with responsibilities and supporting evidence.
- • Responsibilities, production status and Fjord Service's operational procedures must be confirmed and documented in the annex.
Annex C – providers, locations and transfers
321school uses Google Cloud Firestore and Firebase Storage in project skole-c09b8. Firestore database (default) and Storage bucket skole-c09b8.firebasestorage.app are both located in europe-west1 (Belgium). The bucket uses regional storage. Fjord Service checked the locations in Firebase Console and Google Cloud Console on October 18, 2026.
- • European storage does not establish that all processing stays in the EEA. Authentication, server processing, support, logs, AI and email require separate assessment. The contracting entity, countries, applicable transfer basis and supplementary measures must be confirmed for each provider.
- • 321school uses OpenAI Platform/API. The owner reports a DPA signed on 23 October 2026. Account images show all three sharing options disabled, API call logging Enabled per call and Project Residency Global. OpenAI states API data is not used for training without opt-in. Global is neither an EU restriction nor a single processing country. Response storage, Files, prompt caching and security logs have different rules; no general zero-retention guarantee is given. Explicit store:false in the selected text calls was deployed on 28 October 2026. This does not change the other retention rules.
- • Complete for each relevant provider: contracting entity, role, purpose, data, processing/storage countries, support access, contract/date, transfer basis and safeguards. The provider page is working evidence, not municipal authorisation by itself.
Annex D – retention and exit
The draft agreement proposes target periods to be agreed with the school owner: student work and related audio/files during active teaching, deleted within 90 days of the agreed end; operational/error logs 30 days and security logs 90 days. School instructions, earlier deletion and return are agreed in annex D. Specific incident evidence may be retained separately with a documented basis and review date. Enforcement has not been fully verified in operation; procedures, export, copies and provider periods are completed separately.
- • Daily backups are established for Firestore, Firebase Authentication accounts and finalised stored files, with storage in Belgium. Auth and file copies are verified separately. Failures or a missing health check trigger alerts to the operator and a designated backup contact. The first scheduled automatic Auth/file cycle completed and was independently verified on 4 November 2026. Incomplete file uploads are excluded from the file backup.
- • Firestore backups have 14-day retention. The Auth/file backup area has a lifecycle rule that makes copies eligible for deletion after 14 days and seven-day soft delete after actual deletion. The actual deletion time depends on when the lifecycle rule runs. Backup retention is separate from the student-work and log deadlines in Annex D.
- • Scoped recovery tests for Firestore, files and Auth accounts were performed using synthetic data in isolated cloud environments. The procedure documents data and access checks before reopening. An integrated recovery of a Spaces file together with its document references remains a separate verification step. Data import does not necessarily restore previous sign-in sessions.
- • Complete per category: period/criterion, trigger, instructing/executing parties, export format, access termination/deletion timing, backups/provider copies, mandatory retention and municipal confirmation.
