Last updated: 2026-09-26 (raw-source archive operational evidence reconciled; SCB's preschool geodata file, in which a sole trader's company name is the owner's own name, is no longer published as a file and is used for internal matching; a match key in the public preschool data still carries SCB's company name and address and is removed in a separate change. New changes to public data files no longer name the administrator who made them, and an administrator address written earlier stays in a file until its next change; before that, recorded the Zoho processing agreement signed on 2026-09-11; before that, retired the Kommunlicens demo intake and changed demoSessions retention to one-time deletion; internal ROPA v3.17 and transfer annex v2.9 apply). Next review: 2026-10-26 or on a material change.
This is a public summary of Skolkoll's Records of Processing Activities (ROPA) under GDPR article 30. The full internal ROPA is in version control and can be requested as an extract by Municipal Licence customers. The summary is structured so a municipal lawyer or procurement officer can get a complete picture without needing infrastructure-level detail.
1. Roles — municipality vs Skolkoll
- P1–P3, municipal instruction: the municipality is controller and Skolkoll processor for organisation memberships and roles, customer-directed imports/watches, and instruction-bound support and incident material.
- C2/C4 and other own purposes: Skolkoll is controller for its own identity/access security, customer and billing administration, anonymous visitors' own watches, public support/sales enquiries, journalist data orders and other expressly disclosed own activities. Stripe/billing records and public-source data do not become Municipal Licence data merely because the customer uses the service.
- No joint controllers: we do not share data with third parties under joint control.
2. Data category overview
| Category | Contents | Legal basis | Retention |
|---|---|---|---|
| User accounts | Email, name, organisation membership, role, login timestamps | P1: the customer's documented instruction for membership/role. C2: art. 6.1.f for necessary identity, access and security administration; art. 6.1.b only where the data subject personally is party to the agreement | Until account deletion; 36 mo of inactivity → automatic deletion |
| Organisation data | Organisation name, organisation number, billing address, customer number (SK-NNNNN) | Art. 6.1.b only where the data subject personally is party to the agreement; otherwise art. 6.1.f for necessary contact, contract and invoice administration and art. 6.1.c for a concrete accounting duty | Active for the lifetime of the subscription |
| Billing history | Invoices, payment metadata (card details never pass through Skolkoll's servers) | Legal obligation (art. 6.1.c) — Swedish bookkeeping act | 7 years |
| Watchers | Selected school/municipality/school operator, email address, email hash, frequency, confirmation/unsubscribe tokens and watcher events for the digest | C4: consent (art. 6.1.a) for anonymous double opt-in. P2: the customer's documented instruction for an organisation-directed Municipal Licence watch. Art. 6.1.b only where the data subject personally is party to the agreement | Active watches until the user removes them or the customer instruction ends. Pending confirmations have a 48-hour token window. On unsubscribe the email, confirmation/unsubscribe bearer tokens and other direct watch fields are erased immediately; a minimised closed tombstone with the hash, status and close/expiry clocks may remain only for documented suppression/accountability, for no more than 24 calendar months and earlier when the need ends. The daily cleanup job backfills older closed rows, minimises them and purges tombstones when the clock is due; production deployment, first run and live readback are not yet verified. Watch events are normally removed within 35 days. Account deletion removes account-bound watches. |
| Legacy campaign-mail records | Historical contacts, list memberships, campaign and delivery metadata | Consent was only the basis for the historical newsletter send and processing before withdrawal. Thereafter, minimum evidence/suppression requires a concrete C5 purpose and Art. 6(1)(c) where a specific duty applies, otherwise a documented Art. 6(1)(f) balancing | The first-party campaign system is retired. The established retention periods are absolute caps, not a legal basis. After withdrawal or purpose end, only minimum evidence/suppression may remain within the cap under the documented C5 condition; everything else is erased earlier |
| Retired trial-nurture markers | trialNurtureSent and former onboarding fields on the organisation record | The markers do not prove consent or another basis for the historical sends, and no basis is asserted retroactively. Current cleanup/accountability access: art. 6.1.c where a duty applies, otherwise art. 6.1.f | Removed by an explicitly project-confirmed one-time post-deployment migration |
| Campaigns and newsletters (Zoho Campaigns) | Designated separate platform for email, name, organisation/locale, consent provenance, list/segment, delivery status, suppression, opens and link clicks. Complete open and link-click tracking were observed ON on 2026-07-29. Campaigns is governed independently of the Mail restriction: every send and every send-capable automation is STOPPED at the Z-CAMPAIGNS gate. Any future reassessment requires account/contact-consent provenance, DPA/SCC, unsubscribe/RTBF, retention, documented suppression and either the applicable tracking assessment/consent or dated evidence that tracking will not operate; the gate is not verified as tenant-level technical enforcement | Sends and approved tracking: consent (art. 6.1.a) plus separate MFL/LEK assessment. Consent is not reused as the basis after withdrawal; minimum proof/suppression relies on art. 6.1.c where GDPR/MFL requires it, otherwise a documented art. 6.1.f balancing to prevent re-contact or defend a claim | Skolspegeln's governing target is an active contact until withdrawal, unsubscribe or purpose end and no more than 24 months for minimum suppression/consent proof and identifiable recipient reports. A specific existing or threatened claim requires a separate C5 control with owner, purpose, basis, minimum scope, quarterly review and purgeAt. The account's actual erasure/RTBF configuration and enforcement of the 24-month target have not been attested in this revision and remain supplier-evidence follow-up; Zoho's possible five-year maximum has not been adopted as Skolspegeln's retention period |
| Official mailbox (Zoho Mail) | Rights, data-protection, incident, Municipal Licence, quote/demo, verification, journalist and other direct correspondence: name, email, message, voluntary attachments and technical message headers. Zoho Mail is subject to a dated interim-risk restriction with no positive release. New user-initiated inbound enquiries may be received, assessed manually and answered only to the strictly necessary extent after matter-specific content, necessity and minimisation review. Free text is not assumed to be public; Article 9 or 10 data requires a separate basis or is not processed further. Content is not sent to AI. Proactive or discretionary outreach, campaign/relationship sends, bulk workflows, automation and new integrations, features or data categories in Mail are STOPPED. The FAS-0 deadline of 2026-08-14 passed without the evidence being closed; only minimised inbound intake continues, while escalation to a lawful replacement channel is under way. Zoho Legal's 2026-09-08 response identifies SCC Module 3 for Zoho EU → Zoho India in prose. The account-specific DPA was signed on 2026-09-11, but its Schedule 1 is the article 28 processor clauses and states in its own clause 1(f) that they do not by themselves ensure Chapter V compliance, so the transfer mechanism remains supplier-asserted rather than contracted. Clause 5.1(i) makes EEA storage a contractual term, but Schedule 2 expressly permits Indian access and names India alone for EEA customers, while the supplier's own SOC 1, SOC 2 and ISO location annexes place Austin in the United States in scope for support. Our India assessment must address current law and the United States leg remains unsupported. Export, minimisation and verified deletion remain permitted. The restriction proves neither Chapter V compliance nor tenant-level technical enforcement | Legal obligation (art. 6.1.c) where a specific duty applies. Art. 6.1.b is used only where the data subject is personally a prospective contracting party; otherwise a documented art. 6.1.f assessment is limited to reading, minimising and answering the user-initiated enquiry. Art. 5.2 is an accountability duty, not an independent legal basis | The mailbox copy has no separate archive purpose or extension. It follows the same underlying C3/C5 matter schedule and absolute cap and is then erased or minimised into separately governed C5 evidence |
| Requested public-data event watch | Email, municipality filters, themes, frequency, locale, status and confirmation/unsubscribe tokens. The historically named /api/newsletter/** path does not enrol a campaign subscription | Consent (art. 6.1.a) for the expressly requested double-opt-in watch | Unconfirmed for about 30 days through confirmExpiresAt; the TTL policy was verified ACTIVE on 2026-07-26. Confirmed until unsubscribe, when the entire document must be deleted immediately with no inactive record, tombstone or suppression hash. A separate backfill must remove older residue |
| Analytics events (raw) | Random sessionId, page path, event name — no personal data, no IP, no UA | Legitimate interest (art. 6.1.f) — product development | 90 days; aggregated summaries retained indefinitely (no PII) |
| Zoho PageSense (consent-based web analytics) | Page views, clicks/scrolling, heatmaps, session recording, experiment variant, device and browser info on public pages. PageSense does not run on noindex/account/admin pages. | Consent (art. 6.1.a) | According to the selected PageSense plan, max 12 months for Skolkoll's use |
| Google Analytics 4 (code-level stop) | The repository contains configuration, but GA4_LEGAL_RELEASE_APPROVED = false prevents exposure of a measurement ID or start of the loader. Production deployment and live readback remain pending. A future release could involve network metadata, page views, device and approximate location information. | No active processing from the stopped repository path. Future use requires consent (art. 6.1.a), a reviewed code change, verified route/no-track control and role, settings, contract and transfer evidence. | No active GA4 retention is claimed. A future 14-month target can apply only after approved release. |
| CARTO map tiles (code-level stop) | The direct browser request to CARTO has been removed from the repository map code. Production deployment and live readback remain pending. A future external tile service would receive IP/request metadata and tile coordinates. | No active processing from the repository path. Reopening requires a reviewed code change and documented necessity, role, recipient and any third-country transfer. | No current provider retention from the stopped code path is claimed. |
| Zoho Desk (customer support) | Zoho Desk is configured and intended for paying-customer support cases, but Z-DESK is STOPPED and receives no new data until its separate gate has passed. Its intended minimum content is name, email address, organisation membership, ticket content, ticket history and voluntarily attached technical material. | For a user-initiated enquiry submitted through Skolspegeln's own support flow, art. 6.1.b applies only where the data subject personally is the prospective contracting party and requests pre-contractual steps. Otherwise documented art. 6.1.f is limited to necessary manual receipt, case-specific minimisation and response. Unexpected third-party or Article 9/10 data is minimised/deleted or not processed further without a separately documented basis and applicable condition. In Municipal Licence P1, the municipality is controller and Skolkoll processes under its instructions. | No new Desk records while Z-DESK is closed. If the gate later opens: maximum 36 months after case closure, or shorter on customer request when no legal obligation requires retention. |
| Commercial lead forms (Zoho CRM) | Form record in leadSubmissions with name, email, organisation, phone, message, track/surface, locale, versioned Article 13 notice and UTM fields. The form instructs users not to enter private, sensitive or other people's data. Free text is stored only in the access-restricted Firestore record for manual handling and is never sent to CRM Description. The retired marketing-consent field is not collected. Z-CRM is STOPPED, receives no new data and creates no new provider record. The collection is accessible only through the Admin SDK. | Art. 6.1.b only where the data subject personally is the prospective contracting party and requests pre-contractual steps. Otherwise documented art. 6.1.f for necessary technical receipt and access-restricted storage, case-specific manual minimisation/response, abuse prevention and operational recovery. AI/content analysis and proactive contact are outside that purpose. Unexpected third-party or Article 9/10 data is minimised/deleted or not processed further without a separately documented basis and applicable condition. | Each Firestore record is written with purgeAfter for target deletion 90 days from submission. A live readback on 2026-07-30 reported leadSubmissions.purgeAfter as ACTIVE. Policy status does not prove that a particular expired sample has completed Firestore's asynchronous deletion cycle. No new CRM records are created while Z-CRM is closed. If the gate later opens, the CRM record is reviewed at least annually and is not used for newsletters/campaigns without separate consent. |
| Correction form for published school data | Form record in correctionSubmissions with school/page, issue type, your description and the value you believe is correct (free text), any link, source link and school-unit code, optional email address (a name only for manual or API records), locale, browser user-agent and time of receipt. No IP address is stored in the record. Only our own server can read the collection. The form states that free text and contact details are used solely for internal triage and that a published correction is summarised without the reporter's contact details and with sensitive details removed. Matters arriving by email to info@skolspegeln.se are logged manually into the same collection with the mailbox receipt time and, for rights matters, fields for acknowledgement and any extension. | Documented art. 6.1.f for necessary technical receipt, access-restricted storage, case-specific minimisation and the reply the form offers where a contact was left. No consent basis, no art. 6.1.b and no AI analysis of the content. A report concerning the data subject's own data is handled as a rights matter (art. 15–21) with the art. 12.3 period counted from receipt, regardless of when it is assessed. Any reply is sent manually from the mailbox (Z-MAIL, within the dated interim restriction); no automated reply exists. Unexpected data about other people or sensitive data in free text is minimised or removed without further processing. | Controller target: email, any name, user-agent and free text are erased or anonymised 90 days after the case is closed, and no later than 12 months after receipt even if the case is still open; what remains is de-identified case data (school, field, outcome). Rights matters (art. 15–21) in the collection instead follow C5's evidence class, not this target. Automatic purging is not yet in operation — a documented control gap. State 2026-09-03: no record has been purged; three cases have been open for 30–63 days. Until a scheduled purge exists, any deletion is manual, and the state is updated here. |
| Municipal Licence demo | demoSessions — Intake was removed in code on 2026-09-07 (#5803) and ceases in production at the next deployment of that change — no new record can be created thereafter. Storage of historic records is ongoing; storage is processing (art. 4(2)), so the matter is not closed. Historic records may contain name, work email, municipality, role, locale, status, activation times, raw IP and user-agent. The form was replaced by the shared lead intake, which stores neither raw IP nor user-agent. | Historic basis, unchanged for the records that remain: for a user-initiated lead/demo enquiry, art. 6.1.b applies only where the data subject personally is the prospective contracting party; otherwise a documented art. 6.1.f assessment covers necessary manual receipt, case-specific minimisation, response and abuse prevention for a self-requested B2B demo. That purpose ended with the demo, so no basis remains for further retention and erasure is due under art. 5(1)(e)/17(1)(a). | Delete in full. The scheduled cleanup was removed with the endpoint. The purgeAfter TTL override is retained but does not cover everything: the field was introduced on 2026-08-01 while the demo went live on 2026-05-05, so records from the three intervening months carry no purgeAfter and TTL never touches them. The 30-day field-level redaction of raw IP and user-agent was performed by the job and cannot be done by TTL. The one-time erasure — target 2026-09-21, responsible Sales privacy owner, with a readback showing zero documents — is verified only for the Firestore documents in demoSessions. Production PITR windows, backup exports and the email provider's (R-EMAIL) recipient, message and token metadata fall outside that verification and follow their own schedules. The TTL override is removed only once the readback exists. |
| Journalist data orders | Form record in journalist_orders with newsroom/outlet, beat, name, email, order message, consent version/timestamp and minimum technical request/workflow metadata: user-agent and source/surface for abuse prevention, status, allowlisted error classification and recovery outcomes, and purgeAfter. The free-text instruction prohibits private/sensitive information and personal data about other people. If such unexpected content is discovered, it is not forwarded: it is minimised/deleted or quarantined for manual legal assessment. Provider error messages/details are neither logged nor stored. Cloud Logging receives only pseudonymous request/document references plus safe error name/code/numeric status. During the first seven days, Resend may send an authorised admin only document reference, time and alert count—never contact or order content. No full-content fallback email exists. Zoho Desk and CRM are code-level STOPS: their current provider contact models lack order binding and tested matching deletion/minimisation and cannot be opened by general tenant/retention evidence. Zoho Mail has no positive release; no AI is used. | Consent (art. 6.1.a) for storing and handling the form order and providing a contact response. Consent may be withdrawn at any time via info@skolspegeln.se; future consent-based processing stops, while lawfulness before withdrawal is unaffected. Art. 6.1.b applies only if the data subject is personally the prospective contracting party and has requested pre-contractual steps. Legitimate interest (art. 6.1.f) applies only to necessary abuse prevention and operational recovery, including the pseudonymous first-week alert, not to order handling, the contact response, editorial follow-up or an ongoing relationship. Unexpected third-party or Article 9/10 data may be retained only under a separately documented basis and, where relevant, an applicable Article 9/10 condition. Instruction plus manual assessment is the proportionate preventive safeguard; this decision does not require a general technical content block. | FAS-0 decision: each Firestore record is written with purgeAfter for target deletion 180 days from submission. A live readback on 2026-07-30 reported that exact TTL policy as ACTIVE; this proves configuration state, not an expired sample. Unresolved orders need documented extension and have a 12-month hard cap. The current Desk/CRM models are stopped in code and create no provider record. A future approved replacement deletes the whole order-bound provider record at purpose end or withdrawal and no later than the order hard cap; longer retention requires a separate future purpose, basis and notice. Pseudonymous journalistOrderDryRunDigests receipts have a 30-day expiresAt; the writer and repo TTL exist but no live ACTIVE evidence is claimed, so manual cleanup remains required until verified. |
| Audit log | Admin actions with timestamp, target and before/after | Legitimate interest (art. 6.1.f) — security/traceability | 2 years through expiresAt. A live readback on 2026-07-30 reported auditLog.expiresAt as ACTIVE; policy state does not prove that a particular expired sample has been deleted asynchronously. |
Account deletion audit (accountDeletionAudit) | Hashed document ID, domain-separated subjectHash, email hash (SHA-256), deletion status, safe error steps, cleanup counters and timestamps — no raw uid or raw email address | Legitimate interest (art. 6.1.f) for minimum evidence of completion or a failed step; art. 5.2 is an accountability duty, not a separate legal basis | No more than 12 months through expiresAt, whether the status records completed deletion or a retryable/blocked step. The record is not a continuing account. A live readback on 2026-07-30 reported the policy as ACTIVE; this does not prove asynchronous deletion of a particular expired sample. |
| API quota | Number of calls per organisation per month | Customer instruction for customer-directed quota; Skolkoll's separate quota, invoice and dispute check: legitimate interest (art. 6.1.f). Art. 6.1.c only where a concrete accounting requirement covers the data | 13 months |
| AI chat conversation | The conversation and school context exist only in browser sessionStorage and are not retained permanently as a conversation on Skolkoll's server. The information acknowledgement is stored locally in localStorage. Users are instructed not to enter private or sensitive data; the instruction is a proportionate safeguard, not an Article 14 exception. For each processed Kollen request that is eligible for logging, the server makes at most one asynchronous write attempt for an audit entry with type, lengths, status, an IP-derived pseudonym made with keyed, domain-separated HMAC-SHA-256 truncated to 16 characters, and school context as an exact eight-digit school-unit code or null. The request does not await write confirmation, so actual storage of an entry is not guaranteed. The attempt does not contain question or answer text | Legitimate interest (art. 6.1.f) under a documented balancing test; the acknowledgement records that information was shown and is not consent. Where free text mentions an identifiable third person, the public notice is a compensatory measure only when the documented Article 14(5)(b) proportionality assessment applies. If Skolkoll becomes concretely aware of the person and has usable contact information, direct notice is provided within the applicable Article 14(3) period unless another documented Article 14(5) exception applies | The conversation is deleted when the browser tab closes; the information acknowledgement remains until the user clears AI data or local storage. The audit entry has a 90-day target through expiresAt and Firestore TTL, whose deletion is asynchronous after expiry |
| Nominatim place and address geocoding | All browser calls are centralised and new external searches are default-off behind nominatimPublicPlaceEnabled. After just-in-time information at the field, only an exact match in the verified municipality-name catalogue (optionally followed by kommun) may be sent; a named public place requires a separate verified first-party catalogue. Streets/home addresses, numbers/contact details, marker keywords and unclear person-like multiword phrases are blocked before any network call. When the gate is enabled, external request starts are queued at least 1,100 ms apart. Browser geolocation and hits in the local cache are unaffected. The batch flow is separately default-off behind SKOLKOLL_NOMINATIM_BATCH_ENABLED=true; safe business-address hits in Skolkoll's own cache may be used while an external cache miss fails closed. Person/home markers, PO box/care-of/apartment markers and uncertain or person-like principal/school-operator names are blocked and removed from cache | Legitimate interest (art. 6.1.f) only after a documented necessity, role and transparency assessment for the enabled flow. The gates are technical default stops for new external calls and do not claim that OSMF's external log or country conditions have been verified | Browser sessionStorage cache: at most 20 entries and 24 hours. The batch cache is in Skolkoll's own Cloud Storage with a target maximum of 365 days; malformed, person and home-address entries are purged. OSMF's exact raw-log retention remains a supplier-evidence gap. If the batch gate is enabled, one thread runs with an identifying User-Agent, timeout and at least 15 seconds between external request starts |
| Current official institutional school contact details | Email address and phone number from Skolverket's current school record; may be published in the school detail view, API and JSON-LD. An institutional address may be personal data if the source uses an individual's address | Legitimate interest (Art. 6(1)(f)) — an accurate public school directory with official contact channels. Rectification and objections are handled through info@skolspegeln.se | In active directory processing, only the current, daily-refreshed and replaceable school record. Changed or removed source values are replaced or removed on the next successful sync. Email and phone are not added to temporal history; new Bronze and materialised archive generations are contact-minimised, and a one-time migration cleans older materialised rollback archives. Older non-public Bronze source snapshots produced before minimisation follow the configured 1,095-day cleanup window; actual deletion requires a completed and evidenced run |
| Raw-source archive for public institutional records | Unchanged raw bytes of officially published annual reports/ESEF reports and minimum source metadata. The records may incidentally contain names, professional roles and signatures; work contact details or business addresses; portraits or short professional biographies; and named holdings, remuneration or related-party transactions. The approved target is access-restricted Google Cloud storage in G-EU; the production bucket's EUROPE-WEST1 region, uniform bucket-level access and absence of public IAM principals were verified on 2026-09-26. The archive must have no OCR/full-text or person index and must not be disclosed publicly. Only transient parser handling strictly necessary for name-free financial fields is permitted. | Legitimate interest (Art. 6(1)(f)) in verifiable provenance, reproducibility and correction of name-free financial data under source-archive assessment v1.3. The bounded Article 14(5)(b) decision applies only to the raw-source archive and does not open Dataset D/E. | A 30-day notice precedes access review no later than 12 months after retrieval. Material is deleted when the purpose ends and normally no later than 24 months after retrieval. The repository contains a daily control whose request window is designed to subtract live-read soft delete, or a conservative planning fallback when live evidence is unavailable, plus a separate seven-day failure/retry buffer. The first accepted production control ran on 2026-08-14. The 2026-09-26 control verified 5,115 complete entries with no due deadlines, seven-day soft delete and no additional preservation controls. This does not claim completed physical deletion: no entry was due. A separate documented exception for longer retention must be decided and technically active before the earlier request window. The same calculation applies to the absolute 36-month cap. Request time and estimated window end are reported separately without presenting the estimate as proof of physical irrecoverability. Rights are exercised through info@skolspegeln.se. |
| Dataset E/G5 — existing names in internal source, legacy and history layers | Existing names of principals and other professional roles may occur in internal source fields, legacy data and history layers. While DPIA gate G5 is open, new or recurring population-wide extraction, normalisation, indexing, materialisation and history processing of names and person roles is STOPPED. Acquisition of officially published institutional source documents is not itself stopped; unchanged source bytes may be retained for name-free provenance only under the separate public-source archive assessment and without OCR/full-text person indexing. Existing names may be used only to the minimum extent necessary for documented data cleanup or rights matters. The automatic public catalogue, API/export, structured data and other automatic serving are name-free | No positive population-wide processing is approved. A concrete editorial matter may start only after both the treatment-specific Article 85 decision and the Article 14 route have been documented before collection or other new processing. Where no documented Article 14(5) exception applies, notice is provided by the earliest applicable Article 14(3) deadline. Cleanup and rights handling follow their documented obligation or interest basis | There is no positive population-wide retention rule while G5 is open. Names in temporal-backfill and structured bronze/silver layers remain fail-closed and must not be replenished or used as an indefinite archive. A five-year cap may be introduced prospectively only after both a positive G5 decision and a deployed, verified deletion consumer that enforces a non-extending purgeAfter; a new observedAt must never move the deadline. Unchanged public-source bytes instead follow the separate source-archive assessment's active-review period, normal deletion point and absolute cap |
| School images and rights provenance | For submitted images: image, school, the submitter's contact details and licence/rights attestations, and editorial review. The current form collects no separate rights-holder name; CC0 collects no photographer name or person/source link. BY/BY-SA requires a photographer name and may accept an optional HTTPS link. Before a new or retried model request, the form flow requires both current server-validated AI consent/policy and a positive review bound to the image hash, licence, rights attestations and exact optional author URL, confirming the absence of identifiable people. A rights-cleared import does not require form consent; it instead requires a separate positive import review bound to the current hash, source, licence, rights and absence of people, together with documented LIA/Article 14 provenance. The current schoolImageSubmissions.aiEligibilityReview is the form-flow gate only. A missing or mismatched review blocks new and retried requests, but already compliant outputs do not need regeneration. Public form provenance on G-HOSTING may include school, output, transformation and status fields plus the licence and verifiedSchoolUpload: true. A technically decoupled random publicAssetId is used for serving and rights/erasure handling. It is pseudonymous personal data while the access-restricted submission record can map it to a case; the private submissionId and processing claimId must never be exposed in a public path or provenance. Person attribution is published only for CC BY 4.0/CC BY-SA 4.0: the photographer name and exact review-bound HTTPS link. CC0 publishes no person name or person/source link. A photo date is never published. Contact details, account identifiers, administrator data, private notes, submitter role and internal rights-management metadata must not be published there. The AI-stylisation /v1/images/edits endpoint receives only image bytes and a static instruction; contact, attribution, source-link, photo-date, rights and free-text metadata are not sent to the image model | The submitter's own contact details and choices in the AI flow are processed with consent (art. 6.1.a) together with the agreed licence. Where CC BY 4.0 or CC BY-SA 4.0 requires attribution, the photographer name and any exact review-bound HTTPS link are processed and published on the basis of legitimate interest (art. 6.1.f) and the applicable Article 14 route. Where the submitter is the photographer, direct information is recorded through the version-bound collection notice. A named third-party photographer otherwise receives direct notice within the Article 14(3) deadlines. Article 14(5)(b) may replace direct notice only after dated and signed legal evidence has been expressly registered for the exact source and publication; the empty server-controlled registry fails closed. The tracking ID LIA-SCHOOL-IMAGE-ATTRIBUTION-14.5B-2026-07-30 does not activate the exception: a verified prior attribution source must still be documented for the same source and publication. Legacy v2 review evidence may not publish a name or link. CC0 intake and projection contain no person attribution. A third person newly named in the form is not assumed to have been informed by prior publication. | Pending submissions become due for deletion 180 days after upload even if returned to review; rejected submissions become due 90 days after the decision. For approved images, the minimum image, licence, source and review provenance is retained while the image is used or rights claims may reasonably need to be handled. Contact, photo date, review free text and other intake-only fields become due for minimisation 180 days after approval; legacy CC0 names and links are covered by the same pass. The daily cleanup job performs due deletion or minimisation in the next successful run that reaches the record; queueing or operational failures can delay execution. |
| Public school-image revocation queue | schoolImageSubmissions.imagePurge contains minimum queue and control metadata, including dueAt, attempts, status and safe error codes. processing.publicUnrecoverableAt means verified public inaccessibility after active-generation deletion or an object already absent from public access. It never proves physical deletion of every provider byte. | The same basis as the rights/erasure matter: art. 6.1.c where a concrete duty applies, otherwise documented legitimate interest (art. 6.1.f) in safe execution and accountability. | The queue record follows the submission and erasure-matter schedule and is minimised after a verified outcome. non_current_generation may not finalise the matter and instead goes to retry/reinventory. Provider soft delete or provider retention may coexist with public inaccessibility but must not be described as all bytes being physically gone. |
| Open-house date tips (legacy flow stopped) | The legacy openHouseSubmissions collection may contain school, date, links, contact details, free text and review metadata. The form, client-side POST and dynamic GET have been removed. The server unconditionally stops public GET/POST requests and new approved transitions with open_house_reopen_review_required; environment flags cannot open the flow and no legacy record is publicly projected. Admin users may read and reject older records for inventory and minimisation. The separate build-time register is not sourced from the legacy collection and is currently empty. | No positive basis is claimed for new intake, approval or dynamic legacy publication. The first date in the separate build-time register requires a separately reviewed publication-evidence model for basis, necessity, current source, review date and deletion deadline. Reopening requires a separately reviewed legal and technical design and a reviewable code change. | Pending at most 180 days, rejected at most 90 days after decision, and approved until event end + 90 days but never later than 15 months from submission, with earlier deletion when the purpose or basis ends. The code stop does not prove production deployment, legacy inventory, executed cleanup or live deletion; documented monthly inventory and purge/minimisation therefore remain required until verified. |
| Lane-D document extraction (internal AI support) | Officially published public documents within an active, versioned municipality/portal/layout flow are locally preflighted before every model request. The whole document is blocked when private-source markers, personal identity numbers/pupil-identifying contexts or Article 9/10 indicators are detected; email addresses and phone numbers are removed from the separate provider copy. Only that prepared copy is sent to OpenAI (gpt-4o-mini) for structured extraction. The local original is used for grounding and is not written into the provider prompt. Classification can produce false negatives, which is a residual risk; candidates are therefore masked, nothing is published automatically and only human-reviewed values may be published. The controls are implemented and tested in the repository, but production deployment and live readback remain pending; no production use is approved until they are verified. Lane D uses /v1/chat/completions with store: false; the response then has no application-state retention, while prompt caching may retain encrypted key/value tensors in GPU-local storage for up to 24 hours without retaining the original prompt text there. This is a minimisation measure with an express cache exception, not ZDR. | Legitimate interest (art. 6.1.f) — compiling figures from public records for school transparency | Pending review candidates for at most 180 days, rejected candidates for at most 365 days and terminal extraction jobs for at most 90 days. Approved contributions and their minimum change history follow the school-data/provenance schedule, normally at most five years. Raw PDFs follow a separate source-retention rule and are not published directly. |
| Journalist email (manual handling) | New user-initiated inbound journalist enquiries may be received and handled manually; only a strictly necessary reply is sent after matter-specific content, necessity and minimisation review. Free text is not assumed to be public, and Article 9/10 data requires a separate basis or is not processed further. Content is not sent to Anthropic, OpenAI or another AI service. Proactive or discretionary journalist outreach, bulk workflows, automation and new purposes, integrations, features or data categories are STOPPED. | Legal obligation where applicable; otherwise documented legitimate interest (art. 6.1.f) limited to reading, minimising and answering a user-initiated press enquiry. Art. 6.1.b is used only where the data subject is personally a prospective contracting party | The message and necessary manual reply follow the matter's documented storage and absolute cap; the mailbox copy has no extension of its own. The FAS-0 deadline of 2026-08-14 passed without the account, DPA/SCC and India/United States evidence being closed; only the minimised inbound intake remains, while escalation to a lawful replacement channel is under way. The data is not used for campaigns or newsletters. |
The full internal ROPA contains per Firestore collection: exact field list, exact subprocessor link, exact retention mechanism. Municipal Licence customers can request the extract as an annex via info@skolspegeln.se; the request is received and handled manually by email and the extract is delivered within 5 working days.
3. Processors, subprocessors and other recipients
The current role-specific list is published in section 2 of Data protection and suppliers. It includes Google Cloud, Stripe, Resend, Sentry, Zoho Mail, Zoho Campaigns, Zoho PageSense, Zoho Desk, Zoho CRM, Anthropic and OpenAI, plus the code-stopped recipient candidates Google Analytics 4 and CARTO. Separate Desk-support and CRM-lead surfaces are stopped until their own gates have passed. The current journalist connectors to Desk and CRM are instead code-level STOPS that cannot be opened by general evidence or flags: any future replacement must use order-bound objects without cross-purpose merging and have tested matching deletion/minimisation. Zoho Mail has no positive release but may receive new user-initiated inbound enquiries and send strictly necessary manual replies after matter-specific minimisation; content is not sent to AI. Proactive/discretionary outreach, campaign/relationship sends, bulk, automation and new integrations, features or data categories are STOPPED. A provider is a Municipal Licence subprocessor only when it processes personal data in that processing chain; Zoho Mail and Zoho Campaigns instead process Skolspegeln's own controller activities. Resend is limited to service, transactional, requested-watch and technical email. Zoho Campaigns is the designated campaign/newsletter platform but is not governed by the Mail restriction: every next send or send-capable automation is independently STOPPED at the Z-CAMPAIGNS gate until its account, consent, unsubscribe/RTBF, retention/suppression and tracking evidence is closed and the send has manual approval. Kollen and Lane-D document extraction rely on legitimate interest. Form-submitted school images require current AI consent and a positive hash/rights/no-person review; rights-cleared imports instead use a separate positive import gate without form consent. Journalist email is handled manually within the dated restriction and is not sent to an AI provider — see the Internal AI support section on the data-protection page. The agreed 30-day prior-notice process applies to changes to actual Municipal Licence subprocessors.
Retention in OpenAI flows is described per technical mechanism. /v1/chat/completions with store: false has no response application-state retention, while prompt caching may retain encrypted key/value tensors in GPU-local storage for up to 24 hours. /v1/images/generations and /v1/images/edits have no application-state retention. Separately, the provider's standard abuse-monitoring logs may contain customer content or derived safety metadata for up to 30 days; longer retention may occur where required by law or reasonably necessary to protect the service or a third party, and safety-flagged image files may be retained for manual review. Skolkoll therefore does not claim ZDR and does not require a blanket ZDR agreement for the bounded flows.
4. International transfers
Repository configuration and the approved target specify Google Cloud europe-west1 (Belgium) for Firestore, Cloud Functions and Cloud Storage, and an archived production readback dated 2026-09-05 establishes Firestore in europe-west1 and all eight production buckets in EUROPE-WEST1 or the EU multi-region. The application logs were moved to europe-west1 on 2026-09-05; the audit logs remain in global in a locked bucket. Firebase Hosting uses a global CDN. Resend delivers through the United States. MX/SPF routing for Zoho Mail/Campaigns points to Zoho's EU services but does not prove tenant region. Zoho Mail is subject to a dated interim-risk restriction with no positive release: new user-initiated inbound enquiries may be received and strictly necessary manual replies sent after matter-specific minimisation, without AI. Proactive/discretionary outreach, campaign/relationship sends, bulk, automation and new purposes, integrations, features or data categories in Mail are STOPPED. Account-/contract-specific DPA/SCC incorporation and the focused India/United States assessment were to be closed by FAS-0 no later than 2026-08-14. That deadline passed, so only minimised inbound intake remains, while escalation to a lawful replacement channel is under way. Zoho Campaigns is governed separately: every next send or send-capable automation is STOPPED at the Z-CAMPAIGNS gate until its flow-specific evidence and manual approval are complete. No positive Chapter V status or tenant-level technical enforcement is claimed.
ANTH-API (Kollen): a legal country-evidence STOP applies while Anthropic may process outside the EEA in an unnamed country. The repository's fail-closed gate is implemented, but production deployment and live readback remain pending. New requests therefore may not be approved until dated evidence limits processing outside the EEA to the United States and any other expressly named country and records the DPF for an applicable certified US recipient, or otherwise SCCs with a country-/recipient-specific TIA and supplementary measures.
OAI-API (Lane D and school images): rights-cleared image stylisation without identifiable people and bounded extraction from officially published public documents follow a scenario- and country-specific transfer assessment. The mechanism is an adequacy decision where its scope covers the recipient and purpose, the DPF for an applicable certified US importer, or otherwise SCCs with the necessary TIA and supplementary measures. These bounded flows do not require a blanket ZDR agreement.
5. Data subject rights — operational owner
| Right | Contact | Timeline |
|---|---|---|
| Access (art. 15) | info@skolspegeln.se | Internal target: 14 days |
| Rectification (art. 16) | info@skolspegeln.se | Internal target: 14 days |
| Erasure (art. 17) | Self-service in the portal, or info@skolspegeln.se | Self-service: immediate. Mediated request: internal 14-day target after individual assessment and if granted. |
| Portability (art. 20) | info@skolspegeln.se | Internal target: 14 days |
| Object (art. 21) | info@skolspegeln.se | Internal target: 14 days for an individual decision and action if upheld |
| Restriction (art. 18) | info@skolspegeln.se | Internal target: 14 days |
Article 12(3) governs the legal response period: information on action taken is provided without undue delay and no later than one month after receipt. Where necessary, the period may be extended by up to two further months, taking account of the complexity and number of requests; the data subject is informed of the extension and reasons within the first month. An internal 14-day target does not alter this legal framework or the outcome of the individual assessment.
6. DPIA assessment
A simplified DPIA (DPIA-light) is published at Data protection and subprocessors section 7. Its conclusion — that a full DPIA is not required, because the processing does not meet high-risk criteria (no large-scale monitoring, no special categories of personal data stored systematically, no automated decision-making with legal effect on individuals) — applies to the processing within the Municipal Licence, where Skolkoll acts as data processor. For the public review activity, where Skolkoll is the data controller, a separate, full DPIA is in progress (2026). DPIA-light section 7 describes Lane D's local document preflight, contact-minimised provider copy and residual detector-false-negative risk.
7. Incident response
The Incident Response runbook (internal process) is followed for any personal data breach:
- Municipal Licence processor track: Skolkoll notifies the agreed controller without undue delay, with an internal target for an initial fact-based notice within 24 hours, and provides ongoing updates. The municipality assesses and is responsible for any Article 33 notification and Article 34 communication.
- Own-controller track: where Skolkoll is the controller, Skolkoll assesses the risk and notifies IMY without undue delay and, where feasible, within 72 hours of awareness when the breach is likely to result in a risk to individuals' rights and freedoms. Where a high risk is likely, affected individuals are informed without undue delay under Article 34.
- Roles: Incident Commander, Communications Lead, Legal/Compliance Lead (all coordinated by Skolkoll).
- Follow-up: root-cause analysis, decisions and proportionate material improvements are documented internally. External publication is assessed in light of the incident, legal duties and affected individuals' interests; there is no fixed 14-day promise.
The full IR runbook is delivered as an annex to the Municipal Licence agreement and can be requested before signing via info@skolspegeln.se.
8. Review and update
This ROPA summary is reviewed and updated:
- Quarterly — review of the subprocessor list against actual system calls.
- Pre-release — every feature that adds a new collection or subprocessor updates the ROPA in the same PR.
- After every incident — updated with lessons learned.
- Annually — full re-read with date stamp.
Related documents
- Data protection and subprocessors — operational GDPR detail.
- DPA template — data processing agreement.
- SLA — uptime, support, escalation.
- Privacy policy — for end users and anonymous visitors.