Itemra Privacy Policy
Effective date: 2026-10-01
Version: 2026-10-01
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 BRANDSDAL AS ("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: BRANDSDAL AS
- Registered address: Tyinvegen 1035, 2918 Ulnes, Norway (postal address: Postboks 33, 2959 Røn, Norway)
- Organisation number: 924 873 078
- General contact: contact@itemra.io
- Privacy enquiries: contact@itemra.io
EU/EEA representative (Article 27): Not applicable — BRANDSDAL AS is established in Norway (EEA), at the registered address above.
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
Itemra has not designated a formal Data Protection Officer, and no DPO is required under Article 37 GDPR. Privacy enquiries should be directed to our named privacy contact at contact@itemra.io.
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 runs on Itemra-operated infrastructure in Norway; this first-party compute is not a disclosure to a subprocessor. The primary application database is Microsoft Azure SQL Database in the Norway East region (Norway / EEA), and uploaded files are stored in Azure Blob Storage in the same region — both covered by the Microsoft Azure entry below. 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 |
| Microsoft Azure (Azure SQL Database & Azure Blob Storage) | Primary application database, and object storage for uploaded attachments and bug-report files | Account, billing and support records stored in the primary database; file contents and metadata (may contain personal data depending on what is uploaded) (src/backend/infrastructure/Itemra.Integrations.Storage/AzureBlobAttachmentStorage.cs) | Norway East (Norway / EEA) |
| 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 |
| 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) |
| Resend (Plus Five Five, Inc.) | Transactional/notification email delivery — an Itemra-selected provider | Recipient email/name; message subject and content; notification kind/severity; delivery status and a pseudonymous delivery correlation ID (src/backend/infrastructure/Itemra.Infrastructure/Notifications/PlatformEmail/ResendPlatformEmailSender.cs) | United States |
| Sentry (Functional Software, Inc.) — error-telemetry backend | Application error monitoring | Minimised error events only: error category, release, environment and trace ID — no message content, stack traces or user data. Application logs remain in size-bounded on-host container logs. | EU (Sentry EU data residency) |
Two items to highlight. (1) Bug reports send reporter PII and attachment links into GitHub — the destination repository was verified private on 2026-08-15; attachment download links remain valid for 7 days. New reports keep a durable tenant-to-issue correlation, so tenant erasure deletes them through GitHub; only historical issues created before that correlation was introduced require manual reconciliation. (2) Transactional and notification email is sent through Resend, an Itemra-selected provider established in the United States — see Section 6 for the transfer safeguards.
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 keep the application on Itemra-operated infrastructure in Norway, the primary account and inventory database in Microsoft Azure SQL Database in the Norway East region (Norway / the EEA), and uploaded files in Azure Blob Storage in the same Norway East region. However, some of our subprocessors are based in the United States — namely WorkOS (identity), Stripe (billing), GitHub (bug reports) and Resend (email delivery). 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 — Stripe self-certifies, and Resend (Plus Five Five, Inc.) is certified under the DPF (including the UK extension) together with the SCCs incorporated in its data-processing agreement (verified 2026-08-19); WorkOS and GitHub/Microsoft rely on the DPF where they are certified; 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 contact@itemra.io.
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 90 days after account closure 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 no longer than 90 days after account closure. |
| Billing & invoice records | Retained to meet Norwegian bookkeeping law (bokføringsloven) — 5 years after the end of the accounting year. 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, and for no longer than 90 days. |
| 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 — the 7-day point-in-time window, with weekly long-term backups expiring within 4 weeks, monthly long-term backups within 12 months, and blob-storage soft-delete copies within 30 days. |
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 contact@itemra.io 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. Connections to the primary Azure SQL Database are TLS-encrypted (minimum TLS 1.2), and the database and its backups are encrypted at rest with Microsoft platform 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@itemra.io on request.
15. Contact
Questions about this policy or your data: contact@itemra.io — BRANDSDAL AS, Tyinvegen 1035, 2918 Ulnes, Norway (postal address: Postboks 33, 2959 Røn, Norway) (org. no. 924 873 078). Supervisory authority: Datatilsynet (Norway), www.datatilsynet.no.
Governing law for this policy and the Service: Norwegian law; venue Vestoppland og Valdres tingrett (Fagernes rettssted). Nothing in this policy limits any non-waivable rights you have under Norwegian or EU data-protection law.