Data Processing Agreement

Last updated: 25 October 2026

This Data Processing Agreement ("DPA") forms part of the Terms and Conditions (the "Terms") between the customer that holds an Instama organisation ("Customer", the controller) and Instama B.V., Bakenesserstraat 18-RD, 2011 JJ Haarlem, The Netherlands, Chamber of Commerce 99603292 ("Instama", the processor). It applies automatically to every use of the Service in which Instama processes personal data on the Customer's behalf; no signature is needed.

Where the Terms and this DPA conflict on the processing of personal data, this DPA prevails. Where the Standard Contractual Clauses referred to in section 8 apply and conflict with this DPA, those clauses prevail.

1. Definitions

Terms such as "personal data", "processing", "controller", "processor", "data subject", "personal data breach" and "supervisory authority" have the meaning given in Regulation (EU) 2016/679 (the "GDPR"). "Client Data" has the meaning given in the Terms. "Subprocessor" means any third party Instama engages to process personal data contained in Client Data.

2. Scope and roles

2.1 The Customer is the controller, and Instama the processor, of the personal data contained in Client Data. The details of the processing are in Annex I.

2.2 Instama is the controller of account, billing, usage and security data as described in its Privacy Policy; this DPA does not apply to that data.

3. Instructions

3.1 Instama processes personal data only on the Customer's documented instructions, which are the Terms, this DPA and the Customer's use and configuration of the Service, unless Union or Member State law requires otherwise; in that case Instama informs the Customer before processing, unless the law prohibits it.

3.2 Instama informs the Customer without delay if, in its opinion, an instruction infringes the GDPR or other data protection law.

3.3 Instama does not process personal data for its own purposes, does not use Client Data to train or improve AI models, and does not sell it.

4. The Customer's obligations

4.1 The Customer is responsible for the lawfulness of the processing it instructs, including a lawful basis for the personal data it brings into the Service and the information it gives data subjects.

4.2 The Customer configures the Service, its members' access and its connected accounts, and uses the measures the Service offers (such as the second factor and limited API keys), as the shared responsibility described on the Security page sets out.

5. Confidentiality

Instama ensures that everyone it authorises to process personal data is bound by confidentiality, by contract or by law, and processes it only as far as needed to provide or support the Service.

6. Security

6.1 Instama implements the technical and organisational measures in Annex II, appropriate to the risk as article 32 GDPR requires.

6.2 Instama may update those measures as technology and threats evolve, provided the overall level of protection does not decrease. The current measures are published on the Security page, which shows the date of its last update.

7. Subprocessors

7.1 The Customer gives Instama general authorisation to engage subprocessors. The current subprocessors, with their purpose, data and location, are listed on the Subprocessors page (Annex III).

7.2 Instama informs the Customer at least 30 days before a new subprocessor starts processing personal data, by e-mail to the organisation's owners or in the Service. The Customer may object on reasonable data protection grounds within that period. If Instama cannot reasonably address the objection, the Customer may terminate the affected part of the Service without penalty. Fees already paid are not refunded.

7.3 Instama imposes on each subprocessor, by written contract, data protection obligations that are no less protective than this DPA, and remains liable to the Customer for its subprocessors.

8. International transfers

8.1 Client Data is stored in the European Union.

8.2 Instama transfers personal data outside the European Economic Area only as this section describes, or on the Customer's further documented instructions.

8.3 Where a subprocessor processes personal data outside the European Economic Area, Instama ensures the transfer relies on an adequacy decision (including the EU-US Data Privacy Framework for certified recipients) or on the Standard Contractual Clauses adopted by Commission Implementing Decision (EU) 2021/914 (Module 3, processor to processor), together with a transfer impact assessment and supplementary measures where needed. Instama provides a summary of its transfer impact assessments on request.

8.4 If a public authority requests access to personal data in Client Data, Instama informs the Customer without delay, unless the law prohibits it; discloses only what the law strictly requires; and challenges a request it considers unlawful where it has reasonable grounds to do so.

9. Assistance

9.1 Taking into account the nature of the processing, Instama assists the Customer by appropriate technical and organisational measures in responding to data subject requests. The Service lets the Customer access, correct, export and delete Client Data itself; where it cannot, Instama helps on request. Instama forwards to the Customer, without answering it, any request it receives from a data subject about Client Data.

9.2 Instama assists the Customer with data protection impact assessments and prior consultation of a supervisory authority, as far as these concern the Service, by providing the information published in the trust center and answering reasonable questions.

10. Personal data breaches

10.1 Instama notifies the Customer without undue delay, and in any case within 48 hours, after becoming aware of a personal data breach affecting Client Data, so that the Customer can meet its own 72 hours under article 33 GDPR.

10.2 The notification describes, as far as known: the nature of the breach, the categories and approximate numbers of data subjects and records concerned, the likely consequences, and the measures taken or proposed. Information not yet available is provided as it becomes available.

10.3 Instama takes the measures needed to contain the breach and mitigate its effects, and documents every breach.

10.4 The Customer decides whether to notify the supervisory authority and data subjects. Instama does not notify them on the Customer's behalf unless the Customer instructs it to or the law requires it.

11. Return and deletion

11.1 When the Customer's organisation loses access to the Service, the Client Data remains available for restoration for 60 days and is then permanently deleted. On the Customer's written request, Instama deletes Client Data sooner, within 30 days of the request. The Customer can export Client Data at any time while it has access.

11.2 Deleted data leaves Instama's backups within a further 30 days. Instama may keep personal data only as far as Union or Member State law requires, such as invoices under Dutch tax law, and processes it only for that purpose.

12. Audits

12.1 Instama makes available to the Customer the information necessary to demonstrate compliance with article 28 GDPR: the trust center, answers to reasonable security questionnaires, and, once available, its independent audit reports (SOC 2 Type II, ISO/IEC 27001 certificate) under confidentiality.

12.2 Where that information is not sufficient, the Customer may, at most once a year, have an audit carried out by an independent auditor bound by confidentiality, with at least 30 days' notice, during business hours and without disrupting the Service or exposing other customers' data. An audit is carried out remotely, by documents and interviews, unless an on-site audit is needed to verify compliance. Audits that a supervisory authority requires are not limited this way.

12.3 The Customer bears the costs of an audit, its auditor's included, and reimburses Instama's reasonable costs of supporting it, unless the audit shows that Instama materially breached this DPA.

13. Liability, term and law

13.1 The limitation of liability in section 8 of the Terms applies to this DPA. It does not limit the rights of data subjects under article 82 GDPR.

13.2 This DPA runs for as long as Instama processes personal data on the Customer's behalf. Obligations that by their nature continue, such as confidentiality and deletion, survive its end.

13.3 Instama may amend this DPA in the way section 9 of the Terms describes for the Terms. An amendment may not reduce the protection of personal data under this DPA, except where the law requires it.

13.4 This DPA is governed by Dutch law; the courts of Amsterdam have exclusive jurisdiction, without prejudice to the Standard Contractual Clauses' own provisions.

Annex I. Details of the processing

Annex II. Technical and organisational measures

The measures in place at the date of acceptance. Instama may change them under section 6.2; the current description is on the Security page.

Hosting and data residency

• Managed, serverless infrastructure only; no self-operated servers.
• All Client Data stored in the European Union; all platform compute in EU regions, and a deployment outside the EU refused by the platform's configuration.

Encryption

• HTTPS only: TLS 1.2 or 1.3, certificates managed automatically, plain HTTP redirected; HSTS with a two-year max-age.
• All service-to-service traffic (database, storage, rendering, payments, AI providers) over TLS.
• Database, backups and file storage encrypted at rest with AES-256.
• Credentials Instama issues (API keys, OAuth tokens, invitation tokens) stored only as keyed hashes (HMAC-SHA256), shown once.
• Access tokens of connected social and advertising accounts encrypted by the application (AES-256-GCM) before storage, bound to their brand, under a key per environment that the database never holds.

Tenant isolation

• Every record belongs to a brand within an organisation; the database itself (PostgreSQL Row-Level Security on every table) limits every query to the brands the caller belongs to.
• No anonymous access to any application table; internal tables reachable by no user.
• Privileged database functions with a pinned search path; internal functions not callable through the API.
• An append-only audit log that rejects updates and deletes.
• One enforcement point for every credential: sessions, API keys, OAuth tokens and background jobs reach the database as the person they act for, with that person's permissions.
• Automated tests of every role against every permission and table.

Identity and access

• Passwordless sign-in only (a one-time code by e-mail, or Google, Microsoft or GitHub via OAuth with PKCE); accounts by invitation only, enforced by the database.
• Rate limits on codes, sign-ins, token refreshes and invite codes.
• A TOTP second factor that, once set up, the database enforces on every table; a recent proof (within 15 minutes) for sensitive actions; no credential acts above the assurance level of the session that issued it.
• Secure, host-only session cookies; one-hour access tokens; rotating refresh tokens with reuse detection; same-origin checks on changes; signing out ends every session.
• Organisation and brand roles checked by the database; sharing of folders and channels per person.
• Instama staff access limited to a small named group, with a verified second factor, a factor proof within 12 hours and activity within the last hour; every administrative change audited; no feature to sign in as a customer.

API and integrations

• One API for every client, checking brand scope and running under the caller's permissions; errors without internal details.
• API keys of 256 bits, stored as keyed hashes, limited to chosen brands and revocable.
• OAuth 2.1 with mandatory PKCE, single-use codes, one-hour access tokens, rotating refresh tokens revoked as a family on reuse, grants of at most 90 days, exact HTTPS redirect URIs.
• Webhooks verified on receipt and signed when sent; connected accounts through standard OAuth, their tokens per brand.
• Rate limits and spend limits against abuse.

Storage and rendering

• Private storage under the same brand and second-factor rules as the database; delivery through a proxy with the viewer's credentials or signed URLs that expire within an hour.
• Uploads through single-use signed URLs, checked against permission, type, size and quota before they are committed.
• Rendering on short-lived, isolated compute in the EU, given only time-limited links to the brand's own files and keeping nothing afterwards.

AI

• Every AI call starts on Instama's servers and runs under the person's permissions; models act only through checked tools, never with direct database access.
• Brand and organisation context resolved on the server; changes outside the active brand wait for the person's approval.
• No Client Data used to train AI models (section 3.3).

Development and operations

• Every change passes two separate environments, each with its own database and secrets, and a gate of type checks, linting, unit, database and build tests before production.
• Declarative, verified database migrations; security rules encoded as automated tests; configuration checked at build time; a locked dependency tree with a release-age gate; secrets encrypted per environment and never in source control.
• An audit log of every change and refused attempt, kept 24 months; daily automated checks of access rules and retention; daily encrypted backups rolled over within 30 days; instant rollback of any release.
• Notification of personal data breaches under section 10.

Annex III. Subprocessors

The list on the Subprocessors page, maintained under section 7.