Privacy Policy

A privacy policy is often treated as a legal hurdle—a document designed to protect the company rather than inform the user. At Lumexa Media, we view the privacy policy as a foundational element of our client relationship. For business owners, marketers, and in-house teams, understanding how a production partner handles sensitive briefs, proprietary assets, and contact information is a matter of risk management and professional trust.

This guide serves as a detailed field manual for our privacy practices. It moves from the basic mechanics of what we collect to the advanced legal frameworks we use to protect data across different jurisdictions, including the UK, the EEA, and the United States. Whether you are a procurement officer conducting a vendor security review or a freelancer requesting a quote, this document outlines the exact procedures we follow to ensure your data remains secure and your rights are respected.

Fundamentals of Data Collection

Data collection is governed by the principle of data minimization: we only collect what is strictly necessary to perform the service you have requested. When you interact with Lumexa Media, your data enters our system through three primary channels: direct inquiries, site navigation, and financial transactions.

Direct Inquiries and Quote Requests

When a potential client sends an inquiry or requests a free trial, we collect a specific set of identifiers. These include your name, email address, and optionally your phone number, company name, and country of operation. This information is essential for establishing a professional relationship and ensuring that we are communicating with the correct legal entity for contracting purposes.

Beyond contact details, we collect the specifics of your project brief. This includes the volume of work, required turnaround times, budget constraints, and the creative brief itself. This data is categorized as "Project Material." The lawful basis for this processing is twofold: first, it is necessary to take steps at your request before entering into a contract (the quoting phase); second, it is necessary for the performance of a contract once you engage our services.

Passive Site Collection

Browsing our website generates certain data points. Our hosting provider maintains standard server logs. These logs record IP addresses and request timestamps, which are critical for security diagnostics and preventing DDoS attacks. These logs are not used for marketing but for the technical stability of the site.

Analytics tools are handled differently. We distinguish between strictly necessary cookies—those required for session management and security—and optional analytics. Analytics run only after explicit consent is given. If a user declines these cookies, their ability to read the site content or submit an inquiry remains entirely unaffected.

Subscription and Transactional Data

For users who subscribe to our newsletter, we store the email address and a timestamped record of consent. This ensures we can prove compliance with anti-spam laws. When a client purchases a package, we maintain an order record for accounting and delivery purposes. Crucially, payment card details are handled by a PCI-DSS compliant payment provider. These details never touch Lumexa Media servers, removing the risk of credit card data breaches from our internal infrastructure.

Handling and Securing Project Files

For a creative production studio, the handling of client assets—photography, video rushes, and brand guidelines—is the most critical part of the privacy policy. Many studios inadvertently leak client data by placing uploads in public-facing directories that can be discovered by search engine crawlers or "URL guessing" (directory traversal).

The Private Storage Architecture

Lumexa Media employs a strict isolation strategy for client files. Uploads are stored outside the public web root. This means there is no public URL that leads directly to a client's file. Instead, files are stored in a private directory accessible only through an authenticated administrative interface. To retrieve a file, a staff member must be logged into the system with the appropriate permissions, and the system generates an authorized request to fetch the file from storage.

Confidentiality and Portfolio Use

We recognize that project materials often contain pre-release intellectual property. We use your files solely to execute the work you have requested. A common industry friction point is the use of client work in a studio's portfolio. Lumexa Media operates on a strict "opt-in" basis for portfolio display. We will not publish any client work as portfolio material without first obtaining written consent from the client.

Data Retention and Disposal Schedules

Holding data indefinitely is a liability. We implement a tiered retention schedule based on the purpose of the data and the legal requirements governing it. This prevents "data bloat" and ensures that we are not holding personal information without a valid purpose.

Retention Categories

The duration for which we keep data depends on whether the interaction resulted in a formal engagement. For example, if a user submits an inquiry but decides not to proceed, we do not need to keep their project files for years. Conversely, tax laws require us to keep financial records for a significant period.

Data Type	Retention Period	Reason for Retention
Uploaded files (Unsuccessful inquiry)	90 Days	Allowing time for the user to return to the conversation
Uploaded files (Active project)	Project duration + 12 months	Facilitating revisions and project archival
Inquiry records	24 months from last contact	Maintaining relationship history for returning clients
Order and Invoice records	6 Years	Compliance with statutory tax and accounting laws
Newsletter subscriptions	Until unsubscribe	Ongoing consent-based communication
Server logs	30 Days	Security auditing and diagnostics

The Deletion Process

Our system is designed to ensure that when a primary record is deleted, its associated assets are also purged. For instance, deleting an inquiry record in our administrative system triggers an automatic erasure of any files attached to that specific inquiry. This prevents the common issue of "orphaned files" remaining on a server long after the associated client record has been removed.

Third-Party Processors and Data Sharing

Lumexa Media does not sell personal data. However, to operate a digital business, we must use third-party processors. These are entities that handle data on our behalf, strictly under our instructions.

Essential Processors

We limit our data sharing to a small group of essential service providers: hosting providers (for site and file storage), email providers (for communication), payment providers (for transaction processing), and analytics providers (for site performance). Each of these providers is contractually restricted from using our client data for their own purposes or selling it to third parties.

Subcontractors and Confidentiality

In certain complex projects, we may employ specialized subcontractors. In these cases, we only share the specific data necessary for the subcontractor to complete their task. Every subcontractor is required to sign a written confidentiality agreement that mirrors our own privacy commitments to the client. We provide the name of any subcontractor working on a project upon request.

International Data Transfers

Because we are established outside the United States, data from US clients is processed abroad. Similarly, data from EU/UK clients may be processed by providers in other jurisdictions. To ensure this is legal and secure, we rely on two mechanisms:

• Adequacy Decisions: We use processors in countries that the European Commission or UK government has deemed to have adequate data protection laws.
• Standard Contractual Clauses (SCCs): Where an adequacy decision is not in place, we use SCCs—standardized contracts approved by regulators that legally bind the processor to protect the data to the required standard.

Global Rights: GDPR and UK Data Protection

For clients and visitors in the European Economic Area (EEA) and the United Kingdom, we adhere to the General Data Protection Regulation (GDPR) and the UK Data Protection Act. These laws provide some of the strongest data protections in the world, and we apply these standards as our baseline for all users.

The Right to Access and Portability

Under these regulations, you have the right to request a copy of all personal data we hold about you. This must be provided in a portable, machine-readable format (such as a JSON or CSV file), allowing you to transfer your data to another service provider without hindrance.

The Right to Rectification and Erasure

If you discover that the information we hold is inaccurate, you have the right to have it corrected immediately. Furthermore, you can request the "Right to be Forgotten" (erasure). We will delete your data unless we have an overriding legal obligation to keep it—for example, we cannot delete an invoice that must be retained for a tax audit.

The Right to Object and Restrict

You may object to the processing of your data for specific purposes, such as marketing. You can also request that we restrict the processing of your data—meaning we keep the data but stop using it—while a dispute over its accuracy or legality is resolved.

US State Privacy Laws and Resident Rights

The United States does not have a single federal privacy law equivalent to the GDPR. Instead, a growing number of states—including California (CCPA/CPRA), Colorado, Connecticut, Virginia, Utah, Texas, Oregon, and Montana—have enacted their own comprehensive privacy statutes. While these laws differ in detail, their substance is broadly aligned.

The Lumexa Universal Standard

Rather than managing a complex matrix of state-by-state rules, Lumexa Media extends the most stringent protections found in these laws to every client and visitor, regardless of their residency. If a US state grants a right that we would not otherwise owe you under our baseline policy, we honor it anyway.

Core Rights for US Users

We provide the following specific guarantees to all US users:

• Right to Know: You can ask what personal information we hold, where it came from, why we have it, and who we have shared it with.
• Right to Access: You can receive a copy of your personal information in a portable format.
• Right to Correct: You can have inaccurate information put right.
• Right to Delete: You can have your information erased, subject to our legal retention obligations.
• Right to Opt-Out: While many state laws focus on the right to opt-out of the "sale" or "sharing" of data for behavioral advertising, we simply do not engage in these practices. There is nothing to opt-out of because we do not sell your data.

Special Provisions for US Residents

Non-Discrimination: Exercising your privacy rights will not result in a change in the price you pay for our services or the quality of service you receive. We do not penalize users for requesting data transparency.

The Appeal Process: Several US state laws require a formal appeal route if a business refuses a privacy request. If we deny a request (for example, because the data is required for a legal tax record), our refusal will include a detailed explanation and instructions on how to challenge that decision in writing.

Advanced Security Measures and Breach Response

Security is not a static state but a continuous process of risk mitigation. We employ a multi-layered defense strategy to protect client data from unauthorized access, alteration, or destruction.

Technical Safeguards

All traffic to our website and client portals is encrypted using HTTPS (TLS). This ensures that data in transit between your browser and our server cannot be intercepted by third parties. Internally, we follow the principle of least privilege: access to client files is restricted to the specific team members assigned to that project. Credentials are not shared between staff members, and we use unique, strong passwords for all administrative access.

We also maintain a defined patching schedule for all software dependencies to close known vulnerabilities. Backups are tested regularly to ensure that in the event of a system failure, data can be restored without loss.

Breach Notification Protocol

No system is perfectly secure. In the event of a data breach, our priority is transparency and rapid mitigation. We follow a strict notification protocol:

1. Detection and Containment: Upon discovering a breach, we immediately move to isolate the affected systems and stop the leak.
2. Assessment: We determine what data was accessed and which individuals were affected.
3. Notification: We notify the affected individuals and the relevant supervisory authorities without undue delay. Where the GDPR applies, this happens within 72 hours of becoming aware of the breach.
4. Detail: The notification will clearly state what happened, what data was affected, the steps we have taken to remediate the issue, and the steps you should take to protect yourself.

The Mechanics of Consent and Cookies

Consent is the bedrock of modern privacy law. We distinguish between "strictly necessary" operations and "consensual" operations to ensure users have actual control over their digital footprint.

Strictly Necessary Cookies

Some cookies are essential for the site to function. These include session cookies that keep you logged in and security cookies that prevent CSRF (Cross-Site Request Forgery) attacks. Because the site cannot function without these, they are deployed without asking for consent.

Consent-Based Cookies

Any cookie used for analytics or tracking requires explicit, affirmative consent. We do not use "pre-ticked" boxes. You must actively choose to allow these cookies. Once consent is given, you can withdraw it at any time through the site settings, and we will stop the tracking immediately.

Global Privacy Control (GPC)

We recognize the Global Privacy Control signal. GPC is a browser-level setting that allows users to communicate their privacy preferences automatically. When your browser sends a GPC signal, we treat it as a valid opt-out request under the state laws that recognize it. While we do not sell data (meaning the signal doesn't change our behavior), we honor it as a matter of technical and legal principle.

Worked Example: The Lifecycle of a Project's Data

To illustrate how these policies work in practice, let's follow a hypothetical project from start to finish. This example shows the movement of data, the application of retention rules, and the exercise of user rights.

Phase 1: The Inquiry

A marketing manager in California, "Jane," submits a request for a video production quote. She provides her name, email, and uploads a 50MB PDF brief and three reference images.

• Action: The data is stored in our private storage. The IP address is logged in the server logs.
• Status: Jane has not yet entered a contract, so the lawful basis is "taking steps at the request of the data subject."

Phase 2: The Project

Jane hires Lumexa Media. She uploads 10GB of raw footage and a brand style guide.

• Action: These files are placed in a project-specific private directory. Only the assigned editor and producer have access.
• Status: The lawful basis shifts to "performance of a contract."

Phase 3: Project Completion

The project is delivered and the final invoice is paid.

• Action: The final deliverables are sent. The raw footage remains on our server for 12 months as a safety buffer for revisions. The invoice is moved to our permanent financial archive.

Phase 4: The Right to Erasure

Two years later, Jane's company undergoes a data audit. She emails hello@lumexamedia.com requesting that all her personal data be deleted.

• Action: We verify Jane's identity via her email address. We delete her inquiry records and any remaining project files. We do not delete the invoice from six years ago, as we are legally required to keep it for tax purposes.
• Outcome: Jane is notified that her personal data has been erased, with a note explaining the legal retention of the financial record.

Glossary of Privacy Terms

Final Summary of Data Categories

For those conducting a formal audit, the following table summarizes the categories of information we process and the logic behind their retention.

Category	Examples	Purpose	Retention Logic
Contact Details	Name, email, company, phone	Communication and project management	3 years after last contact
Project Material	Uploaded files, briefs, feedback	Executing the creative work	90 days post-delivery (unless requested otherwise)
Billing Records	Invoices, payment references	Legal and tax obligations	6 years (statutory requirement)
Site Analytics	Pages viewed, region, device	Improving site utility	14 months
Correspondence	Emails, messages	Record of agreements	3 years

Operationalizing Privacy: The Data Lifecycle Workflow

Privacy is often mistakenly treated as a static legal document rather than a dynamic operational workflow. To move from a passive policy to an active compliance framework, organizations must map the data lifecycle from ingestion to deletion. This workflow begins with the "Privacy-by-Design" intake phase, where every new feature or data collection point is vetted against a Data Protection Impact Assessment (DPIA). The workflow design must mandate that no production environment is deployed until the data classification—identifying PII, SPI, and anonymized sets—is completed. This creates a gated process where the legal team defines the "what" (the policy), and the engineering team implements the "how" (the technical controls). By integrating these checkpoints into the CI/CD pipeline, privacy becomes a deployment requirement rather than a post-launch audit task.

Role Ownership and the Matrix of Responsibility

A common failure in privacy management is the "diffused responsibility" trap, where the legal team assumes engineering is implementing controls, and engineering assumes legal has defined the parameters. To solve this, ownership must be bifurcated into Policy Ownership and Implementation Ownership. The Data Protection Officer (DPO) or Legal Counsel owns the Policy Definition—the high-level rules governing data retention and user consent. However, the Product Owner (PO) owns the Policy Execution. The PO is responsible for ensuring that the user interface reflects the current policy and that the backend logic enforces data expiration dates. Below this layer, the DevOps lead owns the Technical Enforcement, managing the encryption at rest and the secure deletion scripts. This matrix ensures that when a policy changes, there is a designated "trigger" person responsible for updating the technical implementation.

The Handoff Protocol: From Legal Intent to Technical Spec

The most volatile point in privacy operations is the handoff between the legal department and the development team. Legal requirements are often written in ambiguous terms (e.g., "reasonable timeframes for deletion"), which are untranslatable for a developer. A robust handoff protocol requires the translation of legal prose into a "Privacy Specification Document." This document converts qualitative policy statements into quantitative technical requirements. For example, a policy stating "we only keep data as long as necessary" must be handed off as a specific TTL (Time-to-Live) value of 730 days for inactive accounts. This handoff must include a verification loop: the developer provides a technical summary of the implementation, and the legal team signs off that this specific technical configuration satisfies the legal requirement.

Production Scheduling and the Compliance Calendar

Privacy maintenance cannot be an ad-hoc activity; it must be integrated into the production schedule via a Compliance Calendar. This schedule synchronizes three distinct cadences: the Audit Cycle (quarterly), the Policy Review (annually), and the Data Purge (monthly or weekly). Scheduling "Privacy Sprints" every quarter allows the team to address technical debt related to data sprawl—the tendency for PII to leak into logs or backup servers over time. By allocating 10% of engineering capacity to "Privacy Hygiene" in the production roadmap, organizations avoid the crisis-mode scramble that occurs during external audits. This scheduling ensures that the process of scrubbing legacy data is a routine operational task rather than a disruptive emergency project.

Operational Example: The "Right to be Forgotten" Request

Consider a user submitting a request to delete their account. In a poorly designed system, this is a manual ticket sent to a database administrator. In a mature operational workflow, the process follows this sequence:

1. Intake: The user triggers a "Delete My Data" button (Product Owner's UI).
2. Validation: An automated check verifies the user's identity and flags any legal holds (e.g., pending litigation) that override the deletion (Legal Owner's Rule).
3. Orchestration: An API call is sent to a "Deletion Orchestrator" that identifies every microservice holding that user's UUID.
4. Execution: Each service executes a hard delete or an irreversible anonymization of the record (DevOps Implementation).
5. Verification: The system generates a cryptographic proof of deletion, which is logged and sent to the user as a confirmation.

This transforms a legal right into a repeatable, scheduled technical event.

Decision Criteria for Data Retention and Deletion

When determining whether to retain or purge data, teams should use a weighted decision matrix rather than intuition. The following criteria should drive the decision:

• Legal Mandate: Does a regulatory body (e.g., GDPR, HIPAA, CCPA) require retention for a specific period? (Highest Weight)
• Business Utility: Does the data provide marginal value for ML training or analytics that outweighs the risk of a breach?
• Risk Profile: Is the data "High Sensitivity" (financial/health) or "Low Sensitivity" (timezone/browser type)?
• Cost of Storage vs. Cost of Liability: Does the cost of maintaining the data exceed the potential fine for non-compliance?

If a data point fails the Business Utility test and has no Legal Mandate, the default action must be immediate deletion upon the expiration of the session or the termination of the user relationship.

Hidden Pitfalls in Privacy Workflow Design

Beyond the obvious risks, several non-intuitive pitfalls often undermine privacy policies. One is "Shadow Data Sprawl," where developers create temporary tables or "dev-copies" of production databases for testing, effectively bypassing all policy controls and creating unmonitored PII repositories. Another is the "Consent Drift" phenomenon, where a product evolves to use data in ways that were not covered by the original consent prompt, rendering the existing policy legally void despite no technical changes to the database. Finally, there is the "Backup Paradox": a user requests deletion, and the record is removed from the live database, but remains in encrypted backups for years. A failure to define a "Backup Purge Strategy" means the organization is technically in violation of the "Right to Erasure" despite having a functional live-deletion workflow.

Source-Asset Preparation and Sanitization

Before any privacy-related documentation is ingested into a production environment, source assets must undergo a rigorous sanitization process to prevent the accidental leakage of internal metadata. This involves stripping EXIF data from accompanying imagery and removing "track changes" or comment history from draft documents. For legal teams, this means converting working documents into flat, non-editable formats before final review to ensure that deleted clauses—which may reveal internal negotiation stances—are not recoverable via binary analysis of the file.

Standardized File Organization and Versioning

To maintain a verifiable audit trail, files must be organized using a strict hierarchical naming convention: [ISO-Date]_[Region]_[Version]_[Status].ext. For example, 2023-10-12_EU_v2.1_FINAL.pdf. This prevents the deployment of outdated policies. Assets should be stored in a read-only repository once finalized, with a separate "Archive" directory for superseded versions. This structure ensures that when a regulator requests the policy active on a specific date, the organization can retrieve the exact asset without relying on ambiguous filenames like "Policy_New_Updated_v2."

Technical Specifications and Delivery Formats

Delivery must prioritize accessibility and machine-readability. While PDFs are standard for legal archiving, the public-facing policy should be delivered as semantic HTML5 to ensure compatibility with screen readers and search engine indexing. Technical specifications should include a UTF-8 encoding standard to prevent character corruption of legal symbols (e.g., § or ©). For API-driven transparency centers, policies should be available in JSON format, allowing the system to programmatically surface specific sections (such as "Data Retention") based on user queries.

Operational Example: The Deployment Pipeline

Consider a scenario where a policy update is required for GDPR compliance. The workflow is as follows:

1. Preparation: The legal draft is exported to a .txt file to strip all formatting metadata.
2. Organization: The file is saved as 2023-11-01_EU_v3.0_DRAFT.txt.
3. Conversion: A build script converts the text into a semantic HTML fragment and a tagged PDF/A for long-term archiving.
4. Delivery: The HTML is pushed to the CDN, and the PDF is hashed (SHA-256) to create a digital fingerprint for the compliance log.

Decision Criteria for Format Selection

Choosing the delivery medium depends on the primary intent of the document. Use HTML when the goal is user engagement and discoverability. Use PDF/A (Archival) when the goal is legal permanence and non-repudiation. Use JSON/XML when the policy must be integrated into a "Privacy Dashboard" where users can toggle specific consent settings. If the document is intended for offline distribution, a high-contrast, print-optimized CSS stylesheet must be applied to the source asset.

Technical Pitfalls in Asset Delivery

A common failure is the reliance on "Dynamic Rendering," where the policy content is generated via JavaScript at runtime. This can lead to "Blank Page" errors for users with strict privacy extensions or outdated browsers, potentially resulting in a failure to provide legal notice. Another pitfall is the neglect of "Cache-Control" headers; if a policy is updated but the CDN serves a cached version of the old policy, the organization is technically in violation of its own transparency requirements. Always implement a Cache-Control: no-cache or a short TTL (Time to Live) for legal assets.