Data Usage & Security Policy

Effective Date: 10 August 2026 Service: ETL Console\ Owner: Igor Bobritskii PR Novi Sad Contact: support@etlconsole.com

This Data Usage & Security Policy explains how ETL Console (“Service”, “Platform”, “we”, “us”, “our”) accesses, processes, stores, protects, and deletes customer data, metadata, credentials, rejected rows, logs, and generated outputs.

This Policy is intended to provide practical transparency about how the Platform works. It supplements our Terms of Service, Privacy Policy, and Data Processing Agreement.

1. Core Principle

ETL Console is designed to process customer data according to user-configured connections, mappings, staging jobs, transformations, and target destinations.

The Platform does not own, verify, certify, or control customer source data.

Customer is responsible for:

the legality of connected data sources;\ authorization to access and process such data;\ data quality, accuracy, completeness, and consistency;\ mappings, transformations, filters, and target destinations;\ reviewing and validating Platform outputs before relying on them.

2. Source Systems

ETL Console is designed to use customer-configured source connections primarily for read operations.

By default, ETL Console does not modify customer source systems.

The Platform may read source metadata and source data only as required to perform user-configured operations, such as metadata discovery, table details, staging, previews, analysis, and other supported source operations.

Data write operations performed by normal ETL workflows are directed to customer-configured staging, target, or destination systems.

3. Target and Staging Destinations

Customer selects and configures target, staging, and destination systems.

Depending on user configuration, ETL Console may perform write operations in customer-configured destinations, including:

creating tables;\ inserting rows;\ reloading data;\ truncating or deleting target data;\ recreating target tables;\ writing transformation results;\ recording job status and technical execution context.

Customer is responsible for selecting the correct destination, reviewing configuration, validating mappings, and confirming that the target system may be used for the intended operation.

4. Data Stored in ETL Console

ETL Console may store data required to operate the Platform, including:

user account data;\ organization and workspace data;\ roles and permissions;\ subscription and billing status;\ connection settings;\ encrypted credentials and secrets where supported;\ table metadata;\ schema metadata;\ mapping configurations;\ staging configurations;\ transformation configurations;\ job configurations;\ job logs;\ application logs;\ error logs;\ rejected rows, only if explicitly enabled by the user.

This information is used to provide the Service, maintain user configurations, execute jobs, troubleshoot errors, secure the Platform, and improve usability.

5. Data Not Stored by ETL Console

ETL Console does not store full customer source tables in its internal storage.

ETL Console does not store table contents obtained from Table Details or basic analysis features.

ETL Console does not store generated PDF exports.

ETL Console does not store full payment card details.

Rejected rows are an exception and are described separately below. Rejected rows are stored in ETL Console internal database only when the user explicitly enables rejected row storage.

6. Table Details, Previews, Analysis, and PDF Export

The Platform may allow users to inspect source or target tables and run basic analysis, including:

number of columns;\ column names and data types;\ primary keys;\ nullable information;\ record counts;\ duplicates count;\ unique count;\ unique values;\ minimum and maximum values;\ average or median;\ sample first records.

This information is displayed to authorized users for validation and analysis.

Table contents, sample records, and analysis results from this feature are not stored by us.

If the user exports a PDF report, the PDF is generated on demand for immediate download and is not stored by us.

7. Rejected Rows

Rejected row storage is designed to help users diagnose failed write operations, such as:

duplicate key violations;\ length limit errors;\ invalid formats;\ encoding issues;\ constraint violations;\ target database errors;\ other row-level load failures.

Rejected row storage is disabled by default for each staging or transformation.

Users may enable it in Advanced Settings only with explicit consent.

When enabled, rejected rows are stored in ETL Console internal database and may include:

source row text or failed values;\ error message;\ target schema and target table;\ job ID or log ID;\ staging or transformation ID;\ batch number;\ timestamp;\ user ID.

Rejected rows may contain customer source data, including personal data.

Rejected rows are retained according to the retention period configured by the user. The default retention period is 3 days. The maximum retention period is 30 days.

Rejected rows are automatically deleted after the configured retention period following job completion.

If rejected row storage is disabled, ETL Console may be unable to provide detailed diagnostics for failed rows.

8. Logs and Error Records

ETL Console may store application logs, job logs, technical logs, and error records.

Logs may include:

user ID;\ timestamps;\ page or feature activity;\ connection names;\ mapping, staging, or transformation names;\ job status;\ job duration;\ row counts;\ source and target object names;\ SQL fragments;\ metadata;\ error messages;\ technical stack traces;\ limited source data fragments if included in database error messages or rejected row diagnostics.

Logs are used for security, troubleshooting, debugging, auditability, product improvement, abuse prevention, and dispute resolution.

Application logs related to a deleted user are deleted according to the configured deleted-user log cleanup period. The default period is 14 days.

9. Credentials and Secrets

User Passwords

User passwords are hashed, not encrypted.

Password hashes are not reversible. We do not store user passwords in plain text.

Connection Credentials

Database connection passwords are encrypted at rest where supported by the Platform.

REST API key values and bearer tokens are encrypted where stored in the dedicated encrypted fields.

Managed TLS or wallet upload bytes are encrypted where stored in encrypted storage fields.

Encryption uses a separate application encryption key provided through the ENCRYPTION_KEY environment variable. The application is designed not to start if this key is missing.

Key rotation is not currently implemented.

Important Limitations

Not all sensitive fields are encrypted at field level.

The following may be stored as plain database fields unless otherwise configured or improved in future versions:

billing provider/customer/transaction metadata while the account is active;\ rejected row source text;\ connection URIs;\ REST default headers or query parameters;\ file paths;\ hostnames;\ schemas;\ usernames;\ connection labels;\ notes;\ other configuration metadata.

Customers should not place passwords, tokens, API keys, or other secrets into fields that are not intended for secrets, such as labels, notes, default headers, query parameters, or connection URIs.

If a connection URI contains embedded credentials, those credentials may be stored as part of the URI. Customers should avoid embedding secrets in connection URIs unless expressly supported and protected by the Platform.

10. Transport Security

Hosted SaaS web access uses HTTPS/TLS where applicable.

Database, API, and other external connections may use TLS/SSL where configured by the customer and supported by the relevant source or target system.

Customer is responsible for configuring secure source and target connections where required by their security policies.

11. Access Control

The Platform may include:

user login;\ organization and workspace membership;\ roles and permissions;\ organization administrator controls;\ per-user or per-organization assets.

The Platform does not currently provide, unless separately introduced or agreed:

two-factor authentication; enterprise single sign-on; SCIM provisioning; IP allowlisting.

The Platform provides application and operational logging as described in this Policy and the applicable product documentation, but such logging should not be interpreted as a comprehensive security information and event management or enterprise audit-log service.

12. Administrative and Support Access

For Hosted SaaS, authorized ETL Console personnel may access metadata, logs, configuration records, and rejected rows only when necessary for support, security, troubleshooting, maintenance, or operation of the Service.

Access is limited to authorized persons with a business need.

For on-premise Enterprise deployments, customer data processed inside the customer-controlled environment may remain under customer infrastructure controls, and ETL Console personnel do not have access to such data unless separately agreed or technically enabled by the customer.

13. Backups and Recovery

Backups may be maintained for service continuity, recovery, and operational resilience.

Backup retention follows infrastructure backup cycles and may differ from active database deletion timing.

Data deleted from active systems may remain in backups for a limited period before automatic backup expiration.

14. Analytics

We may use analytics tools, including Google Analytics and Google Tag Manager, where enabled and subject to applicable consent requirements.

We do not send customer source data, rejected rows, connection credentials, table contents, SQL results, or database record values to analytics providers.

Analytics events are intended to be general product usage events, such as page views, button clicks, feature usage, and workflow actions.

15. Account and Asset Deletion

When an individual account or organization workspace is deleted, tenant-owned assets associated with that account or organization are deleted or anonymized according to the applicable deletion process and retention rules.

This includes, where applicable:

connections; mappings; staging configurations; transformation configurations; run or job state; queue history; settings; rejected rows; other tenant-owned operational assets.

User records may be anonymized and retained as limited tombstone records where necessary for system integrity, abuse prevention, trial protection, fraud prevention, or legitimate lifecycle records.

Application logs related to deleted users are deleted after the configured deleted-user grace period. The default grace period is 14 days.

Limited subscription and billing records may be retained where necessary for billing history, tax or accounting obligations, legal compliance, fraud prevention, dispute resolution, payment reconciliation, or other legitimate record-keeping purposes.

Data may remain in backups for a limited period until the applicable backup cycle expires.

A separate Enterprise agreement may define different deletion, retention, or return procedures for Enterprise or on-premise deployments.

16. Security Measures

We apply reasonable technical and organizational measures designed to protect data processed by the Platform.

These measures may include:

password hashing;\ encryption of supported credential fields;\ HTTPS/TLS for hosted access;\ role and permission controls;\ workspace separation;\ restricted administrative access;\ application logging and monitoring;\ retention controls;\ automatic rejected row cleanup;\ deleted-user log cleanup;\ backup and recovery procedures where available.

No method of transmission, storage, or processing is completely secure. We apply reasonable measures, but we cannot guarantee absolute security, uninterrupted operation, or error-free processing.

17. Security Incidents

If we become aware of a security incident or personal data breach affecting Customer data, we will notify affected Customers without undue delay where required by applicable law, our Data Processing Agreement, or other applicable contractual obligations.

The notification will include information reasonably available to us that is relevant to assessing the incident, subject to legal, security, confidentiality, and investigative restrictions.

18. Data Quality and Output Responsibility

ETL Console does not validate, guarantee, or certify customer source data quality, completeness, legality, consistency, or business correctness.

Platform outputs depend on:

customer source data;\ connection settings;\ mappings;\ filters;\ transformations;\ target database behavior;\ user configuration;\ third-party systems.

Customer is solely responsible for reviewing and validating all Platform outputs before relying on them.

To the maximum extent permitted by law, we are not responsible for any losses, damages, business interruption, incorrect decisions, lost profit, lost revenue, missed opportunity, or other consequences resulting from customer use of Platform outputs, data transformations, job results, reports, tables, exports, or integrations.

The Platform should not be used as the sole basis for critical business, financial, legal, operational, or compliance decisions without independent validation.

19. On-Premise Enterprise Deployments

For on-premise Enterprise deployments, customer data processed inside the customer-controlled environment may remain under customer infrastructure controls.

Separate Enterprise documentation or agreements may define deployment-specific terms for:

security controls;\ access;\ updates;\ support;\ diagnostic data;\ license checks;\ infrastructure responsibility;\ backup and recovery;\ incident handling;\ data retention.

Unless separately agreed, we are not responsible for customer-controlled infrastructure, local databases, local backups, internal network security, customer-managed credentials, or customer-administered deployment environments.

20. Changes to This Policy

We may update this Data Usage & Security Policy from time to time.

If changes are material, we will make reasonable efforts to notify users through the Platform, email, or other reasonable means.

Continued use of the Service after the updated Policy becomes effective means you acknowledge the updated Policy.

21. Contact

For questions about data usage, storage, security, or deletion, contact us at:

Igor Bobritskii PR Novi Sad Gajeva 3A 21000 Novi Sad Serbia Email: support@etlconsole.com