Last updated: 2026-06-25
This page is aimed at municipal procurement officers and data protection officers (DPOs) who need to review Skolkoll's data processing prior to contract. For a general overview, see the privacy policy. For a data processing agreement (DPA), see the DPA template.
1. Roles and contact
For personal data covered by the Municipal Licence agreement, the municipality is the data controller and Skolkoll is the data processor. For personal data Skolkoll processes for its own purposes (e.g. visitors to skolkoll.se without an account), Skolkoll is the data controller — see the privacy policy.
Data processor (Skolkoll): Skolspegeln AB
Organisation number: 559359-7288
Contact for data protection enquiries: markus@skolkoll.se
Skolkoll has not appointed a Data Protection Officer (DPO) because the operation does not meet the criteria in GDPR art. 37 (the core activity is not large-scale monitoring of personal data; no special categories of personal data are systematically processed).
2. Subprocessors
Skolkoll uses the following third-party services to provide the service. All have their own DPAs that comply with GDPR. The identity providers used for social login process authentication data under their own terms and the EU Standard Contractual Clauses (SCCs).
| Provider | Service | Data category | Region | DPA |
|---|---|---|---|---|
| Google Cloud (Firebase) | Hosting, Firestore, Cloud Functions, Cloud Storage, Authentication | User accounts, organisation data, analyticsEvents, billing history | Cloud Functions, Hosting, Cloud Storage and Firestore: europe-west1 (Belgium). Firebase Authentication is covered by the Google Cloud DPA/SCCs/DPF without a separate europe-west1 assertion here. | Google Cloud DPA (SCCs included) |
| Stripe Payments Europe Ltd | Payment processing (card + invoice) | Billing address, email, organisation number, payment metadata. Card details never pass through Skolkoll's servers. | Ireland (EU) primarily; some fraud-detection functions may involve Stripe US under SCC. | Stripe DPA |
| Resend Inc. | Transactional email (account confirmations, invoices, watcher digests, security alerts) | Email address, name, subject, message body (deleted at Resend after 30 days) | EU/US (Resend's EU region used where available; SCCs apply for any US transfer) | Resend DPA |
| Functional Software, Inc. (Sentry) | Error monitoring for frontend and Cloud Functions | Error messages and stack traces, browser, OS, IP address (anonymised shortly after receipt by Sentry). In exceptional cases a stack trace may contain form data that was active when the error occurred. | EU (Germany, ingest.de.sentry.io); SCC for any support by US team | Sentry DPA |
| Zoho Corporation / Zoho PageSense | Web analytics, A/B testing, heatmaps/session recording on public pages after consent | Page views, clicks/scrolling, heatmap and session-recording interactions, experiment variant, device and browser info. PageSense is not activated on noindex/account/admin pages and is loaded only after analytics consent. | EU script via cdn-eu.pagesense.io; Zoho DPA/SCCs for any transfer outside the EU/EEA | Zoho GDPR/DPA |
| Zoho Corporation / Zoho Desk | Customer support via support@skolkoll.se/the support portal and journalist data-order tickets when the Zoho intake has been approved and enabled | Name, email address, organisation membership or newsroom/outlet context, ticket/order content, ticket history, internal triage tags, private quality/neutrality comment with risk class/flags, and technical attachments voluntarily submitted by the customer or journalist. | EU (the support portal support.skolkoll.se points to Zoho EU hosting, zohohost.eu); Zoho DPA/SCCs for any transfer outside the EU/EEA | Zoho GDPR/DPA |
| Zoho Corporation / Zoho CRM | CRM contact for journalist data orders, server-side only after the Zoho intake has been approved | Minimal relationship metadata: name, email address, newsroom/outlet, beat, source and order status. Not used for campaign/newsletter sends without separate consent and provenance. | EU API via www.zohoapis.eu; Zoho DPA/SCCs for any transfer outside the EU/EEA | Zoho GDPR/DPA |
| Anthropic / OpenAI | "Kollen" AI chat and AI-based school-image stylisation (only after consent) | Chat messages + school context, and uploaded school-image submissions that are transformed into a chalkboard-style illustration. The image is then processed under OpenAI's own safety and content policies; the editorial review and approval before publication is done by a human. For school images, the image file is sent to OpenAI; contact details, photographer name, rights-holder name and free-text form notes are not sent to the AI provider. AI chat requests are flagged "no-store" where the API supports it (Anthropic: opt-out from training is the default). | US (Anthropic) or EU/US (OpenAI) — under SCC | Anthropic DPA · OpenAI DPA. Active only when the user has given consent in the chat window or school-image form. |
| Identity providers (Google, Microsoft, GitHub, Facebook, Apple) | Social login (OAuth/OIDC) — only if the user chooses this sign-in method instead of email/password | Name and email address from the chosen provider at sign-in | US (all) — under SCCs | Each provider's DPA/terms; transfer to the US under the EU Standard Contractual Clauses (SCCs) |
AI processing of school images
When you submit the school-image form, separate consent is required before the image may be sent to OpenAI for AI-based chalkboard stylisation. The image is then processed under OpenAI's own safety and content policies. The content review and approval of the image before publication is done by a human editor — Skolkoll runs no separate AI moderation step. The image file may be sent to OpenAI, but contact details, photographer name, rights-holder name and free-text form notes are not sent to OpenAI. Those details are stored in Skolkoll's Firestore for editorial review, attribution, rights tracking and possible disputes.
For Municipal Licence data (user accounts, organisation data, billing history) we use no advertising networks, marketing platforms, or social media pixels. Web analytics via Google Analytics 4 and Zoho PageSense runs only after explicit cookie consent from visitors on public, indexable pages — see the privacy policy for details. For signed-in municipal users no GA4 or PageSense tracking is performed regardless of consent. Internal usage statistics are collected via our own anonymous collector in Firebase without personal data.
Notice of subprocessor change
While a Municipal Licence is active, we notify the agreed contact person, DPO and the organisation's administrators by email at least 30 days before adding or replacing a subprocessor. The municipality has the right to object during that period — objections are handled per the Municipal Licence agreement's termination clause. We do not use the new subprocessor for the municipality's personal data before the objection has been handled or the termination period has expired.
3. Retention periods per data category
Periods are measured from the most recent event (e.g. last login, last payment). After the listed time the data is deleted or anonymised.
| Data category | Firestore collection | Retention | Legal basis |
|---|---|---|---|
| User accounts (profile, memberships) | users, organizations/{id}/members | Until deleted by the user. Inactive accounts (24 months without login) receive a reminder and are deleted after 36 months. | Contract (art. 6.1.b) |
| Organisations + Pro subscriptions | organizations, organizations/{id}/subscriptions | Active for the lifetime of the subscription. Billing history retained for 7 years (Swedish bookkeeping act). | Legal obligation (art. 6.1.c) for bookkeeping |
| Analytics events (raw) | analyticsEvents | 90 days, then individual events are deleted. Aggregated daily summaries (no personal data) are retained indefinitely. | Legitimate interest (art. 6.1.f) — product development. No personal data is stored (sessionId is random, no IP, no user-agent). |
| Widget beacon and abuse triage | widgetAbuseLog | Only anomalous or suspicious widget loads are logged. Entries are written with expiresAt = now + 30 days and deleted through Firestore TTL when the TTL policy for widgetAbuseLog.expiresAt is active. | Legitimate interest (art. 6.1.f) — attribution, rate limiting, abuse and security traceability. Contains embedder origin, widget type, municipality/school slug, anomaly flags and a salted IP hash; no cookies. |
| Mail contacts and campaign lists | mailContacts, mailLists, campaigns | Until unsubscribed. Unsubscribed contacts retain an anonymised email hash (to prevent re-subscription) for 24 months, then full deletion. | Consent (art. 6.1.a) for newsletters; contract (art. 6.1.b) for transactional emails. |
| Audit log | auditLog | 2 years. Each new entry is written with expiresAt = now + 2 years and is deleted by Firestore TTL when the TTL policy for auditLog.expiresAt is active. TTL deletion is asynchronous after expiry. | Legitimate interest (art. 6.1.f) — security, traceability, access-control review and dispute/incident investigation. |
| API usage quota | apiQuota/{orgId}/months/{YYYY-MM} | 13 months (for billing reconciliation and dispute). | Legal obligation (art. 6.1.c) |
| Watchers | watchers, watcherEvents | Active watchers are stored until the user ends them or deletes the account. Pending confirmations have a 48-hour token window and are cleaned by the cleanup flow. Watcher events in watcherEvents are cleaned continuously by the digest job, normally within 35 days. | Consent (art. 6.1.a) for anonymous double opt-in; contract (art. 6.1.b) for signed-in account features. |
| Journalist data orders | journalist_orders | FAS-0 decision: the Firestore record is deleted once the order is handled plus a recovery window, with a target of 180 days from submission. Each record is written with a purgeAfter field and Firestore TTL for that field must be deployed and verified before full go-live; until TTL is active, FAS-0 requires a named monthly manual purge owner. Orders unresolved after 180 days require documented approval and have a 12-month hard cap. Zoho Desk tickets are deleted no later than 12 months after closure. The Zoho CRM contact is reviewed at least annually and order-specific status/description is removed when no longer needed. | Consent (art. 6.1.a) for storage/contact through the form; request handling/pre-contractual steps where applicable (art. 6.1.b); legitimate interest (art. 6.1.f) for abuse prevention, operational recovery and editorial relationship handoff. No campaign or newsletter use without separate consent/provenance. |
| School-image submissions and rights data | schoolImageSubmissions | Pending submissions are retained until editorial review is complete. Rejected submissions are deleted after 90 days through the cleanup flow. Approved submissions and associated rights data are retained for as long as the image is used as source/provenance material for a published school image, or until deletion/unpublication is requested and can be completed without breaking rights tracking. | Upload and AI processing: consent (art. 6.1.a). Attribution, rights tracking and possible disputes after review/publication: legitimate interest (art. 6.1.f). Fields may include photographerName, rightsHolderName, contactEmail, contactPhone, schoolName, note and image file. |
| Deletion evidence for rejected school images | imageCleanupAudit | 7 years from cleanup. Each entry is written with expiresAt = deletedAt + 7 years and is deleted through Firestore TTL when a TTL policy for imageCleanupAudit.expiresAt is active. The entry contains only submissionId, cutoff date, deletion reason, deletion timestamp and an optional HMAC-SHA-256 hash of the contact email — not raw contact data, image files, school name or free text. | Legitimate interest (art. 6.1.f) and accountability under GDPR art. 5.2 — being able to answer whether a previously deleted image submission was processed without retaining raw personal data. |
| AI chat conversation | Browser sessionStorage only — never on our server. | Deleted when the browser tab is closed. | Consent (art. 6.1.a) |
| AI audit log | ai-audit-log | Each entry is written with expiresAt = now + 90 days. Deletion happens through Firestore TTL when a TTL policy on expiresAt is active; TTL deletion is asynchronous after expiry and cannot be guaranteed exactly on day 90. Operational release verification: gcloud firestore fields ttls list must show an active TTL policy for ai-audit-log.expiresAt. | Consent (art. 6.1.a) and legitimate interest (art. 6.1.f) — abuse and security traceability. |
4. Right to erasure — operational flow
You can exercise the right to erasure (GDPR art. 17) in the following ways, sorted from fastest to most manual:
AI audit log — TTL and manual deletion
The AI chat does not permanently store questions or answers on Skolkoll's server. For abuse and security traceability, the server writes one pseudonymised audit entry to the Firestore collection ai-audit-log for each AI call. The entry contains call type, SHA-256 hash of the IP address truncated to 16 characters, school context (maximum 50 characters), question and answer length, status, timestamp, and expiresAt.
Normal retention is 90 days: each entry is written with expiresAt = now + 90 days. Firestore's TTL mechanism deletes the entry asynchronously after expiresAt when the TTL policy for ai-audit-log.expiresAt is active. TTL is not an exact deletion timestamp; deletion can happen some time after the field's timestamp has passed.
To request earlier deletion, email info@skolkoll.se with the approximate time and any school context for the AI call. We then search server-side for matching entries and manually delete identifiable matches using the Admin SDK. If an entry cannot be matched without collecting additional data, it remains until the TTL retention expires.
School-image submissions — unpublication and deletion
If you have submitted a school image, you can request unpublication, deletion or correction of photographer/rights-holder data by emailing info@skolkoll.se. Include the school, approximate upload time and the email address used in the form. Rejected submissions are deleted automatically after 90 days. The cleanup flow leaves minimal deletion evidence in imageCleanupAudit so we can answer whether the submission was processed after the raw data has been deleted. For approved/published submissions we perform a manual rights check before deletion, because attribution and rights tracking may need to be retained to handle licence or dispute questions.
Journalist data orders — manual deletion
If you have submitted a no-account data order, you can request deletion or correction by emailing info@skolkoll.se. Include the approximate time, outlet/newsroom and the email address used in the form. We then search for matching journalist_orders records, manually delete or correct identifiable matches, and, if the Zoho intake was enabled, handle the corresponding Desk/CRM record unless there is an ongoing delivery, dispute, regulator request or other legal basis for continued limited retention.
Self-service — user account
- Sign in to the Skolkoll portal.
- Go to Account settings.
- Click Delete account. Confirm the dialog.
- The account, your memberships, watchers and profile information are deleted immediately from the database.
What is not deleted automatically: billing history is retained for 7 years per Swedish bookkeeping law. Audit log entries (auditLog) are tagged with expiresAt for 2-year retention and deleted asynchronously by Firestore TTL when the policy is active. Aggregated analytics data already contains no personal data and is unaffected.
Erasure request — Municipal Licence administrator
As a municipal admin you can request erasure of a specific employee from the organisation by emailing support@skolkoll.se. We acknowledge receipt within 1 working day and complete the erasure within 14 days (the GDPR limit is 30 days).
Erasure request — external person (head teacher objecting)
If you are a named head teacher and object to your name being shown: email info@skolkoll.se with the school's unit code. We remove your data from the display within 14 days and update our sync filter so the data does not return even if Skolverket continues to publish it.
5. DPIA-light — risk assessment for Municipal Licence
For Municipal Licence customers we have done a simplified Data Protection Impact Assessment (DPIA-light) per GDPR art. 35. A full DPIA is not mandatory because the processing does not meet high-risk criteria (no large-scale monitoring, no special categories, no automated decision-making affecting individuals).
Identified risks and mitigations
| Risk | Likelihood × Impact | Mitigation |
|---|---|---|
| Unauthorised access to organisation data | Low × Medium | Firebase Auth with MFA support; admin role check on the server side; auditLog for all admin actions. |
| Data leak via subprocessor (Firebase, Stripe, Resend) | Low × High | EU regions where possible; SCCs for US transfers; least-privilege data sets (Stripe sees no school data; Resend sees only email + subject). |
| Incorrect publication of head teacher's name | Medium × Low | Source is Skolverket's open API; right to object via email with 14-day response; manual sync filter applies objections permanently. |
| Vulnerability in the open analytics endpoint | Low × Low | Origin allowlist, distributed rate-limiting, and event size caps. No personal data is collected in analytics. |
| Operational incident — silent scheduled-function failure | Medium × Low | Error-alerting wrapper emails ops on every scheduled-function failure. Manual backfill endpoint exists for critical syncs. |
6. Personal data breach
In case of a suspected personal data breach:
- Skolkoll gives affected Municipal Licence administrators and the Data Controller's agreed contact, if separate, a preliminary email notice within 24 hours and then provides ongoing updates.
- Notification to the Swedish Data Protection Authority (IMY) happens within 72 hours if the incident poses a risk to individuals' rights.
- The incident-response runbook and postmortem process is described in the Municipal Licence agreement annex ("IR runbook").
7. International data transfer
Personal data is processed in the following regions:
- EU/EEA: Firestore, Cloud Functions, Hosting and Cloud Storage via Firebase in
europe-west1(Belgium); Stripe payments primarily in Ireland; Zoho Desk/CRM through Zoho's EU endpoints for support and approved data orders. - USA/third countries: Firebase Authentication may involve Google processing outside the EU/EEA. Sentry support from the US team, some Resend transfers, Anthropic/OpenAI calls (only with consent) and social-login providers may also involve US processing.
For all US transfers the following legal mechanisms apply:
- Standard Contractual Clauses (SCCs) — Google/Firebase Authentication, Stripe, Resend, Anthropic, OpenAI and the social-login identity providers (Google, Microsoft, GitHub, Facebook, Apple) are covered by SCCs per EU Commission decision 2021/914 when processing occurs outside the EU/EEA.
- EU-US Data Privacy Framework (DPF) — alternative legal basis for DPF-certified providers (Google, Stripe).
Schrems II implications: Skolkoll has performed a Transfer Impact Assessment (TIA) per provider. Summary available on request from Municipal Licence customers.
8. Technical and organisational security measures
- Encryption in transit: TLS 1.2+ for all communication; HSTS enabled.
- Encryption at rest: Firestore encrypts all data automatically with Google-managed keys.
- Access control: Role-based access (admin / user); admin token compared via timing-safe-equal; auditLog for all admin API calls.
- Secrets: All API keys and tokens are stored in Google Secret Manager and provided to runtime securely via Firebase Functions secrets binding. They are not present in source code or committed to the repository.
- Rate limiting: Distributed Firestore-backed rate limiter on all public endpoints; analytics pipeline hardened against abuse via origin allowlist and event size caps.
- Validation: Strict schema validation on all user inputs; field-level length caps; metadata type enforcement including array-element validation.
- Monitoring: Cloud Logging for all functions; error alerting via Resend to ops distribution list on scheduled-function failures; planned Cloud Monitoring policy for error rate.
- Backup: Firestore is configured for Point-in-Time Recovery (PITR) via Google Cloud, which provides point-in-time restore within the window that Firestore PITR offers (up to 7 days). Actual PITR status and any scheduled backup exports are verified using
gcloud firestore databases describeandgcloud firestore backups schedules listrespectively before each release. Recovery has not been exercised in a controlled disaster-recovery drill — we intend to run such a drill ahead of the first Municipal Licence production deployment.
9. Documents for municipal procurement
- DPA template (data processing agreement) — based on SKR's Swedish standard contract.
- Service Level Agreement (SLA) — uptime commitments, support response times, escalation path, and credit policy.
- ROPA summary (Records of Processing Activities) — public summary of the processing register per GDPR art. 30. Full extract available on request to Municipal Licence customers.
- IR runbook — incident-response process and contact details, delivered as an annex to the Municipal Licence agreement.
10. Complaints
If you believe we are processing your personal data unlawfully you have the right to lodge a complaint with the supervisory authority:
Swedish Data Protection Authority (IMY)
Web: imy.se/en
Email: imy@imy.se
Phone: +46 8-657 61 00