Data protection in a freelance practice

A freelance practice processes personal data both while delivering client work and while running its own business. Its responsibilities extend to the tools that receive data, the information accumulated in documents and messages, and the relationship between actual working practices and the privacy policy.

Personal data and the freelancer's role

For a practice governed by the General Data Protection Regulation (GDPR) or Swiss Federal Act on Data Protection, an independent professional carries legal and compliance obligations previously handled within an employer's organisation. ^{1, 2} Personal data includes information relating to an identifiable person, such as a name, email address or job title combined with an employer. ^{3, 2} Reading, opening, storing, sending or altering personal data can constitute processing, even when it stays within the practice; confidentiality and nondisclosure alone do not cover all processing obligations. ⁴

Ordinary activities involving personal data include editing client documents, using grammar tools or AI assistants, cloud storage, website enquiries, invoicing, newsletters, saving prospective clients' details and video calls. ^{5, 6, 7} Whether these activities create a compliance problem depends on the arrangements behind them. ⁸

For client projects in which the client decides what data to collect and instructs the writer's work, the client is the controller and the writer is a processor operating within that framework. ⁹ For business activities in which the freelancer decides what to collect, why and how, the freelancer is the controller. ^{10, 11, 12} Those decisions include the tools, destinations and retention periods, with responsibilities that are not covered simply by following a client's instructions on other work. ^{13, 14, 15}

Pseudonymised patient data remains personal data where a re-identification key exists with the client or elsewhere, even if the writer cannot see the original names. ^{16, 17} Coding patient names also leaves other identifiable people in documents and emails, including investigators, authors, reviewers, commenters and senders. ¹⁷

Freelance medical writers are subject to data-protection requirements as processors, as are writing organisations; safeguards should fit the service provider's size and budget. ¹⁸

Agreements for tools handling client content

A tool's claim to be GDPR compliant describes its platform operations and does not establish that a particular use with client data meets the writer's obligations. ^{19, 20} Processing client personal data through a tool requires a binding data processing agreement (DPA) at the subscription tier actually used, rather than a website badge or privacy policy. ^{21, 22, 23}

DPA availability depends on the subscription tier and is often included without a separate charge at an eligible tier. ²² Examples given by a lawyer in June 2026 were:

Tool	No DPA in the examples	DPA available in the examples
ChatGPT	Free, Plus	Business, Enterprise
Claude	Other tiers	API, Enterprise
Grammarly	Free, Premium	Business
DeepL	Free	Pro
Dropbox	Personal	Business
Google Drive	Personal account	Google Workspace Business

^{22, 24}

A DPA should restrict processing to the purchased service, such as correcting grammar, generating a draft or storing content. ^{25, 12} Business-tier agreements can contain exceptions or wording such as “provide and improve the service”, which may permit model training. ²⁶ Model training, product improvement or algorithm development may benefit the provider beyond the client's project purpose; that purpose most likely did not include training another organisation's model. ²⁷

Two checks are recommended before a tool receives client content:

1. Identify the subscription tier and whether a DPA exists at that tier. If none exists, upgrade or stop using the tool with client data.
2. Read the agreement, with AI assistance if needed to decipher it, for purposes benefiting only the provider, such as model training or product and algorithm improvement. Under this advice, those terms make a tool unsuitable for client content regardless of subscription level.

²⁸

Personal data accumulated in documents and messages

Each review round can add names through comments and tracked changes, so a collaborative document becomes a record of its contributors as well as its content. ^{29, 30, 12} Visible data includes tracked-change names and timestamps and comment authors, sometimes with affiliations and roles. ³¹ Where those records remain necessary to ongoing work, the writer should recognise their presence and consciously choose where the document is sent and which tools process it. ^{30, 31, 32}

Less visible metadata can include the author in document properties, file paths revealing client names or project codes, and deleted text retained in revision history; these can generally be removed. ^{31, 33} Uploading the file can also transfer that accumulated data; a missing DPA or provider rights to use content for additional purposes can therefore affect every contributor's personal data. ^{33, 34}

Cloud version history can retain old drafts, comments and deleted sections, and people with access to a file or folder may also have access to its history. ³⁵ An email attachment retains its embedded data, while the thread contains senders' and recipients' names and contact details. ³⁶

Recommended checks before sharing are:

1. Inspect removable metadata. In Microsoft Word, use File → Info → Check for Issues → Inspect Document to see and remove it before sharing a file.
2. Decide whether a recipient needs old cloud versions; if not, create a clean copy without version history before sharing a link.
3. Keep track of what email archives contain and how long they are retained. Before forwarding a thread, decide whether the recipient needs its embedded personal data; otherwise start a new thread.

^{37, 32}

Controls and records for the business

Tools chosen for the business extend beyond client-document software to email and newsletter platforms, invoicing, note-taking, website contact forms, analytics and tracking, scheduling, payments, contact management and teleconferencing. ^{14, 38} For each tool, the freelancer should establish where data is actually processed, which may differ from the provider's location, and whether a documented transfer mechanism applies if it goes outside the EU, Switzerland or an adequate-protection country. ^{38, 39} The assessment should also establish whether a DPA exists at the tier used and leave records explaining the tool choice. ³⁹

Organisational controls recommended for medical writing services include:

• A data protection policy.
• A step-by-step breach-containment procedure.
• Archiving and data-destruction procedures.
• Personnel awareness of data-protection policies and procedures.
• Confidentiality clauses for processors and freelancers handling personal data.
• A culture of privacy.

⁴⁰

Physical controls include securing servers and data-exchange platforms, securing workstations, procedures for paper containing personal data, policies for physical hardware maintenance and procedures for risks from non-human sources. ¹⁸

A recommended sequence for establishing the practice's data-protection arrangements is:

1. Audit. Inventory every tool, platform, app and piece of software touching personal data, what each processes, where data goes, whether a DPA exists at the right tier and whether a lawful cross-border transfer mechanism is in place.
2. Document. Only after establishing the full inventory, write a privacy policy reflecting actual practice and retain records of tool assessments.
3. Align. Ensure tools and daily processing match the privacy policy. The policy is a declaration of how data is handled and forms part of compliance; producing the document alone does not establish it.

^{41, 42, 43, 44}