This is a convenience translation. Only the German version is legally binding. Read the German version
Legal and transparency
Protective measures.
Last updated:
Deutsche Fassung1. Subject matter and scope
This description names the application measures implemented in Reclyra to protect workspaces, applications and associated data. Upon contractual incorporation, the version designated at that time applies. A later replacement of this page does not automatically change an agreed version.
The technical controls described must be considered together with the specific scope of processing, the service providers used and operational measures. An application function alone proves neither the permissibility of all categories of data nor its appropriateness for every particular use case.
2. Authentication and sessions
Users sign in with individual accounts. The email address must be verified before protected workspace functions can be used. Password registration requires at least twelve characters. The application offers password recovery and revokes existing sessions upon a successful reset.
Sign-ins, registrations, verification and recovery requests are subject to server-side rate limits. Sessions have a limited validity and are renewed with continued use according to the configured refresh rule. Session cookies are protected against being read by browser JavaScript and are transmitted securely on the production HTTPS domain.
The controls described here do not include any promise of multi-factor authentication for product accounts that is already available or can be enforced.
3. Tenant separation and permissions
The application assigns data to a company workspace and checks membership, role and, where applicable, job assignment on the server side. A function hidden in the browser does not replace this check. A platform administration role alone does not authorise access to applications in another workspace.
Sensitive write requests additionally check the origin of the request. Workspace information transmitted by the client is not accepted unchecked as proof of authorisation. Automated tests check, among other things, foreign record identifiers, roles, file access, exports and deletions.
The application's database access uses limited runtime permissions. Public database roles do not receive general access to the application tables. Tenant authorisation lies in the application; row-level security and database permissions are supplementary layers of protection and not an independent guarantee of user-related tenant separation of the backend access.
4. Private application files and upload limits
CVs are stored in private file storage. PDF and DOCX files of up to 3 MiB are permitted for the initial upload. The application checks size, type information and basic format characteristics; DOCX archives are additionally limited in structure, size and impermissible entries. Storage paths are generated and validated by the application.
Downloading a CV requires a current permission check. A short-lived download authorisation is then issued; its current validity is 60 seconds. Authorisations already transmitted and downloaded copies must be protected separately.
Separate size and quantity limits apply to documents submitted later. Direct upload authorisations are purpose-bound and time-limited. The document status distinguishes files not yet released from files released for use. This quarantine status and the format check are not proof of an actual malware scan.
5. Transmission and secrets
The production web application is provided via HTTPS. Credentials for the database, private storage and external services are used in server-side components. These secrets are not made available as public browser configuration.
Where a calendar connection is available, stored OAuth access secrets are encrypted and assigned to the respective workspace, member and provider. Establishing the connection checks a limited callback state; missing protection configuration prevents this connection path.
The application measures do not replace a separate review of the encryption, access and backup measures of the respective infrastructure and communication services.
6. Logging and traceability
Functional changes, exports and downloads are logged with the assignments and timestamps required for the operation. Deletion jobs and their completion receive limited records without application content. The runtime database role can append to and read the audit history provided for this purpose, but cannot subsequently change or delete it.
Internal mentions store the assignment to a note and to an authorised recipient as well as the time of creation and reading. They do not copy the note text into an additional message and do not trigger an external email. Access rights are taken into account again on retrieval.
This functional logging is not a complete record of every administrative infrastructure access. Retention of and access to further provider and security logs must be determined separately.
7. Export and confirmed deletion
Owners and administrators of a workspace can export structured applicant data. For the deletion of an individual application, the current authorisation, application version, deletion preview and express confirmation are checked. The associated application data, notes and mentions are removed; other applications by the same person are retained.
Private files are removed after the database deletion via a persistent job. Errors leave the job visible and retryable. Where direct upload authorisations were issued beforehand, a separate final clean-up follows after their validity period. Relevant concurrent write operations are coordinated with the deletion process.
Active analysis processing and external calendar events whose cancellation has not yet been confirmed can block a deletion. Such blockers are checked before execution. Content already issued, emails delivered and provider backups are not automatically recalled by the local deletion of an application.
Retention periods are not set by default. The configurable period generates a preview from the documented rejection; it does not trigger automatic deletion of applications. An exception from the preview does not prevent an expressly confirmed manual deletion and is not a comprehensive legal hold.
8. Measures for the AI analysis
The analysis path described uses extracted document text and job-related criteria. Certain recognised contact and personal details are replaced before transmission. This does not achieve complete anonymisation.
The application requires structured results with evidence and source references. Technical checks verify that quotations used occur in the document. Missing clear information is treated as unclear; a technical source comparison does not prove an interpretation free of errors in content.
Model, prompt and criteria versions as well as human criteria corrections are stored in a traceable manner. The analysis does not trigger any automatic hiring or rejection decision. A final human decision does not replace the necessary review of the legal basis and of possibly discriminatory criteria.
A distinction must be made between the model developer, the gateway and the inference provider actually executing the request. The existing model configuration alone confirms neither a complete list of recipients nor EU-only processing, absence of retention or a completed provider approval process.
9. Development and technical testing
Source code and database changes are versioned. Development and automated tests use separate local databases and synthetic test data. The tests cover, among other things, authentication, workspace and job permissions, upload limits, data export, confirmed deletion and retrying after errors.
Local tests and a successful build must be distinguished from evidence of production operation. Provider configuration, external delivery, scheduled clean-up runs and restoration procedures need their own operational evidence. This description does not promise an independent certification or a regularly conducted external penetration test.
10. Operational coordination and evidence
CVs and submitted additional documents are scanned by ClamAV in an isolated, short-lived Vercel Sandbox in Frankfurt before they are released. During the file scan its network access is blocked; no snapshots of the application files are created. Hash and version checks bind download and AI processing to the scanned file content. Technical errors, pending scans and rejected files remain blocked. Complete detection of all malware is not guaranteed.
The application measures described in this version do not include guaranteed recovery times, backup rotations or 24/7 standby. Such services may only be relied upon on the basis of specifically agreed and evidenced operational measures.
If the specific engagement requires additional protective measures, these must be agreed and implemented, including responsibilities and evidence, before this processing begins. A general description of technical and organisational measures does not replace the risk-based assessment required under Art. 32 GDPR.
Requests regarding measures and engagement-related evidence can be sent to privacy@reclyra.app. Confidential reports of security problems are received at security@reclyra.app. For the initial report, the function concerned, the observation, the time and a means of contact are sufficient; login credentials or complete application documents of other persons should not be included.