• Product

Our Approach to Privacy

Why you can trust us

Ask anything with your LLM

Select a question

At RM Compare, privacy isn't a feature we've bolted on—it's built into how we operate. We're committed to transparency about what data we process, how we use it, and what we don't do with it. This page explains our approach in detail.

Our Privacy Principles

We believe assessment data is sensitive and belongs to you. That's why:

• You own your data. Schools, colleges, and awarding bodies remain data controllers; we act as your processor, handling data only on your instructions.
• We follow best practice. We align with the ICO's guidance on data protection and are certified ISO 27001 for information security. We run on Amazon Web Services (AWS), which provides world-class security infrastructure and compliance certifications.
• We design for privacy. We don't collect data "just in case." Our architecture is built around data minimisation. We use email addresses for operational purposes and keep assessment work anonymised whenever possible.
• We're transparent. You'll always know what we hold, how we use it, and what we don't do with your data.

Data Minimisation: What We Do and Don't Ingest

What Data Does RM Compare NOT Ingest?

RM Compare deliberately does not import:

• Student names linked to assessment work
• Student ID numbers or registration numbers linked to submissions
• Demographic data (age, gender, ethnicity, postcode)
• Rosters or class lists from your MIS, SIS or other systems
• Linked student records that would allow re-identification of assessment work

What Data Does RM Compare Ingest?

RM Compare processes only what's necessary:

For all assessment scenarios:

• Judge/assessor email addresses – to invite judges, send session invitations, manage authentication, and deliver results
• Anonymised work and artefacts – essays, designs, recordings, portfolios uploaded without student names or identifiers
• Judgements and comparisons – the results of comparative assessment (which submission is stronger) without reference to individual students
• Anonymised results and statistics – rank orders, consistency metrics, feedback
• Anonymised usage data – how many judges participated, session duration, system performance

For contributing judge scenarios only (peer assessment, "learning by evaluating"):

• Student email addresses – to invite students as judges and send them feedback on their own submission
• Student submissions linked to their email – so they can receive feedback on their own work

Important: Even in contributing judge scenarios, when students judge peer work, that peer work remains anonymised - they don't know whose work they're assessing, only their own.

How This Works in Practice

Scenario 1: Teacher-Led Moderation

A history teacher uploads 25 student essays for moderation using her own internal labelling scheme ("Q2-A," "Q2-B," etc.). She invites three colleagues via email to judge. They compare the essays and RM Compare returns a rank order and consistency feedback. The teacher then maps results back to named students using her own key, work that happens outside RM Compare.

Data we hold: Judge email addresses, anonymised essays, judgements
Data we don't hold: Student names, IDs, or who wrote what

Scenario 2: Multi-School Moderation

Three schools in a MAT upload anonymised GCSE work samples ("School A - Sample 1," etc.). Judges from all three schools compare across the samples. RM Compare identifies alignment issues. Each school maps results back to their students.

Data we hold: Judge email addresses, anonymised work, judgements
Data we don't hold: Student rosters or identity-to-work links

Scenario 3: AI Validation

An awarding body tests an AI marking system against human assessors. They upload anonymised exam papers and AI-generated scores. Expert assessors (invited via email) compare AI scores to human benchmarks. RM Compare shows where they diverge, helping validate the system.

Data we hold: Assessor email addresses, anonymised papers, AI scores, judgements
Data we don't hold: Student names, IDs, or links to individual candidates

Scenario 4: Peer Assessment / Contributing Judge Workflows

A lecturer runs a "learning by evaluating" session. Thirty students submit essays and judge five peer essays each. Students receive email invitations, upload their own essay (linked to their email), judge five anonymised peer essays, and receive personalised feedback on their submission.

Data we hold: Student email addresses, student submissions linked to email, anonymised peer judgements
Data we don't hold: Student names, IDs, or which student wrote which peer essay that others judged
Key difference: In this scenario, we know which student submitted which essay, but peer work remains anonymous during judging.

Why This Matters

Compliance is Straightforward

• Simpler Data Protection Impact Assessments (DPIA): You don't need to provide extensive processor instructions about handling student rosters because we don't handle them.
• Clear data controller role: You decide why data is processed (formative assessment, moderation, validation); we process on your instructions only.
• No role ambiguity: There's no question about whose responsibility data security is - we're clearly your processor.
• Lower breach risk: If RM Compare were ever breached, we don't hold student rosters or identity-to-work links (except in contributing judge scenarios where pedagogically necessary).

Operational Simplicity

• No roster synchronisation: You don't need to manage MIS exports or worry about keeping rosters in sync.
• No identity mismatches: Because we don't link work to students automatically, you can't accidentally upload the wrong data or mix up results.
• Flexible integration: You decide when and how to link RM Compare results back to your student records in your own systems, where you maintain full control.

Data Ownership and Portability

• Clear boundaries: We hold work and judgements; you hold the key to student identity.
• Easy export: You can export results and artefacts anytime without extracting linked student data.
• No vendor lock-in: Because we don't hold rosters or necessary identity-to-work links, you're never locked in for data reasons.

How We Protect Your Data

Security and Compliance

• ISO 27001 certified: Our information security management meets international standards.
• AWS infrastructure: World-class security, backup, and disaster recovery.
• Secure by default: We use encryption in transit and at rest, secure session management, and role-based access controls.
• Regular audits: We conduct ongoing security assessments and penetration testing.

In-Product Privacy Controls

RM Compare gives you granular control over data sharing:

• DataShare: Explicit controls for which data is shared across organisations. Nothing is shared unless you choose it.
• Connectors: Safe integrations with your MIS, LMS, and other platforms scoped to pass results and artefacts, not rosters.
• Licence Centre management: Transparent visibility into which tenants/users have access to what data.
• Anonymisation controls: You label and control submission identifiers; RM Compare never sees student names.

Your Responsibilities

As data controller, you're responsible for:

• Informing users: Telling students, teachers, and other users that their assessment data will be processed by RM Compare.
• Managing consent: Obtaining consent where required by law or policy (particularly for contributing judge scenarios).
• Secure uploads: Ensuring you don't accidentally upload identifying information.
• Access governance: Managing who in your organisation has access to RM Compare and results.

We'll support you with templates, guidance, and our privacy statement to help you meet these obligations.

Our Commitment

RM Compare commits to:

• Never import student rosters by default or without explicit, documented consent.
• Use email addresses only for legitimate operational purposes - inviting judges, delivering results, supporting contributing judge workflows.
• Never use student work to train general-purpose AI models without clear, separate consent.
• Publish clearly what data we ingest and why. If our approach changes, we'll update this page and notify customers.
• Support privacy-first integrations with your existing systems.
• Remain transparent about our practices and open to questions.

Continuous Improvement

We review our privacy practices regularly to ensure they reflect evolving regulations, best practices, and customer needs. If you have feedback or questions about our approach please contact us

Related resources:

• Blog: Privacy by Design: Why RM Compare Minimises Student Data
• Standards & Compliance (in this section)
• Data processing agreement and contract terms (available on request)
• ICO guidance on controllers and processors: https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/controllers-and-processors/

Related Articles

• FAQs

Related Questions

• How do I report results to individual students if RM Compare doesn't hold their names?

  You manage that mapping outside RM Compare. Use your own labelling scheme (codes only you understand), get results back anonymised from RM Compare, then use your records to generate individual reports. This keeps identity governance simple and gives you full control.

• How do I integrate with my LMS or MIS?

  Integrations work at the results level, not the roster level. Your LMS sends anonymised artefacts or student emails (in contributing judge scenarios), RM Compare returns anonymised results, and you map back to students in your own system. We're building connectors with major platforms following this pattern.

• Why do you collect judge email addresses?

  We use judge emails for legitimate operational purposes: sending session invitations, authentication, notifications, and delivering results. We don't use them for marketing, AI training, or cross-customer analytics without explicit consent.

• Does RM Compare comply with GDPR, FERPA, and other regulations?

  Yes. Our data minimisation approach aligns with regulations worldwide:

  • UK GDPR / GDPR (EU): Data minimisation is a core requirement; we meet it.
  • FERPA (US): By not holding student names/IDs linked to work (except where pedagogically necessary), we minimise FERPA risk.
  • Other jurisdictions: Most data protection laws encourage vendors to minimise data ingestion.

• Doesn't data minimisation limit what RM Compare can do?

  No. Anonymised work, judgements, and operational emails are sufficient for formative assessment, moderation, AI validation, comparative assessment, professional development, and peer learning. The only use cases requiring full rosters are those needing student identity tracking outside of assessment purposes—and for those, you can manage the link in your own systems.