Data protection and subprocessors

Last updated: 2026-10-01

Revision status: The boundaries for head-teacher names and the records for the OpenAI and Anthropic requests, document extraction, JobEd and sign-in are reconciled with internal ROPA v3.17 and transfer annex v2.9. Kollen has a legitimate-interest basis and a clear instruction not to submit private or sensitive data. Requests to Anthropic are subject to a legal stop until dated provider/account evidence shows that processing outside the EEA is limited to the countries approved in our code and transfer annex, currently only the United States, with the DPF or SCCs and a country- and recipient-specific TIA; another country requires code and annex review. The code stops the requests when such evidence is missing, but we have not confirmed that this block is deployed and working in the production environment and do not assert it here. Zoho Mail has no positive release: new user-initiated inbound enquiries may be received, manually assessed and answered only to the strictly necessary extent after case-specific minimisation and under the matter's documented basis; no AI is used. Proactive or discretionary contact, campaign/relationship-building, automation, bulk processing and new integrations/features/data categories are not permitted. Document extraction is not subject to a blanket stop, but each use must first pass a simple, versioned, flow-specific assessment.

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

In processing activities P1–P3 — P1 organisation memberships/roles of the customer's users, P2 customer-directed imports and watches, and P3 instruction-bound support/incident material — the municipality is the data controller and Skolkoll is the data processor. Skolkoll is separately the controller for its own identity/access security, its own customer and billing administration, watches requested by an anonymous visitor, and other own purposes in the privacy policy. Stripe/billing records and public-source data are not automatically part of the processor engagement.

Data processor (Skolkoll): Skolspegeln AB
Organisation number: 559359-7288
Contact for data protection enquiries: info@skolspegeln.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. Processors, subprocessors and other recipients

The table lists providers by their actual role and processing activity. 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. Processor/DPA terms and transfer mechanisms apply where required for the relevant role and processing. Providers used for user-selected social login process their own account and authentication stage under their own terms; country and transfer mechanism are assessed provider by provider and are not reduced to one shared US/SCC scenario.

AI processing of school images

Before a new model request, one of two alternative checks must be satisfied. An image from the school-image form requires server-validated consent to AI stylisation and a positive editorial review. The consent must carry the current consent version, or be unversioned and submitted on or after 6 July 2026 (UTC), when the form already asked for today's AI consent but its people attestation excluded identifiable people only as main subjects. For such submissions, the editor's people inspection supersedes the submitter's weaker attestation. The review is bound to the current image hash, licence/rights attestations and exact optional author URL, confirming the rights basis and no identifiable people. A separate rights-cleared import does not require or claim form consent; it instead requires a distinct positive import review bound to the current image hash and source/licence/rights evidence, together with LIA §7.1 and the applicable Article 14 provenance. The current AI eligibility check on the school-image submission implements only the form-flow check, so the import route must use a separately recorded review before model processing. Missing or mismatched evidence stops new and retry requests; completed processing that satisfied its applicable check is not regenerated. For a form image, the photographer name and exact review-bound HTTPS link are published only where CC BY 4.0 or CC BY-SA 4.0 requires them. Where the submitter is the photographer, the current v3 review records direct information through the version-bound collection notice. A named third-party photographer must otherwise receive direct information within the Article 14(3) time limits. Article 14(5)(b) may replace direct information only after a dated and signed legal record has been registered expressly for the exact source and publication; the server-controlled register for such records 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 review evidence under the earlier v2 check may not publish a name or link and must be reviewed again; the chalk image itself does not need regeneration. CC0 collects and publishes no photographer/rights-holder name or person/source link. An optional photo date is used for review only and is not published. Skolkoll runs no separate AI moderation step. Only the image file and a static style instruction are sent to OpenAI — never contact details, photographer name, rights-holder name, source link, photo date or free-text form notes. According to OpenAI Data Controls, checked on 2026-07-29, the image flow's requests to OpenAI's image-editing interface have no application-state retention. Standard abuse-monitoring logs may nevertheless be retained for up to 30 days; image content flagged by the provider's safety systems may be held for manual safety review, and longer retention may occur where required for safety or legal obligations. These are exceptions that apply to that interface specifically, not a ZDR claim.

Internal AI support

Kollen. The chat is activated by the user and processes the question on the basis of legitimate interest (Article 6(1)(f)) under a documented balancing test. The interface instructs the user not to enter private or sensitive information. That instruction is the adopted preventive safeguard; no general technical free-text block is claimed. The instruction is not, however, an Article 14 exception if a user nevertheless submits data about another person. The open notice here and a documented proportionality assessment are used as compensating measures; if Skolkoll becomes concretely aware of the person and has contact details, individual notice is provided within the timing required by Article 14(3), unless an applicable exception is documented. Kollen is not approved for Article 9 or 10 data. If Skolkoll becomes concretely aware that such content was nevertheless submitted, further use of that content in the session stops; it is not reused or content-logged, and any incident/risk assessment is performed without copying the content. The legal basis does not replace the third-country transfer requirements: no request may run while Anthropic can route non-EEA processing to an unnamed country.

Document extraction (OpenAI). Officially published public documents may be used after a simple, documented and versioned assessment for the current municipality/portal/layout flow. Our technical controls check the whole document before every model request: private-source markers, personal identity numbers/pupil-identifying contexts and Article 9 or 10 indicators stop the document, while email addresses and phone numbers are removed from the separate provider copy. Classification can produce false negatives and this remains a residual risk. 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 on the strength of this text until they are verified. No extracted value is published automatically: candidates enter a human-reviewed queue. The legal basis is legitimate interest (Article 6(1)(f)); neither ZDR nor document-by-document review is a blanket requirement for this bounded public category. Document extraction uses OpenAI's Chat Completions interface for text generation with OpenAI's optional response storage switched off, so the response object is not retained as application state for the flow. That does not exclude the provider's other retention paths: prompt caching may retain encrypted KV tensors in GPU-local storage for up to 24 hours, standard abuse-monitoring logs may be retained for up to 30 days, and longer retention may occur where required for safety or legal obligations. The flow is therefore not described as retention-free or ZDR.

Journalist email and other user-initiated direct enquiries. A new inbound matter may be received, manually assessed and answered only to the strictly necessary extent after case-specific content and necessity minimisation under Zoho Mail's dated interim-risk restriction. The basis follows the matter as stated in the provider row above; free text is not assumed public and Article 9/10 content requires a separate basis or no further processing. Message content is not sent to Anthropic, OpenAI or another AI service. Proactive/discretionary contact, campaign/relationship-building, automation, bulk processing and new integrations/features/data categories are not permitted. Our internal deadline of 2026-08-14 passed without the evidence being completed; only the minimised intake continues, while escalation to a lawful replacement channel is under way.

For P1–P3 Municipal Licence data we use no advertising networks, marketing platforms or social-media pixels. Zoho PageSense may run only after explicit cookie consent from visitors on public, indexable pages. Skolkoll does not use Google Analytics. PageSense tracking is not run for signed-in municipal users. Internal usage statistics are collected through 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. Unless stated otherwise, the data is stored in our database (Google Cloud Firestore).

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 makes at most one asynchronous write attempt to the Kollen audit log in our database (Google Cloud Firestore) per eligible processed Kollen request. The response does not await that write, failures are logged, and storage is therefore not guaranteed. A stored entry contains call type, a keyed and domain-separated HMAC-SHA-256 pseudonym for the IP address truncated to 16 characters, school context as an exact eight-digit school-unit code or no value, question and answer length, status, a timestamp, and a deletion date.

Normal retention is 90 days: each entry is written with a deletion date set 90 days ahead. A check of the production environment on 2026-07-30 showed the automatic deletion rule (TTL) for the log's deletion date as active; this proves policy state, not deletion of a particular expired sample. Firestore's automatic deletion (TTL) removes the entry asynchronously after the deletion date; TTL is not an exact deletion timestamp.

To request earlier deletion, email info@skolspegeln.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 administrative access to the database. 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@skolspegeln.se. Include the school, approximate upload time and the email address used in the form. Rejected submissions become due for deletion 90 days after the decision and are handled by the next successful daily cleanup run that reaches the record. The cleanup flow leaves a minimal, pseudonymised audit entry in the log of school-image deletions. A due date in the deletion queue makes pending matters searchable. Only verified deletion of the active generation or an object already absent from the public path may record the time of public inaccessibility; a non-current generation enters retry/reinventory. The timestamp means public inaccessibility, not proof that a soft-delete window, provider retention or every physical byte has ended. 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@skolspegeln.se. Include the approximate time, outlet/newsroom and the email address used in the form. We then search for matching records among the journalist orders and manually delete or correct identifiable matches unless there is an ongoing delivery, dispute, regulator request or other legal basis for continued limited retention. The current journalist connectors to Desk and CRM are switched off in the software code and create no supplier record. If a quarantined legacy Desk/CRM record from earlier operation is actually found, it is included in the same correction or erasure assessment, subject to any applicable basis for limited continued retention. Any future approved replacement must be able to carry out the corresponding correction or deletion within the same order-bound lifecycle.

Self-service — user account

1. Sign in to the Skolkoll portal.
2. Go to Account settings.
3. Click Delete account. Confirm the dialog.
4. The account, your memberships, watchers and profile information are deleted immediately from the database.

What is not deleted automatically with the account: billing history is retained for 7 years under Swedish bookkeeping law. Entries in the audit log have 2-year retention. Our account-deletion log uses a hashed document ID and a hash of the account ID and retains email hash, status, safe error steps and cleanup counters for at most 12 months; it contains neither the account ID in plain text nor the email address in plain text and is not a continuing account. A check of the production environment on 2026-07-30 showed both deletion rules (TTL) as active; this proves policy state, not deletion of an expired sample, and deletion is asynchronous after expiry. 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 info@skolspegeln.se. We acknowledge receipt within 1 working day. Our internal target is to make an individual decision and, if the request is granted, complete the erasure within 14 days. Information on action taken is provided without undue delay and no later than one month after receipt under Article 12(3). Where necessary, the period may be extended by up to two further months, taking account of complexity and the number of requests; we notify you of the extension and reasons within the first month, and the final response may be provided during the extension period.

Removal request — named roles in the review service

Skolkoll no longer publishes head teachers' names as baseline data on school-unit pages, in open data files, APIs/exports or structured data. The same applies to representative names from annual-report data — board members, auditors, authorised signatories and report signers. Person-name fields are removed unconditionally at the public serving boundary (name-free by design). As long as the impact assessment for named person roles has not led to a positive decision, new or recurring population-wide internal name processing is paused; existing names may be used only for documented data cleanup, rights requests or a concrete, pre-documented editorial case with its own assessment. How to request removal or object to the processing:

• Head teacher: email info@skolspegeln.se with the school's unit code. The baseline display contains no head-teacher name. If a name nevertheless appears on an automated public surface due to an error, include the link; we remove the erroneous publication within 14 days, investigate the failed publication boundary and ensure that the name does not return through the automated synchronisation. A request concerning the non-public processing is handled under section 5.
• Board member, auditor, authorised signatory or report signer: email info@skolspegeln.se with the operator's organisation number and your role. To identify the correct record, we may also need your full name or a source/case reference even when the request concerns non-public processing. The details are used only as far as necessary for identification; your name is never entered in the block or audit evidence. If the request concerns an actual publication, also state where the name is shown (a link or page description). A request can also be registered preventively, as a block should the publication state change. Manual process: we acknowledge receipt within 7 days. Our internal target is to make the individual decision and, if the request is granted, implement it within 14 days. Information on action taken is provided without undue delay and within one month of receipt (GDPR Article 12(3)). Where necessary, the period may be extended by up to two further months; we notify you of the extension and reasons within the first month, and the final response may be provided during the extension period. Here too, a removed record is blocked from returning on future imports.
• The establishment's registered contact address: email info@skolspegeln.se and state the address — it is the identifier, and a block on the address covers every school unit you are responsible for. The address is the contact route the operator itself registered with the National Agency for Education's register for publication, and we reproduce it as registered. Where it takes the form firstname.lastname@ it does, however, identify you as a natural person, and an objection is then assessed individually under section 5. If it is upheld, the address is suppressed across all our surfaces and blocked from returning on future imports. If you have protected personal data, or are exposed to threats or domestic violence, we implement the suppression immediately and assess the case afterwards — we require no evidence and do not ask you to contact anyone else first.

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)

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. Our assessment of the position following the Court of Justice's judgment in case C-199/24 of 9 July 2026 is kept current through ongoing review as new case law or guidance from the Swedish Authority for Privacy Protection emerges, and this page is updated accordingly.

6. Information under Article 14 — named roles in the review service

Personal data obtained from public registers is normally subject to the information duties in Article 14 GDPR. As long as the data protection impact assessment (DPIA) for named person roles has not led to a positive decision, population-wide processing of named person roles is paused. For the separate access-controlled raw-source archive, source-archive assessment v1.3 has made the Article 14(5)(b) assessment conditional: individual notice to the whole group would require Skolkoll to build the person and contact mapping that data minimisation is intended to avoid. The dedicated archive row below is published safeguard information for this flow. On 26 September 2026, the Swedish and English production notices were verified together with the archive's access, storage and retention controls. Routine archiving is permitted within this boundary after documented activation under the source-archive assessment. Access and retention controls apply continuously; if a start condition is no longer met, new routine writes must stop. If we become concretely aware of an affected person and have a usable contact route, we provide direct notice within the Article 14(3) time limits unless another documented exception applies. Any other new person-role processing requires its own pre-documented Article 85 and Article 14 assessment; otherwise individual notice is provided no later than one month, or earlier at the first contact or disclosure. This page supplements the privacy policy and the publication policy (Swedish: publiceringspolicy).

Categories not intentionally extracted or entered into a derived compilation of named person roles: personal identity numbers, home addresses, private contact details, private finances, family relationships beyond the formal role, signatures, or special categories under Article 9. Signatures and other ordinary incidental personal data in an officially published original file may fall within the bounded archive row above. Article 9 or 10 data and private material may not be used further under archive decision v1.3. On actual detection, new writes and further processing stop and the material is deleted unless a separately documented incident or legal condition requires minimised access-restricted retention.

The data controller for this processing is Skolspegeln AB (org. no. 559359-7288), contact info@skolspegeln.se. (The processor role in section 1 concerns Municipal Licence data; for the review processing Skolkoll is the controller.)

Recipients: the approved recipient and storage target for the raw-source archive is Google Cloud within the EU as processor. The production storage location for the source archive has, since 2026-08-25, been verified in production for the source archive's four parts: region europe-west1 (Belgium), uniform bucket-level access and zero public principals, checked by the daily retention control. The verification covers the source archive — for Firestore and the Hosting logs, the corresponding check in production is still pending. Raw copies must not be disclosed publicly. Neither head-teacher names nor representative names from annual-report data are published as baseline data on skolkoll.se, in open data files, APIs/exports or structured data; the serving layer removes the person-name fields unconditionally. Names may appear in a separate editorial review surface only when a concrete review and its own publication assessment warrant it. There is no person search (you cannot search for a person's name) and there are no dedicated person-lookup pages.

The four-point pattern in the Swedish publishing policy applies only after such a separate editorial publication decision: a stated reason, a cited source, minimisation to the necessary name and role, and a removal/correction route. It safeguards that decided publication; it does not authorise names in the automated directory.

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. This block reflects the position following the Court of Justice's judgment in C-199/24 and is updated through ongoing review as new case law or guidance from the Swedish Authority for Privacy Protection emerges.

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). Document extraction checks the whole document in advance and sends only a contact-minimised provider copy; the residual risk is a classifier false negative. That risk and its mitigations are described in the table below and under Internal AI support.

Identified risks and mitigations

8. Personal data breach

In case of a suspected personal data breach:

1. Where Skolkoll is the processor in the Municipal Licence P1–P3 chain, we notify the agreed controller without undue delay, with an internal target for an initial fact-based notice within 24 hours, and then provide ongoing updates. The municipality assesses and is responsible for any Article 33 notification and Article 34 communication.
2. Where Skolkoll is the controller, we assess the risk and notify IMY without undue delay and, where feasible, within 72 hours after becoming aware when the breach is likely to result in a risk to individuals' rights and freedoms. Where a high risk is likely, we also inform the affected individuals without undue delay under Article 34.
3. 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 target: our configuration specifies europe-west1 (Belgium) for Firestore, Cloud Functions and Cloud Storage; 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. Stripe payments are processed primarily in Ireland. Domain routing for Zoho Mail/Campaigns and configured endpoints for Desk/CRM point to Zoho's EU services, but routing does not prove the Mail/Campaigns tenant's actual account region. Firebase Hosting uses a global CDN and is therefore not covered by the regional-storage target.
• USA/third countries: Firebase Hosting and Authentication and supplier access may involve processing outside the EU/EEA. Resend delivers through the United States. Zoho support from India and applicable US subprocessors, Sentry support from the US team, Anthropic/OpenAI calls and social-login providers may also involve third-country processing.

For third-country transfers the following legal mechanisms apply:

• Standard Contractual Clauses (SCCs) — used under EU Commission decision 2021/914 where the relevant provider and account agreement covers the third-country processing. An account-specific data processing agreement was signed with Zoho Corporation B.V. on 2026-09-11; under its clause 10 it supersedes the parties' previous data-protection agreements at account level. That agreement is the article 28(3)-(4) processor clauses, not the Chapter V transfer clauses. For Mail's India leg, Zoho Legal's 2026-09-08 response identifies SCC Module 3 in prose, but the mechanism remains supplier-asserted rather than contracted and the India/United States assessments remain open. For Campaigns, that agreement covers the article 28 incorporation; its Chapter V mechanism remains supplier-asserted rather than contracted, and every send requires separate prior checks. Mail has no positive release.
• EU-US Data Privacy Framework (DPF) — alternative legal basis for DPF-certified providers (Google, Stripe).

Schrems II implications are assessed per provider and scenario in internal transfer annex v2.9. Zoho Mail's account/contract incorporation and focused India/United States assessment were, under our internal deadline, to be completed no later than 2026-08-14. That deadline passed. Zoho Legal has since identified SCC Module 3 for the India leg in prose. The account-specific DPA was signed on 2026-09-11, but its Schedule 1 is the article 28(3)-(4) standard contractual 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. The assessment under current Indian law and the focused United States assessment remain open: the agreement's Schedule 2 names India alone as the group entity permitted to access EEA customer data, while the supplier's own SOC 1, SOC 2 and ISO location annexes place Austin in the United States in scope for support. The fallback is therefore still the operative state: the dated interim-risk restriction with no positive release remains, and only minimised legally necessary intake occurs while escalation to a lawful replacement channel is under way. Campaigns is the designated platform, but the next send and every send-capable automation are stopped until the evidence for its separate account-specific requirements is complete and the send is manually approved. Municipal Licence customers may request a relevant extract.

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); the administrator key is compared in constant time to hinder timing attacks; audit log 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 version control.
• 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: Point-in-Time Recovery (PITR) is the target for Firestore and, when enabled, provides point-in-time restore within the window Google Cloud offers (up to 7 days). Actual production PITR status and any scheduled backup exports are not supported by an archived check in this revision, and we do not describe them as active until they have been checked directly in the production environment. 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.
• Security appendix — documents the checks before production release, stage/production isolation, build integrity and security headers; delivered as an annex to procurement responses. The appendix is approved for use in procurement responses by a documented decision of 8 August 2026. The approval does not cover the points in the security appendix's checklist that are not yet finalised. Since 2026-08-25 the Cybersecurity Act assessment is complete and dated, and a backup authority has been appointed. Still open: support-tier/SLA dependencies, a cold recovery test, and the outstanding TOM and supplier evidence. For the backup authority, note that she is appointed with working access, but the path is unexercised: she has held her own second factor on the service accounts since 2026-08-26, but no recorded and tested out-of-hours channel exists, and access runs through a shared credential vault — so actions are logged under the maintainer's identity and cannot be revoked independently. The security appendix's own hand-over checklist is the authoritative and complete list; the summary here is an extract. None of its items may be presented as commitments.

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