Privacy Policy

1. Introduction — Our EU-sovereign approach

Secure Academic Studio's data processing is built on the principle of "data protection by design and by default" set out in Article 25 GDPR. What distinguishes us from many of our competitors is that user data is processed within the territory of the European Union, with European providers:

• Hosting: Hetzner Online GmbH (Germany, Nuremberg)
• E-mail: Tuta (formerly Tutanota, Germany)
• AI processing: Google Cloud Gemini Enterprise Agent Platform (formerly Vertex AI), exclusively in the EU region

Payment for premium features and invoicing are handled by Creem (Armitage Labs OÜ, Estonia), which acts as Merchant of Record (reseller). Creem is established within the European Union, so its data processing is directly subject to the EU GDPR (for the jurisdictional details, see Section 6).

Here we highlight a key fact that lies at the heart of our payment architecture: we ourselves do not transfer any personal data to Creem. The customer enters their payment and billing details directly on Creem's interface, and only a single anonymous transaction identifier is returned into our system — we never receive or store a name, e-mail address, billing address or card details (see Section 4.8). The only genuinely US-based processor in the chain is Google LLC, whose services performed in the EU region are strictly limited at the contractual, technical and architectural levels alike (see Section 6).

A significant portion of our tools runs exclusively in your browser, locally. Even for our AI-based premium tools, we use an architecture designed to minimise the transfer of user data. We do not use tracking, we do not create profiles, and we do not share data with third parties for marketing purposes. Our own server handles the processed user content on a storage-free basis, acting solely as a network intermediary and metadata handler.

2. Identification of the Data Controller

• Form: Sole proprietorship
• Name: Krisztián Haga, sole proprietor
• Registered seat: 1068 Budapest, Király utca 80., Hungary
• Registration number: 62514615
• Tax number: 92181500-1-42
• Contact (general): support@secureacademic.com
• Data protection contact: privacy@secureacademic.com (Tuta e-mail service, Germany)

Under Article 37 GDPR we are not required to appoint a Data Protection Officer (DPO), as our activities do not involve large-scale processing of special categories of data or regular and systematic monitoring. For data protection matters, we are available at the e-mail address above.

3. Principles of Data Processing

We process your data in accordance with the principles set out in Article 5 GDPR: lawfully, fairly and transparently. We request only the data strictly necessary for the specified purposes (data minimisation), and we store it only for as long as necessary to achieve the purpose or as required by legal provisions (storage limitation). We do not use automated decision-making or profiling that would produce legal or similarly significant effects on you.

4. Categories of Data Processed

4.1. Visiting the website (Hosting)

• Data processed: IP address, browser and device metadata (User-Agent), request path, timestamp.
• Purpose: Secure operation of the website, protection against cyberattacks (e.g. DDoS, brute force), technical stability of the service.
• Legal basis: Legitimate interest (Article 6(1)(f) GDPR) — our interest in the secure operation of the service is proportionate to the interests of users.
• Retention: Our web server does not use persistent HTTP logging middleware. Incoming IP addresses are stored solely in memory (RAM) for a short window of no more than 15–60 minutes, for the purpose of technical abuse prevention. Our server never writes IP addresses to a database or to server log files.
• Processor: Hetzner Online GmbH, Industriestrasse 25, 91710 Gunzenhausen, Germany.
• Data center: Nuremberg, Germany.

4.2. Use of local (client-side) tools

A significant portion of our tools (e.g. PDF Merger, PDF Splitter, Image/EXIF Metadata Remover, Document Metadata Cleaner, Secure PDF Redactor) runs entirely in your browser. The files and texts to be processed do not leave your device, are not transmitted to our servers, and are not transmitted to any processor.

• Data processed: None (the data remains on your device).
• Legal basis: Not relevant — there is no data processing.

4.3. Bank Statement Converter and Invoice Converter (Stateless RAM architecture)

The Bank Statement Converter and the Invoice Converter tools share the same underlying architecture and data-handling safeguards. Everything described in this section for the Bank Statement Converter applies identically to the Invoice Converter. Both tools operate in a hybrid manner, with two privacy-enhancing layers:

• Local, user-controlled redaction: We convert the uploaded PDF document into an image locally, in your browser. You then select and redact the fields you consider sensitive (names, account numbers, addresses) yourself. The masks are burned permanently and irreversibly into the image in your browser. The original PDF file NEVER leaves your device.
• Stateless server transfer: The image — carrying whatever redactions you applied — is received by our own server solely in its memory (RAM); the execution context passes through it, and within a fraction of a millisecond it is transmitted to the Google Cloud Gemini Enterprise Agent Platform. The image is never written to our server's physical storage (HDD/SSD). The AI response is transmitted back to the user interface using the same stateless mechanism.
• Before transmission, the user can download in advance (Download Check File) the content to be sent to the AI, so they can check for themselves what data we transmit.

• Data processed: The page image rendered in your browser, carrying the redactions applied by the user.
• Purpose: Converting financial documents (bank statement transactions, invoice line items) into a structured format (Excel) with the help of AI analysis.
• Legal basis: Performance of a contract (Article 6(1)(b) GDPR).
• Recipient of the data transfer: Google Cloud Gemini Enterprise Agent Platform, EU multi-region. (Details in Section 6.)
• Retention: Zero File Retention — the processed data is not stored persistently, either on our own server or on Google Cloud.

4.3.1. Batch Bank Statement Converter and Batch Invoice Converter (Batch processing)

The Batch Bank Statement Converter and the Batch Invoice Converter use the same stateless RAM architecture and server-side safeguards as the tools described above in this section, with one significant difference: because of the high-volume, batch nature of the processing, manual, page-by-page masking is not technically feasible, so this step is omitted.

• As with these tools, the uploaded PDF document is converted into an image locally, in your browser; the original PDF file and its metadata NEVER leave your device.
• However, the user does not select or redact sensitive fields — the image produced in the browser is transmitted to our server in its unredacted form, and from there to the Google Cloud Gemini Enterprise Agent Platform.
• The pre-transmission "Download Check File" verification option is not available for this tool, since there is no redaction step to verify. (The Batch tools have their own "Export ZIP" button, but this is only available AFTER processing is complete, and is used to bundle the resulting Excel files together — it is not equivalent to pre-transmission verification.)

• Data processed: Unredacted image data generated from the uploaded document.
• Purpose: Batch conversion of large volumes of financial documents into a structured format (Excel) with the help of AI analysis.
• Legal basis: Performance of a contract (Article 6(1)(b) GDPR).
• Recipient of the data transfer: Google Cloud Gemini Enterprise Agent Platform, EU multi-region.
• Retention: Zero File Retention — the processed data is not stored persistently, either on our own server or on Google Cloud.

Accepted trade-off: Users who need to verify and remove sensitive data themselves before transmission should use the non-batch (single-file) Bank Statement Converter or Invoice Converter, where this manual redaction and pre-transmission verification option is available.

4.4. Academic Proofreader (Signed URL + temporary EU cloud storage)

For the Proofreader tool, the uploaded .docx file (or a previously saved .sau session file) is read and tokenised entirely in your browser; the file itself is never uploaded. The tokenised text is then transferred directly from your browser to EU-based Google Cloud Storage using a short-lived Signed URL, bypassing our own server. To perform the analysis, our server reads that object into its memory (RAM) — solely in order to split it into chunks and forward them to the Google Cloud Gemini Enterprise Agent Platform — and deletes the input object from Cloud Storage immediately after reading it. The text is never written to our server's physical storage (HDD/SSD) or to its database. The result of the analysis returns through our server's memory in the same way and is placed back into Cloud Storage, from where your browser downloads it directly and then automatically requests its deletion.

Please note that this means: the textual content of the document is transmitted for processing. Before uploading a sensitive, unpublished or confidential document, we recommend that you consider what content you share. If it concerns particularly sensitive material (e.g. unpublished research results), we recommend removing personally identifying parts (name, institution, references) in advance.

• Data processed: The tokenised textual content extracted from the document.
• Purpose: Grammatical and stylistic analysis of academic texts.
• Legal basis: Performance of a contract (Article 6(1)(b) GDPR).
• Recipient of the data transfer: Google Cloud Storage (EU multi-region) for temporary storage during processing, and the Google Cloud Gemini Enterprise Agent Platform (EU multi-region) for the analysis itself.
• Retention: No persistent storage on our own server: the text passes through RAM only and is never written to disk or to a database. In EU-based Google Cloud Storage the text exists solely for the duration of processing — the input object is deleted immediately after our server has read it, and the result object is deleted as soon as your browser has downloaded it. The same five-layer deletion guarantee described in Section 4.5.2 applies here in full — two layers enforced at the storage-infrastructure level and three in application code, including the staged on-demand erasure flow with automatic retries and the Force Delete control described in Section 4.5.3.

4.5. Transcriber application (audio transcription)

The Transcriber is the most complex application in our portfolio and the one designed with the greatest care from a data protection standpoint. It provides text transcription of audio files with the help of artificial intelligence. The architecture ensures that not a single byte of user content is written to the physical storage of our own Hetzner server, either on the input (audio) or the output (transcript) side.

Technical parameters and supported formats:

• Maximum duration: 3 hours (10,800 seconds)
• Maximum file size: 500 MB
• Supported formats: MP3, M4A, OGG, WEBM
• Unsupported formats: WAV and FLAC — we deliberately excluded them because these are uncompressed, or losslessly compressed, formats that can often carry unintended additional metadata (e.g. device identifiers, GPS coordinates) in their audio chunks.

Pre-flight Check (advance notice): Before uploading, a user interface modal shows the expected credit cost, the available balance, information regarding content filtering, and the conditions for credit refunds. In accordance with Article 13 GDPR, this feature provides specific, contextualised information at the very moment immediately before processing begins.

4.5.1. The Transcriber data flow: four phases

A) Input upload (direct, bypassing our server): The audio file uploaded by the user is transferred directly from your browser to the "pending/" folder of Google Cloud Storage using a short-lived GCS Signed URL access code. The original file name is replaced by the frontend with a random identifier before the file leaves the browser.

B) AI processing: The Google Cloud Gemini Multimodal model performs the transcription and returns the text in JSON format, broken down by speaker (diarized).

C) Output handling (Stateless RAM-to-Bucket): The JSON transcript arriving from Gemini returns to our Hetzner server. This is an unavoidable architectural step for three reasons: (1) the API call must be authenticated with our private Service Account key, which cannot be present in the user's browser; (2) our server must see the result of the processing for the purpose of credit accounting and the automatic refund applicable in the event of content filtering; (3) Google Gemini's synchronous API architecturally does not support direct bucket writes to a live user interface.

We solve this step with the Stateless RAM-to-Bucket pattern: the server receives the transcript solely in its memory (RAM) and, within a fraction of a millisecond, uploads it to the "results/" folder of Google Cloud Storage. The transcript is NEVER written to the server's physical storage (HDD/SSD). Only a sterile status update is recorded in the database (status: 'done'); the transcript itself is NOT. The Node.js Garbage Collector immediately overwrites the memory area. The entire transfer takes place under TLS 1.3 encryption.

D) Download and On-Demand Erasure: The user interface downloads the transcript directly from Google Cloud Storage to your device using another 1-hour Signed URL. After a successful download, the frontend automatically calls our On-Demand Erasure endpoint, which immediately destroys the transcript file from GCS. If the download is interrupted, the same file is available again with a new Signed URL, for as long as the file still physically exists under the Bucket Lifecycle Rule described in Section 4.5.2 (Layer 5), whose practical outer bound is close to 24 hours.

4.5.2. Five-layer deletion guarantee

Both the input (audio) and the output (transcript) are subject to the same symmetric five-layer deletion guarantee. Two layers are enforced at the storage-infrastructure level, independently of our application code; three are enforced within the application logic itself. The protocol operates uniformly within the Google Cloud Storage bucket, regardless of folder type.

• Layer 1 — Storage-level configuration: Before any application code runs, Soft Delete and Object Versioning are disabled on the bucket, so that a delete command is final — there is no recoverable, versioned copy of a "deleted" object left behind.
• Layer 2 — Immediate active deletion: When processing is completed (whether successful or in error), the finally block of our code deletes the file from GCS within milliseconds.
• Layer 3 — Client-initiated deletion confirmation flow: Immediately after the transcript is ready, the client requests deletion of the result. If this is not confirmed (e.g. due to a network error), the interface automatically retries, up to three times, against a broader endpoint that sweeps every object still tracked for that job. If all retries fail, the interface informs the user transparently and lets them either retry manually or knowingly proceed, deferring the outstanding deletion to Layers 4 and 5 — the user interface does not silently assume success, but it also does not always withhold completion until deletion is confirmed.
• Layer 4 — Orphan Sweeper: A cron job that runs hourly and, based on the gcs_lifecycle_tracking table, clears out entries older than 3 hours (e.g. files stuck due to server shutdown or a network error); in practice this gives a worst case of up to approximately 4 hours.
• Layer 5 — Bucket Lifecycle Rule: A rule on the Google Cloud Storage bucket, independent of our code, deletes any object older than 1 day. Because Google Cloud Storage evaluates this rule once per day rather than in real time, its practical outer bound is close to 24 hours rather than an exact cut-off — and, only in the unlikely case that Layers 2–4 had all already failed, could in theory extend to just under 48 hours. In normal operation, deletion completes within seconds via Layer 2, and this layer is a last-resort failsafe that is not relied upon in practice.

4.5.3. Force Delete — the self-service implementation of Article 17 GDPR

Force Delete is a recovery control, not a permanently visible button: it appears in the progress window of the Transcriber and of the Academic Proofreader only when the automatic on-demand erasure (Layer 3) could not be confirmed after three attempts. In that situation you are told so explicitly, and you are given the choice yourself: either trigger a further round of deletion attempts with a single click, or knowingly leave the remaining object to the Orphan Sweeper (Layer 4) and the Cloud Storage lifecycle rule (Layer 5).

A single click on Force Delete removes every object still registered for that job from Google Cloud Storage — the uploaded input and the generated result alike — together with the corresponding entries in the gcs_lifecycle_tracking table. In the normal case the button is never shown, because the deletion has already completed on its own. Where it is shown, it is a direct, real-time, user self-service implementation of Article 17 GDPR (the right to erasure): the decision about the residual object stays with you rather than being made silently on your behalf.

4.5.4. Internal database tables (anonymous metadata)

For the operation of the Transcriber, two strictly minimised internal technical database tables exist on our Hetzner server:

a) gcs_lifecycle_tracking — used solely to operate the five-layer deletion guarantee. It contains exactly four fields:

• object_name: Random GCS object identifier (e.g. pending/16843..._a1b2c3d4.mp3 or results/16843..._a1b2c3d4.json). The original name of the file is stored neither here, nor on our servers, nor on Google Cloud Storage.
• job_id: Randomly generated universal identifier (UUID).
• created_at: Unix timestamp (in milliseconds).
• status: Textual status indicator (e.g. uploading, processing).

The table EXPLICITLY does NOT contain: IP address, browser data, device identifier, original file name, e-mail address, name, physical address, or any direct or indirect identifier that would identify you as a natural person. Under normal operation (in 99.9% of processing runs), the entry is automatically deleted when processing is completed (typically within 1–5 minutes). In the event of an exceptional error, the maximum theoretical retention time is ~3–4 hours.

b) transcription_jobs — anonymous accounting and settlement metadata. The table does NOT contain any transcript content (the former result_json field has been physically removed from the database). Its content:

• job_id: The UUID of the transcription job.
• token: The anonymous Credit Pack Code (not linkable to any account, e-mail, or other personally identifying data).
• status: processing, done, or error.
• error_message: A sterilised error code that is one of the following four values: content_blocked, overloaded, codec, or AI Server Communication Error. The detailed error messages arriving from Google are sterilised; we do not write internal Google Cloud logs or file-specific information.
• created_at and completed_at: Timestamps for the purpose of accounting retention.

The transcription_jobs table is retained for the accounting retention period (8 years) pursuant to Section 169(2) of Hungarian Act C of 2000 on Accounting. Since the table contains only anonymous metadata, this long retention does not pose a problem from a data protection standpoint.

4.5.5. Content filtering (content_blocked)

The Google Cloud Gemini Enterprise Agent Platform has built-in safety filters (Safety Settings) that automatically refuse to process unlawful content (in particular content related to the sexual abuse of children) or content that violates Google's terms of service. In such cases, the user receives a clear, sterilised error code, and the credits used for the process are refunded.

Please note that, under the relevant international and national laws, in the event of the detection of such content the providers concerned may have a reporting obligation towards the competent authorities, regardless of the fact that we ourselves operate on a Zero File Retention principle. This reporting obligation applies to every technology provider worldwide and does not stem from Secure Academic Studio's data processing practice.

We ourselves do not have access to the content of the file, and we cannot modify Google's filter settings. We do not provide a manual review option, since the content filter is operated by Google Cloud and the information required for this is technically not available to us. In the event of a suspected false positive, we recommend splitting the recording into shorter segments and retrying.

4.5.6. Notice regarding special categories of data

The Transcriber processes audio content which, by its very nature, may also contain special categories of data (Article 9 GDPR: health status, religious or philosophical beliefs, political opinion, sex life, etc.). Use of the service for such a purpose constitutes the user's explicit consent within the meaning of Article 9(2)(a) GDPR. If the user processes recordings that also contain the voices of third parties, it is your responsibility to ensure that the data subjects are informed and have given their consent.

4.6. UI Preferences (Language and Theme)

• Data processed: Language setting and light/dark mode selection.
• Purpose: A convenient user experience, preservation of settings.
• Legal basis: Legitimate interest (technically necessary data).
• Retention: Locally in your browser (localStorage), until you delete or overwrite it.
• Processor: None — the data does not leave your device.

4.7. Anonymous Feedback

Messages received via the "Anonymous feedback" function available in the footer arrive exclusively on our own server operated at Hetzner. We do not use a third-party form service.

• Data processed: The text of the message; from a technical standpoint, at the time of submission our web server temporarily sees the IP address. Optionally provided e-mail address.
• Handling of the IP address: The incoming IP address is stored by our own server solely in its memory (RAM) for a short window of no more than 15–60 minutes, for the purpose of technical abuse prevention. Our server never writes IP addresses to a database or to server log files.
• Purpose: Bug fixing, product development, responding (if you provided an e-mail).
• Legal basis: Legitimate interest (anonymous feedback), or voluntary consent (Article 6(1)(a) GDPR) when the e-mail address is provided.
• Retention: We retain the text of the messages for a maximum of 30 days, after which they are automatically deleted.
• Processor: None — own infrastructure.

4.8. Purchase and Payment (Creem)

The purchase of premium credits is handled by Creem, which acts as Merchant of Record (reseller). This means that, in legal terms, Creem is the seller towards the customer: Creem processes the payment, it charges and remits the applicable tax (VAT/sales tax), and it issues the invoice to the customer in its own name. During the payment process, the customer is taken to an interface operated by Creem, where they enter their payment details. We do not see or store the card details, the name, the e-mail address or the billing address — these are handled solely by Creem, as an independent controller, in accordance with its own privacy policy.

Data minimisation at the architectural level: For a successful payment, Creem sends a digitally signed (HMAC-SHA256) webhook notification to our server. From this notification, our system reads only two pieces of data: the transaction identifier and the price identifier of the purchased product. The price identifier is translated by a server-side dictionary into the amount of credits to be credited. Apart from these two pieces of data, we do not process or store any field of the message arriving from Creem — we do not link any name, e-mail, address, country or amount to the user.

The "vanishing bridge": When the payment is approved, our system generates a random, anonymous Credit Pack Code, credits the credits to it, and, in a temporary delivery queue, temporarily links the transaction identifier to this anonymous code — solely so that, after a successful purchase, your browser can retrieve the code. As soon as you secure the code (copy it, download it, or return to the applications), your browser sends a signal to our server, which immediately and permanently deletes this delivery queue entry. This permanently severs the link between the transaction identifier and the anonymous credit balance.

After deletion, the transaction identifier is retained solely in a separate register against repeated redemption (replay protection), without any connection to any wallet or credit balance. A Creem transaction identifier in our hands is not, on its own, suitable for identifying you — the person behind it can be identified only by Creem, in its own system.

• Data processed (in our own system): The Creem transaction identifier (temporarily), the amount of credits purchased, and the credit balance associated with the anonymous Credit Pack Code. We do not process a name, e-mail address, billing address or card details.
• Data processed (at Creem): The payment and billing details you provide. These are handled by Creem as an independent controller in accordance with its own privacy policy (https://www.creem.io/privacy).
• Purpose: Performance of a contract (crediting of credits), fraud prevention, and fulfilment of our own accounting obligations.
• Legal basis: Performance of a contract (Article 6(1)(b) GDPR) and legal obligation (Article 6(1)(c) GDPR) with respect to accounting retention.
• Retention: The invoices issued to the customer fall within the responsibility and retention scope of Creem as Merchant of Record. The accounting records relating to our own settlement with Creem are retained for 8 years pursuant to Section 169(2) of Act C of 2000 on Accounting; these records do not contain any customer personal data.
• Controller (payment and billing): Armitage Labs OÜ, Telliskivi Street 57b/1, Tallinn 10412, Estonia. (For jurisdictional questions, see Section 6.)

4.9. Account-free credit system (Credit Pack Code)

Premium features are managed on the basis of anonymous codes (Credit Pack Code), without registration. We do not ask you for an e-mail address, password, or any identifier. The credit balance assigned to the code received at purchase is stored in your browser and in the corresponding database record on our server.

• Data processed: The Credit Pack Code (a random value), the credit balance associated with it, the transaction reference related to the issuance of the code.
• Purpose: Providing the purchased service without an account system.
• Legal basis: Performance of a contract (Article 6(1)(b) GDPR).
• Retention: Until the credit balance associated with the code is used up, or otherwise as permitted by accounting obligations.
• Processor: None — stored on our own server (Hetzner).

4.9.1. Free Daily Trial (IP-based abuse prevention)

To limit each visitor to one free daily trial credit allocation, we compute a one-way SHA-256 hash from your IP address, the current date, and a server-side secret value, and store this hash — never your raw IP address — in our database.

• Data processed: A one-way cryptographic hash derived from your IP address and the current date. Your raw IP address is never stored.
• Purpose: Preventing repeated abuse of the free daily trial from the same origin.
• Legal basis: Legitimate interest (Article 6(1)(f) GDPR) — fraud and abuse prevention.
• Retention: A maximum of 3 days, after which the entry is automatically deleted.
• Reversibility: Because a secret, server-side value is combined with your IP address before hashing, the hash cannot be reversed to recover your IP address, and — since the date changes daily — cannot be used to correlate your activity across different days.
• Processor: None — stored on our own server (Hetzner).

4.10. Customer support communication (Tuta e-mail)

• Data processed: E-mail address, content of the message, communication history.
• Purpose: Answering questions, complaint handling, fulfilling legal obligations.
• Legal basis: Performance of a contract, or legitimate interest.
• Retention: Generally 3 years; in the case of communication relating to a complaint, in accordance with the rules on consumer protection complaint handling.
• Processor: Tuta (Tutao GmbH), Hanover, Germany. Tuta is an end-to-end encrypted, EU-based, GDPR-compliant, privacy-focused e-mail service.

5. Processors and Third Parties

The technical infrastructure of the service (hosting, e-mail and AI processing) operates with European processors. We do not use Google Analytics or Google Fonts (we serve our fonts from our own server), we do not use external CDNs, and we have no third-party advertising or tracking scripts. We display our Mozilla Observatory A+ and SSL Labs A+ ratings in a static image format (WebP) served from our own server, without click-to-load or any other external request.

Our Google Cloud contract includes the official Cloud Data Processing Addendum, which provides contractual safeguards meeting the requirements of Article 28 GDPR and expressly excludes the use of user data for training AI models.

6. Data transfers within and outside the European Union

6.1. Processing within the EU

User data is processed both physically and legally within the European Union in the case of Hetzner (Germany) and Tuta (Germany). With these providers, there is neither a physical data transfer nor a jurisdictional risk outside the EU.

6.2. Google Cloud (Vertex AI and Cloud Storage) and the CLOUD Act issue

With our privacy-conscious readers, we address the following fact with complete honesty: Google LLC is a US-based company, and the parent organisation is in principle subject to the US CLOUD Act, even though the European subsidiary of Google Cloud (Google Cloud EMEA Limited, Ireland) provides the service rendered to us, and the physical data centers are located exclusively within the territory of the EU.

We reduce this residual risk through multi-layered measures:

a) EU multi-region: The configuration of our Google Cloud project uses the "eu" (multiple regions in European Union) region for both Vertex AI / Agent Platform and Cloud Storage. According to Google's contractual commitment, for services configured in the EU region, customer data is processed exclusively within the European Union.

b) Restricted encryption-key options on Cloud Storage: On the Google Cloud Storage bucket used for audio processing, customer-supplied encryption keys (CSEK) are explicitly disabled; only Google-managed or Cloud KMS-managed keys are permitted as encryption options. This removes the operational risk of a lost or mismanaged externally-supplied key, while data at rest is, by default, encrypted using Google Cloud's standard server-side encryption mechanisms.

c) Zero File Retention and the five-layer deletion guarantee: For the Bank Statement Converter and the Invoice Converter (including their Batch variants), the processed data passes through via the Stateless RAM mechanism and is not physically stored. For the Transcriber and the Proofreader, which use temporary Cloud Storage, the five-layer deletion guarantee keeps retention, in normal operation, on the order of seconds; only in the unlikely case that several layers fail in sequence could retention theoretically extend to a period close to, and in a rare worst case just under, 48 hours.

d) No-training clause: The Cloud Data Processing Addendum expressly excludes the training of Google AI models on our user data.

e) Data minimisation: For the Bank Statement Converter, we send only the page image as redacted by the user, never the original PDF. For the Transcriber, the original file name does not even leave the user's device — the frontend replaces it with a random identifier.

f) Legal basis: The data transfer to Google Cloud takes place under the Standard Contractual Clauses (SCC) approved by the European Commission and the EU-US Data Privacy Framework (DPF), which Google provides in its official contractual documentation.

We will make the complete contractual documentation and safeguards available on request at the controller's e-mail address.

6.3. Creem (Estonia) and processing within the EU

Payment for premium features and invoicing are handled by Armitage Labs OÜ, trading as Creem (Estonia), with which we have a contractual relationship. As Creem is a company registered within the European Union, payment and billing data processed by Creem falls directly under the EU GDPR, without requiring any third-country adequacy assessment.

a) Architectural data minimisation — our data transfer footprint stays within the EU: From our standpoint, the most important point is that we ourselves do not transfer any personal data to Creem. The customer enters their payment and billing details directly on Creem's interface, and only a single anonymous transaction identifier is returned into our system (see Section 4.8). Consequently, on the part of our data processing there is no data transfer that would take the user's personal data out of the EU.

b) Creem's independent controller responsibility: The payment and billing data is handled by Creem as an independent controller, in accordance with its own privacy policy (https://www.creem.io/privacy). How Creem handles this data within its own organisation falls within Creem's own scope of responsibility and the scope of its own policy.

7. Data security measures

Pursuant to Article 32 GDPR, we apply the following technical and organisational measures:

• HTTPS / TLS 1.3 encryption across the entire site, including forms, API calls, and Google Cloud Storage uploads and downloads alike. Mozilla Observatory A+ rating and SSL Labs A+ rating, which we display in a static WebP image format served from our own server — with no external request, either by default or upon a user's click.
• Architectural data minimisation: The Bank Statement Converter and the Invoice Converter operate with a Stateless RAM mechanism — the processed content is never written to the physical storage of our Hetzner server. The Transcriber and the Proofreader use a Signed URL architecture: the user's content goes directly from the browser to EU-based Google Cloud Storage, and the result returns to the user the same way; our own server functions only as an authenticating, forwarding and accounting gatekeeper, and never writes the content to its own physical storage.
• Zero Tracking: We do not use Google Analytics, Meta Pixel, or any other third-party tracking tool. There are no third-party fonts (we serve them from our own server), and there are no external CDNs.
• In-memory IP address handling: Our web server stores incoming IP addresses solely in RAM, for a short window, for the purpose of abuse prevention. It does not write them to a database or a log file. Our web server does not use persistent HTTP logging middleware.
• Sterilised error handling: Our code organises the detailed error messages arriving from Google Cloud into four predefined, sterile categories (content_blocked, overloaded, codec, AI Server Communication Error). Internal Google Cloud logs or file-specific parameters do not enter our database.
• Restricted encryption-key options: on the Google Cloud Storage bucket used for audio processing, customer-supplied encryption keys (CSEK) are explicitly disabled, leaving only Google-managed or Cloud KMS-managed keys as permitted encryption options — removing the operational risk of a lost or mismanaged externally-supplied key.
• Providers meeting industry standards: Hetzner with ISO 27001 certification; Creem as Merchant of Record; Google Cloud with SOC 2 Type II, ISO 27001/27017/27018 and many other compliances.
• Restricted internal access to administrative interfaces (Hetzner Cloud Console, Creem Dashboard, Google Cloud Console, Tuta) — strong, unique passwords and two-factor authentication (2FA).
• Incident handling: in the event of a personal data breach, we notify the National Authority for Data Protection and Freedom of Information (NAIH) within 72 hours pursuant to Article 33 GDPR, and, where necessary, the data subjects as well.

No system provides absolute security — our goal is to ensure reasonable and proportionate protection in line with the nature and risks of the data processing.

8. Rights of Data Subjects

Under the GDPR you have the following rights:

• Right to be informed (Articles 13-14 GDPR) — this is provided by this policy.
• Right of access (Article 15): You may request that we provide a copy of the data we process about you.
• Right to rectification (Article 16): You may request the correction of inaccurate or incomplete data.
• Right to erasure / "right to be forgotten" (Article 17): You may request the deletion of your data — unless a legal obligation (e.g. the Accounting Act) requires it to be retained.
• Right to restriction of processing (Article 18).
• Right to data portability (Article 20).
• Right to object (Article 21) to processing based on legitimate interest.
• Right to withdraw consent in the case of processing based on consent.

We do not use automated decision-making or profiling that would produce legal or similarly significant effects on you (Article 22 GDPR).

Self-service deletion mechanism: The Force Delete function of the Transcriber application is a direct, real-time implementation of Article 17 GDPR — with a single click, both the input (audio) and the output (transcript) undergoing processing can be deleted immediately and irreversibly, without having to submit any request.

An important particularity: due to the account-free architecture (Credit Pack Code), we ourselves cannot identify you. For the exercise of certain rights (e.g. access to your credit balance), we therefore need your Credit Pack Code — this is the only key that leads to your credit balance. (In exceptional cases, if the generation of the code is delayed, the Creem transaction identifier may also help you reach support while the purchase is in the delivery queue.)

You may exercise your rights at privacy@secureacademic.com. We respond to requests within a maximum of 1 month pursuant to Article 12 GDPR; in the case of complex or numerous requests, this may be extended by a further 2 months, of which we will notify you.

9. Complaints and Remedies

If you feel that we have violated your data protection rights, please first contact us at the e-mail address above. In addition, you are entitled to lodge a complaint with the Hungarian supervisory authority and to seek a judicial remedy:

National Authority for Data Protection and Freedom of Information (Nemzeti Adatvédelmi és Információszabadság Hatóság, NAIH)

• Address: 1055 Budapest, Falk Miksa utca 9-11.
• Postal address: 1363 Budapest, Pf. 9.
• Telephone: +36 (1) 391-1400
• E-mail: ugyfelszolgalat@naih.hu
• Web: www.naih.hu

Users in an EU Member State may also address their complaint to their own national data protection authority.

10. Processing of minors' data

Our service is not intended for users under the age of 16. We do not knowingly collect data from persons under the age of 16. If we become aware that we are processing the personal data of a child under the age of 16 without parental or guardian consent, we will delete the data concerned without delay. If you wish to contact us on behalf of your child, please write to privacy@secureacademic.com.

11. Cookies and local storage

On Secure Academic Studio's own domain we use exactly zero HTTP cookies. There are no tracking, analytics or third-party advertising cookies, and no "Cookie Consent" banner is required either. We manage user preferences using the localStorage technology built into the browser, the data of which is never automatically attached to network requests, unlike classic HTTP cookies.

For details, see our separate Cookie Policy. The local storage mechanisms we use:

• Language selection — the selected interface language (e.g. hu, en). Stored only in your browser.
• Theme (light/dark mode) — your eye-friendliness preference. Stored only in your browser.
• Credit Pack Code and current balance — the validated code and the balance retrieved for it, so that work can be continued after a browser refresh without registration. Stored only in your browser.
• Cookie-notice dismissal — a single boolean flag remembering that you have seen and dismissed our informational "no tracking cookies" notice, so it is not shown again. Stored only in your browser.

Creem checkout cookies: when the purchase process redirects to Creem's payment interface, Creem may place its own cookies on its own domain. These do not fall within the scope of our data processing — Creem's privacy policy applies to them (https://www.creem.io/privacy). On Secure Academic Studio's own domains there are still zero HTTP cookies.

12. Amendments to this Policy

We update this policy as necessary (e.g. in the event of a change in legislation, the introduction of a new service, or a change of processor). The current version is always available by clicking the "Privacy" link in the footer of the page. In the event of significant changes, we place a separate notice on the site.