321school Trust Center School information

321school Trust Center

Documentation for schools and municipalities

Schools, school owners, teachers, students and parents can find information here about how 321school works, the personal data it processes, and ongoing privacy and security work. The documentation distinguishes the current service, tested improvements and matters to clarify before agreed school use.

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

321school in the classroom

A platform for teachers and students. 321school, called 321skole in Norway, is provided by Fjord Service and combines teaching resources, digital classrooms and teacher-led activities.
Flexible teacher access. Teachers can create an email account with email verification. Feide is registered as a sign-in option; school activation and sign-in are checked before use. The service can be used with an individual teacher licence or a school licence within the school's agreed scope.
Simple student access. Teachers invite students to Spaces — digital class and group rooms — using personal student codes. Students can participate without their own email account. Feide is also registered for school sign-in; actual student use follows the school’s agreed setup.
Varied teaching. Teachers can create content with generators and use shared teaching resources. Much of the content can be printed or shared digitally. Writing and podcast workshops provide digital workflows, while Live brings the class together with word clouds, quizzes and image-based writing on a large screen.
Teacher-led AI support. Teachers can use AI to develop teaching content and receive feedback suggestions. Students can receive limited AI support during writing and podcast workshops. Teachers can turn support on or off and set usage limits. They review suggestions before using them as their own feedback.
School data is not sold to third parties. Information about privacy, storage, providers and data flows is collected in the Trust Center.

Information by role

School owner and municipality

Assess processing, contract, providers, Feide, security and open points.

Teacher and school administrator

See the distinctions between teaching access, administration, AI and aggregates.

Students and parents

Read about student access, sign-in and privacy, and how schools handle access and deletion requests.

1. Privacy notice

321school is the service brand. The legal supplier is Fjord Service Jan Hogne Christiansen (Norwegian sole proprietorship/ENK), referred to below as Fjord Service.

School privacy General privacy notice

2. DPA – draft

This is a general draft agreement with annex material for assessment by the school owner. The parties, processing scope and annexes must be clarified and legally reviewed before any signing.

DPA draft and annex evidence

3. Personal data

The school overview describes data about teachers, students using accounts or personal codes, and school administrators, along with student work, media and technical data.

Data categories and flows Retention and rights

4. Storage, providers 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.

Provider and transfer inventory Annex C

5. Purpose and users

321school supports teachers in planning, teaching and following up student work through learning resources, digital class and group rooms, and Live activities. Teachers and students use the teaching features, while school administrators manage their own school's use. The links below explain AI and other feature choices.

Uses and roles AI in teaching Features and municipal assessment

6. Feide and shared information

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.

Feide in the school overview Sikt/Feide and roles

Teaching possibilities and school needs

321school combines teaching resources, Live activities, language support and digital writing and podcast workshops. Translation and reading aloud are useful AI-based support features. Schools and school owners can explore how these possibilities fit their teaching goals and requirements.

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.

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.

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.

Live and teacher-led activitiesPart of the platform

Data flow: Live brings the class together with word clouds, quizzes and image-based writing. Word clouds and image-based writing display answers on the big screen without student names. Display names may appear in the lobby, and quizzes show aliases in the results. Technical participant IDs, answers, results and timestamps may be processed; answers without names are not necessarily anonymised data.
Feature and documented status: Live is part of the platform teaching features. The teacher organises the activity and students join through its Live flow. Data, answer display and retention depend on the activity; access controls and production status remain part of security verification.

Translation, vocabulary and reading aloudPart of the platform

Data flow: 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.
Feature and documented status: Translation, vocabulary and reading aloud support teaching. In the model, student access follows the activity and valid room access regardless of personal code, Feide or another login. Text-to-speech sends text and selected voice to OpenAI. Consistent server access and quota enforcement remain follow-up items.

Podcasts and optional AI supportPart of the platform

Data flow: Notes, scripts, participant fields, recordings, segments and finished podcasts may be stored. AI support can send tasks, student text, podcast names, participant fields and other completed work to OpenAI. This does not mean all recordings are sent to AI.
Feature and documented status: Teachers control podcast AI support with on/off and usage limits. The server route checks membership and submission binding. Support follows the teacher activity rather than unrestricted student AI. Downloading a finished podcast and public publishing are different actions. Any school-owner restriction on processing student text requires development and testing. Download and export fixes from synthetic tests are included in the published source from 28 October 2026.

Process-oriented writingPart of the platform

Data flow: Plans, drafts, fields, submissions and feedback may be stored. AI support can send student text, relevant drafts and task/section context to OpenAI. Image support has separate data flows.
Feature and documented status: Activity/section AI settings exist. The server route checks whether AI is enabled and which support actions are allowed. These settings are not a unified municipal policy.
Possible adaptation for the school owner: For specific requirements, assess one shared restriction on AI support processing student work in writing and podcast workshops. Writing and recordings can remain available without it. Clarify text/media retention together. Shared enforcement requires development and testing.

Teacher AI tools and AI feedbackPart of the platform

Data flow: Content generation sends teacher prompts and selected material. Submission feedback can send student answers, tasks, reading text and results. These are different processing activities; pasted teaching material may also contain personal data.
Feature and documented status: Teachers have AI tools for content and feedback suggestions within their licence. Access to specific submissions requires teaching permission; school administration alone does not grant it. Teachers review AI suggestions before using them as their feedback. Teacher-requested AI feedback is a separate feature from student AI support. Production and provider checks remain separate.

Analytics, statistics and operational logsPart of the platform

Data flow: Operational and security logs may contain technical events. Educational results and school statistics are part of the teaching features.
Feature and documented status: 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.

Public publishing and sharingPart of the platform

Data flow: Publishing can make selected content available outside a teaching room. Text, names, images or voices may identify students. An unlisted link is not authenticated private access.
Feature and documented status: 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.
Possible adaptation for the school owner: At the school owner's request, we can develop a restriction that disables public publishing for its staff. This would also cover teachers' own teaching materials, so lessons about local history and culture, for example, could no longer be shared publicly. The adaptation requires development and testing before use.

Reading testsUnder development

Data flow: The feature may process answers, reading results, timing/activity signals and recordings where used. Test generation and AI feedback on results are different data flows.
Feature and documented status: Reading-test code exists, but the area remains under development and is not ready for ordinary school use. Development status is part of the feature description, not a municipal option.

Discuss specific needs with the school owner. Possible adaptations concern AI processing of student work, storage, analytics and public sharing. Other areas describe teaching possibilities and data flows.

Udir: school-owner privacy responsibilities

Storage and international processing

• 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.
• 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.
• Firebase Authentication: Google documents US processing. Vercel, OpenAI, Resend and other relevant services require account, contract and feature checks.

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.

• Login, guest identity, preferences and drafts can use cookies/browser storage. Analytics and necessary functional storage must be described separately.

DPA, annexes and document status

This is a general draft agreement with annex material for assessment by the school owner. The parties, processing scope and annexes must be clarified and legally reviewed before any signing.

• The draft covers processing, security, providers/transfers and retention/deletion. The municipality's template can use the same evidence.
• 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.
• The municipal report PDF is a summary with links. It does not automatically include every full document or signed annex.

Feide and shared information

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.
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.
Feide approval does not replace a school contract, legal basis or privacy/risk assessment, and does not automatically confer school administration.

Further assessment – area by area

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.

Contact Fjord Service