How POPIA and GDPR actually apply to file sharing

What the laws require, what tools can claim, and how to tell the difference · Updated May 2026

TL;DR

“Tool X is GDPR compliant” is a marketing sentence, not a legal claim. The General Data Protection Regulation and South Africa's Protection of Personal Information Act do not certify software products. They regulate what an organisation does with personal data: the basis on which it processes, the purposes it processes for, how long it keeps the data, how it secures the data, and how it behaves when something goes wrong.

Five obligations carry most of the weight, and every reputable file-sharing service should be able to answer for each in plain language: lawful basis, purpose limitation, storage limitation, appropriate security, and breach notification. The articles and sections that anchor those obligations are public, free, and short enough to read in an afternoon. Once you have read them, the question shifts from “is this tool compliant” to “does this tool let me operate compliantly with my data, and does its disclosure match the actual law.”

This piece walks the load-bearing GDPR articles and POPIA sections, points to the primary text for each, names what sto.care does and does not do against them, and ends with a checklist you can apply to any other free file-sharing service before you trust it with anything sensitive.

Why “is X compliant” is the wrong question

Every “is [tool] GDPR compliant” article online repeats the same four checkboxes: encryption, EU servers, no sign-up, privacy policy. The list looks reassuring and reveals almost nothing. The laws do not regulate whether a tool exists; they regulate the data flows that pass through it, who is responsible for those flows, and on what legal grounds. A tool with all four checkboxes can be used in a way that flatly violates GDPR Article 5, and a tool missing one checkbox can be deployed in a fully compliant programme.

The European Data Protection Board, the body that issues binding guidance on GDPR application across the EU, exists to coordinate supervisory authorities and publish opinions precisely because the regulation does not reduce to a vendor questionnaire. Its guidelines and decisions repeatedly emphasise that the obligations attach to the controller and the processor in their respective roles, not to the tool as an object. A vendor can offer a service that processes data lawfully for one customer and unlawfully for another, depending on each customer's purpose, lawful basis, and disclosures.

The second failure mode of the checkbox framing is that most vendor “GDPR compliance” pages cite Article 32 (security measures) and stop. Article 32 is one of seven articles that matter for a file-sharing tool. A page that lists encryption at rest and walks away has answered roughly one seventh of the question.

The right way to read a privacy page is to ask: what is the lawful basis stated, what purposes are stated, what retention period is stated, what security controls are stated, what breach-notification process is stated, and what cross-border transfer mechanism is stated. If a vendor does not answer those six questions clearly, the absence is the answer.

GDPR's actual requirements for a file-sharing service

Here are the load-bearing articles, in the order a file passes through them. For each, the official text is on the gdpr-info.eu reference site. The summaries below are plain-English readings that should track the source text closely.

Article 5: principles

Article 5 sets the six principles that govern every other obligation: lawfulness, fairness and transparency; purpose limitation; data minimisation; accuracy; storage limitation; and integrity and confidentiality. A seventh requirement, accountability, sits in Article 5(2) and obliges the controller to be able to demonstrate compliance.

For a file-sharing tool, this translates into concrete obligations. The tool must collect only the data needed to deliver the file (data minimisation), use that data only for delivery (purpose limitation), keep it for no longer than necessary (storage limitation), and protect it appropriately (integrity and confidentiality). A tool that collects a recipient's email so it can later sell that email to an ad partner has just violated purpose limitation, regardless of how good its encryption is.

Article 6: lawful basis

Article 6 says processing is only lawful if at least one of six bases applies: consent, contract necessity, legal obligation, vital interests, public task, or legitimate interests. For consumer file sharing the operative bases are consent (the user uploads with awareness of the privacy policy) or legitimate interests (the service exists to deliver the file, the user opted to use it, the legitimate-interests balancing test favours processing).

Vendors that hide behind “legitimate interests” for every operation, including marketing, are reading the article loosely. Article 6(1)(f) requires a balancing test against the data subject's rights and reasonable expectations, and the EDPB has consistently treated marketing repurposing as a tighter case than core service operation.

Articles 13 and 14: information obligations

Article 13 is the privacy-policy article. When the controller collects data directly from the data subject, it must disclose: its identity, a contact for the data protection officer (where one is appointed), the processing purposes and lawful basis, recipients or categories of recipients, third-country transfer details and safeguards, retention period, the data subject's rights, and the right to lodge a complaint with a supervisory authority. Article 14 covers the same disclosures when data is not collected directly from the subject.

A privacy policy that says “we collect data to provide the service” without naming the lawful basis, retention period, and recipient categories has not satisfied Article 13. This is one of the easier compliance gaps to spot from outside.

Article 17: right to erasure

Article 17 gives the data subject the right to request deletion of their personal data when it is no longer necessary, when consent is withdrawn, when there is no other legal basis, when the subject objects, or when processing was unlawful. The controller must erase without undue delay, and must take reasonable steps to notify other controllers holding the data.

For a file-sharing tool this means there must be an actual process. A revoke link, a privacy contact address, a manual admin procedure, anything that lets a user actually exercise the right. A tool with no documented erasure path is in violation by default.

Article 28: processor obligations

When a tool acts as a processor for a business customer (a company sending invoices to a counterparty using the tool), Article 28 kicks in. The contract between controller and processor must cover specific terms: documented instructions only, confidentiality of personnel, Article 32 security measures, sub-processor authorisation, assistance with data-subject rights, breach support, deletion or return of data at the end of services, and audit rights. This contract is the Data Processing Agreement (DPA).

Article 28 is what separates a consumer tool from a B2B tool. Consumer tools rarely sign DPAs because the legal relationship is direct between the user and the tool, not between an employer and the tool. If you are using a free file-sharing site to send corporate data, your employer is probably either accepting the risk or turning a blind eye.

Article 32: security of processing

Article 32 is the article most vendors love because it sounds like a checklist. Take “appropriate technical and organisational measures” for the risk, and the article suggests pseudonymisation and encryption, ongoing confidentiality and integrity and availability, the ability to restore after an incident, and a process for regularly testing the measures.

The word doing most of the work is “appropriate.” For a free file-sharing tool sending family photos, TLS in transit and AES-256 at rest is appropriate. For a tool targeting healthcare or legal workflows, the bar is higher and ISO 27001 or SOC 2 attestations start to matter. Article 32 is a sliding scale, not a binary.

Article 33: breach notification, 72 hours

Article 33 sets the famous 72-hour rule. After becoming aware of a breach likely to result in a risk to individual rights and freedoms, the controller must notify the competent supervisory authority without undue delay and, where feasible, within 72 hours. The notification must describe the nature of the breach, the categories and approximate number of data subjects affected, the likely consequences, and the measures taken to address it.

A tool that has no documented incident-response process cannot meet Article 33. This is another gap that tells you something: if the privacy page is silent on incident response, the infrastructure for it probably does not exist.

POPIA's actual requirements

South Africa's Protection of Personal Information Act is structurally similar to GDPR but uses different language and has slightly different obligations in places. Where GDPR speaks of controller and processor, POPIA speaks of responsible party and operator. Where GDPR has 99 articles, POPIA has 115 sections. Where GDPR fines reach 4 percent of global turnover, POPIA caps administrative fines at R10 million.

The enforcement body is the Information Regulator (South Africa), an independent body established under section 39 of POPIA with a mandate covering both POPIA and the Promotion of Access to Information Act (PAIA, 2000). It has been issuing enforcement notices and infringement findings since the act came into full force in July 2021. The sections that matter for a file-sharing service are below.

Section 8: conditions for lawful processing

Section 8 is POPIA's accountability anchor. The responsible party must ensure the conditions in Chapter 3 are met, both when determining the means of processing and during processing itself. The eight conditions covered by the chapter are: accountability, processing limitation, purpose specification, further processing limitation, information quality, openness, security safeguards, and data subject participation. Section 8 is the on-ramp; the substantive obligations sit in the sections that follow.

Section 14: retention and restriction of records

Section 14 says records of personal information must not be retained any longer than necessary, and that records used to make a decision about a data subject must be retained long enough to allow access. After the lawful retention period, the responsible party must destroy, delete, or de-identify the records as soon as reasonably practicable. The same section gives the data subject a restriction right (similar to GDPR's Article 18) to limit processing in specific circumstances.

Section 19: security safeguards

Section 19 is the POPIA equivalent of GDPR Article 32. The responsible party must take appropriate, reasonable technical and organisational measures to prevent loss, damage, unauthorised destruction, and unlawful access. The section explicitly requires identification of foreseeable risks, maintenance of appropriate safeguards, regular testing, and updates in response to new risks. It also requires due regard for generally accepted information security practices specific to the sector.

Section 22: notification of security compromise

Section 22 is the POPIA breach notification requirement. Where there are reasonable grounds to believe personal information has been accessed or acquired by an unauthorised person, the responsible party must notify the Information Regulator and the affected data subjects as soon as reasonably possible. The notification must describe the consequences, the measures taken, the recommended protective steps for the data subject, and (if known) the identity of the unauthorised person. POPIA does not specify a 72-hour clock the way GDPR does, but the Information Regulator has signalled in its enforcement practice that “as soon as reasonably possible” means days, not weeks.

Section 72: cross-border transfers

Section 72 governs when a responsible party in South Africa may transfer personal information to a recipient outside the Republic. One of five grounds must apply: the recipient is bound by a law, binding corporate rules, or agreement that provides protection substantially similar to POPIA; the data subject consents; the transfer is necessary for performance of a contract with the data subject; the transfer is necessary for a contract in the data subject's interest; or the transfer is for the benefit of the data subject and consent cannot be reasonably obtained.

For a South African user uploading a file to a tool that stores in the EU, the EU's adequacy regime under GDPR provides protection substantially similar to POPIA, which satisfies Section 72(1)(a). The Information Regulator has not published an adequacy list of its own equivalent to the European Commission's, but EU storage is treated as broadly safe under the substantially-similar test.

On fines and penalties: under Section 109, the Information Regulator may impose administrative fines up to R10 million (roughly $540,000 at current rates), with the Minister able to adjust the ceiling for inflation. Some offences also carry criminal penalties. GDPR's ceiling is materially higher: 4 percent of global annual turnover or 20 million euros, whichever is greater. The practical takeaway is that the GDPR risk of getting it wrong is much larger for a company with international revenue.

How sto.care handles each obligation

Concrete answers, mapped to the articles and sections above. Where we do less than a stricter framework would want, that is named directly.

• Lawful basis (Art. 6, Sec. 8): consent. The user uploads with awareness of the privacy policy, which states the purpose, retention, and recipient categories. We do not rely on legitimate interests for any non-core processing because there is no non-core processing.
• Purpose limitation (Art. 5, Chapter 3 Cond. 3): delivery only. Files are stored to be downloaded by the recipient. They are not used for advertising, model training, or any analytics that would derive from file content.
• Storage limitation (Art. 5, Sec. 14): 7-day automatic expiry, enforced by an S3 lifecycle rule plus a DynamoDB TTL on the metadata row. The link also stops resolving on the read path at the 7-day mark even before the sweep catches up. We have a separate piece on the precise mechanics at what actually happens to your files after 7 days.
• Security (Art. 32, Sec. 19): TLS 1.2+ in transit, AES-256 at rest via SSE-S3 (AWS-managed keys), private S3 bucket, signed URLs valid for one hour, IAM least-privilege on Lambda execution roles, 10 uploads per IP per hour rate limiting.
• Right to erasure (Art. 17): on-demand revoke link in every confirmation email. Clicking it triggers an immediate S3 DeleteObject call and removes the metadata row. We honour out-of-band erasure requests through the privacy contact.
• Breach notification (Art. 33, Sec. 22): 72-hour clock under GDPR; “as soon as reasonably possible” under POPIA. Notification would cover nature, categories of data, likely consequences, and remediation.
• Cross-border (Sec. 72): data lives in eu-west-1 (Ireland), which keeps it under EU jurisdiction. AWS control-plane access from US-based AWS staff is governed by the EU-US Data Privacy Framework, the adequacy decision adopted by the European Commission on 10 July 2023 (covered on the European Commission's EU-US data transfers page).

What we do not offer, named directly:

• End-to-end encryption. AWS holds the SSE-S3 keys. If your threat model requires that AWS could not read the file even with a court order, you want a true E2EE service like Tresorit, Mega, or Proton Drive.
• Data Processing Agreements. sto.care is a free consumer tool. We do not sign Article 28 DPAs with consumer users. If you need a processor relationship, the tool category is B2B file transfer, not consumer.
• Formal certifications. No ISO 27001, no SOC 2 Type II report. Our security posture is documented in public on the privacy page; it is not third-party attested.

How to read another tool's privacy claims

Apply this to any free file-sharing service before sending anything you would not put on a postcard. The questions are ordered from most to least important.

1. Where does the tool say data lives? Look for an explicit jurisdiction (region, country) and an explicit storage provider, not just the company's headquarters. A Swiss company storing in AWS US is operating under US jurisdiction for that data. A Dutch company storing in eu-west-1 is operating under EU jurisdiction.
2. Does the tool name a Data Protection Officer or equivalent? GDPR Article 37 makes a DPO mandatory only in specific cases, but a serious tool will name a contact for privacy matters that is not just a generic info@ alias. POPIA requires registration of an Information Officer with the Information Regulator.
3. Does the privacy policy specify retention windows in days? “As long as necessary” is legalese for “we have not decided.” A tool that gives a number (7 days, 30 days, 12 months) is operating to a real schedule.
4. Does the tool list sub-processors? Article 28 requires the controller to authorise sub-processors. A tool that names AWS, Stripe, Mailgun, and so on is taking the obligation seriously. A tool that says nothing is either ignoring the obligation or has not thought about it.
5. Does the tool publish an EU representative under Article 27 and a South African Information Officer? These are required only in specific cases (GDPR Article 27 for non-EU controllers offering goods or services to EU residents; POPIA registration for responsible parties), but their presence signals a tool that has done the jurisdictional homework.

A tool that answers vaguely on any of these is not necessarily non-compliant. It is a tool that has not done the work to make compliance verifiable from outside. If you would not let your employer process your data through such a tool, do not let it process your data either.

The Article 5 lifecycle, mapped

Here is the GDPR Article 5 principle stack applied to a single sto.care upload, end to end. Each principle attaches at a different point in the lifecycle, and a tool that satisfies one but not the others has not satisfied the article.

The cross-border picture

Cross-border data transfer is the area most consumer privacy pages handle worst. The geography of the company rarely matches the geography of the data, and the jurisdiction that applies depends on where the data actually lives, not on where the founders sit. Here is the path for a sto.care upload, traced across the relevant legal frameworks.

The post-Schrems II picture is worth a sentence on its own. In 2020, the Court of Justice of the European Union invalidated the EU-US Privacy Shield in case C-311/18 (Schrems II), holding that US surveillance law did not offer protections essentially equivalent to GDPR. Three years later the European Commission adopted the EU-US Data Privacy Framework, an updated adequacy decision built on new US executive-order safeguards. The framework is current law for EU-US transfers as of this writing, and it is the instrument under which AWS's US-based control-plane access to EU data is treated as lawful. If a future court ruling invalidates the framework (a Schrems III scenario), that picture would change quickly.

What to take away

The five questions in the checklist above (jurisdiction, privacy contact, retention in days, sub-processor list, EU/SA representative) work as a fast triage on any file-sharing service. If the answers are concrete and cite the right articles, the tool has done the work. If the answers are vague or absent, the tool has not. The rest of the assessment is whether your specific use case (consumer one-off, regulated workflow, B2B processor relationship) needs more than the tool offers.

sto.care is positioned for the first case. Free, no sign-up, 5 GB max, 7-day expiry, EU storage, on-demand revoke, named limits. For the second and third cases, the right tool has DPAs, certifications, and a direct sales relationship. We name the boundary because pretending otherwise is the failure mode this article is trying to teach you to spot. If a tool cannot answer the five questions clearly, that is your answer.

Related reading: a separate piece on what actually happens to your files after 7 days unpacks the deletion mechanics that satisfy storage limitation. The encrypted file transfer page documents the TLS plus AES-256 boundary that satisfies Article 32. The share a file without signing up page covers the no-account flow that keeps data minimisation real. For a jurisdiction-by-jurisdiction comparison with a Swiss alternative, see our sto.care vs SwissTransfer page.

Frequently asked questions

Is sto.care GDPR-compliant?

We process uploads under consent (Article 6(1)(a)), use the data only for delivery (Article 5 purpose limitation), expire files after 7 days (storage limitation), apply TLS in transit and AES-256 at rest with private buckets (Article 32), and would notify within 72 hours of a confirmed breach (Article 33). We are not E2EE, AWS holds the keys, and we do not sign Data Processing Agreements with consumer users. For business processors who need an Article 28 DPA, we are not the right fit today.

Is sto.care POPIA-compliant?

We follow the POPIA conditions in Section 8: lawful processing on consent, purpose specification (delivery only), retention limited to 7 days under Section 14, security safeguards under Section 19 (TLS, AES-256, private bucket, signed URLs), and we would notify the Information Regulator and affected data subjects under Section 22 in a confirmed breach. Files live in eu-west-1 (Ireland), so for South African users that is a Section 72 cross-border transfer, lawful where the receiving jurisdiction has substantially similar protection (the EU does, by adequacy).

What is the difference between GDPR and POPIA?

Both are principles-based privacy laws covering lawful basis, purpose limitation, retention, security, and breach notification. GDPR (EU) covers EU residents and has fines up to 4 percent of global revenue or 20 million euros. POPIA (South Africa) covers South African data subjects and caps administrative fines at R10 million under Section 109, with separate criminal penalties for some offences. POPIA uses the term responsible party where GDPR says controller, and operator where GDPR says processor. The structures are close enough that a tool built for GDPR generally satisfies POPIA, with adjustments for cross-border transfer rules.

Where are my files actually stored?

In an S3 bucket in AWS region eu-west-1 (Ireland). That keeps the data under EU jurisdiction and within the GDPR perimeter. AWS control-plane access from US-based AWS staff falls under the EU-US Data Privacy Framework adopted by the European Commission in July 2023. We do not use any non-EU storage region.

How do I exercise my right to erasure?

Every confirmation email contains a revoke link. Clicking it triggers an immediate S3 DeleteObject call and removes the DynamoDB metadata row. The link breaks within seconds. If you need an additional channel (for example, you lost the email), contact us through the privacy address on the privacy page and we will action the deletion. The 7-day automatic expiry runs in parallel as a default.

What happens if there is a breach?

Under GDPR Article 33 we would notify the lead supervisory authority within 72 hours of becoming aware of a breach likely to risk individual rights. Under POPIA Section 22 we would notify the South African Information Regulator and affected data subjects as soon as reasonably possible. The notification would include the nature of the breach, the categories of data affected, the likely consequences, and the remediation taken.

Can I use sto.care for sending HR or financial data under GDPR?

For occasional ad-hoc transfers between you and a counterparty, yes, the Article 32 controls (TLS, encryption at rest, access controls, short retention) are appropriate. For systematic processing of HR or financial data on behalf of your employer, you need a signed Data Processing Agreement under Article 28, which sto.care does not offer for consumer users today. In that case, your employer should be using a B2B processor with a DPA in place.

Does sto.care sign Data Processing Agreements?

Not for free consumer use. A DPA under GDPR Article 28 is a contract between a controller (your business) and a processor (us) with required terms covering instructions, sub-processors, security, breach support, and audits. We are a free consumer-grade tool and do not currently offer DPAs. If you need one, the right tool category is a B2B file-transfer service that markets itself for processor relationships.