Last updated: 2026-10-01 (commercial lead forms: each stored enquiry is emailed internally through Resend to Skolspegeln's operations mailbox, where the copy is deleted within 90 days, and a pseudonymous fingerprint prevents duplicate notices; before that, reconciled the raw-source archive operational evidence; 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 retention of the demo sessions 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 (P1), customer-directed imports/watches (P2), and instruction-bound support and incident material (P3).
- 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. Own account security: 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 | Anonymous watches: consent (art. 6.1.a) through 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. A daily cleanup job goes through older closed records, minimises them and deletes the closure records when their time is up; we have not yet confirmed that the job is deployed, that it has run for the first time or that it works in the production environment. 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 purpose of security, accountability or legal claims 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 condition for security, accountability or legal claims; everything else is erased earlier |
| Retired trial-nurture markers | Markers of sent emails from the retired in-house trial follow-up system 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 under the separate preconditions for Campaigns. 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 stop is not technically verified in the Zoho account | 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. Longer retention for a specific existing or threatened legal claim requires a separate assessment within our processing for legal claims, with owner, purpose, basis, minimum scope, quarterly review and a set deletion date. 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 not permitted. Our internal deadline of 2026-08-14 for obtaining the evidence passed without the evidence being completed; 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 that it is technically enforced in the Zoho account | 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 retention schedule and absolute cap as the underlying matter (enquiry, support, or rights/security matter) and is then erased or minimised into separately governed evidence for security, accountability or legal claims |
| Requested public-data event watch | Email, municipality filters, themes, frequency, locale, status and confirmation/unsubscribe tokens. The site's older newsletter addresses (sign-up, confirmation and unsubscribe), kept for compatibility reasons, do not enrol a campaign subscription | Consent (art. 6.1.a) for the expressly requested double-opt-in watch | Unconfirmed for about 30 days through a deletion date for unconfirmed records, which is removed on confirmation; the deletion rule (TTL) was confirmed active on 2026-07-26. Confirmed until unsubscribe, when the entire record must be deleted immediately with no inactive record, tombstone or suppression hash. A separate backfill must remove older residue |
| Analytics events (raw) | Random session ID, 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 |
| CARTO map tiles (not used) | The direct browser request to CARTO has been removed from the website's map code. We have not yet confirmed the change in the production environment. A future external tile service would receive IP/request metadata and tile coordinates. | No active processing from the website's map code. 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 the Zoho Desk support surface is switched off and receives no new data until its separate preconditions have been approved. 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 support under the Municipal Licence (processing activity P3 in the record of processing: support and incident cases handled on the municipality's behalf), the municipality is controller and Skolkoll processes under its instructions. | No new Desk records while the support surface is switched off. If it is later opened: maximum 36 months after case closure, or shorter on customer request when no legal obligation requires retention. |
| Commercial lead forms (Zoho CRM) | Form record among the lead submissions in our database 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 never sent to Zoho CRM's free-text description field. So that the enquiry can be answered, our email provider Resend sends an internal email with the form's details to Skolspegeln's own operations mailbox for each stored record; an identical submission is not notified again within 24 hours. To do so, a pseudonymous fingerprint of the submission, without contact details, is kept and deleted automatically within about two days of its last use. Resend keeps the message for 30 days, and the copy in the operations mailbox is deleted within 90 days under a documented manual routine run by the owner. The retired marketing-consent field is not collected. The connector to Zoho CRM is switched off, receives no new data and creates no new provider record. The lead submissions cannot be accessed directly from browsers or apps, only through our server-side code and authorised administration tools. | 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 database record is written with a deletion date stored on the record, targeting deletion 90 days from submission. A check of the production environment on 2026-07-30 showed the deletion rule for the lead submissions' deletion date 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 the connector is switched off. If it is later opened, 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 among the correction reports in our database 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 correction reports. 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 among the same correction reports 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 (Zoho 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) among the correction reports instead follow the retention rules for evidence in security, accountability and rights matters, 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 | The demo sessions — Intake was removed in code on 2026-09-07 and ceases in production once that change has been deployed — 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 together with the demo intake's server function. The automatic deletion rule (TTL) for the deletion date on the records is retained but does not cover everything: the deletion date was introduced on 2026-08-01 while the demo went live on 2026-05-05, so records from the three intervening months carry no deletion date 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 check in production showing zero documents — is verified only for the demo sessions' records in the database (Firestore). Production PITR windows, backup exports and the email provider's (Resend) recipient, message and token metadata fall outside that verification and follow their own schedules. The automatic deletion rule (TTL) for the demo sessions is removed only once that check exists. |
| Journalist data orders | Form record among the journalist orders in our database 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 a deletion date stored on the record. 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. The connectors to Zoho Desk and CRM are switched off in the software code: their current provider contact models lack order binding and tested matching deletion/minimisation and cannot be switched on by general evidence about the account or retention. 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. | Under our decision, each database record is written with a deletion date stored on the record, targeting deletion 180 days from submission. A check of the production environment on 2026-07-30 showed the automatic deletion rule (TTL) for this exact deletion date 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 and CRM connectors are switched off in the software 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 receipt records for the daily check of journalist orders while the transfer to Zoho is switched off (dry run) have a deletion date 30 days ahead; the code that writes them and the deletion rule (TTL) exist, but we do not claim to have confirmed in the production environment that the rule is active, 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 a deletion date stored on the record. A check of the production environment on 2026-07-30 showed the deletion rule for the audit log's deletion date as active; policy state does not prove that a particular expired sample has been deleted asynchronously. |
| Our account-deletion log | Hashed document ID, a separate domain-separated hash of the account ID, email hash (SHA-256), deletion status, safe error steps, cleanup counters and timestamps — neither the account ID in plain text nor the email address in plain text | 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 a deletion date stored on the record, whether the status records completed deletion or a retryable/blocked step. The record is not a continuing account. A check of the production environment on 2026-07-30 showed the deletion rule 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 the browser's session storage (sessionStorage) and are not retained permanently as a conversation on Skolkoll's server. The information acknowledgement is stored in the browser's local storage (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 no value. 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 a deletion date stored on the entry and the database's automatic deletion (Firestore TTL), whose deletion is asynchronous after expiry |
| Nominatim place and address geocoding | All browser calls are centralised and new external searches are off by default and require an express activation. After just-in-time information at the field, only an exact match in the verified municipality-name catalogue (optionally followed by the Swedish word “kommun”, municipality) 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 searches are activated, 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 off by default and requires its own explicit activation; safe business-address hits in Skolkoll's own cache may be used while an external cache miss is stopped. 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 switch-offs are technical default stops for new external calls and do not claim that OSMF's external log or country conditions have been verified | Cache in the browser's session storage (sessionStorage): 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 flow is activated, 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 archive generations in the raw-data layer (Bronze) and in the materialised archives are contact-minimised, and a one-time migration cleans older materialised rollback archives. Older non-public source snapshots in the raw-data layer 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 within the EU; the production bucket's europe-west1 (Belgium) 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 the processing of named person roles. | 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. A daily control exists whose request window is designed to subtract the soft delete read in production, or a conservative planning assumption when no such reading is available, 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. |
| Named person roles (including head-teacher names) — 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. As long as the data protection impact assessment (DPIA) for named person roles has not led to a positive decision, 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 as long as the impact assessment has not led to a positive decision. Names in history layers and structured intermediate layers (the raw-data layer and the processed intermediate layer, bronze/silver) remain blocked and must not be replenished or used as an indefinite archive. A five-year cap may be introduced prospectively only after both a positive decision in the impact assessment and a deployed, verified automatic deletion that enforces a deletion date on the record that cannot be extended; a new observation date 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 server-validated consent to AI stylisation (the current consent version, or an unversioned consent submitted on or after 6 July 2026 UTC, whose weaker people attestation the editor's people inspection supersedes) 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 AI eligibility check on the school-image submission is the form-flow check only. A missing or mismatched review blocks new and retried requests, but already compliant outputs do not need regeneration. Public form provenance on our web hosting service (Firebase Hosting) may include school, output, transformation and status fields plus the licence and a marker that the image is a verified school upload. A technically decoupled random public image ID 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 submission ID and the processing flow's internal ID 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's call to OpenAI's image-edit interface 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 server-controlled register for such evidence is empty, and without such a registration the exception is not used. Our documented Article 14(5)(b) assessment for image attribution (2026-07-30) does not by itself 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 | The deletion queue on the school-image submission contains minimum queue and control metadata, including the time the next deletion attempt is due, attempts, status and safe error codes. The time at which the image was verified as publicly unreachable 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. An outcome where the inventoried version of the image file is no longer the current one because a newer version appeared before or after the deletion attempt 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 older set of open-house tips in our database 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 transitions to approved status with an error stating that reopening requires review; 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 older set 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. That the flow is stopped in the code does not prove that the change is deployed, that older records have been inventoried, that cleanup has run or that deletion takes place in production; documented monthly inventory and deletion/minimisation therefore remain required until verified. |
| 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 (the gpt-4o-mini model) 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 built and tested, but we have not yet confirmed that they are deployed and working in the production environment; no production use is approved until they are verified. Document extraction uses OpenAI's Chat Completions interface for text generation with OpenAI's optional response storage switched off; 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 not permitted. | 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. Our internal deadline of 2026-08-14 passed without the evidence on the account, DPA/SCC and India/United States being completed; 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 set of stored data in the database: 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 CARTO, which is not used today. Separate Desk-support and CRM-lead surfaces are switched off until their own preconditions are met. The current journalist connectors to Desk and CRM are instead switched off in the software code and cannot be switched on by general evidence or settings: 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 not permitted. 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 under the separate preconditions for Campaigns until its account, consent, unsubscribe/RTBF, retention/suppression and tracking evidence is closed and the send has manual approval. Kollen and document extraction rely on legitimate interest. Form-submitted school images require server-validated AI consent and a positive hash/rights/no-person review; rights-cleared imports instead use a separate positive import review 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. OpenAI's Chat Completions interface for text generation, with OpenAI's optional response storage switched off, has no response application-state retention, while prompt caching may retain encrypted key/value tensors in GPU-local storage for up to 24 hours. OpenAI's image-generation and image-edit interfaces 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
Our configuration and the approved target specify Google Cloud europe-west1 (Belgium) for Firestore, Cloud Functions and Cloud Storage, and an archived check of the production environment 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 Google's global location, which is not tied to a region, 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 not permitted. Account-/contract-specific DPA/SCC incorporation and the focused India/United States assessment were, under our internal deadline, to be completed 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 under the separate preconditions for Campaigns until its flow-specific evidence and manual approval are complete. No positive Chapter V status or technical enforcement in the Zoho account is claimed.
Anthropic (Kollen): a legal stop applies pending evidence of the processing country, as long as Anthropic may process outside the EEA in an unnamed country. The code stops the requests when the evidence is missing, but we have not yet confirmed that this block is deployed and working in the production environment. 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.
OpenAI (document extraction 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 document extraction's local document check, 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 set of stored data in the database or a new 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.