Rakomi

Privacy Policy

Quick Summary

Effective Date: 2026-04-22 Version: 6

1. Who We Are

Rakomi is an authentication-as-a-service platform operated by:

CRE8EVE Sp. z o.o. Tulipanowa 4, 72-003 Dobra, Poland KRS: 0000912669 (Sąd Rejonowy Szczecin-Centrum w Szczecinie, XIII Wydział Gospodarczy KRS) NIP: 8513262229 | REGON: 389506637 Kapitał zakładowy: 5 000,00 zł

Data protection contact: dpo@rakomi.com General contact: info@rakomi.com Security contact: security@rakomi.com

CRE8EVE has not designated a Data Protection Officer (DPO) under Art. 37 GDPR, as it does not meet the mandatory designation criteria. This assessment will be reviewed annually or upon a significant change in processing activities. In the meantime, all data protection inquiries should be directed to dpo@rakomi.com.

Our Three GDPR Roles

CRE8EVE acts in three distinct data processing roles:

Processing Activity CRE8EVE's Role Legal Basis Data Subjects
Dashboard member accounts (name, email, password, sessions) Data Controller Art. 6(1)(b) — contract performance Tenant developers
End-user authentication data (on behalf of tenants) Data Processor Art. 28 — Data Processing Agreement End-users of tenant applications
Platform security operations (credential stuffing detection, cross-tenant IP correlation) Independent Controller Art. 6(1)(f) — legitimate interest All users (end-users and dashboard members)

2. Scope of This Policy

This Privacy Policy governs:

This Privacy Policy does NOT govern:

End-user data processed through the Rakomi platform on behalf of tenant developers. When a tenant integrates Rakomi into their application, the tenant is the Data Controller for their end-users' personal data. CRE8EVE processes that data solely as a Data Processor under the Data Processing Agreement. End-users should refer to the privacy policy of the tenant's application for information about how their data is handled.

In other words: if you signed up directly on rakomi.com, this policy applies to you. If you are logging into someone else's app that uses Rakomi for authentication, that app's privacy policy applies — not this one. We only process your data on that app's instructions.

3. Data We Collect

3.1 Dashboard Members (Controller Relationship)

When you create a Rakomi dashboard account, we collect and process:

Category Data Required Purpose
Identity Name, email address Yes Account operation, communication
Security Password hash (industry-standard algorithm) Yes (unless magic-link user) Authentication
Security Magic link tokens Transient Passwordless authentication
Security Public cryptographic identifier and minimal device-type metadata for registered security credentials (passkeys) Optional Phishing-resistant sign-in
Session Session ID, token, IP hash, user agent hash Yes Session management, security monitoring
Audit Authentication events, actions, timestamps Yes Security audit trail, compliance
Federation OAuth provider, subject identifier, email (when using Google, GitHub, Microsoft, Apple, Discord, Facebook, Slack, Twitter/X, GitLab, or LinkedIn login) Conditional Federated authentication
Billing Subscription plan, billing interval, payment status, subscription identifiers Conditional (paid plans) Subscription management, payment processing

Data we do NOT collect: physical addresses, phone numbers, behavioural analytics, advertising identifiers, or Art. 9 GDPR special category data (health, biometric, racial/ethnic origin, political opinions, religious beliefs, trade union membership, genetic data, sex life/sexual orientation, criminal convictions).

Security credentials (passkeys): To support phishing-resistant sign-in, we store a public cryptographic identifier and minimal device metadata for each registered security credential. We do not store private key material or raw device identifiers. You may delete any credential at any time from your account settings. Registered credentials are deleted automatically when your account is deleted.

3.2 Platform Security (Independent Controller)

For credential stuffing detection, we process:

Category Data Storage Retention
IP address Raw IP address In-memory only 1-hour sliding window
Aggregate Tenant-count-per-IP In-memory only 1-hour sliding window

This data is never written to disk or database. It is used solely to count how many different tenant applications a single IP address attempts to authenticate against within a one-hour window.

In other words: we look at login patterns across tenant applications to detect credential stuffing attacks. We don't profile individual users — we only count how many different apps the same IP address tries to access within one hour. If the number is unusually high, we temporarily block that IP for one hour. This protects you and all other users of the platform.

3.3 Pseudonymisation

IP addresses and user agent strings stored in audit logs are pseudonymised using HMAC-SHA256 keyed hashing. In accordance with EDPB Guidelines 01/2025 on Pseudonymisation, pseudonymised data remains personal data under GDPR — it is not anonymised. The keyed hash means that without access to the HMAC key, the original IP address or user agent cannot be recovered from the hash alone.

3.4 Guest (Anonymous) Identifiers

When enabled by the tenant's application, we may create a short-lived opaque identifier for users who have not registered, so they can try the application before creating an account. This identifier is deleted automatically after a period of inactivity configured by the tenant (between 1 and 90 days, default 30). No email, name, phone number, or other directly identifying information is stored on the guest record. Pseudonymous identifiers without contact information cannot be linked to a natural person for access requests; users may obtain access rights by registering (claiming) the account, at which point the standard data-subject rights apply.

Claiming a guest account can be completed either by registering with an email address and password, or by signing in with a supported social provider. Whichever path is used, the guest record is upgraded in place: no duplicate account is created, and any data already associated with the guest identifier (for example, session state, application-specific preferences) carries over to the now-identifiable account.

4. How We Use Your Data (Purposes and Legal Bases)

CRE8EVE does not rely on Art. 6(1)(a) GDPR (consent) as a legal basis for any processing activity. All processing is based on contract performance, legal obligation, or legitimate interest. Because we do not use consent, the right to withdraw consent (Art. 7(3)) is not applicable.

4.1 Contract Performance — Art. 6(1)(b)

Processing Activity Purpose
Account creation and management Providing the Rakomi authentication service
Session management and JWT issuance Authenticating users and maintaining sessions
Email verification and password reset Securing account access
Transactional email delivery (via Brevo) Account notifications, security alerts
OAuth federation (via Google, GitHub, Microsoft, Apple, Discord, Facebook, Slack, Twitter/X, GitLab, or LinkedIn — when enabled) Enabling federated sign-in
Subscription management and payment processing (via payment processor) Managing plan upgrades, downgrades, and billing cycles
Art. 16(m) withdrawal waiver consent recording Documenting consent to immediate service access

4.2 Legal Obligation — Art. 6(1)(c)

Processing Activity Legal Basis
Compliance audit trails GDPR Art. 5(2) accountability principle, Art. 30 records of processing

4.3 Legitimate Interest — Art. 6(1)(f)

For each legitimate interest activity, we apply the three-part cumulative test required by EDPB Guidelines 1/2024:

Activity 1: Security Logging

  1. Legitimate interest identified: Protecting the platform and its users from unauthorized access, detecting anomalies, and maintaining audit trails for incident response.
  2. Necessity: Security logging is essential for detecting and responding to threats. There is no less intrusive alternative that achieves the same security outcome.
  3. Balancing test: IP and user agent data are pseudonymised (HMAC-SHA256). Retention is limited to 90 days for IP/UA hashes. The processing directly benefits data subjects by protecting their accounts. The impact on data subjects is minimal given pseudonymisation.

Activity 2: Credential Stuffing Detection

  1. Legitimate interest identified: Protecting all users of the platform from credential stuffing attacks — a widespread threat where attackers use leaked credentials from other services to compromise accounts.
  2. Necessity: Cross-tenant IP correlation is the only effective method to detect coordinated attacks targeting multiple tenant applications simultaneously. Per-tenant detection alone cannot identify the pattern.
  3. Balancing test: Only raw IP addresses are processed, in-memory only, for a maximum of 1 hour. No individual profiling occurs — only an IP-to-tenant-count aggregate. The maximum adverse effect is a 1-hour temporary authentication delay from the affected IP address, with the right to contest (see Section 13). Processing protects data subjects by preventing account takeover.

In other words: we need to see login patterns across all apps on our platform to catch attackers who try the same stolen passwords everywhere. We only remember an IP address for one hour and only count how many apps it tried — nothing else.

Activity 3: Abuse Prevention

  1. Legitimate interest identified: Preventing platform misuse including phishing, illegal data collection, and service abuse.
  2. Necessity: Rate limiting and abuse detection require processing of request metadata to identify patterns.
  3. Balancing test: Processing is limited to metadata necessary for abuse detection. Retention periods are proportional to the threat landscape.

4.4 Art. 5(1)(a) Fairness — Cross-Tenant IP Correlation

Cross-tenant IP correlation does not disadvantage data subjects because: (a) the processing protects them against credential stuffing attacks, (b) no individual profiling occurs — only an IP-to-tenant-count aggregate is computed, (c) the maximum adverse effect is a 1-hour temporary authentication delay with the right to contest, and (d) this Privacy Policy provides full transparency through Art. 14 disclosures (see Section 8).

4.5 Art. 5(1)(b) Purpose Limitation

5. Automated Decision-Making (Art. 22)

Rakomi employs automated credential stuffing detection that may temporarily block authentication requests from specific IP addresses. This is a solely automated decision within the meaning of Art. 22(1) GDPR.

How it works:

Legal basis for automated processing: CRE8EVE invokes Art. 22(2)(b) — processing authorized by EU law. Specifically, GDPR Art. 32(1)(b) imposes a security obligation requiring appropriate technical measures to ensure a level of security appropriate to the risk. Automated credential stuffing detection is an industry-standard technical security measure fulfilling this obligation.

This decision is NOT based on Art. 9 special category data. IP addresses are not special category data.

Art. 22(3) safeguards are provided regardless of whether Art. 22(1) applies:

In other words: if your IP gets blocked because our system thinks it looks like an attack, you can email us and a human will review it. If it was a mistake, we'll unblock you.

5.2 Automated Billing Decisions

Rakomi employs automated billing decisions that may affect service availability:

MAU (Monthly Active User) enforcement:

Past-due subscription restrictions:

Trial expiry:

Art. 22(3) safeguards apply to all automated billing decisions:

6. Data Sharing and Sub-Processors

We share personal data only with the following service providers, all of which have Data Processing Agreements in place:

Sub-Processor Service Data Categories Location EU/Non-EU DPA
Hetzner Online GmbH Infrastructure and database hosting All personal data Germany EU Hetzner DPA
Brevo (Sendinblue SAS) Transactional email delivery Email addresses, IP addresses, user agents, tenant names (in transactional email HTML bodies) France EU Brevo DPA
Google LLC OAuth federation (conditional — only when a tenant enables Google sign-in) Email address, subject identifier USA Non-EU (DPF) Google DPA
GitHub, Inc. (Microsoft Corporation subsidiary) OAuth federation (conditional — only when a tenant enables GitHub sign-in) Email address, subject identifier USA Non-EU (DPF) GitHub DPA
Microsoft Corporation OAuth federation (conditional — only when a tenant enables Microsoft or LinkedIn sign-in) Email address, authentication identifier (object identifier), tenant identifier (for forensic auditing) USA Non-EU (DPF) Microsoft DPA
Apple Inc. OAuth federation (conditional — only when a tenant enables Apple Sign In) Email address (may be anonymised via Apple's private email relay), subject identifier USA Non-EU (DPF) Apple Business DPA
Discord, Inc. OAuth federation (conditional — only when a tenant enables Discord sign-in) Email address, subject identifier USA Non-EU (DPF) No public DPA link
Meta Platforms, Inc. OAuth federation (conditional — only when a tenant enables Facebook sign-in) Email address (when provided), subject identifier USA Non-EU (DPF + SCCs) Meta DPA
Salesforce, Inc. / Slack Technologies OAuth federation (conditional — only when a tenant enables Slack sign-in) Email address, subject identifier, workspace identifier USA Non-EU (DPF) Slack DPA
X Corp. OAuth federation (conditional — only when a tenant enables Twitter/X sign-in) Email address, subject identifier USA Non-EU (DPF) No public DPA link
GitLab Inc. OAuth federation (conditional — only when a tenant enables GitLab sign-in, supports self-hosted instances) Email address, subject identifier USA Non-EU (DPF) GitLab DPA
Cloudflare, Inc. Bot protection / CAPTCHA alternative (Turnstile) — public signup form only IP addresses (server-side token verification only; no cookies, no persistent identifiers) USA Non-EU (DPF) Cloudflare DPA
Stripe, Inc. Payment processing Subscription identifiers, payment status, billing metadata USA + Ireland Non-EU (DPF + SCCs) Stripe DPA

Sub-processor certifications:

We do not sell, rent, or share personal data with advertisers, data brokers, or any third parties beyond those listed above.

7. International Transfers

All primary data processing occurs within the European Union:

Transfer to Google LLC (USA): When a tenant enables Google OAuth federation, email addresses and subject identifiers are shared with Google LLC in the United States. This transfer relies on the EU-US Data Privacy Framework (DPF) adequacy decision (Commission Implementing Decision C(2023) 4745) as the primary transfer mechanism.

As a contingency measure: in the event the DPF adequacy decision is invalidated, transfers to Google LLC shall continue under Standard Contractual Clauses (SCCs) Module 3 (Processor-to-Processor) per Commission Implementing Decision (EU) 2021/914, already in place as a secondary mechanism.

Transfer to GitHub, Inc. (USA): When a tenant enables GitHub OAuth federation, email addresses and subject identifiers are shared with GitHub, Inc. (a subsidiary of Microsoft Corporation) in the United States during the authentication flow. This transfer relies on the EU-US Data Privacy Framework (DPF) adequacy decision (Commission Implementing Decision C(2023) 4745) as the primary transfer mechanism. GitHub, Inc. participates in the DPF as a subsidiary of its certified parent company Microsoft Corporation.

As a contingency measure: in the event the DPF adequacy decision is invalidated, transfers to GitHub, Inc. shall continue under Standard Contractual Clauses (SCCs) Module 3 (Processor-to-Processor) per Commission Implementing Decision (EU) 2021/914.

Transfer to Microsoft Corporation (USA): When a tenant enables Microsoft or LinkedIn OAuth federation, email addresses, authentication identifiers (object identifiers), and tenant identifiers are shared with Microsoft Corporation in the United States during the authentication flow. This transfer relies on the EU-US Data Privacy Framework (DPF) adequacy decision (Commission Implementing Decision C(2023) 4745) as the primary transfer mechanism. Microsoft Corporation is a direct DPF participant (certification verified at dataprivacyframework.gov). Microsoft Graph API fallback (for email resolution) is covered by the same mechanism. LinkedIn OAuth is served by Microsoft Corporation as the legal entity.

As a contingency measure: in the event the DPF adequacy decision is invalidated, transfers to Microsoft Corporation shall continue under Standard Contractual Clauses (SCCs) Module 3 (Processor-to-Processor) per Commission Implementing Decision (EU) 2021/914.

Transfer to Apple Inc. (USA): When a tenant enables Apple Sign In, email addresses (which may be anonymised via Apple's private email relay) and subject identifiers are shared with Apple Inc. in the United States during the authentication flow. This transfer relies on the EU-US Data Privacy Framework (DPF) adequacy decision (Commission Implementing Decision C(2023) 4745) as the primary transfer mechanism.

As a contingency measure: in the event the DPF adequacy decision is invalidated, transfers to Apple Inc. shall continue under Standard Contractual Clauses (SCCs) Module 3 (Processor-to-Processor) per Commission Implementing Decision (EU) 2021/914.

Transfer to Discord, Inc. (USA): When a tenant enables Discord sign-in, email addresses and subject identifiers are shared with Discord, Inc. in the United States during the authentication flow. This transfer relies on the EU-US Data Privacy Framework (DPF) adequacy decision (Commission Implementing Decision C(2023) 4745) as the primary transfer mechanism, subject to verification of Discord's DPF participation status.

As a contingency measure: in the event the DPF adequacy decision is invalidated or Discord's participation cannot be verified, transfers to Discord, Inc. shall continue under Standard Contractual Clauses (SCCs) Module 3 (Processor-to-Processor) per Commission Implementing Decision (EU) 2021/914.

Transfer to Meta Platforms, Inc. (USA): When a tenant enables Facebook sign-in, email addresses (when provided by the user) and subject identifiers are shared with Meta Platforms, Inc. in the United States during the authentication flow. This transfer relies on the EU-US Data Privacy Framework (DPF) adequacy decision (Commission Implementing Decision C(2023) 4745) as the primary transfer mechanism, with Standard Contractual Clauses (SCCs) in place as a secondary mechanism.

As a contingency measure: in the event the DPF adequacy decision is invalidated, transfers to Meta Platforms, Inc. shall continue under Standard Contractual Clauses (SCCs) Module 3 (Processor-to-Processor) per Commission Implementing Decision (EU) 2021/914.

Transfer to Salesforce, Inc. / Slack Technologies (USA): When a tenant enables Slack sign-in, email addresses, subject identifiers, and workspace identifiers are shared with Salesforce, Inc. (Slack Technologies) in the United States during the authentication flow. This transfer relies on the EU-US Data Privacy Framework (DPF) adequacy decision (Commission Implementing Decision C(2023) 4745) as the primary transfer mechanism.

As a contingency measure: in the event the DPF adequacy decision is invalidated, transfers to Salesforce, Inc. shall continue under Standard Contractual Clauses (SCCs) Module 3 (Processor-to-Processor) per Commission Implementing Decision (EU) 2021/914.

Transfer to X Corp. (USA): When a tenant enables Twitter/X sign-in, email addresses and subject identifiers are shared with X Corp. in the United States during the authentication flow. This transfer relies on the EU-US Data Privacy Framework (DPF) adequacy decision (Commission Implementing Decision C(2023) 4745) as the primary transfer mechanism, subject to verification of X Corp.'s DPF participation status.

As a contingency measure: in the event the DPF adequacy decision is invalidated or X Corp.'s participation cannot be verified, transfers to X Corp. shall continue under Standard Contractual Clauses (SCCs) Module 3 (Processor-to-Processor) per Commission Implementing Decision (EU) 2021/914.

Transfer to GitLab Inc. (USA): When a tenant enables GitLab sign-in, email addresses and subject identifiers are shared with GitLab Inc. in the United States during the authentication flow. For self-hosted GitLab instances, data is shared with the self-hosted server at the location specified by the tenant. This transfer (for GitLab.com) relies on the EU-US Data Privacy Framework (DPF) adequacy decision (Commission Implementing Decision C(2023) 4745) as the primary transfer mechanism.

As a contingency measure: in the event the DPF adequacy decision is invalidated, transfers to GitLab Inc. shall continue under Standard Contractual Clauses (SCCs) Module 3 (Processor-to-Processor) per Commission Implementing Decision (EU) 2021/914.

Transfer to Cloudflare, Inc. (USA): When a visitor submits the public signup form, the visitor's IP address is sent to Cloudflare's server-side verification endpoint (challenges.cloudflare.com) to validate the Turnstile bot-protection token. This transfer relies on the EU-US Data Privacy Framework (DPF) adequacy decision as the primary transfer mechanism. Cloudflare does not set cookies or create persistent identifiers via Turnstile.

Transfer to Stripe, Inc. (USA + Ireland): When a tenant activates a paid subscription, subscription management data (plan identifiers, billing status, payment metadata) is processed by Stripe, Inc. EU payment flows are routed through Stripe's Ireland entity. Data transfers to the US rely on the EU-US Data Privacy Framework (DPF) adequacy decision as the primary mechanism, with Standard Contractual Clauses (SCCs) Module 2 (Controller-to-Processor) in place as a contingency.

No other international transfers of personal data occur.

8. Information for End-Users of Tenant Applications (Art. 14 Disclosures)

When CRE8EVE processes personal data not obtained directly from the data subject, Art. 14 GDPR requires specific disclosures. Data may be obtained from third-party OAuth providers (Google, GitHub, Microsoft, Apple, Discord, Facebook/Meta, Slack, Twitter/X, GitLab, LinkedIn) when a tenant enables the respective federated sign-in method. The following scenarios apply:

8.1 Google OAuth Federated Login

When an end-user authenticates via Google through a tenant application:

8.1b GitHub OAuth Federated Login

When an end-user authenticates via GitHub through a tenant application:

8.1c Microsoft OAuth Federated Login

When an end-user authenticates via Microsoft through a tenant application:

8.1d Apple Sign In Federated Login

When an end-user authenticates via Apple through a tenant application:

8.1e Discord OAuth Federated Login

When an end-user authenticates via Discord through a tenant application:

8.1f Facebook OAuth Federated Login

When an end-user authenticates via Facebook through a tenant application:

8.1g Slack OAuth Federated Login

When an end-user authenticates via Slack through a tenant application:

8.1h Twitter/X OAuth Federated Login

When an end-user authenticates via Twitter/X through a tenant application:

8.1i GitLab OAuth Federated Login

When an end-user authenticates via GitLab through a tenant application:

8.1j LinkedIn OAuth Federated Login

When an end-user authenticates via LinkedIn through a tenant application:

8.2 Independent Controller IP Processing (Credential Stuffing Detection)

When CRE8EVE processes IP addresses of end-users who never directly interact with Rakomi:

This processing is not "further processing" under Art. 6(4). CRE8EVE processes IP addresses as an Independent Controller under its own Art. 6(1)(f) legal basis, separate from the tenant's Art. 6(1)(b) basis. The three-part legitimate interest test provides independent justification.

9. Data Retention

Data Type Retention Period Legal Basis Detail
IP hash / UA hash in audit logs 90 days Legitimate interest (security) Pseudonymised, then purged
Authentication events (Free plan) 30 days Contract performance Configurable per plan
Authentication events (Pro plan) 365 days Contract performance Configurable per plan
Authentication events (Enterprise plan) 730 days Contract performance Configurable per plan
Compliance events Minimum 3 years; may be retained longer Legal obligation (Art. 5(2), Art. 30) For ongoing GDPR accountability
Federated identities (Google, GitHub, Microsoft, Apple, Discord, Facebook, Slack, Twitter/X, GitLab, or LinkedIn OAuth) Active account lifetime Contract performance Deleted on user deletion
Active sessions 30 days after expiry Contract performance Automatic cleanup
Revoked sessions 90 days Security (replay detection) Then purged
Authorization codes 10 minutes (functional lifetime) Security Expired codes cleaned up in batch
Webhook deliveries (delivered) 30 days Contract performance Then purged
Webhook deliveries (failed) 90 days Legitimate interest (debugging) Then purged
Credential stuffing IP data 1 hour (in-memory) Legitimate interest Never persisted
Billing audit trail 5 years from end of calendar year Legal obligation (Polish Ordynacja podatkowa Art. 86 §1) Tax record retention
Subscription metadata Active subscription + 90 days Contract performance Cleanup after cancellation
User account data Until deletion request + 7-day recovery grace period Contract + legal obligation See Art. 17 below

Test/Sandbox environments: Rakomi provides logically separated test environments for developers to test authentication integration. Test environment data is isolated from production through multiple technical measures including cryptographic token isolation. Test emails are suppressed and never leave Rakomi infrastructure. Test data is automatically purged after 90 days or on manual reset. Developers are encouraged to use synthetic data in test environments.

Post-deletion retention (Art. 17(3)): When you request account deletion (Art. 17(1)), CRE8EVE deletes your account data but retains anonymised compliance audit log metadata under: Art. 17(3)(b) — legal obligation (GDPR Art. 5(2)/Art. 30 accountability), and Art. 17(3)(e) — establishment, exercise, or defence of legal claims. Post-erasure retained data consists of: event type, timestamp, tenant ID, action category — no email, no IP/UA hash (purged by automated cron jobs). Minimum retention: 3 years; indefinite for ongoing accountability.

10. Your Rights

10.1 Dashboard Members (Direct Controller Relationship)

As a dashboard member, you may exercise the following rights directly with CRE8EVE:

Right Article How to Exercise
Access Art. 15 Email dpo@rakomi.com
Rectification Art. 16 Via dashboard settings or email dpo@rakomi.com
Erasure ("right to be forgotten") Art. 17 Via dashboard account deletion or email dpo@rakomi.com
Restriction of processing Art. 18 Email dpo@rakomi.com
Data portability Art. 20 Via dashboard data export (JSON format) or email dpo@rakomi.com
Object to processing Art. 21 See Section 11 below

Art. 20 portability scope: Data portability applies only to data processed under Art. 6(1)(b) (contract). Portable data includes: name, email, session history, audit logs. Data processed under Art. 6(1)(f) (legitimate interest) — such as IP/UA hashes — is not portable under Art. 20.

Art. 17(3) limitations on erasure: Compliance audit log metadata is retained after deletion under Art. 17(3)(b) (legal obligation) and Art. 17(3)(e) (legal claims defence). See Section 9 for details.

Art. 18(1)(d) restriction during objection: If you exercise your right to object under Art. 21, you have the right to request restriction of processing under Art. 18(1)(d) during the assessment period. Restricted data is frozen (not processed further and not deleted) until the assessment concludes.

We respond to all data subject requests within 30 days (Art. 12(3)). If a request is complex, we may extend by a further 60 days with prior notice.

10.2 End-Users of Tenant Applications (Processor Relationship)

If you are an end-user authenticating through a tenant's application, the tenant is the Data Controller for your personal data. To exercise your GDPR rights (access, rectification, erasure, portability), please contact the tenant directly.

CRE8EVE, as Data Processor, will assist the tenant Controller in fulfilling your data subject requests in accordance with the Data Processing Agreement.

10.3 Whether Data Provision Is Required

For dashboard members: providing your name and email address is a contractual requirement for account creation. If you do not provide this data, we cannot create your account or provide the service. Providing a password is required unless you use magic-link authentication.

11. Right to Object (Art. 21)

You have the right to object at any time, on grounds relating to your particular situation, to processing of your personal data based on Art. 6(1)(f) (legitimate interest).

How to exercise: Email dpo@rakomi.com with the subject line "Right to Object" and describe the grounds for your objection.

Assessment: CRE8EVE will assess your objection within 30 days. For security-related processing (security logging, credential stuffing detection), compelling legitimate grounds for continued processing typically exist — platform integrity and the protection of all users generally override an individual objection. However, every objection receives an individual assessment.

If your objection is upheld: Processing of your personal data for the contested purpose ceases, and erasure follows under Art. 17(1)(c).

During the assessment period: You have the right to restriction of processing under Art. 18(1)(d). Your data is frozen — not processed further and not deleted — until the assessment concludes.

Direct marketing: CRE8EVE does not process personal data for direct marketing purposes. Art. 21(2)-(3) GDPR (absolute right to object to direct marketing) is therefore not applicable.

12. Children's Data

CRE8EVE does not knowingly collect or process personal data of children under 16 years of age. Age verification for end-users is the responsibility of tenant Controllers (Data Controllers for their end-users).

If we become aware that we have collected personal data from a child under 16 without appropriate consent or authorization, we will delete such data promptly.

13. We Do NOT...

14. Breach Notification

In the event of a personal data breach:

15. Supervisory Authority

You have the right to lodge a complaint with the supervisory authority:

Prezes Urzędu Ochrony Danych Osobowych (UODO) ul. Stawki 2, 00-193 Warszawa, Poland Website: https://uodo.gov.pl

16. Changes to This Policy

We will notify you of changes to this Privacy Policy by:

Material changes to data processing purposes, legal bases, or data categories will take effect no earlier than 30 days after notification. You may terminate your account if you do not agree with the changes.

Previous versions of this policy will be available upon request to dpo@rakomi.com.

17. Contact

For any questions about this Privacy Policy or to exercise your data protection rights:

Data protection: dpo@rakomi.com General inquiries: info@rakomi.com Security issues: security@rakomi.com

For complaints, see our Complaint Procedure. For our full entity details, see Provider Identification. For cookie and web storage details, see our Cookie Policy. For data processing terms, see our Data Processing Agreement.