Why data protection is a role-level obligation, not a platform-level one
When learners search for an EdTech platform, they usually assume that data protection is something the platform "does" for them: a privacy policy at the footer, a cookie banner, a padlock in the URL bar. That framing is comfortable but wrong. In practice, once a learner enrolls, most of the sensitive interactions happen not with the platform layer but with the humans who earn on it: the instructor grading their code, the mentor reading their career doubts, the tutor sitting on a Zoom call with their webcam on, the course provider whose slide deck references a real client project.
At Refonte Learning, we treat data protection as a role-level duty. Every person who earns money on the platform, whether they teach a five-hour module or run a twelve-week cohort, inherits specific legal and operational responsibilities the moment they access learner information. Those responsibilities are not identical across roles. An instructor grading assignments has different exposure than a job mentor reading a candidate's rejection letter from a hiring manager, and both are different again from a course provider licensing pre-recorded content.
This article is a child piece under our pillar on how Refonte vets everyone who earns on the platform. Vetting is the entry gate. Data protection is what happens after the gate opens: the daily habits, the tools, the escalation paths, and the red lines that separate a professional educator from a liability.
We operate under the French SAS Refonte Infini Infiniment Grand (SIREN 949 841 605, verifiable at https://data.inpi.fr/entreprises/949841605), which anchors us in the EU GDPR regime, and we run a UK operational office at 1 Poulton Close, Dover, Kent, CT17 0HL, which means UK GDPR expectations apply in parallel. That dual footprint is not a marketing point; it shapes the concrete controls we require from every earner. If you teach for us, mentor for us, or supply courses to us, you are handling data that sits under two of the strictest privacy regimes in the world.
The rest of this article walks role by role through what that means in practice in 2026. We will look at what each type of earner sees, what they must never do with it, how we audit compliance, what tooling we provide, and what the failure modes look like when someone gets it wrong. If you are considering applying to teach with us, this piece will tell you exactly what you are signing up for. If you already earn on the platform, treat it as a refresher for the audits we run each quarter.
The data map: what each role actually sees
Before discussing duties, it helps to draw the map. Different Refonte Learning roles touch different data categories, and the duty of care scales with sensitivity.
Instructors on a live cohort typically see: the learner's display name and email, submitted assignments (often containing personal code repositories or business context), attendance and grading records, forum posts, and, during synchronous sessions, video and audio. If the cohort runs a capstone project, instructors may also see anonymized or lightly redacted client data that the learner has permission to share.
Mentors, both career mentors and job mentors, see something quite different. They see CVs, salary expectations, interview feedback, employer names, rejection reasons, sometimes mental health context ("I burnt out at my last job"), and occasionally documentation such as visa status or disability accommodations. This is a materially heavier data footprint, and it frequently includes what GDPR classes as special category data. We cover that specifically in our piece on mentor handling of special category data.
Tutors, who typically deliver shorter one-to-one or small-group sessions, sit between the two. They see enough to teach effectively (current skill level, past sessions, sometimes employer context) but generally not the full career file.
Course providers, who license pre-recorded or asynchronous content to the platform, see the least individual-level data. Their exposure is mostly aggregate: completion rates, cohort feedback, sometimes anonymized forum questions used to improve v2 of the course. However, when their material is used inside a live cohort, they may receive derivative information ("learners struggled with module 4") that itself needs careful handling. The duties are laid out in course provider data protection duties.
Advisors and reviewers, a smaller category, see even more targeted slices: a specific curriculum audit, a specific portfolio review, a specific compliance question. Their exposure is narrow but often deep.
Why the map matters: the moment we can name exactly what a role sees, we can name exactly what that role must protect. Generic "be careful with data" guidance fails because it does not tell someone what to do on a Tuesday afternoon when a learner shares a screenshot containing a real customer's phone number. The role-specific playbook does.
The lawful basis question: on what grounds does each role process data
Under GDPR, every processing activity needs a lawful basis. This is where a lot of well-meaning educators trip up: they assume that because the learner enrolled voluntarily, consent covers everything. It does not.
For instructors, the primary lawful basis for handling assignment data, grading, and forum interactions is contract performance: the learner signed up for the course, and the instructor's processing is necessary to deliver that course. Consent is layered on top for optional activities such as recording a session for later playback, using a learner's project as a case study, or publishing testimonials.
For mentors, the picture is more nuanced. The core one-to-one mentoring relationship runs on contract, but the sensitive add-ons (career history, salary discussions, mental health context that emerges naturally) frequently require explicit consent, and that consent must be revocable. A learner who tells their mentor about a burnout episode has not thereby consented to that information being noted permanently in a shared CRM. Mentors need to know the difference.
For course providers and tutors, contract remains the anchor, with legitimate interest occasionally invoked for product improvement (using anonymized feedback to iterate on a module). Legitimate interest requires a documented balancing test, which the platform provides templates for.
This matters because when a learner exercises their rights, whether that is a subject access request, a request for erasure, or a request to restrict processing, the response depends on the lawful basis. A mentor cannot claim contract as the basis for holding notes on a learner's mental health three years after the mentoring relationship ended. That data has to go, unless a separate, documented basis exists.
We teach earners to think in three questions before they process anything: What am I doing with this data? Under what basis am I doing it? How long does that basis remain valid? If any answer is unclear, the escalation path is to the platform's DPO alias, not to guessing.
Instructor duties in a live cohort
Instructors sit at the highest-volume end of the data flow. A single cohort of thirty learners can generate thousands of data points across a twelve-week module: assignments, forum posts, one-to-one office hour transcripts, grading rubrics, feedback recordings. The volume alone creates risk.
The first duty is minimization. Instructors are trained to grade against the rubric, not against the learner's identity. If a submitted notebook contains hardcoded credentials, a real client's database URL, or personal identifiers not required for the exercise, the instructor's job is to flag it and ask the learner to redact and resubmit, not to grade around it. We provide a redaction checklist inside the grading interface that walks instructors through the common cases: API keys, connection strings, real customer names, phone numbers, unmasked screenshots of internal dashboards.
The second duty is channel discipline. Instructors must keep learner communication inside the platform, not in personal DMs, personal email, or WhatsApp. This is not a preference; it is what makes deletion, audit, and subject access possible. A learner who requests erasure cannot have their data deleted from a WhatsApp thread we do not know exists. Instructors who route around this get warned once, then removed. The specifics are in what gets you removed from the platform.
The third duty is session recording hygiene. Live sessions can be recorded only with visible notice and only for playback within the cohort. Recordings are not to be downloaded, clipped for marketing, or shown to future cohorts without a separate consent flow. The platform enforces watermarking and access logs on recordings, but the instructor is the human control: they announce the recording, they confirm learners are aware, they pause for anyone who objects.
The fourth duty is grading confidentiality. Individual grades are visible only to the learner and the instruction team. Instructors do not discuss one learner's performance with another, do not use one learner's work as an anonymized example without permission, and do not export grade sheets to personal spreadsheets. All grading happens inside the platform's grading UI, which logs every view and edit.
When instructors get this right, the invisible reward is that audits become boring. When they get it wrong, the visible penalty is quick: a warning, a mandatory refresher, or removal. The reason for the sharp edge is that a single leaked assignment containing a real client's data is not just a Refonte problem; it is a problem for the learner's employer, the learner's career, and potentially their liberty to work in regulated industries.
Mentor duties and the special category minefield
Mentors carry the heaviest data-protection load on the platform, and it is worth being honest about why: the mentoring relationship generates trust, trust generates disclosure, and disclosure often includes categories of data that GDPR treats as special. Health information, ethnic origin, religious belief, sexual orientation, trade union membership, biometric data, and political opinion all sit in this heightened tier.
Most mentors do not set out to collect special category data. It arrives sideways. A career mentor asks "what is blocking your job search?" and the learner answers "I have ADHD and interview anxiety." A job mentor asks "what happened at your last role?" and hears about a discrimination complaint. A technical mentor asks "why did you leave the fintech role?" and learns about a bereavement. These are not failures of the conversation; they are the conversation working. The failure would be treating that information carelessly afterwards.
The operational rule is simple. Special category data is discussed, not documented. If a mentor needs to remember that a learner has ADHD to adjust session pacing, they can note "pacing preference: shorter blocks with breaks" rather than "learner has ADHD." If a mentor needs to remember that a learner is job hunting under time pressure due to visa constraints, they can note "visa timeline: end of Q2" rather than the underlying immigration category. The functional information stays; the sensitive attribute does not enter the shared record.
When documentation is unavoidable, for instance because the learner explicitly requests an accommodation letter, the mentor uses the platform's structured accommodations form, which encrypts the entry and restricts access. It does not go into free-text session notes.
Mentors also carry the duty of onward transfer control. If a job mentor introduces a candidate to a hiring contact, the mentor decides what the contact sees. A CV, yes. A note that the candidate had a mental health gap, no, unless the candidate has explicitly agreed to that disclosure in writing for that specific introduction. Consent for one purpose does not travel to another. The detailed workflow is covered in job mentor and candidate data protection.
Finally, mentors carry a retention duty. Session notes for an active mentoring relationship are retained for the life of the engagement plus a defined tail (currently twelve months for career mentoring, six months for technical mentoring). After that, they are deleted or anonymized on a rolling basis. Mentors do not keep private archives of past mentees for their own reference. The audit trail must match the retention policy; personal archives break both.
Course provider duties: aggregate does not mean anonymous
Course providers often assume that because they see "aggregate" learner data (completion rates, feedback scores, forum question themes), they are outside the sharp edge of GDPR. They are not.
Aggregation reduces risk; it does not eliminate it. A completion rate for a cohort of eight learners in a niche specialization is close to individually identifying, especially when combined with the provider's knowledge of which employers sponsored the cohort. A forum question quoted verbatim, even without a name, may still identify the asker to anyone who was in the room. A feedback comment mentioning "the mentor from Lagos" identifies a specific mentor in a small pool.
The duty on course providers is therefore threefold. First, treat all cohort-derived data as personal data by default, and only downgrade its handling once a documented anonymization test has been passed. K-anonymity thresholds, currently k of at least five for our smaller cohorts, are the operational floor. Second, keep cohort-derived data inside the provider's contracted scope. Feedback used to iterate on a module is fine; feedback used to build a personal case study for a conference talk is not, absent separate consent. Third, honor the platform's deletion cascade. When a learner exercises erasure, the course provider must be able to identify and delete or anonymize any residual data they hold that traces back to that learner, even in a feedback spreadsheet from eighteen months ago.
The operational lever we use to make this workable is a strict data-out interface. Course providers receive data through structured exports that carry provenance metadata (cohort ID, timestamp, retention deadline). They do not receive raw dumps. The export tooling automatically applies the aggregation and redaction rules for the provider's tier of access. If a provider needs a slice we do not currently support, the request goes through a data protection impact assessment before we build it.
Course providers who follow this rhythm tend to find that their content improves faster, because the structured feedback is more honest than a raw dump would be. Providers who try to route around it, exporting screenshots into personal notes or asking mentors informally for "war stories," trigger removal reviews. The behavior is not tolerated because it undermines every other earner's ability to promise learners a clean data trail.
Tutor duties in one-to-one sessions
Tutors run the shortest and most personal engagements on the platform: a single hour, a small block of sessions, targeted at a specific skill or exam. That intimacy creates a specific set of duties.
The first is session boundary discipline. A tutor is not a mentor, not a therapist, not a career advisor. When a learner brings a broader concern into a tutoring session, the tutor's job is to acknowledge, offer a signposting to the appropriate role (career mentor, job mentor, learner support), and return to the technical work. This is not coldness; it is data hygiene. A tutor who takes on informal mentoring is generating data they are not trained or authorized to handle.
The second is screen-share caution. Tutors frequently ask learners to share their screen to debug code or walk through a workflow. That screen may contain a live email inbox, a Slack notification from the learner's employer, a browser tab with personal banking. Tutors are trained to say, before the share starts, "close anything you would not want me to see, and I will look away while you do it." It sounds informal; it is a documented control.
The third is note minimization. Tutors keep only what is necessary to continue the tutoring arc: current topic, next topic, sticking points. They do not maintain profiles. Their notes are visible to the learner on request and are deleted on a shorter cycle than mentor notes (currently ninety days after the last session).
The fourth is escalation clarity. If a tutor notices something concerning, for instance a learner appearing distressed, a learner sharing code that looks like it belongs to an employer without permission, or a learner asking for help with something that would breach an exam integrity policy, the tutor escalates to the platform's trust and safety alias. They do not investigate, do not counsel, do not adjudicate. Escalation is a data-protective act because it moves the information to a role that is authorized to handle it.
Identity, authentication, and the platform layer
Role-level duties only work if the platform layer underneath them is trustworthy. Earners cannot protect data if the account system leaks it, and learners cannot trust earners if impostors can pose as instructors.
Refonte Learning runs identity verification on every earner at onboarding, refreshed on a schedule and on trigger events (change of country, extended inactivity, complaint pattern). The mechanics are covered in our piece on identity verification for earners. The relevant point for this article is that when an instructor's account acts on a learner's data, we can prove who acted, when, and from where. That is a precondition for meaningful accountability.
Authentication for earners requires MFA. We enforce hardware key or authenticator app options, not SMS, for anyone whose role touches special category data or bulk learner records. Session lengths are shorter for high-privilege roles: a mentor's session in the CRM times out faster than an instructor's session in the grading UI, because the data at stake is more sensitive per view.
Access is scoped by cohort and by role, not by seniority. A senior instructor teaching cohort A does not automatically see cohort B's data. This is boring engineering, but it is the boring engineering that makes the human duties enforceable. If everyone can see everything, no one can be held responsible for anything.
Audit logs cover every access, export, and edit. We do not tell earners when their access is being reviewed; we tell them at onboarding that it will be, and we sample continuously. Log retention outlasts the earner relationship, because forensics on a data incident may need to reach back further than an active contract.
Finally, the platform provides tooling that makes the right behavior the easy behavior. Redaction assistants in the grading UI, consent-capture forms in the mentoring UI, structured export flows for course providers. When we ask earners to do the right thing, we make sure the right thing is not the hard thing.
Cross-role scenarios: when one person wears two hats
A growing share of Refonte earners hold more than one role. A senior instructor may also mentor. A course provider may also run occasional tutoring sessions. A job mentor may also review capstone projects. Combining roles is legitimate and often valuable, but it complicates data protection, and the complications are worth naming.
The first issue is data-basin separation. A person who mentors a learner one quarter and instructs the same learner the next quarter must not carry mentor-context notes into the instruction relationship. The learner's disclosure that they had a difficult manager in their last role is not context the instructor needs to grade their assignment. In practice, this means the earner uses the mentor UI for mentor data and the instructor UI for instructor data, and does not export between them. The platform makes cross-context access visible in audit logs, and repeated blurring is flagged.
The second issue is consent scoping. Consent given to a mentor for one purpose does not travel to the same person acting as instructor. If a learner has consented to their mentor discussing their career gap with a hiring contact, that consent does not authorize the same person, wearing the instructor hat, to reference the gap in a cohort session. Earners are trained to re-ask, in role, for each new purpose.
The third issue is conflict of interest. A job mentor who is also a course provider has an incentive to steer mentees toward their own courses. A mentor who is also a hiring manager at another firm has an incentive to route candidates toward that firm. These are not necessarily wrongdoing, but they are disclosure-worthy, and Refonte requires proactive disclosure at the point the conflict is relevant. The relevant guidance is in combining multiple roles, which sets out both the permitted patterns and the disclosure duties.
The fourth issue is compounded retention. An earner in three roles for a single learner may hold data across three retention schedules. When the learner exercises erasure, all three schedules trigger, and the earner must respond in each context. The platform automates most of this, but the earner has to keep their contexts clean enough for the automation to work.
We do not discourage multi-role earners; the platform benefits from experienced people who can move between teaching, mentoring, and advising. But we require them to work harder on the discipline of role separation, and we test for it in the quarterly audits.
Incident response: what happens when something goes wrong
Data protection cultures are best tested not by their prevention but by their response. Something will go wrong eventually. A shared screen will leak a client name. A mentor will paste a note in the wrong window. A course provider will save an export to a personal drive. The question is what happens next.
Refonte Learning runs a defined incident response flow with four stages: report, contain, assess, notify. The report stage requires the earner to raise the incident through the platform's incident intake within one working day of noticing it. Delayed reporting is treated more seriously than the underlying incident in most cases, because delay is a choice while the underlying incident often is not.
The contain stage is fast and often ugly. We revoke access, pull down exposed material where possible, and lock affected accounts pending review. Earners are expected to cooperate immediately. The platform's DPO leads the containment; the earner supports.
The assess stage looks at scope. What data was exposed, to whom, for how long, in what form, with what likelihood of onward transfer. This drives whether the incident is a reportable breach under GDPR's seventy-two-hour window, whether individual learners need to be notified, and whether the earner remains on the platform.
The notify stage handles regulator notification and learner notification. Refonte handles the regulatory side; the earner supports with facts. Learner notification is a Refonte communication, not the earner's, because a coordinated message is safer than a well-intentioned personal apology that inadvertently discloses more.
After the incident, we run a blameless post-mortem for systemic causes and a separate accountability review for individual conduct. The two are kept separate on purpose. The post-mortem tells us how to change the tooling or the training; the accountability review tells us whether the earner remains fit to earn on the platform. An honest reporter of their own mistake is treated very differently from someone whose incident is uncovered by audit.
Earners who read this and think "that sounds harsh" are reading it correctly. It is harsh because the alternative, a soft response, punishes the ninety-nine earners who did the boring right thing to make the hundredth's shortcut feel acceptable. Data protection is a public good on the platform, and public goods degrade quickly if free-riding is tolerated.
What we ask of earners at application time
Everyone who applies to become an instructor on Refonte Learning, or to mentor, tutor, or supply courses, goes through a data-protection module before their first learner interaction. It is not a video-and-quiz formality. It is a working session with scenarios drawn from real incidents, scrubbed of identifying details, with a written commitment at the end.
Applicants can expect: a role-specific walk-through of what data they will see, a working exercise in redaction and note minimization, a scenario-based assessment on consent and lawful basis, a review of the platform's tooling for their role, and a signed data-processing addendum to their earner contract. Applicants who cannot pass the assessment do not proceed. Applicants who pass but seem uncomfortable with the discipline are counseled toward a role with lower data exposure, for instance a course provider role rather than a mentoring role.
The module is refreshed annually and re-taken by every active earner. Regulation changes, threat models change, and the platform's own tooling changes. What was best practice in 2024 is not automatically best practice in 2026. The refresh is short but mandatory, and non-completion suspends the earner's access to learner data until it is done.
We are open about the fact that this raises the friction of joining the platform. That is deliberate. A meaningful proportion of applicants drop out at the data-protection module, and we are content with that. The ones who complete it are the ones who understand that trust with learners is the underlying asset of the entire platform, and that trust is preserved by the boring, daily discipline of handling data well.
If you are considering supplying teaching, mentoring, tutoring, or advisory work to Refonte Learning, and you want to know what the job actually asks of you day to day, we would rather you read this article and the linked pieces first than skip them and discover the duties on your first day. And if the answer is yes, this is the discipline I already practice, then apply to teach on Refonte Learning and start the conversation. The data protection module is waiting.
About Refonte Learning
Refonte Learning is operated by Refonte Infini Infiniment Grand, a French SAS registered at SIREN 949 841 605, with an operational office at 1 Poulton Close, Dover, Kent, United Kingdom, CT17 0HL. We deliver professional training in AI, data, cloud, DevOps, and software engineering through a mix of live cohorts, one-to-one mentoring, and licensed asynchronous content. Every person who earns on the platform is vetted, verified, and trained in role-specific data protection before their first learner interaction, because trust with learners is the platform's most important asset, and trust is built by the daily discipline of handling data well.