1. Application Overview

Hozina Clip (also referenced in technical documentation as Hozina Clipboard & Saved Text Dock) is a Windows desktop utility for managing clipboard history and reusable text templates. Its documented architecture processes all clipboard payloads locally on the host computer where the application runs. This notice details what the software captures, how local records are stored and encrypted, and the operational risks users must manage. This disclosure reflects the documented product architecture and applies to the verified release binary installed by the user.

2. Local Clipboard Processing

While clipboard monitoring is enabled, Hozina Clip listens to Windows clipboard-change notifications and automatically processes clipboard data formats exposed by the operating system, including:

• Plain text and multiline text strings.
• Rich Text Format (RTF) and HTML clipboard fragments.
• Bitmap images and screenshots copied to the system clipboard.
• Lists of copied local or network file paths.

In addition to the copied payload, the application records the executable name of the source Windows process associated with the clipboard event as described in the product documentation. The application is not architected to record external application window titles or surrounding uncopied keystrokes. Because capture occurs automatically upon any Windows copy event while monitoring is active, copying sensitive personal data, corporate secrets, authentication codes, bearer tokens, passwords, or medical records will cause that material to be ingested into the local database unless capture is paused or the source application is excluded.

3. Saved Templates and Settings Stored Locally

The documented version of Hozina Clip stores the following categories of data on the local storage drive:

• Captured clipboard text, rich HTML/RTF content, bitmap images, and file-path lists.
• User-created text templates, reusable blocks, organizational tags, folders, hotkey aliases, and dynamic placeholder rules.
• Source process executable names linked to historical clipboard events.
• User configuration preferences, including visual theme, global hotkeys, retention quotas, and process exclusion lists.

By default, these records are stored within %APPDATA%\ProClipboardDock\, specifically inside the clipboard_v1.db SQLite database and associated local storage files (exact directory paths may vary by release version). These files exist solely to provide local application functionality and are never transmitted to Hozina Technologies under the documented zero-network architecture.

4. Network Activity and Third-Party Services

The documented build of Hozina Clip is engineered with zero outbound network clients: it contains no analytics beacons, no telemetry SDKs, no automated crash-reporting uploaders, no cloud synchronization daemons, and no cloud artificial intelligence (AI) API integrations. Neither clipboard history nor saved templates are uploaded to Hozina Technologies or any third-party cloud server.

This representation applies strictly to the verified local-only release build. Should any future version introduce automated update checks, cloud synchronization, AI text processing, or telemetry, a revised privacy notice will be distributed prior to release. Users should always verify the notice accompanying their specific installed version.

5. DPAPI Encryption and Local Security Limitations

The documented implementation encrypts stored clipboard payloads, previews, and template bodies at rest using the Windows Data Protection API (DPAPI). While DPAPI binds cryptographic decryption to the corresponding Windows user security context, no local storage mechanism can guarantee absolute immunity against all endpoint threats. Data confidentiality remains entirely dependent on the integrity of the Windows operating system, user-account password strength, malware or spyware infection status, local administrator access, system backup configurations, and physical device security. This policy must never be interpreted as a warranty that local data cannot be read by another process or person operating with sufficient privileges on the same machine.

6. Heuristic Secret Detection and Excluded Applications

Hozina Clip provides a configurable process blacklist (excluded applications) and optional offline regular-expression (regex) pattern matching designed to identify certain secret-like strings—such as specific API access-token formats, private cryptographic key headers, database connection strings, and bearer tokens. When enabled and matched, the application discards the matching string rather than committing it to persistent storage.

Limitation of Liability for Secret Filtering: These detection mechanisms are purely heuristic and configuration-dependent. They can fail to recognize custom, novel, obfuscated, base64-encoded, or altered credentials, and may also trigger false positives on ordinary text. They are a convenience feature and are strictly not a substitute for a dedicated password manager, enterprise Data Loss Prevention (DLP) system, endpoint detection and response (EDR) suite, or corporate secrets-governance policy. Users assume full responsibility for testing and configuring exclusions before relying on them.

7. Retention Quotas, Database Purge, and Plaintext JSON Exports

Users can configure maximum history item quotas and retention age limits within the application settings, enabling automatic pruning of older, unpinned clipboard records. Users may also pause capture, clear unpinned items, or execute a complete database purge via in-app controls.

Plaintext Export Warning: If a user utilizes the export feature to save clipboard history or templates to a JSON file, the resulting external file is not encrypted by Windows DPAPI. An exported JSON file contains raw, human-readable plaintext of clipboard entries, templates, and file paths. The user alone selects the destination directory and assumes total legal and operational responsibility for encrypting, securing, and purging exported JSON files from shared drives, cloud-synced folders, and external backups.

Purging the in-app database or uninstalling Hozina Clip does not erase previously exported JSON files, Windows pagefile/hibernation artifacts, shadow copies, or external system backups.

8. Legal Roles, User Responsibilities, and Contact

Because Hozina Clip processes all clipboard records locally on the user's hardware and transmits no clipboard data to Hozina Technologies, Hozina Technologies never receives, accesses, or controls those local records during normal software operation. To use the software safely, the user must:

• Assess whether persistent clipboard history is appropriate for the sensitivity of the environment and data handled on the workstation.
• Proactively pause clipboard monitoring before copying passwords, cryptographic keys, banking credentials, or regulated personal data.
• Configure application exclusions for password managers, terminal emulators, and banking browsers without treating heuristic filters as infallible.
• Maintain strict Windows account security, endpoint anti-malware protection, and encrypted full-disk storage (such as BitLocker).
• Inspect and secure any exported JSON files prior to storage or transfer, and never use the utility to capture material the user lacks legal authority to retain.

Material changes to Hozina Clip's data handling will be published in updated release documentation and this notice. For privacy questions, contact Hozina Technologies via the website Contact Us page and specify Hozina Clip alongside the installed version number.

1. Application Overview

Hozina Clean (also referenced in project documentation as Duplicate Cleaner Pro and Duplicate + Large File Cleaner Pro) is a Windows desktop utility engineered to identify exact duplicate files and locate large files across user-selected directories for storage review. Directory scanning, cryptographic hashing, byte comparison, media preview rendering, and scan-result aggregation are executed entirely as local operations on the host computer.

2. Information Processed Locally

To scan directories designated by the user, Hozina Clean reads and processes the following local filesystem attributes:

• File names, file extensions, full directory paths, byte sizes, and file creation or modification timestamps.
• Raw file bytes read into local memory to compute partial and full SHA-256 cryptographic fingerprints and verify exact content matches.
• Filesystem identity metadata required to detect NTFS hardlinks and prevent inaccurate storage-reclamation estimates.
• Image and media file streams required to render local visual previews within the user interface.
• Selected scan target root paths, scan summary statistics, total file counts, and calculated estimates of potentially reclaimable disk space.
• Application configuration settings, including interface theme, minimum file-size thresholds, and directory exclusion rules.

Because directory trees and file names frequently reflect sensitive personal or corporate structures even when no file contents leave the machine, users must only scan storage volumes and folders they are legally authorized to inspect.

3. Local SQLite Database and Retention

The documented application architecture maintains a local SQLite database located at %APPDATA%\DuplicateCleaner Pro\cleaner.db (exact directory paths or table schemas may vary across versions). This local database stores a persistent hash cache mapping file paths, byte sizes, modification timestamps, and file identifiers to SHA-256 digests, alongside historical scan logs, root target paths, file counts, storage metrics, and user preferences.

The user interface provides built-in controls to purge the SHA-256 hash cache and clear scan history records. Local database records persist on the user's storage drive until cleared via those in-app controls, removed during application uninstallation, or manually deleted by the user. Uninstalling the software does not automatically delete user-exported CSV/JSON reports, system backups, or files stored outside the application data directory.

4. Network, Telemetry, and Cloud Services

The documented build of Hozina Clean operates on a strictly local-first architecture with zero outbound network requests, no telemetry beacons, no usage analytics, no cloud synchronization, and no remote file uploads. Under this design, scanned file names, directory paths, SHA-256 hashes, file contents, and scan results are never transmitted to Hozina Technologies.

If any future version introduces update checks, online licence activation, crash reporting, or cloud features, this privacy notice will be updated prior to release to specify the endpoints, data categories, and user controls.

5. File Removal Mechanics and Limitation of Liability

Hozina Clean allows users to select duplicate or large files for removal using standard Windows file-operation mechanisms. Although the documented workflow invokes Windows Recycle Bin functionality by default, actual recoverability depends entirely on Windows operating-system behavior, filesystem type, drive letter or mount point, access permissions, network share protocols (SMB/CIFS), removable USB/external media settings, and Recycle Bin size quotas.

No Guarantee of Recoverability: Users must never assume that every file removed through the utility can be restored from the Recycle Bin. Before initiating any scan or file-deletion action, the user is solely responsible for maintaining complete, verified backups of critical data, manually reviewing full directory paths, and confirming that removing a duplicate file will not break application dependencies, symbolic links, or project builds. This privacy notice supplements and does not replace the operational disclaimers in the End User Licence Agreement (EULA).

6. Exported CSV and JSON Scan Reports

Users may export scan results to CSV or JSON files. Exported reports contain file names, complete directory paths, byte sizes, modification dates, duplicate grouping identifiers, scan root locations, and storage estimates. Full directory paths routinely expose Windows account usernames, employer names, client identities, legal matter titles, or confidential project hierarchies.

Exported reports are written strictly to the local path chosen by the user and are never automatically transmitted to Hozina Technologies. However, if a user subsequently attaches an exported CSV or JSON report to a technical support ticket or email sent to Hozina Technologies, that report becomes voluntarily submitted support information governed by the General Website Privacy Policy.

7. Accuracy Limitations, Device Security, and Contact

Duplicate detection, large-file listings, preview generation, and space-reclamation calculations depend on filesystem accessibility, OS permissions, NTFS hardlink structures, and allocation unit sizes; estimated space savings may differ from actual disk space freed. The tool is not a backup utility or a forensic archival system.

Protection of the local SQLite hash cache and scan history depends on the user's Windows account security, anti-malware controls, and physical device access. Hozina Clean is a general-purpose utility not directed at children. For privacy enquiries, use the Contact Us page on the Hozina Technologies website and reference Hozina Clean and the installed version.

1. Application Overview

Hozina Explorer is an advanced Windows file-management utility. Its documented architecture provides local directory browsing, file previews, batch renaming and file operations, saved workspaces, custom tags, a rolling activity timeline, visual disk-space analysis, an integrated command-line terminal, optional Windows Explorer shell association, network-drive mounting, and an embedded web viewer. This notice clearly separates data processed locally on the workstation from external network communications initiated when a user browses third-party URLs, mounts remote shares, or executes terminal commands.

2. Local Files and Filesystem Metadata

When a user navigates or performs actions on drives, directories, and files, Hozina Explorer accesses the selected locations and processes associated filesystem attributes, including file names, directory paths, byte sizes, file streams required for content previews or comparisons, timestamps, cryptographic hashes, directory trees, and OS metadata required to execute file operations. User-initiated actions can move, rename, copy, compress, extract, or permanently delete files. Hozina Explorer does not transmit these local files or directory structures to Hozina Technologies to execute its core file-management functions. Users must operate the software strictly on files and systems they hold authorization to access.

3. Local Preferences, Workspaces, and Rolling Activity Timeline

To support productivity features, the documented build stores the following operational records locally on the user's device:

• Application configuration preferences and folder-specific layout or sorting views.
• Saved Workspaces, tab collections, and items pinned to the Workspace Shelf.
• A local activity timeline recording recently visited directories and previewed files (documented as a rolling history capped at up to 150 items).
• User-defined file tags, custom folder color assignments, and undo/redo action stacks for supported file operations.
• A local disk-analysis index and cache used to render storage utilization charts.
• In-memory or local-session command history for the integrated terminal as implemented by the installed build.

These records are persisted by default within %APPDATA%\ModernExplorer\storage\ and associated application localStorage containers (exact paths may vary by release). Because recent-folder timelines, workspaces, and tags can reveal work habits and confidential directory names to anyone with access to the Windows user profile, users should utilize in-app clearing controls where appropriate and secure their Windows user account.

4. Network Activity, Embedded Web Viewer, and Integrated Terminal

Core file-management operations in Hozina Explorer are local-first: file names, folder hierarchies, file contents, terminal session logs, and file-manager actions are never uploaded to Hozina Technologies servers. However, users must account for two user-driven network pathways:

• Embedded Web Viewer: When a user loads an external URL inside the embedded web viewer, the host device establishes a direct network connection with that third-party web server and its sub-resources. Those external websites automatically receive the user's IP address, browser/webview user-agent, and standard HTTP headers, and may set cookies, run tracking scripts, or process form submissions under their own independent privacy notices. Hozina Technologies exercises no control over, and assumes no liability for, third-party websites accessed via the web viewer.
• Integrated Terminal: The built-in terminal passes user-typed commands directly to the underlying Windows operating-system command processor (such as PowerShell or Command Prompt). Commands executed by the user—or scripts invoked through the terminal—can read, overwrite, delete, or exfiltrate local files and communicate across local or public networks. Such command outcomes are governed entirely by the user's actions, OS permissions, and invoked binaries, and do not constitute data collection by Hozina Technologies.

5. Windows Shell Integration and Network Drives

Windows Registry Shell Association: If a user enables the option to register Hozina Explorer as the handler for Windows folder or drive-opening actions, the application modifies user-level Windows Registry keys to route those shell invocations to Hozina Explorer. While the software includes a built-in restore function to revert to default Windows Explorer associations, users must review confirmation prompts carefully and maintain system restore points prior to altering shell registrations.

Network Drive Mounting: When a user connects a remote network drive or SMB share through the utility, Windows networking APIs transmit connection parameters and authentication credentials directly to the target network server or domain controller in accordance with the user's OS configuration. Hozina Technologies never receives or intercepts those network credentials; the remote server administrator or enterprise network owner processes authentication logs under its own governance policies.

6. Zero Telemetry Representation, Data Deletion, and Contact

The documented release build embeds no telemetry SDK, no analytics beacon, no automated crash-reporting daemon, and no background cloud upload of local files. To completely remove local application records, users may use in-app history clearing controls or close Hozina Explorer and delete the ModernExplorer directory inside %APPDATA% (which removes saved workspaces, tags, the 150-item activity timeline, and disk-analysis caches, but does not remove files moved outside the app folder, OS artifacts, or data held by external websites visited in the web viewer).

Users remain responsible for maintaining independent backups before executing batch file operations or terminal commands. For privacy enquiries, contact Hozina Technologies via the website Contact Us page and reference Hozina Explorer and the installed version.

1. Application Overview

Hozina Search is a local desktop search utility for Windows that indexes file names, directory paths, filesystem metadata, and—when deep content indexing is enabled by the user—full text extracted from supported office documents, PDFs, emails, and source-code files. It provides both a floating desktop search bar and an optional web-browser interface served locally on the same computer. This privacy notice details local indexing storage, global shortcut behavior, loopback server boundaries, and the application's documented outbound network requests.

2. Information Indexed and Stored Locally

Depending on the scan directories selected and indexing depth configured by the user, Hozina Search processes and persists the following data locally:

• File names, full directory paths, byte sizes, creation and modification timestamps, file type classifications, and selected filesystem attributes.
• Full text extracted from supported PDF documents, Microsoft Office and OpenDocument files, plain text, Markdown, CSV spreadsheets, email files, and source-code files when deep content indexing is active.
• Inverted search indexes, tokenized vocabulary records, text preview fragments used to render search results, and search cache structures.
• Installed application names and executable paths used to locate and launch local programs.
• User indexing preferences, excluded folder lists, scan state checkpoints, and local configuration settings.

The documented architecture stores these records inside a local SQLite index located at an application data directory associated with the Windows user Security Identifier (SID), or a fallback directory under %LOCALAPPDATA%\HozinaSearch\Data\ (exact paths may vary by packaged build). Because an extracted full-text search index consolidates sensitive text from across the user's hard drive into a single SQLite database, users must select indexed folders judiciously, configure folder exclusions for highly confidential directories, and protect their Windows user account.

3. Global Keyboard Shortcut Behavior

The documented global activation shortcut detects consecutive presses of the Left or Right Control (Ctrl) key to summon or focus the Hozina Search bar. Under the documented architecture, the keyboard hook immediately discards all non-Control key events during this detection routine and does not log, store, or transmit typed search queries, passwords, or general keystrokes across other applications. It is strictly not designed as a keylogger.

4. Localhost Browser Search Interface (Loopback Boundary)

Hozina Search includes an optional browser-accessible search interface powered by a local HTTP service bound strictly to the IPv4 loopback address 127.0.0.1 (commonly listening on port 42800, or a dynamically assigned local port). Search requests submitted through this browser interface are processed locally on the host machine, and the HTTP service is not designed to listen on external LAN or public network interfaces.

Security Boundary Disclaimer: Binding to 127.0.0.1 is an architectural boundary rather than an absolute security guarantee. Other processes running on the same computer, malicious browser extensions, local cross-site request vulnerabilities, malware, or manual changes to system networking/proxy rules could potentially interact with a localhost port. Users must maintain strict endpoint security and keep the application updated.

5. Documented Outbound Network Connections

Hozina Search is not a zero-network binary. Its documented architecture performs two specific categories of external network requests:

5.1 Currency Exchange Rate Refresh (open.er-api.com)

To support the built-in smart calculator's currency conversion feature, the application checks a local rate cache and periodically initiates an outbound HTTPS GET request (documented as approximately once every 12 hours) to https://open.er-api.com/v6/latest/USD to fetch updated foreign exchange rates. This request transmits the application's user-agent string. As with any standard HTTPS connection, the external exchange-rate provider receives standard network connection metadata, including the user's public IP address, request timestamp, and user-agent header. Under the documented design, no search queries, file names, file contents, indexed document text, or persistent machine identifiers are transmitted in this request. If the external API is unreachable, the calculator falls back to cached or baseline exchange rates.

5.2 Software Update Manifest and SHA-256 Verification

When the software updater is invoked, the application contacts the publisher's update endpoint or Content Delivery Network (CDN) to retrieve a remote version manifest and validate the cryptographic SHA-256 hash of any downloaded installer package. The CDN or update host receives standard HTTP connection metadata (requesting IP address, timestamp, requested resource URI, and user-agent). This update check operates entirely independently of the local search index and never transmits search queries or indexed document text.

External API endpoints, polling intervals, and updater behavior may be modified in future software releases, and this notice will be updated accordingly.

6. What Is Never Transmitted by the Search Workflow

Under the documented architecture, user search queries, extracted document text, document bodies, file names, directory paths, and SQLite index contents are processed exclusively on the local computer and are never transmitted to Hozina Technologies servers or to the currency exchange-rate API. However, because of the currency-rate and updater connections detailed in Section 5, no representation in Hozina documentation should be construed as a claim that the application never communicates over the internet.

7. Index Retention, Purging, Limitations, and Contact

Users can add or remove indexed directories and rebuild or completely purge the local SQLite search index via the application Settings menu. An integrated filesystem deletion watcher automatically purges corresponding index entries when it detects that an indexed local file has been deleted. Users may also delete the application data directory during uninstallation. Purging the search index deletes records from the SQLite database without deleting the original source files on disk.

Indexing Limitations: Due to OS file locks, permission restrictions, folder exclusions, password-protected/encrypted archives, file corruption, file-size caps, or concurrent edits during scanning, certain files or text passages may be skipped or only partially indexed. Hozina Search is a convenience productivity tool and must never be relied upon as a guaranteed completeness archive, compliance vault, or formal legal-discovery (e-discovery) system. Always verify critical records directly against the original source directories. For privacy questions, contact Hozina Technologies via the website Contact Us page and specify Hozina Search and the installed version.

1. Applicability and Legal Role Allocation

This Service Privacy Notice applies whenever Hozina Technologies scopes, designs, develops, tests, deploys, troubleshoots, or maintains a website or web application for a B2B customer. It supplements the General Hozina Technologies Privacy Policy and the governing Statement of Work (SOW) or Master Services Agreement (MSA).

In a website development project, the customer (as website owner) determines why and how its website collects personal data from end-users and visitors. Where Hozina Technologies encounters or processes such visitor personal data strictly to build, host, debug, or maintain the website on the customer's documented instructions, Hozina Technologies acts as a Data Processor or service provider. Hozina Technologies acts separately as an independent Data Fiduciary / Controller solely with respect to its own client contact records, commercial contracts, billing ledgers, and project correspondence. Formal processor obligations must be confirmed in the written project agreement and, where required by law, a Data Processing Agreement (DPA).

2. Categories of Information Encountered During Delivery

Depending on the contracted technical stack and access granted by the customer, Hozina Technologies may encounter or process:

• The customer's corporate contact coordinates, stakeholder details, and functional project specifications.
• Website copy, media assets, web form structures, contact submissions, user account tables, or Content Management System (CMS) entries supplied by the customer for implementation, content migration, or staging verification.
• End-user visitor traffic data and web server or application error logs where hosting administration, deployment pipelines, analytics setup, or production debugging is included in the contracted deliverables.
• Domain registrar, DNS, cloud hosting, CMS administration, deployment pipeline, or third-party API configuration parameters required to perform the contracted engineering work.
• Test records, stack traces, error screenshots, and diagnostic logs exchanged during technical support.

Hozina Technologies does not require access to live production personal data merely to code or style a website. Customers must provide synthetic, dummy, or anonymized test records wherever practicable.

3. Permitted Purposes and Client Instructions

Hozina Technologies processes project-related information solely to gather technical requirements, develop the contracted web application, verify functional behavior, migrate approved CMS content, configure contracted hosting or third-party integrations, diagnose bugs, deploy authorized updates, and provide contracted maintenance. When acting as a Data Processor, Hozina Technologies processes customer personal data strictly in accordance with documented customer instructions and the governing contract, subject to overriding statutory obligations.

Hozina Technologies never uses a customer's production visitor database for independent marketing, profiling, or artificial intelligence model training.

4. Credentials, Access Governance, and Security Limitations

Website engineering frequently requires temporary developer access to web hosting control panels, Git repositories, CMS administrator dashboards, DNS zones, relational databases, or external API accounts. Hozina Technologies recommends—and customers should enforce—dedicated named developer accounts, least-privilege role permissions, multi-factor authentication (MFA), encrypted credential-sharing channels, and immediate revocation or rotation of temporary credentials upon project handover.

Customers must never transmit plaintext passwords, secret API tokens, or private SSH/TLS keys through public web forms or unencrypted project notes. The customer remains responsible for retaining master ownership of all domains, cloud accounts, and billing profiles belonging to its business.

No Absolute Security Guarantee: While Hozina Technologies applies reasonable engineering practices appropriate to the contracted budget and stack, it cannot and does not warrant that any website, hosting server, third-party CMS plugin, open-source dependency, or external API will be immune from vulnerabilities, defacement, DDoS attacks, or unauthorized intrusion. Ongoing website security depends on the customer's hosting tier, patching discipline, plugin maintenance, and operational vigilance after handover.

5. Hosting, Cookies, Analytics, and Third-Party Providers

Modern websites routinely integrate third-party infrastructure and scripts—including cloud hosting, transactional email (SMTP/API), payment gateways, web analytics, CAPTCHA anti-spam widgets, external web fonts, embedded video/maps, cookie-consent banners, and CMS plugins. These third-party providers collect and process visitor data (such as IP addresses, device fingerprints, and cookies) directly from visitors' browsers under their own independent terms and privacy policies.

Unless explicitly contracted as a distinct deliverable in the Statement of Work, Hozina Technologies does not draft legal privacy policies, configure legally binding cookie-consent workflows, perform formal accessibility or penetration testing audits, or provide legal compliance sign-off for the customer's website.

6. Retention, Project Handover, Deletion, and Incident Cooperation

Hozina Technologies retains project source files, staging artifacts, and any accessed data only for the duration reasonably necessary to complete delivery, fulfill contracted warranty or support terms, maintain corporate records, or comply with applicable law. Upon project completion, Hozina Technologies returns, deletes, or relinquishes access to customer environments as specified in the contract, subject to statutory retention rules, immutable backup cycles, and dispute-resolution holds. Where Hozina Technologies does not host or manage the live production environment under an active retainer, the customer exclusively controls and operates its own database retention, backup, and deletion schedules.

Security Incidents: If Hozina Technologies becomes aware of a confirmed data security incident affecting customer personal data within Hozina's direct operational control, it will assess the event and notify the customer in accordance with the governing contract and applicable law. The customer remains solely responsible for fulfilling its statutory breach-notification duties as Data Fiduciary / Controller. For enquiries regarding Hozina's own corporate records, use the website Contact Us page marked Privacy Request.

1. Applicability and Legal Role Allocation

This Service Privacy Notice governs Hozina Technologies' Custom CRM Development engagements, encompassing business workflows such as lead and customer management, activity timelines, call/meeting notes, task scheduling, follow-up reminders, role-based user hierarchies, custom reporting, and contracted API integrations. It supplements the General Hozina Technologies Privacy Policy and the governing project contract.

A client business determines why personal data is collected and how its CRM system is operated. Where Hozina Technologies processes personal data contained in a client's CRM strictly on the client's documented instructions to design, build, test, migrate data into, host, or support the platform, Hozina Technologies acts as a Data Processor or service provider. Hozina Technologies acts separately as an independent Data Fiduciary / Controller for its own sales enquiries, commercial contracts, invoicing, and client support communications. Specific controller-processor responsibilities must be memorialized in the written project agreement and Data Processing Agreement (DPA).

2. Categories of Data Stored Within a Custom CRM

Depending on the database schema and workflow modules specified by the client, a custom CRM may store and process:

• Lead, prospect, and customer names, business email addresses, telephone numbers, company names, job titles, lead sources, and pipeline statuses.
• Free-text interaction notes, call or meeting summaries, follow-up tasks, automated reminders, and chronological activity logs.
• Record assignment, account ownership, internal staff user accounts, and permission role mappings.
• Uploaded file attachments, commercial proposals, project requirement documents, and custom client-defined database fields.
• Historical records imported from legacy CSV/Excel spreadsheets or migrated from an existing third-party CRM.
• Application access logs, authentication records, and technical diagnostic telemetry generated by the CRM and its hosting environment.

The client exclusively determines which database fields are created and populated. Clients must avoid collecting sensitive personal data (such as health, biometric, financial credential, or government identifier data) inside CRM fields or free-text notes unless strictly lawful, necessary, and protected by contracted high-security safeguards.

3. Permitted Processing Purposes and Live Data Migration Rules

Hozina Technologies processes relevant information to gather schema requirements, model relational databases, build contracted CRM modules, configure role permissions, import approved datasets, test workflow logic, troubleshoot bugs, deploy releases, and deliver contracted support. Development and staging builds utilize synthetic, dummy, or anonymized records wherever practical.

Hozina Technologies will not access or migrate live production CRM records unless the project agreement explicitly requires data migration or production debugging and the client has granted written authorization. Where live CRM data access is required, the permitted purpose, access window, authorized engineers, and post-migration data deletion obligations must be documented in the project SOW or DPA.

4. Client Statutory Responsibilities (Lawfulness of Imported Data)

As the Data Fiduciary / Controller of its CRM, the client is solely responsible for establishing a valid lawful basis (such as consent or specified legitimate use) for every lead, customer, and employee record stored in the system; delivering statutory privacy notices to Data Principals; maintaining data accuracy; administering internal user accounts; governing who may view, edit, export, or delete CRM records; and fulfilling individual rights requests (access, correction, erasure) and statutory retention limits.

Warranty Against Unlawful Lists: The client warrants that it holds full legal authority to supply all data provided to Hozina Technologies for migration or testing. Clients must never instruct Hozina Technologies to import illegally purchased, unauthorized scraped, confidential third-party, or non-consensual marketing lists into a CRM environment.

5. Security Architecture and Scope-Dependent Controls

Enterprise security features—such as granular Role-Based Access Control (RBAC), immutable audit trails, automated encrypted backups, field-level encryption at rest, password complexity enforcement, Multi-Factor Authentication (MFA), rate-limited data exports, and intrusion monitoring—depend entirely on the contracted project specifications and deployed hosting architecture.

No Implied Security Features: Hozina Technologies does not represent or imply that every custom CRM build automatically includes every advanced security control by default. Specific requirements for cloud hosting, access administration, backup frequency, encryption standards, audit logging, OS patching, recovery time objectives (RTO/RPO), and incident response must be explicitly agreed in writing before production deployment. Credentials must be exchanged exclusively via secure channels, adhere to least privilege, and be rotated by the client immediately upon project handover.

6. Third-Party Integrations, Hosting, Retention, and Demo Environment

Third-Party Integrations: Where contracted, a custom CRM may integrate with external email servers, calendars, web forms, automation platforms, payment gateways, cloud storage, or third-party APIs. Connecting such services transmits CRM data to those external providers under their respective terms and privacy policies. No third-party integration is included unless expressly specified in the SOW.

Hosting & Post-Project Deletion: When a CRM is deployed onto cloud infrastructure owned or controlled by the client, the client controls the production database and server environment. If Hozina Technologies is contracted to host or manage the CRM environment, those hosting and processor duties must be documented in a written agreement. At the conclusion of a development or migration engagement, Hozina Technologies returns, deletes, or disables access to temporary project artifacts and client datasets as agreed, subject to statutory retention, backup overwrite cycles, and legal holds.

Public Demo CRM Disclaimer: The Hozina CRM Demo is strictly for interface evaluation using fictional sample data. Users must never input real personal data, passwords, financial details, or confidential files into the demo. Demo records are periodically reset or purged without notice. For privacy requests concerning Hozina's own corporate records, contact Hozina Technologies via the website Contact Us page marked Privacy Request.

1. Applicability and Legal Role Allocation

This Service Privacy Notice applies whenever Hozina Technologies designs, architects, configures, tests, deploys, or supports workflow automations and system integrations for a B2B client. Depending on the engagement, the technical toolkit may involve n8n, Microsoft Power Automate, Google Workspace services, custom PHP/Laravel or CRM endpoints, REST/GraphQL APIs, and HTTP webhooks. Reference to these platforms does not imply that every tool or connector is included in every engagement.

The client business determines the commercial purpose of its workflow and selects which systems and datasets are connected. Where Hozina Technologies processes personal data strictly on the client's documented instructions to build, debug, or maintain an automation pipeline, Hozina Technologies acts as a Data Processor or service provider. Hozina Technologies acts separately as an independent Data Fiduciary / Controller for its own business contacts, commercial proposals, contracts, and billing records. Roles and processor obligations must be confirmed in the governing service agreement and Data Processing Agreement (DPA).

2. Categories of Data Flowing Through an Automation Pipeline

Depending on the connected endpoints and trigger rules, an automated workflow may transmit and process:

• Website form submissions, lead inquiries, and customer contact records.
• CRM entity records, pipeline statuses, interaction notes, task assignments, and staff user identifiers.
• Spreadsheet rows, accounting entries, and structured operational records.
• Transactional or internal emails, calendar event metadata, chat/notification messages, and binary file attachments.
• Raw API request and response JSON/XML payloads, webhook bodies, external system IDs, and HTTP error messages.
• Workflow execution logs, retry queue payloads, execution timestamps, connection metadata, and technical diagnostic traces.
• API keys, OAuth 2.0 access and refresh tokens, webhook signing secrets, and service-account credentials required to authenticate connections.

Execution Log Exposure Warning: By default, workflow automation engines copy full incoming and outgoing payloads into execution histories and error logs to facilitate debugging. Unless log masking, payload redaction, and shortened retention windows are technically supported by the chosen platform and contracted within the project scope, execution logs may retain plaintext personal data. Clients must avoid routing unnecessary sensitive personal data through webhook URLs, query parameters, or unmasked test payloads.

3. Permitted Purposes and Synthetic Testing Protocol

Hozina Technologies processes relevant information solely to map business processes, develop and test automation nodes, configure triggers and actions, authenticate endpoints, debug failed runs, deploy approved workflows, and provide contracted maintenance. All processing of client data is performed in accordance with documented client instructions.

Wherever feasible, development and testing must utilize synthetic test payloads and sandbox/non-production accounts. If live production records must be processed to verify an integration, the client and Hozina Technologies must agree in advance on the exact scope, temporary access window, authorized personnel, and post-verification log cleanup procedure.

4. Third-Party Platforms, Subprocessors, and Cross-Border Transfers

Automation engines and connected endpoints process data in accordance with their own independent terms of service, cloud infrastructure, geographic server regions, log retention policies, and privacy notices. A single workflow may route data across a form provider, a CRM, an email service, a cloud spreadsheet, an n8n or Power Automate instance, and external webhook URLs. Any webhook or API node configured in a workflow will disclose payload data to the designated destination endpoint.

Data residency and legal terms depend entirely on the client's subscription plan, cloud hosting region, and chosen vendors. Hozina Technologies will never assume that a workflow is local-only, cloud-only, or compliant with a specific country's data-localization rules without auditing the actual configuration. If the client is subject to statutory data-residency mandates, strict subprocessor approval lists, or cross-border transfer restrictions, the client must specify those requirements in writing prior to development so they can be formally scoped.

5. API Credentials, Least Privilege, and Account Ownership

Integration credentials grant programmatic access to live business systems and must be handled as strictly confidential secrets. Implementations should utilize provider-supported OAuth flows or encrypted credential vaults, provision dedicated service accounts rather than personal admin accounts, enforce least-privilege API scopes, and never transmit secrets in plaintext emails or public forms. Hozina Technologies must be granted only the minimum access required for the contracted work, and all temporary credentials must be revoked or rotated upon project handover or immediately following any suspected compromise.

The client retains full legal ownership of its third-party software accounts and is responsible for ensuring it holds valid authorization under vendor terms to connect those systems and grant Hozina Technologies integration access.

6. Execution Logs, Retries, Retention, and Environment Control

Automation platforms retain run histories, failed execution queues, task logs, and cached payloads based on platform settings and subscription tiers. Where technically supported and contracted in scope, Hozina Technologies will configure log minimization, field masking, or reduced retention periods; however, Hozina Technologies does not guarantee that every third-party SaaS platform or license tier permits immediate erasure of every operational log entry.

The written project agreement must explicitly specify whether the client or Hozina Technologies hosts and administers the automation environment (such as a self-hosted n8n server vs. a client-owned cloud account), who can view execution histories, and who manages backups and log deletion.

7. Workflow Failures, 24/7 Monitoring Disclaimer, and High-Impact Decisions

Automated integrations can fail or halt at any time due to upstream third-party API schema changes, expired OAuth tokens, vendor rate limits, server outages, malformed source data, or modified business logic. While automated error alerts, retry policies, and human-in-the-loop review queues can be engineered if contracted in scope, clients must not assume that a deployed workflow is monitored 24/7, guaranteed to execute without failure, or capable of safely resolving every edge-case exception unless covered by an active, written managed-support agreement.

Prohibition on Unreviewed High-Impact Decisions: Clients must never use automated workflows to execute high-impact legal, financial, employment, credit, or eligibility decisions concerning individuals without implementing appropriate human review, verification, and statutory safeguards. The client retains sole responsibility for its business decisions and for verifying critical workflow outputs.

8. Client Responsibilities, Project Handover, and Contact

The client is solely responsible for ensuring it holds a valid lawful basis to process and transfer all personal data routed through an automation; providing transparent privacy notices to affected individuals; approving all destination endpoints and data fields; maintaining accurate source records; and complying with third-party platform terms. Clients must never instruct Hozina Technologies to route personal data to unauthorized endpoints.

If Hozina Technologies identifies a security incident involving client data under its direct control, it will assess the matter and cooperate with the client in accordance with the governing contract and applicable law. Upon project completion, workflow definitions, credentials, test payloads, logs, and developer access are returned, purged, or handed over as agreed, and the client must immediately rotate all production secrets and API tokens. For privacy requests regarding Hozina's own corporate records, contact Hozina Technologies via the website Contact Us page marked Privacy Request.