# Skald Privacy Policy

> **PILOT VERSION.** Skald is in a closed pilot, not yet operating as a paid B2B service. This privacy policy is the in-house version Skald relies on with pilot users; external legal counsel review is scheduled to complete **before paid general availability** and any remaining `<<PLACEHOLDER: …>>` tokens must be resolved by then. Pilot users are informed of this posture at onboarding.

**Last updated**: 2026-05-14
**Policy version**: 2026-05-13
**Geographic scope**: Norway and the European Economic Area (EEA). See § 12.

---

## 1. Who we are

Skald (`<<PLACEHOLDER: registered legal entity name — e.g., "Skald AS">>`, a `<<PLACEHOLDER: country of incorporation>>` company with company number `<<PLACEHOLDER: company number>>`, registered office at `<<PLACEHOLDER: registered address>>`) is the **data controller** for the personal data described in this policy, except where this policy expressly identifies a different controller (for example, your employer's organisation acts as controller of the content you create inside Skald).

You can reach us at:

- **Email**: `<<PLACEHOLDER: privacy contact email, e.g., privacy@skald.app>>`
- **Post**: as above
- **Privacy contact**: `<<PLACEHOLDER: named role — at launch, the founder; replace with DPO once appointed>>`

Skald has not appointed a Data Protection Officer at this time (we have assessed Art. 37(1) GDPR and determined that mandatory appointment does not currently apply). The privacy contact above performs the equivalent function and reviews this assessment annually.

---

## 2. The short version

Skald is a B2B SaaS application for product management. We hold three kinds of personal data:

1. **Pointers to your Clerk identity** (`clerk_user_id`, `clerk_org_id`) so we can show your work as yours and your organisation's as theirs. We do **not** mirror your name, email, or password — Clerk holds those.
2. **Content you and your colleagues author** — requirements, descriptions, board content, planning data, agent prompts. This is your organisation's content; we process it on your organisation's behalf.
3. **Operational data** — webhook records, audit log entries, your consent record on the cookie banner, request metadata at our hosting layer.

When you delete your account, we replace the pointer to you with a sentinel value (`deleted_user`) so your contributions stop being identifiable as yours. When your organisation is deleted, we archive its content and permanently delete it 30 days later (see § 8 — note the disclosed gap, in force until our retention purge ships).

For self-service: sign in and use **Account settings → Download my data**. Organisation admins can use **Organisation settings → Export organisation**. If you can't sign in (for example, because your account is already deleted), see § 6 — Your rights.

---

## 3. What personal data we collect and where it comes from (Art. 13(1)(c), 14(1)(d))

### 3.1 Data we receive from Clerk (our identity sub-processor)

When you sign up or sign in via Clerk, Skald receives an opaque user ID (`user_…`) and your organisation ID (`org_…`) on every authenticated request. Skald does **not** receive your password, OAuth tokens, MFA factors, or session secrets — those live with Clerk.

### 3.2 Data you and your colleagues create inside Skald

- **Requirements, descriptions, gherkin scenarios, glossary entries, board content, planning data, share links, agent prompts and responses.**
- **Attribution metadata**: `created_by`, `updated_by`, and similar columns are populated with your `clerk_user_id`.
- **Free-text content (Art. 14(1)(d)) — important note**: titles, descriptions, gherkin, board entries, and agent prompts can incidentally include personal data about third parties (for example, the name of a stakeholder mentioned in a requirement description). Skald does **not** automatically scan for, redact, or filter such incidental personal data. Your organisation is the **controller** for that content under our Data Processing Agreement (DPA, see § 4). The org admin is responsible for managing how your organisation's users handle third-party personal data in free-text.

### 3.3 Data Skald collects automatically

- **Request metadata at the hosting layer**: IP address, user-agent, referrer. Held briefly at the edge by our hosting sub-processor for routing, rate-limiting, and abuse detection (see § 4 — Vercel).
- **Audit log entries** (`audit_events` table): webhook deliveries (Clerk), data exports, rectifications, retention purges, breach incidents, sub-processor changes. Each entry is pseudonymous (it stores `clerk_user_id`-class identifiers, not your name).
- **Consent record** (`consent_records` table): your cookie preference and the version of this policy you saw when you made it (see § 11).

### 3.4 Agent interactions

When you invoke an AI feature, the free-text you type — and the surrounding context Skald gathers for the agent — is sent to **Anthropic** (our LLM sub-processor, US) for inference. Anthropic does not use Skald API content to train models per their published data-use policy. See § 4 — Anthropic.

If `MASTRA_CLOUD_ACCESS_TOKEN` is enabled in our production environment, agent traces are also sent to **Mastra Cloud** (US) for observability. See § 4 — Mastra Cloud.

---

## 4. Recipients (Art. 13(1)(e), 14(1)(e)) — our sub-processors

Skald uses the third-party service providers below to deliver our service. They process personal data on our behalf within the scope of our written instructions. Full details are in our [sub-processor list](./sub-processors.md).

| Sub-processor | Role | Country |
|---|---|---|
| **Clerk** | Authentication; identity controller | United States |
| **Neon** | Postgres database hosting | `<<PLACEHOLDER: confirm region>>` (assumed United States) |
| **Vercel** | Application hosting, edge network, cron scheduler | United States (global edge) |
| **Anthropic** | Large language model inference for agent features | United States |
| **Mastra Cloud** | Optional agent-trace observability | United States; conditional — only active when `MASTRA_CLOUD_ACCESS_TOKEN` is set |

We notify existing customers in writing **at least 30 days before** any new sub-processor begins processing their organisation's data (see [sub-processors.md § Sub-processor change-notification procedure](./sub-processors.md#sub-processor-change-notification-procedure)).

---

## 5. International transfers (Art. 13(1)(f), 14(1)(f))

All of Skald's current sub-processors process personal data outside the EEA (in the United States). Each non-EEA transfer relies on the **2021 Standard Contractual Clauses** (Modules 2 / 3 as applicable) executed with the sub-processor, plus the technical and organisational supplementary measures described in our [Transfer Impact Assessment](./transfer-impact-assessment.md).

Where a sub-processor is self-certified under the **EU-U.S. Data Privacy Framework**, that certification provides an additional parallel basis under Art. 45 GDPR; it does not replace the SCCs and supplementary-measures analysis.

You can obtain a copy of the SCCs executed with any of our sub-processors by contacting `<<PLACEHOLDER: privacy contact email>>`.

---

## 6. Your rights (Art. 13(2)(b), 14(2)(c) and Art. 15–22)

You can exercise the following rights free of charge.

### 6.1 Right of access (Art. 15) and right to data portability (Art. 20)

**Self-service** (preferred):

- **Personal data**: sign in to Skald and open **Account settings → Download my data**. You will receive a machine-readable JSON archive containing every row referencing your `clerk_user_id`, your AI agent threads, and a pointer to Clerk's own identity export for the parts Clerk holds.
- **Organisation content**: if you are an organisation administrator, open **Organisation settings → Export organisation**. You will receive a machine-readable JSON archive containing every row owned by your organisation.

The export envelope is documented in `<<PLACEHOLDER: link to docs/legal/export-example.json once published — generated by the spec 005 Story 6 sub-plan>>`.

**Free-text content is included as-is** in both exports — we do not attempt to redact incidental personal data about third parties from titles, descriptions, gherkin, or board content. Your organisation (acting as controller of that content) is responsible for managing such incidental data per its own Art. 13 / 14 obligations.

**Manual fallback** (for users who cannot sign in — primarily because the Clerk account has been deleted, or for **authorised agents** acting on a data subject's behalf):

- Email: `<<PLACEHOLDER: privacy contact email, e.g., privacy@skald.app>>`
- **Acknowledgement**: within 5 business days of receipt.
- **Substantive response**: within **one month** of receipt per Art. 12(3). For complex requests, Skald may extend this by up to two further months (total three months) and will tell you, in writing and before the original deadline elapses, the reason for the extension.
- For users who have already deleted their Clerk account, Skald's response is **"no personal data is held"** plus a reference to the audit log entry proving the erasure — Skald has already pseudonymised every attribution to a non-identifying sentinel.

### 6.2 Right to rectification (Art. 16)

See our [rectification procedure](./rectification-procedure.md). Three channels:

1. **Identity** (name, email): edit them in Clerk's account settings — they live with Clerk, not Skald.
2. **Content you authored** (requirements, descriptions, board content): edit them in the app directly.
3. **Edge cases** (third-party personal data in someone else's free-text, attribution disputes, requests via an authorised agent): email `<<PLACEHOLDER: privacy contact email>>`. We respond within one month (extendable to three for complex cases — see § 6.1).

### 6.3 Right to erasure (Art. 17)

- **Your account**: delete your Clerk account. Clerk notifies Skald, and Skald (per the existing [GDPR data-deletion flow](../../specs/004-gdpr-data-deletion/spec.md)) replaces every attribution column referencing you with the sentinel value `"deleted_user"` and purges your AI agent threads from Mastra storage. Your work in the org stays in the org with attribution shown as "deleted user".
- **Your organisation**: an org admin deletes the organisation from Clerk. Skald archives every row owned by the org with `archived = true` and `archived_at = now()`. **Pending the retention-purge feature ship** (see § 8), archived rows remain in our database indefinitely; once that feature ships, archived rows are physically deleted 30 days after archival.

### 6.4 Right to restriction (Art. 18), objection (Art. 21), and automated decision-making (Art. 22)

- **Restriction / objection**: email `<<PLACEHOLDER: privacy contact email>>`. We respond within one month.
- **Automated decision-making**: Skald does **not** make decisions about you that produce legal or similarly significant effects on you using solely automated means. Agent features generate suggestions for human review and adoption; they do not finalise decisions.

### 6.5 Right to lodge a complaint with a supervisory authority

You have the right to lodge a complaint with the Norwegian Data Protection Authority, **Datatilsynet**:

- Website: <https://www.datatilsynet.no>
- Phone: +47 22 39 69 00
- Post: Datatilsynet, Postboks 458 Sentrum, 0105 Oslo, Norway

You may also lodge a complaint with the supervisory authority in the EEA Member State of your habitual residence, place of work, or place of the alleged infringement.

---

## 7. Legal bases (Art. 13(1)(c), 14(1)(c))

| Processing | Legal basis (Art. 6) |
|---|---|
| Authentication, session issuance, organisation membership | Art. 6(1)(b) — performance of a contract |
| Authoring features (requirements, board, planning, workshops, share links, agent prompts) | Art. 6(1)(b) (Skald-to-user contract) and the org's Art. 6(1) basis for content it processes through us (Skald acts as processor for org content) |
| Agent inference and observability | Art. 6(1)(b) |
| Audit log and accountability records | Art. 6(1)(c) (legal obligation — Art. 5(2) accountability) and Art. 6(1)(f) (legitimate interests — operational integrity) |
| Retention purge | Art. 6(1)(c) (Art. 5(1)(e) storage limitation) |
| Breach response | Art. 6(1)(c) (Art. 33 / 34) |
| Sub-processor governance | Art. 6(1)(c) (Art. 28) |
| Marketing and prospective-customer communications | `<<PLACEHOLDER: confirm — Art. 6(1)(a) (consent) typically, with opt-out>>` |

---

## 8. Retention (Art. 13(2)(a), 14(2)(a))

### 8.1 Your account, while active

Retained for the duration of the contract between you (or your organisation) and Skald.

### 8.2 When you delete your Clerk account

Skald's [data-deletion flow](../../specs/004-gdpr-data-deletion/spec.md) pseudonymises every attribution to your `clerk_user_id` to the sentinel `"deleted_user"`. Share links you created are deactivated. Your AI agent threads in Mastra are purged. The corresponding `audit_events` row is retained as evidence that we acted on the deletion.

### 8.3 When your organisation is deleted (FR-043)

When your organisation is deleted in Clerk, Skald archives every row owned by your organisation (sets `archived = true` and `archived_at = now()`). The rows no longer appear in any normal application view.

**Archived organisation data is permanently deleted 30 days after archival.** A daily scheduled job sweeps every tenancy-scoped table at 03:00 UTC and physically removes rows where `archived = true AND archived_at < now() − 30 days`. Each run is recorded in our audit log (`audit_events.category = 'retention_purge'`).

If you delete your organisation by mistake within the 30-day window, contact `<<PLACEHOLDER: privacy contact email>>` and an administrator can restore the archived rows. After 30 days the deletion is irreversible.

### 8.4 Mastra agent storage on organisation deletion (disclosed gap, deferred)

Mastra's schema does not currently carry an `archived` flag. v1 of Skald takes **no organisation-level action** against Mastra on organisation deletion. Per-user Mastra cleanup continues to run through the existing Clerk `user.deleted` webhook flow whenever a user account is deleted. Closing this gap (org-level Mastra purge) is tracked as a follow-on programme.

### 8.5 Audit log retention

`audit_events` rows are retained for **18 months** after `processed_at`. Enforcement of this retention by a scheduled purge job is deferred to a follow-on sub-plan; pending that, the log grows monotonically.

### 8.6 Cookie consent records

`consent_records` rows are retained for **12 months** by default; this matches the renewal cycle for the consent cookie (see § 11).

### 8.7 Request logs

Request metadata at our hosting layer (Vercel) is retained per Vercel's retention schedule (typically days for raw logs, longer for aggregated metrics). This is hosting-tier data, not application data.

### 8.8 Backups

Postgres backups (managed by Neon) are retained per Neon's point-in-time recovery window (`<<PLACEHOLDER: confirm Neon PITR window — typically 7 days>>`). Restoration from backup is rare and is followed by a re-execution of the retention purge.

---

## 9. Security and breach response

We implement appropriate technical and organisational measures (see DPA Annex II, in [`docs/legal/dpa-template.md`](./dpa-template.md) § 14):

- TLS 1.2+ in transit;
- Encryption at rest by our database sub-processor;
- Identity pseudonymisation (we store `clerk_user_id`, not your name);
- Tenant isolation by `clerk_org_id`;
- Append-only audit log;
- Confidentiality undertakings by every person with access to production data.

If we suffer a personal data breach, our [breach response procedure](./breach-response-procedure.md) governs detection, triage, and notification. We commit to:

- **Acknowledge** a credible report within 4 business hours / 8 non-business hours.
- **Notify Datatilsynet** within 72 hours of awareness of a notifiable breach (Art. 33).
- **Notify affected data subjects** without undue delay where the breach is likely to result in a high risk (Art. 34), in clear language with the legally required content.
- **Test** the procedure with at least one tabletop exercise per year.

---

## 10. Records of Processing Activities (Art. 30)

Skald maintains an internal [Records of Processing Activities document](./ropa.md) covering every processing activity, reviewed at least annually and on every material change. The RoPA is **not** surfaced on the public site; it is producible to a supervisory authority on request within 30 days.

---

## 11. Cookies

Skald uses a small number of cookies. Strictly-necessary cookies are set without consent (you cannot use the service without them); all other categories require your opt-in via our consent banner.

### 11.1 Strictly necessary

These cookies are essential for the service and fire pre-consent:

| Cookie | Origin | Purpose | Lifetime |
|---|---|---|---|
| `skald_consent` | Skald | Encodes your consent decision so the banner does not re-render. | 12 months |
| `skald_consent_id` | Skald | Opaque UUID tying you to your `consent_records` row. | 12 months |
| `__session` | Clerk (via Skald) | Authenticated session — set only after sign-in. | Session |
| `__client`, `__client_uat` | Clerk | Auth client identity — set only after sign-in. | Per Clerk |
| `__cf_bm` | Cloudflare via Vercel CDN | Bot management at the edge. | 30 minutes |

### 11.2 Optional categories

Skald asks for opt-in in the consent banner for these categories (presence reflects what is enabled in the consent banner at policy version `2026-05-13`):

| Category | Purpose | Vendors |
|---|---|---|
| `analytics` | Aggregated usage analytics for product improvement. | `<<PLACEHOLDER: list analytics vendor(s) if any; if none enabled at launch, mark as "none currently enabled — placeholder category">>` |
| `marketing` | Cross-site advertising and remarketing. | `<<PLACEHOLDER: list marketing vendor(s) if any; mark as "none currently enabled" if applicable>>` |

If you click "Reject all" or close the banner without accepting, **no** optional cookies fire. If you opt into a category and later change your mind, click **"Cookie preferences"** in any page footer to reopen the banner and update your choice.

Your consent record is stored for 12 months (per CNIL guidance on cookie-consent renewal). After that, or when this policy materially changes (signalled by a bump in `policyVersion` in the banner), we re-prompt.

A continuous CI guard (`scripts/check-no-tracking-cookies.ts`) checks every deployment to ensure no cookie outside the allowlist above fires pre-consent.

---

## 12. Geographic scope at launch — Norway and the EEA only

Skald's documents (this privacy policy, the DPA, the sub-processor list, the TIA, the breach procedure, the rectification procedure, and the RoPA) are written for the Norwegian and EEA market and assume GDPR + the Norwegian Personal Data Act as the applicable framework.

**Skald does not serve non-EEA data subjects at this launch.** Marketing and sales screen for the customer's location. Where a non-EEA sign-up arrives despite this screening:

- The customer is declined by the responsible role until parallel documents (e.g., UK GDPR addendum, CCPA / LGPD disclosures) ship in a follow-on programme;
- This decline is communicated in writing.

If you are a non-EEA data subject and have nonetheless created a Skald account, please contact `<<PLACEHOLDER: privacy contact email>>` so we can either close the account or transition you to the appropriate framework once available.

---

## 13. Changes to this policy

When this policy materially changes — including the addition of a new sub-processor, a change in retention, a change in legal basis, or any change that the responsible role classifies as material — we bump the `policyVersion` field in the page frontmatter, update the **Last updated** date, and re-prompt for cookie consent (the version bump triggers the re-prompt on next visit).

For tracked changes through time, see the git history of this document at `docs/legal/privacy-policy.md` in our public repository.

A CI guard (`scripts/check-legal-staleness.ts`) fails our build if the `lastReviewed` date slips more than 365 days behind today — we cannot ship a policy that has gone stale beyond an annual review without a deliberate intervention.

---

## 14. Counsel sign-off (annual review marker)

| Date | Counsel (initials + firm) | Notes |
|---|---|---|
| `<<PLACEHOLDER: first counsel sign-off date>>` | `<<PLACEHOLDER: counsel initials + firm>>` | Initial publication for launch (spec 005 Story 1) |

---

## 15. Open items surfaced for counsel review

(Deliberately kept in the doc through the first counsel review pass; pruned before public publication.)

- **Q-PP-1**: Confirm legal-entity boilerplate (§ 1) and privacy contact email used consistently across all `docs/legal/*.md`.
- **Q-PP-2**: Confirm Neon storage region (§ 4 + § 5) — affects whether the international-transfer disclosure for that row stands.
- **Q-PP-3**: Confirm Mastra Cloud status (§ 4 + § 3.4) — if not active in production, soften the disclosure to "currently inactive".
- **Q-PP-4**: Confirm geographic-scope disposition (§ 12) — declined / softer language / parallel-framework treatment.
- **Q-PP-5**: Confirm marketing legal basis (§ 7) — consent + opt-out, or legitimate interest with opt-out?
- **Q-PP-6**: Confirm representative-in-Union analysis (§ 1) — required only if Skald is not established in the EEA.
- **Q-PP-7**: Confirm DPO assessment (§ 1) — internal record per Art. 37(1) analysis.
- **Q-PP-8**: Confirm optional-cookie vendor list (§ 11.2) — at first publication, mark "none currently enabled" honestly; bump policy version when any analytics or marketing tool is added.