Privacy for schools

Information about personal data, purposes and responsibilities when using 321school in schools. A shared reference for schools and school owners assessing the service.

Review draft v0.12. Content revised: November 12, 2026.

Supplier

321school is supplied by Fjord Service. Company details and the privacy contact are provided below.

Student access

Students can participate using a personal code without a private email. Participation is linked to a technical user ID.

AI in teaching

AI is used for language support and feedback suggestions, among other features. Relevant text and student work may be sent to OpenAI.

Documentation for school owners

This page describes the current service, proposed adaptations and matters to clarify before an agreement.

Municipal assessment and feature scope

General evidence for municipalities and schools assessing 321school. It describes the platform, data flows, limitations and open questions. It is not a completed municipal agreement or approval of every feature for school use.

Fjord Service works systematically on internal control, privacy and information security as an ongoing part of operations. Access controls, private file handling, participant-link approval, school boundaries for invitations, time-limited substitute access and daily backups are deployed and checked. Data-flow mapping, provider clarifications, retention procedures and documentation continue to be maintained, with clear responsibility and verification for each measure.
School-use model: Teachers have AI tools for creating and developing teaching content and feedback suggestions within their licence. Students in Spaces have translation, vocabulary, reading aloud and teacher-controlled activity support, without unrestricted AI generators through school use. Support access follows the activity and valid room access, whether using a personal code, Feide or another sign-in method.
Since 11 November 2026, a platform administrator can disable AI feedback suggestions for Lessons answers and AI help in writing activities across Space rooms linked to one verified school, including new rooms. Rooms may apply stricter settings; a room cannot override the school's restriction. These settings are not automatically enabled for every school. Rooms without a verified school link are outside their scope. Other AI features and school-owner-wide controls are not covered by these two restrictions.
This is 321school's school-use model. School and room restrictions for the two specified Spaces features are deployed. The technical account boundary between school use and individual self-study was also deployed and checked with synthetic accounts on 11 November 2026. Broader AI enforcement and school-owner controls remain under assessment. This does not establish that all AI restrictions are implemented.
The account boundary between school use and individual self-study was deployed and checked with synthetic accounts on 11 November 2026. A Feide-linked or active school-linked student account cannot enable individual self-study, including when an older profile selection points to self-study. Self-study requires a separate individual account; school data and student work are not transferred automatically. Teachers can still use Feide for teaching tools. Actual Feide sign-in will be checked when the school owner activates the service.
Possible adaptations focus on AI processing of student content, media retention, product analytics and public sharing. Live, language support and general teacher AI tools are not a menu of municipal choices. Specific blocks require assessment, development and testing before being offered.

Supplier and school responsibilities

321school is supplied by Fjord Service. Company details, contact information and school-use responsibilities are set out below.

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.
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.

Purpose and users

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.

Teachers create rooms, activities and tasks. Students participate using a personal code or an account agreed with the school. Parents receive information about school use through the school.
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 owner must approve accounts, participation by code and AI for the age group and teaching context. A general age-13 threshold or parental acceptance does not replace the municipality's assessment of legal basis, contract and risk for school use.

Student access and accounts

Students can participate by code/QR without a private email or personal Feide login. Participation is linked to a technical user ID, chosen display name, room membership and submitted work. These may be personal data; anonymous authentication does not mean anonymised work.

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.
When participating without a personal account, the student's technical identity may be browser-bound. A new device, private browsing or cleared browser storage may create a new identity. Linking to a signed-in account can retain associated work.
School-created student accounts may use a school-assigned login identity instead of a private email. Account type and procedures for issuing/resetting login details must be agreed with the school.

Personal data by user group

Data depends on the account type and features actually used. The processing annex must limit these categories to the municipality's use.

Teacher: user ID, name/display name, email when available, login provider, role, any school affiliation, rooms, tasks, content, usage/quota information and timestamps.
Student account: user ID, name/display name, any email or school-assigned login identity, role, room membership, answers, results and teacher/AI feedback. The authentication provider processes necessary login information.
Student without a personal account: technical user ID, chosen name, room/activity membership, work, any attachments and timestamps. Text and attachments may contain personal data even when email is not collected.
School administrator: account/contact data, school, membership/licence administration, administrative events and aggregates for their school. Individual answers are outside the role's agreed access.

Student work, media and technical data

Student content may contain personal data even when the form does not request it. Use only data and media needed for the school purpose.

Work: free text, answers, writing, submission status, results, reading/activity times and feedback. Reading-test signals support learning and are not an official diagnosis.
Media: student audio, reading recordings, podcast segments, writing images and shared board images, linked to relevant users, rooms or activities. Voices and images may identify students.
Automatic/technical: authentication metadata, timestamps, page/events and necessary operational/security logs. Infrastructure providers may process IP addresses and browser/device information. Scope and retention must be documented per service.

AI and student work

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.

Teachers have AI tools for teaching content and feedback suggestions. Students in Spaces use translation, vocabulary, reading aloud and teacher-controlled activity support. Students' open-ended AI generation belongs to individual self-study outside the school account. The account boundary is deployed and tested with synthetic accounts; broader AI enforcement remains under assessment.
Translation, vocabulary support and text-to-speech are AI-based support features in 321school. Text for translation or reading aloud and relevant language context may be sent to OpenAI. They can support comprehension, language learning and access to teaching content. Assess them separately from open-ended AI generation and AI feedback. Ordinary student recordings and audio playback do not themselves imply AI processing.
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.
AI feedback is a suggestion. Teachers must review it before using it as their feedback or assessment. Avoid unnecessary names, health details and private family information in prompts and free text.

Feide and account access

The service is registered in the Feide customer portal as Innlogging 321skole, service ID 2196690, listing Fjord Service as provider and OpenID Connect as authentication type. Sign-in uses Firebase Authentication. Registration is documented in console images from 25 October 2026. Each school owner’s activation and actual sign-in are checked before Feide is used there. Licences, roles and room access are managed in 321school.

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.
Attributes listed in the Feide portal: userinfo-name includes givenName, sn, norEduPersonLegalName, displayName and cn; userid-feide includes eduPersonPrincipalNamePrior, eduPersonPrincipalName, uid, eduPersonTargetedID and eduPersonUniqueId; email includes mail. These are configured requested fields, not proof that every field is received or stored. Feide identifiers must be distinguished from the Firebase UID.
Feide approval is not a DPA, purchased licence or admin assignment. The reviewed code does not grant school administration from Feide login alone. The ordinary client flow does not request a national identity number; the complete attribute configuration must be confirmed.

Storage, recipients 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.
Google/Firebase, Vercel and OpenAI have different tasks. Email, payments, Feide and external video/course content also require a defined scope. Not every listed service is necessarily a sub-processor of student data under the individual agreement.

Browser storage and analytics

Google Analytics and application product analytics are disabled in the published service, regardless of role. Necessary operational/security logging and educational statistics are separate purposes and are not disabled by this measure. Aggregate statistics are not necessarily anonymous, especially in small groups.

Google Analytics and application product analytics are disabled in the published code policy for all roles, deployed on 28 October 2026. This was checked in source and tests and on a selected public page view. Necessary operational/security logging and educational results are described separately. Any later activation of product analytics requires a separate assessment and documented change.
Firebase login and features may use cookies, IndexedDB, localStorage and sessionStorage. Browsers may also retain technical user identity, preferences and drafts. Clearing browser data does not delete work stored on the server.
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.

Retention, rights and 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.

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.
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.
For school use, students/parents normally contact the school/municipality. Fjord Service assists on verified instructions and identity checks. The controller assesses rights and exceptions; complaints may be made to the Norwegian Data Protection Authority.

Security and documentation status

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.

Visibility controls for lesson publishing were deployed and verified in production on 12 November 2026 using synthetic data. Publishing requires an explicit visibility value: public, unlisted or private. The library lists only active public copies. Anyone with the link can open an unlisted copy; this is not private access. Private copies require owner or platform-administrator access and are excluded from public listings and page metadata. Unpublishing closes public access to the copy while retaining its content and the owner's access.
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.
Since 11 November 2026, a platform administrator can disable AI feedback suggestions for Lessons answers and AI help in writing activities across Space rooms linked to one verified school, including new rooms. Rooms may apply stricter settings; a room cannot override the school's restriction. These settings are not automatically enabled for every school. Rooms without a verified school link are outside their scope. Other AI features and school-owner-wide controls are not covered by these two restrictions.
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.
The agreed access model distinguishes teaching permissions, Space membership, school licence and global account status. Small groups and combined statistics require assessment to avoid unintended identification.
The security annex will bring together documented measures and describe responsibilities, log access, retention, recovery and incident handling. Completed checks and further follow-up are described separately.

Contact us about privacy and school use

Contact Fjord Service at post@321skole.no about privacy, data use or adaptation needs. The scope and implementation of any adaptations are agreed in dialogue with the school owner.

Contact Fjord Service Providers and locations Access and deletion DPA draft and annexes AI and data flows