Data Processing Agreement
Quick Summary
- This DPA governs how CRE8EVE processes end-user data on your behalf when you use Rakomi.
- You are the Data Controller. CRE8EVE is the Data Processor. Your instructions determine how we handle your users' data.
- All data is stored in the EU (Germany). Transfers to third-party OAuth providers only occur if you enable their respective social login.
- We notify you of data breaches within 24 hours. We delete data within 30 days of contract termination.
- We do not use your data for AI training, marketing, or any purpose beyond providing the Rakomi service.
Effective Date: 2026-03-20 Version: 7
1. Definitions
| Term | Meaning |
|---|---|
| Controller | The Customer — the natural or legal person who determines the purposes and means of processing End-User personal data |
| Processor | CRE8EVE Sp. z o.o. — processing End-User personal data on behalf of the Controller |
| Personal Data | Any information relating to an identified or identifiable natural person processed through the Rakomi platform |
| Processing | Any operation performed on Personal Data (collection, storage, retrieval, use, disclosure, erasure) |
| Sub-Processor | A third party engaged by the Processor to process Personal Data on behalf of the Controller |
| Data Subject | End-users of the Controller's applications who authenticate through Rakomi |
| Service Agreement | The Terms of Service governing the Controller's use of Rakomi |
| Supervisory Authority | The competent data protection authority, in particular Prezes UODO (Poland) |
2. Scope, Duration, and Nature of Processing
Pursuant to Art. 28(3) GDPR:
Subject-matter: Processing of End-User authentication data through the Rakomi platform, including enterprise identity provisioning where enabled by the Controller.
Duration: The term of the Service Agreement between the Controller and CRE8EVE. Processing ceases upon termination, subject to the data deletion provisions in Section 4.7.
Nature and purpose: CRE8EVE processes Personal Data to provide authentication services as instructed by the Controller through the platform's configuration and API. Processing activities fall into two categories:
A. User-Initiated Processing — registration, login, session management, OAuth authorization, social login federation, audit logging, webhook delivery. The Data Subject initiates the interaction with Rakomi.
B. Enterprise-Push Processing (applicable when the Controller enables enterprise identity provisioning) — enterprise directory synchronisation (SCIM 2.0 provisioning), bulk user import. The Controller's enterprise identity provider pushes Personal Data to Rakomi without direct Data Subject interaction at the time of provisioning.
Type of Personal Data: Email addresses, password hashes (industry-standard memory-hard algorithm), OAuth identifiers (provider, subject, email), cryptographic IP hashes, cryptographic user agent hashes, session data, authentication events, authorization codes, timestamps. When enterprise identity provisioning is enabled: external identifiers, display names, user profile attributes as configured by the Controller (e.g. department, employee number, cost centre, manager reference), organisational membership data, group memberships, account status, operation audit records.
Categories of Data Subjects: End-users of the Controller's applications who create accounts, authenticate through Rakomi, or are provisioned via enterprise directory synchronisation.
Sandbox/Test Environments: The Processor provides logically separated test environments for the Controller to test authentication integration. Test environment data is processed identically to production data with environment isolation. The Controller is responsible for the lawfulness of any personal data used in test environments — synthetic data is recommended. Test emails are suppressed and never leave Processor infrastructure. Test data is auto-purged after 90 days or on manual reset by the Controller.
3. Controller's Obligations
The Controller shall:
- Ensure it has a lawful basis for processing Personal Data and for instructing CRE8EVE to process on its behalf.
- Provide its own privacy policy to its End-Users in compliance with Art. 13/14 GDPR.
- Respond to Data Subject requests from its End-Users (with CRE8EVE's assistance per Section 11).
- Notify CRE8EVE of any restrictions or special requirements regarding the processing.
- Ensure that only authorised persons have access to the Controller's Rakomi dashboard and API keys.
- Represent and warrant that End-User data does not include Art. 9 special category data (Section 9.1).
- Represent compliance with age verification requirements for its End-Users.
Enterprise Identity Provisioning (SCIM) — applicable when the Controller enables enterprise directory synchronisation:
- Represent and warrant that it has a lawful basis (Art. 6 GDPR) for transmitting employee Personal Data to the Processor via enterprise directory synchronisation — specifically Art. 6(1)(b) (performance of the employment contract) or Art. 6(1)(f) (legitimate interest in IT security and access management). Employee consent is not a valid basis for employer-pushed provisioning due to the inherent power imbalance in the employment relationship.
- Represent and warrant that data pushed via enterprise directory synchronisation does not include Art. 9 special category data. If Art. 9 data is discovered in provisioning storage, the Controller bears responsibility and must instruct the Processor on remediation within 72 hours of notification (cross-reference Section 9.1).
- Inform SCIM-provisioned employees about the processing within 30 days of provisioning per Art. 14(3)(a) GDPR. The Processor provides a first-login transparency notice as technical assistance under Art. 28(3)(e), but the Controller bears ultimate responsibility for Art. 14 compliance.
- Rotate enterprise directory synchronisation service credentials in accordance with rotation reminders provided by the Processor. Failure to rotate credentials resulting in synchronisation failure and continued access by terminated employees constitutes a Controller-side security incident.
- Notify the Processor of corporate acquisitions, mergers, or entity changes that affect the Controller's identity under this DPA. Transfer of an enterprise directory synchronisation connection requires acceptance of this DPA by the acquiring entity.
- Comply with applicable national employment law requirements before deploying enterprise directory synchronisation — in particular, jurisdictions with employee co-determination rights (such as works council consultation requirements) may require prior approval for introduction of identity management systems. The Processor provides technical assistance documentation but cannot assess the Controller's national employment law obligations.
- Comply with Art. 14 GDPR transparency obligations for all users provisioned via enterprise directory synchronisation who authenticate exclusively via API/SDK and never access the Processor's hosted interface — the Processor's first-login transparency notice does not reach these users.
4. Processor's Obligations
4.1 Processing on Instructions — Art. 28(3)(a)
CRE8EVE processes Personal Data only on the documented instructions of the Controller, including with regard to transfers to third countries. Such instructions are documented through: (a) this DPA, (b) the Service Agreement, (c) the Controller's configuration of Rakomi features (e.g., enabling Google OAuth), and (d) API calls made by the Controller.
If CRE8EVE is required by EU or Member State law to process Personal Data beyond the Controller's instructions, CRE8EVE shall inform the Controller of that legal requirement before processing, unless the law prohibits such information.
4.2 Confidentiality — Art. 28(3)(b)
CRE8EVE ensures that all persons authorised to process Personal Data have committed themselves to confidentiality or are under an appropriate statutory obligation of confidentiality.
4.3 Security Measures — Art. 28(3)(c)
CRE8EVE implements appropriate technical and organisational measures to ensure a level of security appropriate to the risk, as required by Art. 32 GDPR. These measures are detailed in Annex 2 and include:
- Authenticated encryption for signing keys at rest; database disk encryption via hosting infrastructure
- TLS encryption in transit
- Multi-layer tenant isolation (database-level + application-level + automated testing)
- Industry-standard memory-hard password hashing per NIST SP 800-63B-4
- Asymmetric cryptographic JWT signing with periodic key rotation
- Per-endpoint, per-IP rate limiting with progressive delay
- Cross-tenant credential stuffing detection
- CSRF protection via SameSite=Lax cookie attribute + token-based API authentication
- Webhook SSRF protection (private IP blocking, HTTPS-only, no redirects)
- No stack traces, internal details, or dependency versions in error responses
- Secrets managed via dedicated secrets vault (never stored on disk)
- Structured JSON audit logging
- Role-based access control (Owner/Member), API key scoped permissions
- Authorization code functional lifetime: 10 minutes
- Emergency security measures: the Processor is pre-authorised to take emergency security measures — including but not limited to mass session revocation, signing key rotation, and platform status updates — when necessary to prevent or mitigate an ongoing security incident affecting the availability, integrity, or confidentiality of Personal Data. The Processor shall notify affected Controllers within 24 hours of taking such measures, providing the nature of the incident, the measures taken, and the estimated impact on the Controller's end-users.
4.4 Sub-Processors — Art. 28(3)(d) / Art. 28(2)
CRE8EVE engages Sub-Processors under a general authorisation model per Art. 28(2).
Notification: CRE8EVE will notify the Controller by email at least 30 days in advance of any intended changes to Sub-Processors (additions or replacements).
Objection: The Controller has 14 days from notification to object to the change. If the Controller objects, CRE8EVE will make reasonable efforts to provide the service without the objected Sub-Processor or propose an alternative. If no resolution is reached, the Controller may terminate the Service Agreement.
Pass-through: CRE8EVE imposes the same data protection obligations as set out in this DPA on each Sub-Processor, pursuant to Art. 28(4).
The current Sub-Processor list is in Annex 3 and is also available on the public DPA page per EDPB Opinion 22/2024.
4.5 Data Subject Requests — Art. 28(3)(e)
CRE8EVE assists the Controller in responding to Data Subject requests under Art. 15-22 GDPR, taking into account the nature of the processing. Assistance includes providing relevant data exports and technical support for erasure, rectification, and portability requests directed at the Controller.
4.6 DPIA Assistance — Art. 28(3)(f)
CRE8EVE assists the Controller with data protection impact assessments (Art. 35) and prior consultation with supervisory authorities (Art. 36), taking into account the nature of the processing and the information available to CRE8EVE.
4.7 Deletion and Return — Art. 28(3)(g)
Upon termination of the Service Agreement:
- Data return: The Controller may export data via the dashboard export feature (CSV format) or API before account deletion.
- Grace period: A 7-day recovery grace period applies after account deletion. (Note: this will be extended to comply with EU Data Act Art. 25(2)(g) minimum 30-day data retrieval period.)
- Permanent deletion: After the grace period, all Personal Data is permanently deleted within 30 days.
- Backup purge: Backup copies are purged within the 7-day backup rotation cycle.
- Deletion certificate: CRE8EVE provides a deletion certificate scoped honestly to data within CRE8EVE's direct control.
Art. 17(2) sub-processor cascade: Upon erasure, CRE8EVE takes reasonable steps to inform Sub-Processors (in particular Brevo, which may retain IP addresses, user agents, and tenant names in transactional email logs) to erase the Controller's Personal Data.
At the Controller's choice, CRE8EVE shall delete or return all Personal Data and delete existing copies, unless EU or Member State law requires storage.
4.8 Audit — Art. 28(3)(h)
CRE8EVE makes available to the Controller all information necessary to demonstrate compliance with Art. 28 obligations and allows for and contributes to audits, including inspections, conducted by the Controller or an auditor mandated by the Controller.
Two-tier audit model:
- Passive (annual): CRE8EVE provides an annual security certification summary free of charge, including relevant compliance documentation and the compliance audit package (Story 7.3).
- Active (on-request): On-site or remote inspections are available under the following conditions:
- 30 days' advance written notice required.
- Auditor must sign a confidentiality agreement.
- Remote audits using the compliance audit package are preferred.
- On-site audits are available on reasonable terms.
- Controller bears audit costs.
- Maximum 1 audit per year, unless a data breach or security incident has occurred.
- When available, a SOC 2 Type II report may satisfy the active audit requirement.
CRE8EVE shall immediately inform the Controller if, in its opinion, an instruction from the Controller infringes GDPR or other EU/Member State data protection provisions.
5. Independent Controller Processing
CRE8EVE also acts as an Independent Controller for platform security operations, specifically credential stuffing detection (cross-tenant IP correlation). This processing:
- Is conducted under CRE8EVE's own Art. 6(1)(f) legal basis (legitimate interest).
- Is not sub-processing on behalf of the Controller.
- Is separate from the Processor obligations in this DPA.
Full disclosure of this Independent Controller processing, including the three-part legitimate interest test, is provided in the Privacy Policy Sections 4.3 and 8.2.
Enterprise directory synchronisation (SCIM) processing is performed exclusively in the Processor's capacity under Art. 28. No enterprise directory synchronisation data is processed as Independent Controller.
6. Breach Notification
In the event of a Personal Data breach affecting the Controller's data:
- CRE8EVE notifies the Controller without undue delay, and in any event within 24 hours of becoming aware of the breach.
- The notification includes, to the extent available: (a) the nature of the breach, (b) categories and approximate numbers of Data Subjects and records affected, (c) likely consequences, (d) measures taken or proposed to address the breach and mitigate adverse effects.
- CRE8EVE assists the Controller in fulfilling its obligations under Art. 33 (supervisory authority notification within 72 hours) and Art. 34 (data subject communication when high risk exists).
- Enterprise directory synchronisation breach scenarios (applicable when the Controller enables enterprise identity provisioning): service credential compromise, unauthorised provisioning or deprovisioning operations, and discovery of Art. 9 special category data in provisioning storage are classified as breach categories subject to this notification obligation. The Processor maintains internal incident response procedures for service credential compromise scenarios, including automated detection and containment measures.
- DORA Art. 19 assistance (applicable to Controllers subject to the Digital Operational Resilience Act): the Processor shall provide structured incident data (affected user count, timeline, containment measures) to assist the Controller in fulfilling its ICT incident reporting obligations under DORA Art. 19.
7. International Transfers
All primary processing occurs within the European Union (Hetzner, Germany; Brevo, France).
Transfer to Google LLC (USA): Occurs only when the Controller enables Google OAuth federation. This transfer relies on the EU-US Data Privacy Framework (DPF) adequacy decision (Commission Implementing Decision C(2023) 4745) as the primary mechanism.
DPF contingency: 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): Occurs only when the Controller enables GitHub OAuth federation. GitHub, Inc. participates in the EU-US Data Privacy Framework as a subsidiary of Microsoft Corporation. This transfer relies on the EU-US Data Privacy Framework (DPF) adequacy decision (Commission Implementing Decision C(2023) 4745) as the primary mechanism.
Transfer to Microsoft Corporation (USA): Occurs only when the Controller enables Microsoft OAuth or LinkedIn OAuth federation. Microsoft Corporation is a direct participant in the EU-US Data Privacy Framework. This transfer relies on the EU-US Data Privacy Framework (DPF) adequacy decision (Commission Implementing Decision C(2023) 4745) as the primary mechanism, with Standard Contractual Clauses (SCCs) Module 3 (Processor-to-Processor) in place as a contingency.
Transfer to Apple Inc. (USA): Occurs only when the Controller enables Apple Sign In federation. This transfer relies on the EU-US Data Privacy Framework (DPF) adequacy decision (Commission Implementing Decision C(2023) 4745) as the primary mechanism.
Transfer to Discord, Inc. (USA): Occurs only when the Controller enables Discord OAuth federation. This transfer relies on the EU-US Data Privacy Framework (DPF) adequacy decision (Commission Implementing Decision C(2023) 4745) as the primary mechanism, subject to verification of Discord, Inc.'s current DPF participation status. If DPF coverage is not confirmed, Standard Contractual Clauses (SCCs) Module 3 (Processor-to-Processor) apply as the transfer mechanism.
Transfer to Meta Platforms, Inc. (USA): Occurs only when the Controller enables Facebook OAuth federation. Meta Platforms, Inc. participates in the EU-US Data Privacy Framework. This transfer relies on the EU-US Data Privacy Framework (DPF) adequacy decision (Commission Implementing Decision C(2023) 4745) as the primary mechanism, with Standard Contractual Clauses (SCCs) Module 3 (Processor-to-Processor) in place as a contingency.
Transfer to Salesforce, Inc. / Slack Technologies (USA): Occurs only when the Controller enables Slack OAuth federation. Salesforce, Inc. participates in the EU-US Data Privacy Framework. This transfer relies on the EU-US Data Privacy Framework (DPF) adequacy decision (Commission Implementing Decision C(2023) 4745) as the primary mechanism.
Transfer to X Corp. (USA): Occurs only when the Controller enables X (Twitter) OAuth federation. This transfer relies on the EU-US Data Privacy Framework (DPF) adequacy decision (Commission Implementing Decision C(2023) 4745) as the primary mechanism, subject to verification of X Corp.'s current DPF participation status. If DPF coverage is not confirmed, Standard Contractual Clauses (SCCs) Module 3 (Processor-to-Processor) apply as the transfer mechanism.
Transfer to GitLab Inc. (USA): Occurs only when the Controller enables GitLab OAuth federation. GitLab Inc. participates in the EU-US Data Privacy Framework. This transfer relies on the EU-US Data Privacy Framework (DPF) adequacy decision (Commission Implementing Decision C(2023) 4745) as the primary mechanism.
Transfer to Stripe, Inc. (USA + Ireland): Occurs when the Controller activates a paid subscription. Subscription management data is processed by Stripe, Inc. EU payment flows are processed through Stripe Technology Europe, Ltd (Ireland). This transfer relies 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. CRE8EVE shall not transfer Personal Data to a third country or international organisation without the Controller's prior consent and appropriate safeguards.
8. Supplementary Measures
In accordance with post-Schrems II best practices:
- No backdoors: CRE8EVE does not include purposefully-created backdoors, trapdoors, or similar mechanisms in its infrastructure or software.
- Public authority requests: CRE8EVE has procedures in place for handling public authority data access requests, including: (a) assessing legality of requests under EU law, (b) challenging disproportionate or unlawful requests, (c) notifying the Controller of requests unless legally prohibited.
- Transparency: CRE8EVE commits to transparency reporting regarding public authority requests. No such requests have been received to date.
9. Prohibited Data
9.1 Art. 9 Special Category Data
The Controller must not send special category data (Art. 9 GDPR) through the Rakomi platform. This includes data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, trade union membership, genetic data, biometric data for identification, health data, or data concerning sex life or sexual orientation. Rakomi processes authentication data only — no Art. 9 data is expected or permitted.
9.2 AI/ML Prohibition
CRE8EVE will not use Controller's Personal Data for AI/ML model training, fine-tuning, analytics, or improvement. This applies to all data processed under this DPA.
10. Liability
10.1 Processor Liability Scope — Art. 82(2)
CRE8EVE is liable for damage caused by processing only where it has not complied with obligations of GDPR specifically directed to Processors, or where it has acted outside or contrary to the Controller's lawful instructions.
10.2 Exemption — Art. 82(3)
CRE8EVE shall be exempt from liability if it proves that it is not in any way responsible for the event giving rise to the damage.
10.3 Joint-and-Several Liability — Art. 82(4)
Where CRE8EVE and the Controller are involved in the same processing that gives rise to damage, each may be held liable for the entire damage to ensure effective compensation for the Data Subject. This joint-and-several liability is non-waivable.
10.4 Right of Recourse — Art. 82(5)
Where CRE8EVE has paid full compensation for damage, it is entitled to claim back from the Controller that part of the compensation corresponding to the Controller's part of responsibility for the damage. Conversely, where the Controller has paid full compensation, the Controller may claim back from CRE8EVE proportionately.
The parties shall cooperate in good faith on breach-related claims, including mutual notification obligations when either party receives a Data Subject compensation claim.
11. Controller Becoming — Art. 28(10)
If CRE8EVE processes Personal Data in breach of this DPA by determining the purposes and means of processing, CRE8EVE shall be considered a Controller in respect of that processing and shall be subject to the obligations of a Controller under GDPR.
12. Acceptance and Form
This DPA is accepted upon the Controller's creation of a Rakomi account and acceptance of the Service Agreement, constituting written form per Art. 28(9) GDPR (electronic form suffices).
For your tenant-specific DPA with live sub-processor list and processing activities, access the DPA in your dashboard or via the API endpoint GET /v1/compliance/dpa.
A more explicit acceptance mechanism (checkbox-based DPA acceptance in dashboard onboarding) is planned as a future enhancement.
13. Term and Termination
This DPA remains in effect for the duration of the Service Agreement. Upon termination:
- Data deletion/return obligations per Section 4.7 apply.
- EU Data Act switching provisions per the Terms of Service Section 15 apply.
- The 30-day data retrieval period under EU Data Act Art. 25(2)(g) runs concurrently with or after any transitional period.
- Enterprise directory synchronisation service credentials are automatically invalidated upon DPA or subscription termination. Post-termination provisioning operations from the Controller's identity provider are rejected. This prevents data processing after the contractual basis expires.
Provisions that by their nature survive termination (confidentiality, liability, post-termination data handling) shall survive.
14. NIS2 Voluntary Alignment
CRE8EVE is currently below the NIS2 size threshold (Directive (EU) 2022/2555; Polish KSC transposition in force April 2, 2026). NIS2 does not apply directly. However, CRE8EVE voluntarily aligns its security measures with NIS2 Art. 21 requirements as a supply-chain security commitment to Controllers who are themselves NIS2-regulated entities.
Changes to This Agreement
Changes to this DPA will be communicated by email at least 30 days before they take effect. Material changes to processing scope, security measures, or Sub-Processor arrangements require the Controller's acceptance. For the avoidance of doubt, changes to Annex 2 security measures — including the addition of security controls for new processing activities such as enterprise directory synchronisation — constitute material changes subject to this notification requirement.
Previous versions are available upon request to dpo@rakomi.com.
v7 Changelog (2026-04-04): Added enterprise directory synchronisation (SCIM 2.0) as a new processing activity in Section 2 (Enterprise-Push Processing category). Added Controller obligations for enterprise provisioning (Section 3, items 8-14). Added enterprise directory synchronisation breach scenarios to Section 6. Added SCIM-specific security measures to Annex 2. Added service credential invalidation upon termination to Section 13. Clarified Section 5 (Independent Controller) scope exclusion for SCIM. Added Annex 3 statement regarding no additional Sub-Processors for SCIM processing. Expanded Annex 1 processing description with enterprise provisioning data categories. All SCIM-specific additions are conditionally applicable when the Controller enables enterprise identity provisioning.
Annex 1: Processing Description
A. User-Initiated Processing
| Element | Description |
|---|---|
| Subject-matter | Authentication services for the Controller's End-Users |
| Duration | Term of the Service Agreement |
| Nature | Automated processing: storage, retrieval, pseudonymisation, deletion |
| Purpose | User registration, authentication, session management, OAuth authorisation, social login federation, audit logging, webhook delivery, data export, compliance reporting, subscription management, payment processing coordination, tenant interface customisation |
| Personal Data types | Email, password hash (memory-hard algorithm), cryptographic IP hash, cryptographic UA hash, OAuth identifiers (provider, sub, email), session data, auth events, authorisation codes, timestamps, subscription plan identifiers, billing status, payment processor customer identifiers, tenant branding assets (logo images, colour preferences) |
| Data Subject categories | End-users of the Controller's applications who create accounts or authenticate through Rakomi |
| Controller's obligations | Provide lawful basis, privacy policy to End-Users (Art. 13), respond to DSR, manage access |
| Processor's obligations | Process per instructions, security measures, confidentiality, breach notification, audit support, deletion/return |
B. Enterprise-Push Processing (applicable when the Controller enables enterprise identity provisioning)
| Element | Description |
|---|---|
| Subject-matter | Enterprise directory synchronisation for the Controller's employees/members |
| Duration | Term of the Service Agreement and the active enterprise directory synchronisation connection |
| Nature | Automated processing: inbound data receipt from Controller's identity provider, storage, retrieval, synchronisation, deprovisioning, deletion |
| Purpose | Enterprise directory synchronisation (SCIM 2.0 provisioning and deprovisioning), identity lifecycle management, access control through group-to-role mapping, operation audit logging |
| Personal Data types | Email addresses, external identifiers, display names, user profile attributes as configured by the Controller (e.g. department, employee number, cost centre, manager reference), organisational membership data, group memberships, account status, operation audit records, extended attribute storage |
| Data Subject categories | Employees, contractors, or members of the Controller's organisation provisioned via enterprise directory synchronisation |
| Controller's obligations | Provide lawful basis (Art. 6(1)(b) or (f)), Art. 14 transparency to provisioned employees within 30 days, Art. 9 prohibition warrant, service credential rotation, national employment law compliance (Section 3, items 8-14) |
| Processor's obligations | Process per instructions, multi-layer tenant isolation, service credential security, operation audit records (30-day retention), deprovisioning lifecycle management, breach notification, Art. 28(3)(e) technical assistance (first-login transparency notice) |
Annex 2: Security Measures
The following technical and organisational measures are implemented pursuant to Art. 32 GDPR:
Encryption
| Measure | Implementation | Standard Reference |
|---|---|---|
| Encryption at rest (signing keys) | Authenticated encryption | BSI TR-02102-1 (2026-01) |
| Encryption at rest (database) | Disk encryption via hosting infrastructure | — |
| Encryption in transit | TLS encryption | BSI TR-02102-1 (2026-01) |
| JWT signing | Asymmetric cryptographic signing | BSI TR-02102-1, NIST SP 800-131A |
Authentication and Access Control
| Measure | Implementation | Standard Reference |
|---|---|---|
| Password hashing | Industry-standard memory-hard algorithm | NIST SP 800-63B-4 (2025) |
| Session management | Server-side sessions, HTTP-only Secure cookies, SameSite=Lax | OWASP ASVS 4.0 L2 |
| CSRF protection | SameSite cookie attribute + token-based API authentication | OWASP ASVS 4.0 L2 |
| Role-based access control | Owner/Member roles, API key scoped permissions | — |
| OAuth PKCE | S256 mandatory, plain rejected | RFC 7636 |
Data Isolation and Integrity
| Measure | Implementation |
|---|---|
| Multi-tenant isolation | Database-level isolation + application-level checks + automated cross-tenant tests |
| Pseudonymisation | Keyed cryptographic hashing for IP addresses and user agents (EDPB Guidelines 01/2025) |
| Authorization code TTL | 10 minutes functional lifetime |
Network Security
| Measure | Implementation |
|---|---|
| Rate limiting | Per-endpoint, per-IP with progressive delay |
| Credential stuffing detection | Cross-tenant IP correlation (in-memory, 1h window) |
| Webhook SSRF protection | Private IP blocking, HTTPS-only, no redirects, self-referencing blocked |
| Error sanitisation | No stack traces, file paths, internal IPs, or dependency versions in responses |
Operational Security
| Measure | Implementation |
|---|---|
| Secrets management | Dedicated secrets vault — secrets never stored on disk |
| Audit logging | Structured JSON logging |
| Key rotation | Periodic JWT key rotation with zero-downtime overlap |
| Breach notification cascade | 24h to Controllers, 72h to UODO |
| Backup rotation | 7-day cycle |
Enterprise Directory Synchronisation (SCIM) Security (applicable when the Controller enables enterprise identity provisioning)
| Measure | Implementation | Standard Reference |
|---|---|---|
| Service credential security | Long-lived service credential with industry-standard memory-hard hashing and multi-stage validation | NIST SP 800-63B-4, RFC 6819 §4.6.2 |
| Per-connection tenant isolation | Each enterprise directory synchronisation connection is cryptographically scoped to a single tenant | SOC 2 CC6.1 |
| Operation audit records | Immutable append-only records of all provisioning operations | SOC 2 CC6.2, Microsoft Entra provisioning pattern |
| Automated circuit breaker | Mass deactivation safeguard — operations affecting a disproportionate share of provisioned users require manual confirmation | SOC 2 CC7.2 |
| Role escalation safeguard | Privileged role assignment via directory synchronisation requires explicit tenant administrator approval by default | ISO 27001 A.8.2 |
| Configurable per-attribute provisioning controls | Controllers can restrict which identity attributes are accepted from the enterprise identity provider, supporting Art. 25 GDPR privacy-by-design and data minimisation | EDPB Guidelines 4/2019 |
| Service credential activity monitoring | Dashboard alert when service credentials have not been used for more than 24 hours, indicating potential synchronisation failure and orphaned account risk | CSA IAM-07, ISO 27001 A.5.16 |
| Immediate session invalidation on deprovisioning | User deactivation via enterprise directory synchronisation immediately revokes all active sessions and refresh tokens | SOC 2 CC6.3, NIST SP 800-63B §5.1.1 |
| Art. 9 data prohibition | Enterprise directory synchronisation does not process special category data; Controller warrant per Section 3 item 9 | GDPR Art. 9 |
Application Security Benchmark
CRE8EVE aligns with OWASP ASVS 4.0 Level 2 (standard application security verification).
Annex 3: Sub-Processor List
Current as of 2026-04-04. Available publicly per EDPB Opinion 22/2024.
| Sub-Processor | Service | Data Categories | Location | EU/Non-EU | Certifications | DPA |
|---|---|---|---|---|---|---|
| Hetzner Online GmbH | Infrastructure and database hosting | All Personal Data | Germany | EU | ISO 27001, BSI C5 Type 2, EMAS | Hetzner DPA |
| Brevo (Sendinblue SAS) | Transactional email | Email addresses, IP addresses, user agents, tenant names (in email HTML bodies) | France | EU | ISO 27001:2022 | Brevo DPA |
| Google LLC | OAuth federation (conditional) | Email address, subject identifier | USA | Non-EU (DPF + SCCs) | SOC 2, ISO 27001/27017/27018 | Google DPA |
| GitHub, Inc. (Microsoft Corporation subsidiary) | OAuth federation (conditional) | Email address, subject identifier | USA | Non-EU (DPF) | SOC 2 Type II, ISO 27001 | GitHub DPA |
| Microsoft Corporation | OAuth federation (conditional) — Microsoft + LinkedIn | Email address, authentication identifier (object identifier), tenant identifier (forensic metadata) | USA | Non-EU (DPF + SCCs) | ISO 27001, SOC 2 Type II, DPF | Microsoft DPA |
| Apple Inc. | OAuth federation (conditional) | Email address, subject identifier | USA | Non-EU (DPF) | — | Apple Business DPA |
| Discord, Inc. | OAuth federation (conditional) | Email address, subject identifier | USA | Non-EU (DPF, pending verification; SCCs fallback) | — | — |
| Meta Platforms, Inc. | OAuth federation (conditional) | Email address (when provided), subject identifier | USA | Non-EU (DPF + SCCs) | ISO 27001, SOC 2 | Meta DPA |
| Salesforce, Inc. / Slack Technologies | OAuth federation (conditional) | Email address, subject identifier, workspace identifier | USA | Non-EU (DPF) | ISO 27001, SOC 2 Type II | Slack DPA |
| X Corp. | OAuth federation (conditional) | Email address, subject identifier | USA | Non-EU (DPF, pending verification; SCCs fallback) | — | — |
| GitLab Inc. | OAuth federation (conditional) | Email address, subject identifier | USA | Non-EU (DPF) | SOC 2 Type II, ISO 27001 | GitLab DPA |
| Cloudflare, Inc. | Bot protection / CAPTCHA alternative (Turnstile) — public signup form only | IP addresses (server-side token verification; no cookies, no persistent identifiers) | USA | Non-EU (DPF) | ISO 27001:2023, SOC 2 Type II | Cloudflare DPA |
| Stripe, Inc. | Payment processing | Subscription identifiers, payment status, billing metadata | USA + Ireland | Non-EU (DPF + SCCs) | PCI DSS Level 1, SOC 2, ISO 27001 | Stripe DPA |
Enterprise Directory Synchronisation (SCIM): No additional Sub-Processors are engaged for enterprise directory synchronisation processing. Enterprise directory synchronisation is an inbound-only protocol — the Processor receives data from the Controller's identity provider; no data is transmitted to external services.
Hetzner EU data guarantee: "If you have chosen a server location within the EU, your data will only be processed within the EU."
Brevo breach notification: 72 hours (the bottleneck in the sub-processor chain). CRE8EVE's 24h commitment to Controllers is achievable because CRE8EVE detects breaches independently.
Google: Conditional sub-processor — engaged only when the Controller enables Google OAuth federation for their tenant.
Microsoft Corporation: Conditional sub-processor — engaged only when the Controller enables Microsoft OAuth or LinkedIn OAuth federation for their tenant. Microsoft maintains its own sub-processor list available at servicetrust.microsoft.com. Microsoft provides 6 months advance notice of sub-processor changes per Microsoft's Products and Services DPA.
Apple Inc.: Conditional sub-processor — engaged only when the Controller enables Apple Sign In federation for their tenant. Apple participates in the EU-US Data Privacy Framework. Apple may relay a private email address when the user opts to hide their real email.
Discord, Inc.: Conditional sub-processor — engaged only when the Controller enables Discord OAuth federation for their tenant. Discord participates in the EU-US Data Privacy Framework.
Meta Platforms, Inc.: Conditional sub-processor — engaged only when the Controller enables Facebook OAuth federation for their tenant. Meta participates in the EU-US Data Privacy Framework with Standard Contractual Clauses as a supplementary mechanism. Email address availability depends on user permissions granted during the OAuth flow.
Salesforce, Inc. / Slack Technologies: Conditional sub-processor — engaged only when the Controller enables Slack OAuth federation for their tenant. Salesforce participates in the EU-US Data Privacy Framework. Workspace identifier is transmitted as part of the OAuth flow to identify the Slack workspace context.
X Corp.: Conditional sub-processor — engaged only when the Controller enables X (Twitter) OAuth federation for their tenant. X Corp. participates in the EU-US Data Privacy Framework.
GitLab Inc.: Conditional sub-processor — engaged only when the Controller enables GitLab OAuth federation for their tenant. GitLab participates in the EU-US Data Privacy Framework.
Cloudflare: Engaged for all visitors to the public signup form. Only IP addresses are transferred; Turnstile does not use cookies or persistent identifiers. Transfer mechanism: EU-US Data Privacy Framework (DPF).
Stripe: Engaged when the Controller activates a paid subscription. EU payment flows routed through Stripe Technology Europe, Ltd (Ireland). Transfer mechanism: EU-US Data Privacy Framework (DPF) + Standard Contractual Clauses (SCCs) Module 2 (Controller-to-Processor).