Last updated: 2026-07-12
This page is aimed at municipal procurement officers and data protection officers (DPOs) who need to review Skolkoll's data processing prior to contract. For a general overview, see the privacy policy. For a data processing agreement (DPA), see the DPA template.
1. Roles and contact
For personal data covered by the Municipal Licence agreement, the municipality is the data controller and Skolkoll is the data processor. For personal data Skolkoll processes for its own purposes (e.g. visitors to skolkoll.se without an account), Skolkoll is the data controller — see the privacy policy.
Data processor (Skolkoll): Skolspegeln AB
Organisation number: 559359-7288
Contact for data protection enquiries: markus@skolkoll.se
Skolkoll has not appointed a Data Protection Officer (DPO) because the operation does not meet the criteria in GDPR art. 37 (the core activity is not large-scale monitoring of personal data; no special categories of personal data are systematically processed).
2. Subprocessors
Skolkoll uses the following third-party services to provide the service. All have their own DPAs that comply with GDPR. The identity providers used for social login process authentication data under their own terms and the EU Standard Contractual Clauses (SCCs).
| Provider | Service | Data category | Region | DPA |
|---|---|---|---|---|
| Google Cloud (Firebase) | Hosting, Firestore, Cloud Functions, Cloud Storage, Authentication | User accounts, organisation data, analyticsEvents, billing history | Cloud Functions, Hosting, Cloud Storage and Firestore: europe-west1 (Belgium). Firebase Authentication is covered by the Google Cloud DPA/SCCs/DPF without a separate europe-west1 assertion here. | Google Cloud DPA (SCCs included) |
| Stripe Payments Europe Ltd | Payment processing (card + invoice) | Billing address, email, organisation number, payment metadata. Card details never pass through Skolkoll's servers. | Ireland (EU) primarily; some fraud-detection functions may involve Stripe US under SCC. | Stripe DPA |
| Resend Inc. | Transactional email (account confirmations, invoices, watcher digests, security alerts) | Email address, name, subject, message body (deleted at Resend after 30 days) | EU/US (Resend's EU region used where available; SCCs apply for any US transfer) | Resend DPA |
| Functional Software, Inc. (Sentry) | Error monitoring for frontend and Cloud Functions | Error messages and stack traces, browser, OS, IP address (anonymised shortly after receipt by Sentry). In exceptional cases a stack trace may contain form data that was active when the error occurred. | EU (Germany, ingest.de.sentry.io); SCC for any support by US team | Sentry DPA |
| Zoho Corporation / Zoho PageSense | Web analytics, A/B testing, heatmaps/session recording on public pages after consent | Page views, clicks/scrolling, heatmap and session-recording interactions, experiment variant, device and browser info. PageSense is not activated on noindex/account/admin pages and is loaded only after analytics consent. | EU script via cdn-eu.pagesense.io; Zoho DPA/SCCs for any transfer outside the EU/EEA | Zoho GDPR/DPA |
| Zoho Corporation / Zoho Desk | Customer support via support@skolkoll.se/the support portal and journalist data-order tickets when the Zoho intake has been approved and enabled | Name, email address, organisation membership or newsroom/outlet context, ticket/order content, ticket history, internal triage tags, private quality/neutrality comment with risk class/flags, and technical attachments voluntarily submitted by the customer or journalist. | EU (the support portal support.skolkoll.se points to Zoho EU hosting, zohohost.eu); Zoho DPA/SCCs for any transfer outside the EU/EEA | Zoho GDPR/DPA |
| Zoho Corporation / Zoho CRM | CRM contact for journalist data orders, server-side only after the Zoho intake has been approved | Minimal relationship metadata: name, email address, newsroom/outlet, beat, source and order status. Not used for campaign/newsletter sends without separate consent and provenance. | EU API via www.zohoapis.eu; Zoho DPA/SCCs for any transfer outside the EU/EEA | Zoho GDPR/DPA |
| Anthropic / OpenAI | "Kollen" AI chat and AI-based school-image stylisation (both only after consent), plus two internal processing operations that do not require consent: document extraction (Lane-D) and drafting replies to journalist emails. See "Internal AI support" below. | Chat messages + school context, and uploaded school-image submissions that are transformed into a chalkboard-style illustration. The image is then processed under OpenAI's own safety and content policies; the editorial review and approval before publication is done by a human. For school images, the image file is sent to OpenAI; contact details, photographer name, rights-holder name and free-text form notes are not sent to the AI provider. The internal processing operations Lane-D document extraction (OpenAI) and journalist-email drafts (Anthropic) handle additional data categories — see "Internal AI support" below for data flow and legal basis. AI chat and Lane-D requests are sent with storage disabled (no-store) where the API supports it (Anthropic: opt-out from training is the default). | US (Anthropic and OpenAI) — under SCC | Anthropic DPA · OpenAI DPA |
| Identity providers (Google, Microsoft, GitHub, Facebook, Apple) | Social login (OAuth/OIDC) — only if the user chooses this sign-in method instead of email/password | Name and email address from the chosen provider at sign-in | US (all) — under SCCs | Each provider's DPA/terms; transfer to the US under the EU Standard Contractual Clauses (SCCs) |
AI processing of school images
When you submit the school-image form, separate consent is required before the image may be sent to OpenAI for AI-based chalkboard stylisation. The image is then processed under OpenAI's own safety and content policies. The content review and approval of the image before publication is done by a human editor — Skolkoll runs no separate AI moderation step. The image file may be sent to OpenAI, but contact details, photographer name, rights-holder name and free-text form notes are not sent to OpenAI. Those details are stored in Skolkoll's Firestore for editorial review, attribution, rights tracking and possible disputes.
Internal AI support
Beyond the user-facing AI ("Kollen" chat and school-image stylisation, both of which require consent), Skolkoll uses AI in two internal processing operations. Neither is published or sent automatically — a human reviews and decides first. The legal basis for both is legitimate interest (art. 6.1.f), not consent.
Document extraction (Lane-D, OpenAI). To compile figures from public records (allmän handling) — primarily statistics on degrading treatment — the raw text of the documents is sent to OpenAI (gpt-4o-mini) for structured extraction. Because it is raw text from public records, a document may contain pupil data, and that text may then pass through OpenAI. Masking of personal data is applied to what Skolkoll stores after extraction, not to what is sent to OpenAI. The requests are made with storage disabled (no-store), and no extracted value is published automatically: all candidates go to a human-reviewed queue and auto-publication is disabled.
Journalist reply drafts (Anthropic). Incoming journalist emails (the sender's name, email, newsroom and message text) are sent to Anthropic (Claude) to classify the query and propose a draft reply. A human reviews and sends; no reply is sent automatically. Anthropic does not train on API content by default. The data is not used for mailings, campaigns or CRM without separate consent and provenance.
For Municipal Licence data (user accounts, organisation data, billing history) we use no advertising networks, marketing platforms, or social media pixels. Web analytics via Google Analytics 4 and Zoho PageSense runs only after explicit cookie consent from visitors on public, indexable pages — see the privacy policy for details. For signed-in municipal users no GA4 or PageSense tracking is performed regardless of consent. Internal usage statistics are collected via our own anonymous collector in Firebase without personal data.
Notice of subprocessor change
While a Municipal Licence is active, we notify the agreed contact person, DPO and the organisation's administrators by email at least 30 days before adding or replacing a subprocessor. The municipality has the right to object during that period — objections are handled per the Municipal Licence agreement's termination clause. We do not use the new subprocessor for the municipality's personal data before the objection has been handled or the termination period has expired.
3. Retention periods per data category
Periods are measured from the most recent event (e.g. last login, last payment). After the listed time the data is deleted or anonymised.
| Data category | Firestore collection | Retention | Legal basis |
|---|---|---|---|
| User accounts (profile, memberships) | users, organizations/{id}/members | Until deleted by the user. Inactive accounts (24 months without login) receive a reminder and are deleted after 36 months. | Contract (art. 6.1.b) |
| Organisations + Pro subscriptions | organizations, organizations/{id}/subscriptions | Active for the lifetime of the subscription. Billing history retained for 7 years (Swedish bookkeeping act). | Legal obligation (art. 6.1.c) for bookkeeping |
| Analytics events (raw) | analyticsEvents | 90 days, then individual events are deleted. Aggregated daily summaries (no personal data) are retained indefinitely. | Legitimate interest (art. 6.1.f) — product development. No personal data is stored (sessionId is random, no IP, no user-agent). |
| Widget beacon and abuse triage | widgetAbuseLog | Only anomalous or suspicious widget loads are logged. Entries are written with expiresAt = now + 30 days and deleted through Firestore TTL when the TTL policy for widgetAbuseLog.expiresAt is active. | Legitimate interest (art. 6.1.f) — attribution, rate limiting, abuse and security traceability. Contains embedder origin, widget type, municipality/school slug, anomaly flags and a salted IP hash; no cookies. |
| Mail contacts and campaign lists | mailContacts, mailLists, campaigns | Until unsubscribed. Unsubscribed contacts retain an anonymised email hash (to prevent re-subscription) for 24 months, then full deletion. | Consent (art. 6.1.a) for newsletters; contract (art. 6.1.b) for transactional emails. |
| Audit log | auditLog | 2 years. Each new entry is written with expiresAt = now + 2 years and is deleted by Firestore TTL when the TTL policy for auditLog.expiresAt is active. TTL deletion is asynchronous after expiry. | Legitimate interest (art. 6.1.f) — security, traceability, access-control review and dispute/incident investigation. |
| API usage quota | apiQuota/{orgId}/months/{YYYY-MM} | 13 months (for billing reconciliation and dispute). | Legal obligation (art. 6.1.c) |
| Watchers | watchers, watcherEvents | Active watchers are stored until the user ends them or deletes the account. Pending confirmations have a 48-hour token window and are cleaned by the cleanup flow. Watcher events in watcherEvents are cleaned continuously by the digest job, normally within 35 days. | Consent (art. 6.1.a) for anonymous double opt-in; contract (art. 6.1.b) for signed-in account features. |
| Journalist data orders | journalist_orders | FAS-0 decision: the Firestore record is deleted once the order is handled plus a recovery window, with a target of 180 days from submission. Each record is written with a purgeAfter field and Firestore TTL for that field must be deployed and verified before full go-live; until TTL is active, FAS-0 requires a named monthly manual purge owner. Orders unresolved after 180 days require documented approval and have a 12-month hard cap. Zoho Desk tickets are deleted no later than 12 months after closure. The Zoho CRM contact is reviewed at least annually and order-specific status/description is removed when no longer needed. | Consent (art. 6.1.a) for storage/contact through the form; request handling/pre-contractual steps where applicable (art. 6.1.b); legitimate interest (art. 6.1.f) for abuse prevention, operational recovery and editorial relationship handoff. No campaign or newsletter use without separate consent/provenance. |
| School-image submissions and rights data | schoolImageSubmissions | Pending submissions are retained until editorial review is complete. Rejected submissions are deleted after 90 days through the cleanup flow. Approved submissions and associated rights data are retained for as long as the image is used as source/provenance material for a published school image, or until deletion/unpublication is requested and can be completed without breaking rights tracking. | Upload and AI processing: consent (art. 6.1.a). Attribution, rights tracking and possible disputes after review/publication: legitimate interest (art. 6.1.f). Fields may include photographerName, rightsHolderName, contactEmail, contactPhone, schoolName, note and image file. |
| Deletion evidence for rejected school images | imageCleanupAudit | 7 years from cleanup. Each entry is written with expiresAt = deletedAt + 7 years and is deleted through Firestore TTL when a TTL policy for imageCleanupAudit.expiresAt is active. The entry contains only submissionId, cutoff date, deletion reason, deletion timestamp and an optional HMAC-SHA-256 hash of the contact email — not raw contact data, image files, school name or free text. | Legitimate interest (art. 6.1.f) and accountability under GDPR art. 5.2 — being able to answer whether a previously deleted image submission was processed without retaining raw personal data. |
| AI chat conversation | Browser sessionStorage only — never on our server. | Deleted when the browser tab is closed. | Consent (art. 6.1.a) |
| AI audit log | ai-audit-log | Each entry is written with expiresAt = now + 90 days. Deletion happens through Firestore TTL when a TTL policy on expiresAt is active; TTL deletion is asynchronous after expiry and cannot be guaranteed exactly on day 90. Operational release verification: gcloud firestore fields ttls list must show an active TTL policy for ai-audit-log.expiresAt. | Consent (art. 6.1.a) and legitimate interest (art. 6.1.f) — abuse and security traceability. |
4. Right to erasure — operational flow
You can exercise the right to erasure (GDPR art. 17) in the following ways, sorted from fastest to most manual:
AI audit log — TTL and manual deletion
The AI chat does not permanently store questions or answers on Skolkoll's server. For abuse and security traceability, the server writes one pseudonymised audit entry to the Firestore collection ai-audit-log for each AI call. The entry contains call type, SHA-256 hash of the IP address truncated to 16 characters, school context (maximum 50 characters), question and answer length, status, timestamp, and expiresAt.
Normal retention is 90 days: each entry is written with expiresAt = now + 90 days. Firestore's TTL mechanism deletes the entry asynchronously after expiresAt when the TTL policy for ai-audit-log.expiresAt is active. TTL is not an exact deletion timestamp; deletion can happen some time after the field's timestamp has passed.
To request earlier deletion, email info@skolkoll.se with the approximate time and any school context for the AI call. We then search server-side for matching entries and manually delete identifiable matches using the Admin SDK. If an entry cannot be matched without collecting additional data, it remains until the TTL retention expires.
School-image submissions — unpublication and deletion
If you have submitted a school image, you can request unpublication, deletion or correction of photographer/rights-holder data by emailing info@skolkoll.se. Include the school, approximate upload time and the email address used in the form. Rejected submissions are deleted automatically after 90 days. The cleanup flow leaves minimal deletion evidence in imageCleanupAudit so we can answer whether the submission was processed after the raw data has been deleted. For approved/published submissions we perform a manual rights check before deletion, because attribution and rights tracking may need to be retained to handle licence or dispute questions.
Journalist data orders — manual deletion
If you have submitted a no-account data order, you can request deletion or correction by emailing info@skolkoll.se. Include the approximate time, outlet/newsroom and the email address used in the form. We then search for matching journalist_orders records, manually delete or correct identifiable matches, and, if the Zoho intake was enabled, handle the corresponding Desk/CRM record unless there is an ongoing delivery, dispute, regulator request or other legal basis for continued limited retention.
Self-service — user account
- Sign in to the Skolkoll portal.
- Go to Account settings.
- Click Delete account. Confirm the dialog.
- The account, your memberships, watchers and profile information are deleted immediately from the database.
What is not deleted automatically: billing history is retained for 7 years per Swedish bookkeeping law. Audit log entries (auditLog) are tagged with expiresAt for 2-year retention and deleted asynchronously by Firestore TTL when the policy is active. Aggregated analytics data already contains no personal data and is unaffected.
Erasure request — Municipal Licence administrator
As a municipal admin you can request erasure of a specific employee from the organisation by emailing support@skolkoll.se. We acknowledge receipt within 1 working day and complete the erasure within 14 days (the GDPR's ordinary response period is one month from receipt of the request).
Removal request — named roles in the review service
Skolkoll currently displays head teachers' names (from Skolverket's register) on school-unit pages. Representative names from annual-report data — board members, auditors, authorised signatories, report signers — are processed in the data layer but are currently not published on public surfaces or in the API: the person-name fields are nulled unconditionally in the serving layer (name-free by design). Such names may, however, appear in editorial review surfaces (e.g. related-party reviews) when a concrete review warrants it. How to request removal:
- Head teacher: email info@skolkoll.se with the school's unit code. We remove the data from the display within 14 days and set a sync filter so it does not return even if Skolverket continues to publish it.
- Board member, auditor, authorised signatory or report signer: email info@skolkoll.se with the operator's organisation number, your role and where on skolkoll.se the name appears (a link or page description). Because representative names are currently not published as baseline data, you only need to provide your full name if you are pointing to an actual publication — the name is then used to identify the correct record when several people share the same role and to derive an internal source reference; the block-list entry itself never stores your name. A request can also be registered preventively, as a block should the publication state change. Manual process: we acknowledge receipt within 7 days and decide within one month of receipt of the request (GDPR art. 12.3). In complex cases the period may be extended by two months — we then notify you within that same one-month period from receipt and state the reasons. Here too, a removed record is blocked from returning on future imports.
If you instead want to object to the processing as such — which places the burden of proof on us — see section 5.
5. Your right to object (Article 21 GDPR)
This information is provided explicitly and separately from other information, as required by Article 21(4) GDPR.
Where Skolkoll processes your personal data on the basis of legitimate interest (Article 6(1)(f)) — this includes the baseline display of head-teacher names and the processing of company-representative roles in the data layer, see section 6 — you have the right to object at any time to the processing, on grounds relating to your particular situation. The right to object applies to the processing as such, whether or not the data is currently displayed publicly.
Once you have objected, we may no longer process the data unless we can demonstrate compelling legitimate grounds for the processing which override your interests, rights and freedoms. The burden of proof is on us, not on you.
How to object: email info@skolkoll.se. State your role and identifiers: the school unit code if you are a head teacher; the operator's organisation number and your role if you are a board member, auditor, authorised signatory or report signer. If your name appears on an actual surface, state where it is shown (a link or page description) and your full name — the name is then used only to identify the correct record and derive an internal source reference; the block-list entry itself never stores the name. Preferably also describe the circumstances you rely on. We acknowledge receipt within 7 days, assess the objection individually and in a documented manner, and decide within one month of receipt of the objection (Article 12(3)). If we cannot demonstrate compelling legitimate grounds, the data is removed from the display and blocked from returning on future updates from the source registers.
If you are not satisfied with our decision you can complain to the Swedish Data Protection Authority (IMY) — see section 12.
To the extent a given surface is covered by the journalistic exemption (chapter 1, section 7 of the Swedish Data Protection Act), Article 21 does not formally apply — we nevertheless assess every objection under the framework above. The legal position following the Court of Justice's judgment in case C-199/24 of 9 July 2026 is under external legal review (opinion expected by 21 August 2026); this page will be updated if that review changes the assessment.
6. Information under Article 14 — named roles in the review service
Skolkoll processes — and in some cases displays — personal data that was not collected from the data subjects themselves but from public registers. Article 14 GDPR requires that the data subjects be informed. The processing concerns named role holders at roughly 16,500 school units and their operators; notifying each person individually would involve a disproportionate effort, and Skolkoll therefore relies on the exception in Article 14(5)(b). As the compensating measure, the information is instead kept openly available here. It supplements the privacy policy and the publication policy (Swedish: publiceringspolicy).
| Category of personal data | Source | Legal basis | Retention / mirroring logic |
|---|---|---|---|
| Head teacher's name, role and school unit | Skolverket's register (open data) | Journalistic purposes (Article 85 GDPR, chapter 1, section 7 of the Swedish Data Protection Act) for edited review surfaces; legitimate interest (art. 6(1)(f)) for the baseline display on school-unit pages | The record mirrors the source register and is replaced/updated on every synchronisation. Removed or objection-filtered records are blocked from returning through a sync filter. |
| Representative roles at school operators — board member, auditor, authorised signatory, report signer (name + role + operator). Processed in the data layer; the names are currently not published as baseline data (see Recipients below) | Bolagsverket, public annual reports | Journalistic purposes in a review context (e.g. related-party analysis); legitimate interest (art. 6(1)(f)) otherwise | Deregistered roles are pseudonymised or removed no later than five years after deregistration. Removed records are blocked from returning. |
Categories we do not process in these datasets: personal identity numbers, home addresses, private contact details, private finances, family relationships beyond the formal role, or special categories under Article 9.
The data controller for this processing is Skolspegeln AB (org. no. 559359-7288), contact info@skolkoll.se. (The processor role in section 1 concerns Municipal Licence data; for the review processing Skolkoll is the controller.)
Recipients: head teachers' names are publicly visible on skolkoll.se — on school-unit pages and in the open data files that power the service. Representative names from annual-report data are currently not published on public surfaces or in the API (the serving layer nulls the person-name fields unconditionally); they may appear in editorial review surfaces when a concrete review warrants it. There is no person search (you cannot search for a person's name) and there are no dedicated person-lookup pages.
Your rights: access (art. 15), rectification (art. 16), erasure (art. 17 — see section 4), restriction (art. 18) and objection (art. 21 — see section 5), plus the right to complain to IMY (section 12). To the extent the processing takes place for journalistic purposes, parts of the GDPR are formally exempted (chapter 1, section 7 of the Swedish Data Protection Act) — Skolkoll nevertheless applies the processes above as documented practice.
The documentation behind this block (legitimate interest assessment and ongoing data protection impact assessment) is working-draft material under external legal review following the Court of Justice's judgment in C-199/24 (opinion expected by 21 August 2026). This block will be updated if that review changes the assessment.
7. DPIA-light — risk assessment for Municipal Licence
For Municipal Licence customers we have done a simplified Data Protection Impact Assessment (DPIA-light) per GDPR art. 35. The conclusion that a full DPIA is not mandatory applies to the processing within the Municipal Licence delivery, where the municipality is the data controller and Skolkoll the data processor (see section 1): that 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). Skolkoll's public review activity, where Skolkoll is the data controller, is assessed separately — a full DPIA for that processing is in progress (2026). Lane-D document extraction may temporarily process raw text from public records that can contain pupil data before masking — this exposure and its mitigations are described in the risk table below and under Internal AI support.
Identified risks and mitigations
| Risk | Likelihood × Impact | Mitigation |
|---|---|---|
| Unauthorised access to organisation data | Low × Medium | Firebase Auth with MFA support; admin role check on the server side; auditLog for all admin actions. |
| Data leak via subprocessor (Firebase, Stripe, Resend) | Low × High | EU regions where possible; SCCs for US transfers; least-privilege data sets (Stripe sees no school data; Resend sees only email + subject). |
| Incorrect publication of head teacher's name | Medium × Low | Source is Skolverket's open API; removal on request within 14 days (section 4) and objection assessment per section 5; the sync filter applies removals permanently. |
| Vulnerability in the open analytics endpoint | Low × Low | Origin allowlist, distributed rate-limiting, and event size caps. No personal data is collected in analytics. |
| Operational incident — silent scheduled-function failure | Medium × Low | Error-alerting wrapper emails ops on every scheduled-function failure. Manual backfill endpoint exists for critical syncs. |
| Pupil data in raw text reaching OpenAI before masking during Lane-D document extraction | Low × Medium | Only public records (allmän handling) are processed; requests are made with storage disabled (no-store) and the OpenAI DPA/SCCs apply. Masking is applied to what is stored, no automatic publication occurs, and all candidates pass through a human-reviewed queue before anything can be published. Processing is limited to approved document layouts and municipalities. |
8. Personal data breach
In case of a suspected personal data breach:
- Skolkoll gives affected Municipal Licence administrators and the Data Controller's agreed contact, if separate, a preliminary email notice within 24 hours and then provides ongoing updates.
- Notification to the Swedish Data Protection Authority (IMY) happens within 72 hours if the incident poses a risk to individuals' rights.
- The incident-response runbook and postmortem process is described in the Municipal Licence agreement annex ("IR runbook").
9. International data transfer
Personal data is processed in the following regions:
- EU/EEA: Firestore, Cloud Functions, Hosting and Cloud Storage via Firebase in
europe-west1(Belgium); Stripe payments primarily in Ireland; Zoho Desk/CRM through Zoho's EU endpoints for support and approved data orders. - USA/third countries: Firebase Authentication may involve Google processing outside the EU/EEA. Sentry support from the US team, some Resend transfers, Anthropic/OpenAI calls (chat and school image after consent; Lane-D extraction and journalist-email drafts on legitimate interest) and social-login providers may also involve US processing.
For all US transfers the following legal mechanisms apply:
- Standard Contractual Clauses (SCCs) — Google/Firebase Authentication, Stripe, Resend, Anthropic, OpenAI and the social-login identity providers (Google, Microsoft, GitHub, Facebook, Apple) are covered by SCCs per EU Commission decision 2021/914 when processing occurs outside the EU/EEA.
- EU-US Data Privacy Framework (DPF) — alternative legal basis for DPF-certified providers (Google, Stripe).
Schrems II implications: Skolkoll has performed a Transfer Impact Assessment (TIA) per provider. Summary available on request from Municipal Licence customers.
10. Technical and organisational security measures
- Encryption in transit: TLS 1.2+ for all communication; HSTS enabled.
- Encryption at rest: Firestore encrypts all data automatically with Google-managed keys.
- Access control: Role-based access (admin / user); admin token compared via timing-safe-equal; auditLog for all admin API calls.
- Secrets: All API keys and tokens are stored in Google Secret Manager and provided to runtime securely via Firebase Functions secrets binding. They are not present in source code or committed to the repository.
- Rate limiting: Distributed Firestore-backed rate limiter on all public endpoints; analytics pipeline hardened against abuse via origin allowlist and event size caps.
- Validation: Strict schema validation on all user inputs; field-level length caps; metadata type enforcement including array-element validation.
- Monitoring: Cloud Logging for all functions; error alerting via Resend to ops distribution list on scheduled-function failures; planned Cloud Monitoring policy for error rate.
- Backup: Firestore is configured for Point-in-Time Recovery (PITR) via Google Cloud, which provides point-in-time restore within the window that Firestore PITR offers (up to 7 days). Actual PITR status and any scheduled backup exports are verified using
gcloud firestore databases describeandgcloud firestore backups schedules listrespectively before each release. Recovery has not been exercised in a controlled disaster-recovery drill — we intend to run such a drill ahead of the first Municipal Licence production deployment.
11. Documents for municipal procurement
- DPA template (data processing agreement) — based on SKR's Swedish standard contract.
- Service Level Agreement (SLA) — uptime commitments, support response times, escalation path, and credit policy.
- ROPA summary (Records of Processing Activities) — public summary of the processing register per GDPR art. 30. Full extract available on request to Municipal Licence customers.
- IR runbook — incident-response process and contact details, delivered as an annex to the Municipal Licence agreement.
12. Complaints
If you believe we are processing your personal data unlawfully you have the right to lodge a complaint with the supervisory authority:
Swedish Data Protection Authority (IMY)
Web: imy.se/en
Email: imy@imy.se
Phone: +46 8-657 61 00