Data Processing Agreement (DPA)

Version: [VERSION] · Effective date: [EFFECTIVE_DATE]

This Data Processing Agreement (the "DPA") forms part of, and is incorporated by reference into, the Itemra Terms of Service (the "Agreement") between:

• BRANDSDAL AS, org. no. 924 873 078, registered at Tyinvegen 1035, 2918 Ulnes, Norway (postal address: Postboks 33, 2959 Røn, Norway) ("Itemra", "Processor"); and
• the customer that has accepted the Agreement (the "Customer", "Controller").

Itemra and the Customer are each a "Party" and together the "Parties".

This DPA governs Itemra's processing of personal data on behalf of the Customer in the course of providing the Itemra warehouse / inventory management service (the "Service"). It implements Article 28 of Regulation (EU) 2016/679 ("GDPR"), as incorporated into Norwegian law by the Personal Data Act (personopplysningsloven).

1. Roles of the Parties and scope

1.1 In respect of personal data contained within the Customer's inventory and operational records in the Service (the "Customer Personal Data"), the Customer is the Controller and Itemra is the Processor. This includes personal data that the Customer or its authorised users enter into, upload to, or generate within the Service — for example supplier and purchase-order contacts, free-text notes, attachment file contents, and the user identifiers stamped onto inventory and audit records.

1.2 This DPA does not govern personal data for which Itemra is itself the Controller — account, authentication, billing, support and telemetry data, personal notification preferences, or Itemra-owned account, trial, billing and service-administration messages. That processing is described in Itemra's Privacy Policy. Where an operational alert or digest is derived from Customer Personal Data, its message content and transmission are processor-side processing under this DPA even though Itemra also processes the recipient's preference and delivery-administration records as Controller. Where this DPA and the Privacy Policy appear to overlap, each governs the role-specific processing just described.

1.3 Where Itemra engages another party (a "Sub-processor", e.g. Microsoft Azure, GitHub) that processes Customer Personal Data, Itemra does so as Processor and the Sub-processor as further (sub-)processor in the processing chain.

1.4 The details required by Article 28(3) GDPR — subject-matter, duration, nature and purpose of processing, types of personal data and categories of data subjects — are set out in Annex I.

2. Processing on documented instructions only

2.1 Itemra shall process Customer Personal Data only on the Customer's documented instructions, including with regard to transfers of personal data to a third country, unless required to do so by EU, EEA, Norwegian or Member-State law to which Itemra is subject. In such a case, Itemra shall inform the Customer of that legal requirement before processing, unless that law prohibits such information on important grounds of public interest. (Art 28(3)(a).)

2.2 The Customer's instructions are constituted by: (a) this DPA and the Agreement; (b) the Customer's configuration and use of the Service through its accounts, settings and APIs; and (c) any further written instructions agreed by the Parties. Operating the Service in accordance with the Agreement and the Service documentation is a documented instruction.

2.3 Itemra shall immediately inform the Customer if, in its opinion, an instruction infringes the GDPR or other applicable EU/EEA or Norwegian data-protection law. (Art 28(3), final paragraph.) Itemra may, pending the Customer's revised instruction, suspend the affected processing.

2.4 When the Customer enables email for operational notification kinds, chooses recipients through its roles/rules, or its Authorised Users select real-time/hourly/daily/weekly delivery, those settings instruct Itemra to render and transmit the corresponding alert or digest through Itemra's selected email delivery provider. Resend is therefore a further processor for Customer Personal Data contained in those messages and must be governed by Section 6 and Annex III. Customer-configured outbound workflow webhooks remain destinations chosen by the Customer; the Customer is responsible for selecting those webhook destinations and for any onward transfer.

3. Confidentiality

3.1 Itemra shall ensure that persons authorised to process Customer Personal Data have committed themselves to confidentiality or are under an appropriate statutory obligation of confidentiality. (Art 28(3)(b).)

3.2 Itemra shall limit access to Customer Personal Data to personnel who need it to provide the Service and shall ensure those persons are bound by the confidentiality obligation for the duration of, and after, their engagement.

4. Security of processing (Article 32)

4.1 Taking into account the state of the art, the costs of implementation and the nature, scope, context and purposes of processing, as well as the risk to data subjects, Itemra shall implement appropriate technical and organisational measures ("TOMs") to ensure a level of security appropriate to the risk. (Art 28(3)(c); Art 32.)

4.2 The TOMs in force as of the effective date are set out in Annex II. Itemra may update the TOMs from time to time provided the updates do not materially reduce the overall level of security.

5. Assistance to the Controller

5.1 Data-subject requests. Taking into account the nature of the processing, Itemra shall assist the Customer, by appropriate technical and organisational measures and insofar as possible, in fulfilling the Customer's obligation to respond to requests by data subjects exercising their rights under Chapter III GDPR (access, rectification, erasure, restriction, portability, objection, and rights related to automated decision-making). (Art 28(3)(e).) Where a data subject contacts Itemra directly about Customer Personal Data, Itemra shall, without undue delay, forward the request to the Customer and shall not respond to the data subject itself except on the Customer's instruction.

5.2 Security, breach, DPIA and prior consultation. Itemra shall assist the Customer in ensuring compliance with the obligations in Articles 32 to 36 GDPR, taking into account the nature of processing and the information available to Itemra. (Art 28(3)(f).)

5.3 Personal data breach notification. Itemra shall notify the Customer without undue delay — and in any event within 48 hours — after becoming aware of a personal data breach affecting Customer Personal Data. The notification shall, to the extent known, describe the nature of the breach, the categories and approximate number of data subjects and records concerned, the likely consequences, and the measures taken or proposed. Itemra shall provide further information in phases as it becomes available and shall cooperate with the Customer to investigate and remediate the breach. (Art 33; supporting Art 33(2).)

6. Sub-processors

6.1 The Customer grants Itemra a general written authorisation to engage Sub-processors to process Customer Personal Data, subject to this Section 6. (Art 28(2).)

6.2 The Sub-processors authorised as of the effective date are listed in Annex III (which mirrors Itemra's published Sub-processor List).

6.3 Where Itemra engages a Sub-processor, it shall do so by a written contract imposing on the Sub-processor data-protection obligations equivalent to those in this DPA, in particular providing sufficient guarantees to implement appropriate technical and organisational measures. Itemra remains fully liable to the Customer for the performance of the Sub-processor's obligations. (Art 28(4).)

6.4 Change notice and right to object. Itemra shall inform the Customer of any intended addition or replacement of a Sub-processor at least 30 days in advance (by updating the published Sub-processor List and/or by email or in-app notice), thereby giving the Customer the opportunity to object on reasonable data-protection grounds within 30 days. If the Customer objects and the Parties cannot agree a resolution, the Customer may, as its sole remedy, terminate the affected part of the Service without penalty.

7. International transfers

7.1 Itemra shall not transfer, and shall not permit a Sub-processor to transfer, Customer Personal Data to a country outside the EEA without a valid transfer mechanism under Chapter V GDPR.

7.2 As of the effective date, primary Customer Personal Data is stored at rest in Itemra-operated, self-hosted SQL Server infrastructure in Norway / the EEA ([VERIFY_SELF_HOSTED_SQL_LOCATION]). Uploaded file content is stored in Microsoft Azure Blob Storage in region [VERIFY_AZURE_BLOB_REGION], which the Customer instructs Itemra to keep within the EEA. Certain Sub-processors are established in the United States — see Annex III. For transfers to those Sub-processors, the transfer relies, in order: (a) on an adequacy decision where the importer is certified under the EU-US Data Privacy Framework ("DPF"); and/or (b) on the EU Standard Contractual Clauses (Commission Implementing Decision (EU) 2021/914), Module Two (controller-to-processor), incorporated through each Sub-processor's data-processing terms, together with supplementary technical and organisational measures (encryption in transit and at rest, data minimisation, access controls).

7.3 The EU SCCs (Module Two) are incorporated into this DPA by reference for any transfer of Customer Personal Data to a country that is not the subject of an adequacy decision and that is not otherwise covered by a DPF certification. In case of conflict between the SCCs and this DPA, the SCCs prevail in respect of the relevant transfer. Annex I and Annex II of this DPA serve as the corresponding annexes to the SCCs, and Annex III identifies the importing Sub-processors.

7.4 Itemra shall, on request, make available to the Customer a copy of the relevant transfer safeguards (DPF certification reference and/or executed SCCs) and any transfer-impact assessment, with confidential commercial terms redacted.

8. Audits

8.1 Itemra shall make available to the Customer all information necessary to demonstrate compliance with the obligations laid down in Article 28 GDPR and shall allow for and contribute to audits, including inspections, conducted by the Customer or an auditor mandated by the Customer. (Art 28(3)(h).)

8.2 The Customer shall give at least 30 days' prior written notice. Audits shall take place during normal business hours, no more than once per twelve-month period (save where required by a supervisory authority or following a personal data breach), and shall be conducted so as to minimise disruption to Itemra's operations and without compromising the confidentiality or security of other customers' data. Itemra may satisfy an audit request in the first instance by providing relevant certifications, third-party audit reports or written responses to a security questionnaire (BRANDSDAL AS itself holds no security certifications at this time; key sub-processors hold SOC 2 / ISO certifications as listed in the sub-processor list).

9. Deletion or return of data on termination

9.1 On expiry or termination of the Agreement, Itemra shall, at the Customer's choice, delete or return all Customer Personal Data and delete existing copies, unless EU/EEA or Norwegian law requires continued storage. (Art 28(3)(g).)

9.2 Itemra shall give effect to the Customer's choice within 30 days of termination. The Customer may export its data using the Service's export functionality during the subscription term and during any post-termination wind-down window stated in the Agreement.

9.3 Deletion extends to attachment file content in Azure Blob Storage and propagates to backups within the ordinary backup rotation cycle (a 7-day point-in-time window, with weekly long-term backups expiring within 4 weeks and monthly long-term backups within 12 months and blob-storage soft-delete copies within 30 days); pending purge from backups, the data remains protected by the TOMs in Annex II and is not processed for any other purpose.

Implementation note for legal review: The durable export and delayed tenant-erasure workflow is documented in docs/ops/data-lifecycle.md; log, audit, security-event, and customer API usage periods are documented in docs/ops/data-retention-policy.md. The lifecycle covers SQL, recorded Azure Blob objects, WorkOS, Stripe, and newly correlated GitHub issues. Tenant archives intentionally exclude credentials, signing-secret material, provider session identifiers, secret hashes, and row-version bytes. Erasure deletes active organization sessions and de-links the organization context from immutable consent evidence. Historical GitHub issues created before the correlation migration require manual reconciliation. Counsel/owner must still approve the backup-rotation window, export-artifact expiry, statutory billing exception, and GitHub bug-report retention policy before these clauses are executed; live provider deletion proof is also required.

10. Liability, term, precedence and governing law

10.1 The liability of each Party under this DPA is subject to the limitations and exclusions of liability set out in the Agreement, except where applicable data-protection law does not permit such limitation.

10.2 This DPA takes effect on the effective date and remains in force for as long as Itemra processes Customer Personal Data, notwithstanding termination of the Agreement, until deletion or return under Section 9 is complete.

10.3 Order of precedence. In the event of conflict on a data-protection matter, the order of precedence is: (1) the EU SCCs (for transfers within their scope); (2) this DPA; (3) the Agreement. On all other matters the Agreement prevails.

10.4 This DPA is governed by Norwegian law and subject to the exclusive jurisdiction of Vestoppland og Valdres tingrett (Fagernes rettssted), aligned with the Agreement. Nothing in this DPA limits any non-waivable rights of data subjects or obligations under the GDPR or Norwegian data-protection law.

10.5 Acceptance. For self-serve customers, this DPA is accepted electronically (click-to-accept) as part of accepting the Agreement, or by counter-signature where the Parties so agree. Acceptance is effective on the effective date.

Annex I — Details of the processing

Categories of personal data (grounded in code)

Note on AI features: all "AI" capabilities (natural-language search planner, duplicate detector, datasheet enricher, import-mapping suggester, insight detector) are local heuristic implementations with no external model call (src/backend/infrastructure/Itemra.Infrastructure/DependencyInjection.cs; HeuristicDatasheetEnricher.cs). Itemra makes no solely-automated decisions with legal or similarly significant effect on data subjects (Art 22).

Annex II — Technical and Organisational Measures (TOMs)

These measures reflect Itemra's security posture as inspected in the codebase. Items in [PLACEHOLDER] must be confirmed by Itemra.

1. Tenant isolation and access control

• Multi-tenant isolation with every persisted record scoped to an organisation/tenant; user and audit records carry OrganizationId. Requests are executed in the context of an authenticated AppSession bound to a tenant.
• Role-based access control (RBAC) with role slugs and a permission model; permission denials are recorded as audit events.
• Public API access via per-customer API keys: the raw key is never stored — only a keyed hash plus a prefix is held; keys are soft-revocable, after which use is rejected (src/backend/core/Itemra.Domain/PublicApi/CustomerApiKey.cs).
• Session validation on every request: cookie principals are re-validated against the active AppSession row and rejected if revoked (src/backend/infrastructure/Itemra.Integrations.WorkOS/DependencyInjection.cs, OnValidatePrincipal).

2. Authentication and session security

• Authentication is delegated to WorkOS (AuthKit). Session cookie itemra_session is HttpOnly, SameSite=Lax, with SecurePolicy=Always in deployed environments, a 7-day sliding expiry, and server-side revocation (DependencyInjection.cs).
• CSRF protection via an anti-forgery token (itemra_csrf, X-CSRF-TOKEN header, SameSite=Lax, Secure in production).
• Refresh tokens are stored as ciphertext via an ISecretProtector (ASP.NET Core Data Protection), never in plaintext (AppSession.RefreshTokenCiphertext).

3. Encryption

• In transit: TLS for external calls (Azure Blob, WorkOS, Stripe, GitHub and Resend APIs over HTTPS). Encryption for application-to-database traffic on the self-hosted network must be confirmed and documented: [VERIFY_SQL_TRANSPORT_ENCRYPTION].
• At rest: The encryption controls for the self-hosted SQL Server database and its backups must be confirmed and documented: [VERIFY_SQL_AT_REST_ENCRYPTION]. Azure Blob Storage uses Microsoft platform encryption at rest. Attachment containers are private (PublicAccessType.None) and access is granted only via short-lived single-blob SAS URLs (create+write for upload, read for download) — src/backend/infrastructure/Itemra.Integrations.Storage/AzureBlobAttachmentStorage.cs. Managed Identity is supported for storage access (AzureBlobOptions.AccountUrl).

4. Logging, monitoring and auditability

• Append-only, immutable audit log capturing actor identity, IP, User-Agent, action, subject and a change diff (AuditEvent.cs, AuditLogger.cs).
• Structured request logging (Serilog) enriched with UserId and OrganizationId; optional OpenTelemetry traces/metrics, exported only when an OTLP endpoint is configured (src/backend/infrastructure/Itemra.Infrastructure/DependencyInjection.cs; Program.cs). Telemetry destination: browser/application error telemetry goes to Sentry (Functional Software, Inc.) with EU data residency, receiving minimised error events (error category, release, environment, trace ID — no message content, stack traces, or user data); application logs remain in size-bounded on-host container logs, and backend OTLP export remains unconfigured.
• Health checks for the SQL datastore (Program.cs).

5. Resilience and data integrity

• Database access configured with automatic retry on transient failure and a 30-second command timeout (Itemra.Persistence/DependencyInjection.cs).
• Backups: continuous point-in-time backup, with a 7-day point-in-time restore window plus weekly long-term backups kept 4 weeks and monthly long-term backups kept 12 months; blob-storage soft-delete for 30 days (Azure SQL automated backups with geo-redundant backup storage; restore testing evidenced by rehearsal).

6. Secrets management

• Connection strings, API keys and webhook secrets supplied via configuration/secret store (not committed; repo defaults are empty).
• ASP.NET Core Data Protection uses the stable application name Itemra and a shared private Azure Blob key ring in deployed environments. Startup verifies that the configured key repository can protect and unprotect data before the host becomes ready. Production Key Vault wrapping and the approved Coruscant workload credential remain activation requirements. Evidence: Itemra.Integrations.Storage/DataProtectionDependencyInjection.cs, both API Program.cs files, and docs/ops/release-hardening.md.

7. Organisational measures

• Personnel confidentiality obligations (Section 3).
• Least-privilege access to production systems and data. [PLACEHOLDER — document access-grant/review process.]
• Vulnerability management / penetration testing: at least annually.
• Certifications: BRANDSDAL AS itself holds no security certifications at this time; key sub-processors hold SOC 2 / ISO certifications as listed in the sub-processor list.
• Breach-response process: documented procedure for detection, triage, containment and notification under Section 5.3. [PLACEHOLDER — confirm runbook.]

8. Data minimisation and retention

• Pseudonymisation where applicable; no special-category data by design (see Annex I).
• Retention of audit-event and session IP/User-Agent records: customer-facing audit rows are indefinite by default while the tenant exists; Business customers may select 12, 36, or 84 months. Production request logs and diagnostic security events have a maximum 30-day rolling window. Minimized customer API daily request-count aggregates are retained for 13 months. Technical boundaries and activation proof are defined in docs/ops/data-retention-policy.md.
• Notification records and provider copies: notification preferences are retained for the life of the account; delivery and outcome records for 90 days. Resend retains sent email content for 30 days and delivery/activity data for 30 days (verified 2026-08-19). Operational message content must follow the Customer's documented retention/erasure instructions; Itemra must not promise deletion sooner than the provider can evidence.
• Resend suppressions and data-subject/customer requests: Resend maintains an automatic suppression list, and customer data is deleted within 90 days of account termination. Access, restriction and erasure requests are reconciled with bounce/block/spam-report/unsubscribe records without re-enabling unwanted mail, and are escalated to privacy@resend.com under Resend's DPA where provider-side deletion is required (process adopted 2026-08-19; first-exercise evidence to be recorded on the next DSAR or before commercial launch).

Annex III — Sub-processors

As of [EFFECTIVE_DATE], version [VERSION]. This Annex mirrors Itemra's published Sub-processor List and must be kept in sync with it and with the Privacy Policy recipients section.

Customer-configured destinations (not Itemra-selected Sub-processors): any outbound workflow webhook the Customer configures. The Customer chooses the destination and event filters and is responsible for its recipient and any onward transfer. Itemra's Resend email delivery is Itemra-selected and is therefore listed above; it is not a customer-selected destination.

Change notification: Itemra notifies Customers of new or replacement Sub-processors per Section 6.4, by updating the published Sub-processor List and/or by email or in-app notice, with the advance period and objection rights stated there.

Last updated: [EFFECTIVE_DATE] · Version [VERSION].

Reminder: This is a draft template grounded in Itemra's source code as of commit 6e5ecef. Several integrations are feature-flagged off in repo defaults (WorkOs:Enabled=false, Stripe:Enabled=false, empty connection strings); this DPA describes the intended production configuration, which Itemra must confirm. A qualified lawyer must review and finalise it, all provider facts and implementation gaps noted in Section 9 and Annex II must be closed, and matching Norwegian Bokmål and English documents must be approved before publication, canonical version advancement, or re-acceptance.