DRAFT — for legal review, not legal advice. This template was generated from Itemra's source code and must be reviewed and completed by the founder's qualified lawyer before publication. Bracketed [PLACEHOLDER] tokens mark company-specific facts that must be confirmed and filled in.

Itemra Privacy Policy

Effective date: [EFFECTIVE_DATE] Version: 2026-07-16 Available languages: Norwegian (Bokmål) and English. (The application ships Norwegian and English locales — src/web/src/lib/i18n. If the language versions diverge, state which prevails.)

1. About this policy and who we are

This Privacy Policy explains how [LEGAL_ENTITY_NAME] ("Itemra", "we", "us") processes personal data in our own right, as a data controller, in connection with the Itemra warehouse and inventory management service (the "Service").

Controller (Article 13(1)(a) GDPR):

Legal entity: [LEGAL_ENTITY_NAME]
Registered address: [REGISTERED_ADDRESS]
Organisation number: [ORG_NUMBER]
General contact: [CONTACT_EMAIL]
Privacy enquiries: [PRIVACY_CONTACT_EMAIL]

[ART27_REPRESENTATIVE] — If [LEGAL_ENTITY_NAME] is established inside the EEA/Norway, state the main establishment here. If established outside the EEA, you must appoint and name an Article 27 EU/EEA representative.

Two roles — please read

Itemra plays two distinct data-protection roles:

Controller — for the data described in this policy: account and identity data, billing data, support/bug-report data, security logs and telemetry. This is the data we decide the purposes and means for.
Processor — for the inventory data that our business customers upload into the Service (items, locations, stock, attachments, notes, supplier/purchase-order contacts, and similar). For that data, our customer is the controller and we act only on their instructions. That processing is governed by our Data Processing Agreement (DPA), not by this Privacy Policy. If you are an individual whose data appears inside a customer's inventory records (for example, a named user attributed to a stock movement, or a supplier contact) and you wish to exercise your rights, please contact the relevant Itemra customer (the controller); we will assist them as required by the DPA.

2. Data Protection Officer / privacy contact

[DPO_OR_PRIVACY_CONTACT] — Either name an appointed Data Protection Officer and their contact details, or state that no DPO is required under Article 37 GDPR and that privacy enquiries should be directed to [PRIVACY_CONTACT_EMAIL].

3. What personal data we collect, why, and our legal basis

We only collect what we need to run the Service. As a B2B product, most account data relates to the staff of our business customers. The table below lists the personal data we process as controller, the purpose, and the lawful basis under Article 6 GDPR.

Data we process (controller scope)	Purpose	Lawful basis (Art. 6)
User account & identity — email address (stored lower-cased), first/last name, role, account status (Invited/Active/Deactivated), last sign-in time, WorkOS user and invitation IDs. (`src/backend/core/Itemra.Domain/Users/User.cs`)	Create and administer accounts; authenticate users; manage organisation membership and roles	Performance of a contract — Art. 6(1)(b)
Authentication, session & device data — sign-in credentials, session and refresh tokens, session ID, and the IP address and user-agent of your device at sign-in. (Identity/auth is handled by our subprocessor WorkOS; Itemra also stores session records including IP + user-agent — `src/backend/core/Itemra.Application/Auth/AppSession.cs`, refresh token stored encrypted)	Securely sign you in and keep you signed in; protect accounts against unauthorised access	Performance of a contract — Art. 6(1)(b); and our legitimate interest in account security — Art. 6(1)(f)
Billing & subscription data — billing email, plan/price, subscription status, and the Stripe customer and subscription identifiers. (`src/backend/core/Itemra.Domain/Billing/Subscription.cs`; `src/backend/infrastructure/Itemra.Integrations.Stripe/StripeBillingGateway.cs`)	Provision paid plans; manage subscriptions, renewals and invoicing	Performance of a contract — Art. 6(1)(b); and compliance with bookkeeping/tax law — Art. 6(1)(c)
Payment card data	Take payment	Collected directly by Stripe in its hosted checkout — Itemra never receives or stores card numbers (Art. 6(1)(b), via Stripe)
Support & bug-report data — when you submit an in-app bug/feedback report: your name, email, user ID and organisation ID, the page URL, your free-text description, metadata, and any screenshots or files you attach. (`src/backend/host/Itemra.Api/Services/GitHubBugReportService.cs`)	Diagnose and resolve issues; respond to and improve the Service	Our legitimate interest in providing and improving support — Art. 6(1)(f)
Public roadmap feedback and abuse-prevention data — category, locale, free-text message, an opaque submission ID, and submission/deletion timestamps. We derive a keyed, rotating client-network fingerprint solely for short-lived rate limiting; neither the raw IP address nor account, contact, cookie, or user-agent data is stored with public feedback or in its limiter record.	Receive and prioritise product feedback; prevent automated or excessive submissions	Our legitimate interest in proportionate product improvement and abuse prevention — Art. 6(1)(f)
Audit & security event data — actor user ID, actor name/email, IP address, user-agent, and free-text reason/notes for security-relevant actions (e.g. role changes, session revocations, permission denials). (`src/backend/core/Itemra.Domain/Audit/AuditEvent.cs`)	Maintain an audit trail; detect and investigate security incidents and misuse	Our legitimate interest in security, fraud prevention and accountability — Art. 6(1)(f); and, where applicable, legal obligation — Art. 6(1)(c)
Server request logs & telemetry — request logs enriched with user ID, organisation ID and request data, plus distributed traces (which may include the IP address, target URLs and recorded exceptions). (`src/backend/host/Itemra.Api/Program.cs` — `UseSerilogRequestLogging`; OpenTelemetry instrumentation in `src/backend/infrastructure/Itemra.Infrastructure/DependencyInjection.cs`)	Operate, monitor, secure and debug the Service	Our legitimate interest in service reliability and security — Art. 6(1)(f)
First-party product-usage signals — organisation ID, a fixed low-cardinality event name, first-occurrence time, and an allowlisted feature key where relevant. These records contain no email, IP address, user-agent, free text, scanned value, inventory identifier, page URL, or individual user identifier.	Understand organisation-level activation and feature adoption; find onboarding drop-off; improve the Service	Our legitimate interest in proportionate, privacy-minimised product improvement — Art. 6(1)(f)
API key security and usage data — for customer API keys: key label, the creating/revoking user, configured IP addresses or CIDR networks, a rate-limit override, rotation/overlap timestamps, IP address, user-agent and timestamp of last use, plus per-key UTC-day request counts grouped by uppercase HTTP method and a canonical route template. Secret values and credential hashes are not exposed in archives or audit data. Security-change audit records use counts rather than individual allowlist entries; rotation audit records prove the action without copying its overlap duration/boundary or internal security version. Usage events and aggregates do not contain raw paths, query strings, request bodies, inventory identifiers or free text. (`src/backend/core/Itemra.Domain/PublicApi/CustomerApiKey.cs`; `CustomerApiKeyUsageEvent.cs`; `CustomerApiKeyDailyUsage.cs`)	Operate the public API securely; restrict credential use to customer-selected networks; attribute and investigate usage; show customers their monthly API consumption	Performance of a contract — Art. 6(1)(b); and legitimate interest in security and service reliability — Art. 6(1)(f)
Customer/company (tenant) record — company name, primary email domain, default locale, plan, status. (`src/backend/core/Itemra.Domain/Customers/Customer.cs`)	Manage the customer account and provisioning	Performance of a contract — Art. 6(1)(b)
Notification & email-delivery records — recipient identity and notification content/delivery status, including any delivery error text. (`src/backend/core/Itemra.Domain/Notifications/`)*	Send transactional and notification emails and in-app notices you have requested	Performance of a contract — Art. 6(1)(b); and legitimate interest — Art. 6(1)(f)

Customer-configured webhook records. If your organisation enables outbound webhooks, Itemra stores the destination URL, selected event filters, signing-secret verification material, and delivery status/error history. Event payloads may contain Customer Data and are sent only to the destination chosen by your organisation. That destination is customer-controlled, not an Itemra-selected subprocessor; your organisation is responsible for its recipient and any onward transfer.

Legitimate-interest balancing (Article 13(1)(d))

Where we rely on legitimate interests (Art. 6(1)(f)) — for account security, fraud and abuse prevention, service logging, support, public roadmap feedback, and product/service improvement — we have assessed that these interests are not overridden by your interests or fundamental rights, taking into account the limited, business-context nature of the data and the safeguards in Section 9. You can ask for a summary of this balancing assessment, and you have the right to object (see Section 8).

A note on free-text fields and uploads

Some fields (notes, descriptions, bug reports, and public roadmap feedback) and file uploads accept free text and arbitrary files. Please do not enter personal, confidential, or special-category data (e.g. health, racial/ethnic, religious, political, trade-union, biometric or genetic data, or data about sex life/orientation) into these fields. Itemra is an inventory product and does not intentionally collect special-category data (Article 9 GDPR); none is defined anywhere in the Service's schema.

4. Where we get your data (Article 14)

Most data comes directly from you when you use the Service. However, some data may be provided about you, by someone else — in particular:

When an administrator of an Itemra customer organisation invites you, they provide your email address (and sometimes your name and role) to create your invitation before you have interacted with Itemra. (User.Invite — src/backend/core/Itemra.Domain/Users/User.cs)
Identity attributes (e.g. confirmed name, sign-in events) may be synced from WorkOS, our identity provider, via webhooks. WorkOS is the authoritative source of identity; the Itemra user record is a mirror.

5. Who we share data with (recipients and subprocessors)

We do not sell your personal data. We share it only with service providers ("subprocessors") who process it on our behalf to deliver the Service, and only as needed for the purposes above. Each is bound by a data-processing agreement.

A current, versioned list is maintained in our Subprocessor List (linked from this policy and from the app footer). The application and primary SQL Server database are hosted on Itemra-operated infrastructure in Norway / the EEA ([VERIFY_SELF_HOSTED_APP_AND_SQL_LOCATION]); this first-party hosting is not a disclosure to a subprocessor. As at the effective date, the external recipients are:

Recipient	Role / activity	Personal data shared	Country
WorkOS, Inc.	Authentication and identity; organisation and user-membership management; invitations; federated logout	Email, first/last name, WorkOS user ID; organisation name and domain; role; session/refresh tokens; sign-in IP. No inventory data. (`src/backend/infrastructure/Itemra.Integrations.WorkOS/`)*	United States (EU residency: [WORKOS_DATA_RESIDENCY])
Microsoft Azure (Azure Blob Storage)	Object storage for uploaded attachments and bug-report files	File contents and metadata (may contain personal data depending on what is uploaded) (`src/backend/infrastructure/Itemra.Integrations.Storage/AzureBlobAttachmentStorage.cs`)	EEA region [VERIFY_AZURE_BLOB_REGION]
Stripe	Billing and subscription payments	Billing email, organisation ID, plan/price, Stripe customer/subscription IDs. Card data is collected by Stripe directly. No inventory data. (`src/backend/infrastructure/Itemra.Integrations.Stripe/`)*	United States / Ireland (account region: [STRIPE_ACCOUNT_REGION])
GitHub, Inc. (Microsoft)	In-app bug/feedback report capture (creates a support issue)	Reporter name, email, user ID, organisation ID, the report text, and links to any uploaded screenshots/files. (`src/backend/host/Itemra.Api/Services/GitHubBugReportService.cs`)	United States
Frankfurter (FX rates API)	Foreign-exchange rates for valuation features	No personal data — only ISO currency codes are sent. (`src/backend/infrastructure/Itemra.Infrastructure/Purchasing/FrankfurterFxRateProvider.cs`) Listed for transparency only.	EU (typical)
Email (SMTP) provider	Transactional/notification email delivery	Recipient email/name and message content	Customer-configured per organisation — your organisation chooses this provider (`src/backend/core/Itemra.Domain/Settings/EmailSettings.cs`)
Telemetry/observability backend (optional)	Diagnostic logs and traces	Logs/traces including user ID, organisation ID and IP	[TELEMETRY_BACKEND_AND_REGION] (only if a hosted backend is configured; otherwise console/host logs only)

Two items to highlight for review. (1) Bug reports send reporter PII and attachment links into GitHub — confirm the destination repository is private ([VERIFY_GITHUB_REPO_VISIBILITY]), since data placed there persists outside Itemra's normal deletion controls; attachment download links remain valid for 30 days. (2) The SMTP email provider is chosen by your organisation, not by Itemra — your organisation is responsible for that provider's data handling.

We may also disclose personal data where required by law, to enforce our agreements, or to protect rights, safety and security.

6. International transfers (Article 13(1)(f))

We aim to keep the application and primary account and inventory database on Itemra-operated infrastructure in Norway / the EEA ([VERIFY_SELF_HOSTED_APP_AND_SQL_LOCATION]) and uploaded files in Azure Blob Storage region [VERIFY_AZURE_BLOB_REGION]. However, some of our subprocessors are based in the United States — namely WorkOS (identity), Stripe (billing) and GitHub (bug reports). Transfers to these providers are protected by one or more of the following safeguards:

The EU–U.S. Data Privacy Framework (DPF), where the provider is self-certified (please verify each provider's current certification at the time of reliance — Stripe self-certifies; [VERIFY_WORKOS_DPF_STATUS] and GitHub/Microsoft to be confirmed); and/or
The European Commission's Standard Contractual Clauses (SCCs, 2021/914), incorporated into each provider's data-processing agreement, together with supplementary technical measures (encryption in transit and at rest, access controls, data minimisation).

Frankfurter is not an international transfer of personal data because only currency codes are sent. You can obtain a copy of the relevant transfer safeguards by contacting [PRIVACY_CONTACT_EMAIL].

7. How long we keep your data (Article 13(2)(a))

We keep personal data only as long as necessary for the purposes above, then delete or anonymise it. Our retention criteria by category:

Category	Retention criterion
Account & user records	For the life of the organisation's subscription, plus a short wind-down window of [ACCOUNT_RETENTION_WINDOW] for reactivation, after which records are deleted or anonymised. Deactivated users are retained as historical records until that point.
Authentication & sessions	Held by WorkOS per its retention; Itemra session records are kept for [ACCOUNT_RETENTION_WINDOW] (define a purge period for revoked sessions).
Billing & invoice records	Retained to meet Norwegian bookkeeping law (bokføringsloven, generally ~5 years) — [BILLING_RETENTION_PERIOD]. This legal-obligation basis can override an erasure request for the retention term.
Support / bug reports	Reports (in GitHub) and their attachments are retained until reviewed and purged — [BUGREPORT_RETENTION_PERIOD].
Public roadmap feedback	Free-text submissions and their minimized metadata are automatically deleted when `DeleteAfterUtc` is reached, 365 days after submission. The globally leased Worker runs hourly by default and deletes in bounded batches.
Public roadmap abuse-prevention limiter	The keyed, rotating client-network fingerprint and token-bucket state become unusable after two rate-limit windows: no more than 10 minutes under the validated production maximum. The hourly Worker physically deletes expired SQL limiter rows by its next tick, within a conservative maximum of 70 minutes. Raw IP addresses are not persisted in these records. In-process limiter partitions report idle duration and are evicted after inactivity.
Audit & material security events (incl. IP/user-agent)	Indefinite by default while the organisation exists. Business organisations may select 12, 36, or 84 months; tenant erasure removes remaining rows earlier. See the Log, audit, and security-event retention policy in the service documentation.
Server request logs, telemetry, and diagnostic security events (incl. IP)	A maximum rolling window of 30 days in production. The production sink must enforce and prove the setting before activation.
First-party product-usage signals	13 months from the recorded first occurrence, then automatically deleted; tenant erasure removes them earlier. Repeated use is not retained as a user-level activity history.
Customer API key security configuration	Retained with the logical API key and removed by key deletion or tenant erasure. Rotation uses only one minimized predecessor hash/key-id/algorithm slot with no predecessor display metadata: its authentication validity ends at the exclusive overlap boundary, and a later rotation replaces the inactive tuple. Audit evidence contains no secret or credential-hash material; allowlists appear only as counts, while rotation overlap timing and the internal security version are omitted. It follows the audit/security-event criterion above.
Customer API usage events and daily aggregates	Request-count events are deleted transactionally after aggregation. Minimized UTC-day/method/canonical-route aggregates are retained for 13 months and purged automatically; key deletion or tenant erasure removes them earlier. Events and aggregates contain no IP address, user agent, request body, or response body.
Backups	Deletions propagate to backups within the backup rotation cycle of [ACCOUNT_RETENTION_WINDOW].

For legal review: Itemra now has a durable 30-day cooling-off tenant-erasure workflow and a dated technical retention policy. The lawyer/founder must still approve the backup rotation, statutory billing exception, and GitHub bug-report policy before publication.

8. Your rights (Article 13(2)(b))

Subject to the conditions in the GDPR, you have the right to:

Access (Art. 15) — confirmation of whether we process your data and a copy of it, with the related information. The first copy is free.
Rectification (Art. 16) — correction of inaccurate or incomplete data. (For identity fields, WorkOS is the authoritative source, so corrections may flow through it.)
Erasure (Art. 17) — deletion of your data, subject to legal-retention exceptions (e.g. accounting records). Where applicable, we propagate deletion requests to relevant subprocessors.
Restriction (Art. 18) — limiting how we process your data while a dispute or accuracy check is pending.
Data portability (Art. 20) — receiving data you provided in a structured, commonly used, machine-readable format, where processing is automated and based on consent or contract.
Objection (Art. 21) — objecting to processing based on legitimate interests, and objecting to direct marketing at any time (which we will always honour).
Withdraw consent (Art. 7(3)) — where we rely on consent, you may withdraw it at any time, as easily as you gave it, without affecting processing already carried out.
Lodge a complaint (Art. 77) — with a supervisory authority, in Norway the Norwegian Data Protection Authority (Datatilsynet — www.datatilsynet.no), or your local EEA authority.

How to exercise them. Email [PRIVACY_CONTACT_EMAIL] or use the in-app account controls. We will respond without undue delay and within one month, extendable by up to two further months for complex or numerous requests (we will tell you within the first month if we need an extension). We may need to verify your identity proportionately. Requests are free unless manifestly unfounded or excessive.

Controller-vs-processor routing. For data we hold as controller (accounts, billing, support, telemetry), we respond to you directly. For inventory data where we act as processor, we forward your request to the relevant Itemra customer (the controller) and assist them, as required by our DPA.

9. How we protect your data

We apply technical and organisational measures appropriate to the risk (Article 32 GDPR), including:

Encryption in transit for external service calls and at rest in Azure Blob Storage. The self-hosted SQL Server transport, database and backup encryption controls remain subject to confirmation: [VERIFY_SQL_TRANSPORT_AND_AT_REST_ENCRYPTION].
Private storage — attachments live in private Blob containers accessed only via short-lived, single-file access URLs (SAS) / Managed Identity. (See Itemra.Integrations.Storage.)
Access control and tenant isolation — role/permission-based access, with each customer organisation's data logically segregated.
Secure sessions — HttpOnly, SameSite session cookies and CSRF protection; refresh tokens stored encrypted, not in plaintext.
Logging and monitoring — security audit trail and operational telemetry to detect and investigate incidents.

No system is perfectly secure, but we work to protect your data and to respond promptly to any incident.

10. Automated decision-making and profiling (Article 22)

We do not make decisions that produce legal or similarly significant effects about you based solely on automated processing. The Service includes assistive features (e.g. natural-language search and duplicate detection) that run on local heuristics and do not make Article 22 decisions and do not send your data to any external AI provider. (All such features are local implementations — src/backend/infrastructure/Itemra.Infrastructure/DependencyInjection.cs.)

11. Cookies and local storage

The Service uses only strictly-necessary cookies (an authentication session cookie and a CSRF/security token) and functional browser storage for your preferences (e.g. language, theme, layout). We do not use analytics, advertising or third-party tracking cookies. During sign-in or checkout, WorkOS and Stripe may set their own cookies on their domains. See our separate Cookie Policy (linked here) for the full itemised list and details.

12. Is providing data mandatory? (Article 13(2)(e))

Providing certain data is necessary to use the Service. For example, we cannot create or operate an account without an email address, and we cannot provide paid plans without billing information. If you do not provide this data, we will be unable to provide the relevant parts of the Service.

13. Children

The Service is a business tool not directed at children and is not intended for anyone under the age required to enter into a contract in their jurisdiction.

14. Changes to this policy (Article 12)

We may update this policy from time to time. We will post the new version with an updated effective date and version number and, for material changes, notify you by a reasonable means (e.g. email or an in-app notice). The current version is always available within the app and at [CONTACT_EMAIL] on request.

15. Contact

Questions about this policy or your data: [PRIVACY_CONTACT_EMAIL] — [LEGAL_ENTITY_NAME], [REGISTERED_ADDRESS] (org. no. [ORG_NUMBER]). Supervisory authority: Datatilsynet (Norway), www.datatilsynet.no.

Governing law for this policy and the Service: [GOVERNING_LAW]; venue [VENUE]. Nothing in this policy limits any non-waivable rights you have under Norwegian or EU data-protection law.