WEBINAR @ 13th May, 2 PM (GMT+1)
What's Stopping Progress in Higher Education?
Register now
Admissions creates a particularly demanding privacy environment, and higher education adds several layers of operational complexity.
Personal data starts arriving long before anyone formally applies: at an open day, in a webinar form, on a campaign landing page, or through a list shared by a recruitment agent. Applicants then upload sensitive documents such as passports, transcripts, references, and sometimes health, disability or accessibility disclosures. Many teams need different levels of access to the same record, that data moves into finance, identity and student systems, and much of it stays relevant after a decision. Operational messages and marketing overlap constantly, and applicants rarely distinguish between them.
It is tempting to treat this as a software problem: buy a customer relationship management (CRM) system with a consent feature and consider it handled. That is not how the General Data Protection Regulation (GDPR) works.
Here is the direct answer. A higher education admissions CRM must do more than store consent. It should help institutions record purposes and lawful bases, display and version privacy information, minimise collection, restrict access, protect sensitive documents, apply retention policies, support individual rights, maintain audit trails and govern integrations. The institution remains responsible for how those controls are configured and used. A CRM does not make a university GDPR compliant; it makes the institution's own decisions easier to implement, enforce, audit and review.
This article is educational and does not provide legal advice; GDPR obligations depend on the institution, jurisdiction, purpose and context, so confirm your approach with your data protection officer (DPO) and qualified legal advisers. We use the EU GDPR as the primary framework and note relevant UK GDPR, Data Protection Act 2018 and Data (Use and Access) Act 2025 (DUAA) considerations separately where they diverge.
The development and maintenance of an in-house system is a complex and time-consuming task. Full Fabric lets you turn your full attention to maximizing growth and performance.
GDPR compliance in admissions is the institution's ability to demonstrate that every use of applicant data has a clear purpose, an appropriate lawful basis, proportionate collection, controlled access, defined retention and respected individual rights, supported by evidence. That is an institutional responsibility, not a product feature: the institution owns its purposes, lawful bases, retention, privacy information, rights responses, processor relationships, DPIA decisions, training and policies, while CRM functionality makes those decisions repeatable for teams who are not privacy specialists.
The EU GDPR rests on seven principles, and a CRM should help honour each: lawfulness, fairness and transparency; purpose limitation; data minimisation; accuracy; storage limitation; integrity and confidentiality; and accountability. Accountability pulls the others together: the institution must not only comply but be able to show how. Data protection by design and by default (Article 25) underpins this. The European Data Protection Board (EDPB) is clear that these considerations belong before processing begins and should be reviewed throughout the lifecycle, so privacy decisions belong at the point a form, workflow or integration is designed.
Different purposes, lawful bases, access needs and retention periods may apply at different stages.
Initial enquiry. Website forms, event registrations, webinars, open days, campaign landing pages, enquiries from education agents, purchased or shared data where lawful, and regional application services. The purpose and appropriate lawful basis need to be established at this first touch, together with consent where the institution relies on it or where applicable marketing rules require it. These decisions are often implemented by recruitment teams whose primary remit is not privacy.
Application. Contact details, date of birth, nationality and residency, identification documents, academic history, transcripts, employment history, personal statements, references, financial and sponsorship information, and programme preferences.
Evaluation. Reviewer comments, interview notes, scoring, rankings, automated recommendations and decision rationales. Some of this is personal data about third parties such as referees.
Offer and enrolment. Offer conditions, acceptance, deposits, payment status, visa or immigration documentation where relevant, enrolment forms and student identifiers.
Post-decision. Rejected and withdrawn applications, deferred applicants, reapplications, enrolled students, and alumni or future-learning communications.
Without a single connected record, the same applicant can exist as a CRM contact, a spreadsheet row, a shared-drive folder, an admissions-tool profile and a student information system (SIS) record, each with different consent states and no shared audit trail. Every fragmentation point is a governance risk.
Roles under GDPR are defined by who determines the purposes and means of processing, not who holds the data.
In admissions, the institution commonly determines the purposes and essential means and therefore acts as controller, and a CRM vendor commonly acts as processor when it processes applicant data on the institution's documented instructions. However, roles depend on the specific activity: a vendor that reuses customer data for its own purposes, for example to train shared models, may be a controller for that activity. Roles should be assessed per activity and reflected in the contract.
Where a vendor acts as a processor, GDPR requires an Article 28 contract, commonly a Data Processing Agreement (DPA), covering the subject matter and duration, the nature and purpose of processing, the types of data, confidentiality, security, assistance with rights requests, breach notification, deletion or return at termination, audit rights and subprocessors, as the ICO's guidance on controllers, processors and contracts sets out. Accountability cannot be outsourced: using an agent, aggregator or cloud vendor does not transfer institutional responsibility away.
Consent is one possible lawful basis, not the only one, and often not the most appropriate.
The EU GDPR sets out six bases in Article 6: consent; steps before entering a contract, and performance of a contract; legal obligation; vital interests in limited circumstances; public task; and legitimate interests, each described in the European Commission's guidance on legal grounds for processing. Different activities relating to one applicant may rest on different bases: an application may sit under steps before a contract or public task, statutory reporting under legal obligation, and optional marketing may require consent or another route. The appropriate basis must be determined before processing begins and documented by the institution. Treating consent as the default is a mistake, because it carries specific requirements and can be withdrawn, which is disruptive if the institution relied on it for processing that should have rested elsewhere. The ICO's guidance on lawful basis and on consent is a useful reference.
A further distinction is frequently mishandled. The transparency obligation is met by providing the required privacy information clearly and at the appropriate time; recording which notice was shown, its version and the collection context helps demonstrate this. Requiring an applicant to acknowledge or accept the notice is not what makes the processing lawful, and that acknowledgement does not constitute consent to every purpose. A CRM should record which notice was displayed, its version, when it was shown, the collection source, any acknowledgement, and, separately, any specific consent requested with the purpose and channel it covered.
A CRM that merely stores applicant data is not enough, and one that adds consent checkboxes without data governance is not enough either. The requirements below turn institutional decisions into repeatable operational controls. None of them, alone or together, constitutes compliance; they form the operational layer on which policy is applied.
The CRM should help record the purpose, the lawful basis chosen by the institution, the data source, the lifecycle stage, the programme or campaign, any Article 9 condition where special category data is involved, and the supporting assessment where appropriate. It must not select the lawful basis automatically without governance, and it should accommodate different purposes and bases for the same applicant rather than forcing a single label.
Transparency depends on showing what an applicant was told, and when. The CRM should support notices at the point of collection, layered or contextual notices, version history, timestamps, source tracking and evidence of what was seen.
It should support Article 14 workflows for data received indirectly, for example from agents, partner institutions, lead lists, referrals or imported event lists. Where personal data is obtained indirectly, Article 14 generally requires the information to be provided within a reasonable period and no later than one month, or at the time of the first communication with the applicant if earlier, or before the first disclosure to another recipient if that applies, subject to the Regulation's exceptions, which should be checked case by case.
Full Fabric can present the institution's privacy information at collection points and maintain a record of policy agreements and consent history. The institution remains responsible for deciding whether an acknowledgement, agreement or separate consent is appropriate for each purpose and lawful basis.
The CRM should distinguish acknowledgement of a notice, consent to a specific optional activity, acceptance of terms, contractual or admissions processing, and marketing preferences. A single mandatory checkbox labelled "I agree to everything" is not adequate: it bundles distinct decisions, obscures what the applicant agreed to, and makes it impossible to honour a change of mind about one purpose without disrupting the others.
Where consent is the basis, the CRM should record the precise purpose, the channel, the programme or category, the date and time, the source, the wording shown, the version, the affirmative action, any withdrawal, and suppression status. Withdrawal should be as easy to process as collection. Withdrawing marketing consent does not require deleting the admissions record; a limited suppression record may need to remain so the institution can respect the opt-out. Deleting an email address entirely and then marketing to it again is a common, avoidable failure.
Minimisation is a design decision expressed through forms. The CRM should let institutions control which fields appear on each form, use conditional fields, avoid collecting information too early, restrict optional questions, justify required fields, remove obsolete fields, limit free-text collection where structured data is safer, and review imported data before use. It should not require every possible field at enquiry stage: asking for a passport number or disability disclosure before it is needed is unnecessary collection that increases risk.
The CRM should support field-level or record-level access restrictions, restricted document categories, purpose-specific permissions, separate workflows for disability or health information, limits on reviewer access, audit trails, secure document storage and retention appropriate to the category. Not all admissions staff should see health, equality or accessibility information, and a decision-maker does not necessarily need to see monitoring data such as ethnicity. Because special category data sitting alongside evaluation invites inappropriate inference, separate it from decision workflows unless there is a clear, lawful reason for it to be visible there.
Admissions data may be touched by central admissions, programme teams, faculty reviewers, marketing, finance, registry, student services, IT administrators and external reviewers. The CRM should support access based on role, programme, campus, region, lifecycle stage, record type, document type and responsibility. Least privilege means each user sees only what their role requires, and because roles change, the CRM should support periodic access reviews and rapid adjustment when someone moves or leaves.
The CRM should record data creation, field changes, document uploads and downloads where supported, consent and preference changes, notice acceptance, exports, decisions, user and administrative actions where appropriate, retention and deletion actions, and integration events. Logs do not prove compliance on their own: they must be understandable, retained appropriately and reviewable, ideally emerging as a by-product of normal work so a rights request does not become a forensic exercise.
Retention is not a single deletion date. The CRM should allow different policies by record type and status: enquiry with no application, incomplete, withdrawn, rejected, accepted, enrolled, deferred, reapplicant, financial or contractual records, complaints or appeals, legal holds and statutory requirements. There is no universal period; institutions set retention against their purposes and legal obligations. The CRM should support scheduled review, archival, anonymisation where appropriate, purging, legal holds, deletion evidence, handling of linked records and controlled backup restoration, so the institution's schedule becomes enforceable and evidenced.
The CRM should help with the right to be informed, access, rectification, erasure where applicable, restriction, portability where applicable, objection, and rights relating to automated decisions. Useful capabilities include locating all records for one person, identifying duplicates, exporting data, correcting consistently, restricting processing without deleting, recording the request, assigning ownership, tracking deadlines, recording identity verification, documenting the response and identifying data shared with connected systems.
Two cautions matter. Applicant records often contain third-party personal data, such as references, requiring review before disclosure. And no CRM completes every request automatically: erasure is not absolute but subject to exemptions, for example where retention is required for a legal obligation or the defence of legal claims. Qualified staff must review the result. The ICO's guidance on subject access, erasure and the right to be informed sets out how these rights operate.
The CRM should support secure uploads, role-controlled downloads, reduced reliance on email attachments, controlled exports, export logging, integration authentication, minimum necessary fields, purpose-specific data flows, monitoring and error handling, and documented systems of record. Integrations reduce unmanaged spreadsheets but create new data flows that must be governed: every export is a copy of personal data leaving the governed environment.
Institutions should evaluate the controller and processor roles for each service, the Article 28 terms, processing instructions, confidentiality, security, rights-request assistance, breach notification, deletion or return at termination, audit rights, subprocessor approval and notification, processing locations, international transfers, whether the vendor uses data for its own purposes, and whether customer data trains shared AI models. A polished interface does not replace a suitable DPA; the contract, not the screen, is where processor obligations live.
The CRM and vendor should support security-event logging, incident escalation, breach investigation, evidence preservation, identification of affected records and data categories, communication between processor and controller, and documented response responsibilities. Notification obligations depend on risk and jurisdiction, and not every incident is a reportable breach. Under the EU GDPR, a personal data breach must be reported to the relevant supervisory authority without undue delay and, where feasible, within 72 hours of the controller becoming aware, unless it is unlikely to result in a risk to individuals. The 72-hour period therefore applies to reportable breaches and starts when the controller becomes aware, subject to the relevant framework. A processor that becomes aware of a breach must inform the controller without undue delay. The ICO's breach guidance sets out the UK position.
Admissions CRMs increasingly offer scoring, document classification, predictive models, prioritisation, recommendations, AI summaries and workflow automation. The CRM should support human review, decision ownership, role-based AI access, transparent criteria, auditability, data minimisation, model and vendor documentation, bias and accuracy testing, override mechanisms, a record of whether AI influenced a decision, restrictions on special category data, and separation between administrative automation and consequential decision-making.
The EU and UK regimes now differ, so treat them separately. Under the EU GDPR, Article 22 concerns decisions based solely on automated processing that produce legal or similarly significant effects; not every automated workflow falls under it, and the EDPB has emphasised that human involvement must be genuine, not a rubber-stamp, for a decision to fall outside the solely-automated category. In the UK, the DUAA 2025 replaced Article 22 with new provisions (Articles 22A to 22D), in force from 5 February 2026, moving to a more permissive model, with specific restrictions where significant, solely automated decisions rest on special category data and with requirements to inform individuals and let them challenge such decisions. Institutions processing UK and EU data should not assume one approach satisfies both. The ICO consulted on draft updated automated decision-making and profiling guidance between March and May 2026; at the time of writing, institutions should check the ICO website for the final version and should not rely solely on older Article 22 guidance that predates the DUAA changes.
Full Fabric positions its contextual AI as a permission-aware layer within the platform, with support for visible steps, auditability and human verification of sensitive outputs. It states that the AI Console is designed to assist staff, not replace institutional judgement, and that outputs affecting a record should be verified against the underlying data. Institutions must still evaluate the exact workflow, the data involved, the lawful basis, transparency requirements, vendor terms and the level of human involvement before using it in admissions.
A starting point for evaluation, not a compliance guarantee.
| CRM requirement | GDPR principle or operational need | What the platform should support | Evidence to request from the vendor | Warning signs |
|---|---|---|---|---|
| Lawful basis | Lawfulness; accountability | Recording purpose and basis per activity | Configuration examples; documentation | Basis assigned automatically with no governance |
| Privacy notices | Transparency | Versioned notices, timestamps, source, Article 14 workflows | Screenshots of version history | No record of which notice was shown |
| Consent | Lawfulness; fairness | Granular capture, withdrawal, suppression | Consent audit export | Bundled or pre-ticked consent |
| Minimisation | Data minimisation | Configurable, conditional fields | Form builder walkthrough | Mandatory sensitive fields at enquiry |
| Role-based access | Integrity and confidentiality | Access by role, programme, field, document | Permissions matrix; review logs | All users see everything |
| Special category data | Article 9; safeguards | Separated storage and access | Field-level restriction demo | Health data visible to all reviewers |
| Audit logs | Accountability | Reviewable, retained event history | Sample audit report | Logs absent or unreadable |
| Retention | Storage limitation | Policy by record type; archival, purge, hold | Retention configuration | One universal deletion date |
| Rights requests | Individual rights | Locate, export, restrict, correct, document | SAR workflow demo | Fully manual archaeology |
| Integrations | Integrity; accountability | Authenticated, logged, minimal flows | Data flow map | Undocumented exports |
| Processor governance | Accountability | Article 28 terms; subprocessor list | DPA; subprocessor register | No written DPA |
| International transfers | Chapter V | Transfer mechanism and hosting detail | Transfer documentation | "EU hosting" offered as the whole answer |
| Breach response | Integrity and confidentiality | Detection, escalation, controller notification | Incident process | No defined notification timeline |
| AI and profiling | Fairness; Article 22 | Human review, audit, override | AI documentation | Automated decisions with no oversight |
Vendors often lead with a "consent management" feature as though it answers GDPR. It does not, because consent is only one lawful basis. Admissions processing may continue under another basis even when marketing consent is withdrawn: an applicant who opts out of newsletters still receives the offer letter for the programme they applied to. Where consent is used, it should be specific and granular, given by a clear affirmative action; pre-ticked boxes and silence are not consent, and bundled consent is problematic. Withdrawal should be recorded and respected, separate purposes may need separate decisions, and the institution must keep the evidence.
Three things applicants experience as one are worth separating:
In the UK, the Privacy and Electronic Communications Regulations (PECR) apply alongside the UK GDPR to electronic direct marketing. Marketing by email, SMS or similar channels may require consent, or may be permitted through a specific exception or soft opt-in, depending on the institution, its legal status, its relationship with the recipient, the type of communication and national law. An existing product and service soft opt-in may apply where all its conditions are met. The DUAA 2025 introduced a separate charitable purposes soft opt-in from 5 February 2026, but it applies only to organisations meeting the legal definition of a charity and only where all statutory conditions are met, so not every university or education provider can assume it qualifies. The DUAA also inserted a statutory example confirming direct marketing can be a legitimate interest under the UK GDPR, but this does not override PECR's separate requirements for electronic marketing, and every message must still offer a clear means to opt out where required. For EU institutions, national implementations of the ePrivacy framework may apply.
Some applicant data is more sensitive and attracts stricter rules: disability and accessibility information, health declarations, equality-monitoring data, religious information where relevant, biometric identification, and inferred special category information. Criminal offence data is subject to separate rules under Article 10 and is not, technically, special category data.
Processing special category data lawfully requires two things at once: an Article 6 lawful basis and a separate Article 9 condition, with appropriate safeguards. Consent is not automatically the appropriate Article 9 condition, and institutions should not default to it. The ICO's guidance on special category data explains the conditions and safeguards.
For each type, the institution should consider whether collection is necessary at all, when it is genuinely needed, who should have access, whether it should be separated from decision workflows, the Article 6 basis and Article 9 condition, applicable national law, whether a DPIA is required, retention and human review. A DPIA is required where processing is likely to result in a high risk to individuals, and large-scale processing of special category data in admissions can fall into that territory. Equality-monitoring information should not normally influence admissions decisions, and where collected for monitoring it should generally be separated from evaluation so it cannot, by design, affect an individual outcome.
The purpose of each message determines how it should be treated.
| Communication | Likely category to assess |
|---|---|
| Application receipt | Operational admissions communication |
| Missing-document reminder | Operational admissions communication |
| Interview invitation | Operational admissions communication |
| Offer notification | Operational admissions communication |
| Unrelated programme promotion | Direct marketing |
| Newsletter | Direct marketing |
| Future intake campaign | Direct marketing |
| Event promotion | May be direct marketing depending on context |
These are categories to assess, not definitive legal bases; the institution must assess the purpose and applicable law. For UK readers, current PECR rules on electronic mail marketing are the relevant reference alongside the UK GDPR, and the ICO's direct marketing guidance is the practical source. For a CRM, suppression and preference controls must work across every channel used: email, SMS, messaging platforms, telephone preferences where recorded, and connected marketing tools, since an opt-out that applies in one tool but not another is a governance gap.
Retention drift, keeping data longer than the institution's stated policy, is a recurring operational risk in higher education. The answer is not a single deletion date but a set of treatments reflecting different purposes and obligations.
Different records may need different handling: unsuccessful, incomplete, withdrawn and accepted applications, deposits and payments, appeals and complaints, visa or immigration evidence, equality monitoring, communications and reapplication. A CRM should let institutions separate the active operational record, the archived record, anonymised data, a suppressed marketing record, a legally retained record, and deleted or purged data. Anonymisation, done properly, retains statistical value without retaining personal data, and legal holds should override scheduled deletion where a complaint, appeal or investigation is live. This article does not recommend specific periods, because they depend on institutional purpose and jurisdiction; the CRM's job is to make the institution's schedule enforceable and evidenced.
A practical rights-request workflow, supported by the CRM but reviewed by qualified staff:
The CRM should make each step faster and more reliable, particularly locating every record for one person and identifying duplicates. It should not be assumed to complete the request unattended, because third-party data, exemptions and the balance between different people's rights require human judgement. The European Commission's individual-requests guidance and the ICO's subject access guidance set out the expectations.
From 19 June 2026, organisations subject to the relevant UK requirements must operate a process for handling data protection complaints under the Data (Use and Access) Act 2025. The obligation applies to controllers, with no exemptions.
The process should let the organisation provide a clear way to submit a complaint, acknowledge receipt within 30 days, investigate without undue delay, keep the complainant appropriately informed, communicate the outcome, and retain an appropriate record. Individuals should also be told about their right to complain, for example in a privacy notice.
An admissions CRM need not be a complete complaints-management system, but it should support the process through complaint logging, assignment to an accountable owner, links to the applicant record and relevant documents and communications, status and deadline tracking, access restrictions, audit history, and recording the response and outcome. This is a UK requirement under the DUAA; it is not an equivalent EU-wide obligation under the EU GDPR.
International recruitment multiplies the parties touching applicant data: agents, application aggregators, partner schools, regional application services, overseas campuses, cloud vendors, communication and document-verification providers, payment providers and AI vendors.
For each, the institution should know who collected the data, what privacy information was provided and for what purpose, which lawful basis applies, whether data is shared or processed on instructions, where it is accessed, which transfer mechanism and subprocessors are involved, and whether it is reused for unrelated purposes.
Two points are easy to get wrong. Using an agent does not transfer accountability away from the institution. And data residency is not the same as international-transfer compliance: residency is where data is stored, while transfer compliance concerns the legal conditions under which data is made available or transferred across jurisdictions. An EU data centre can be relevant but does not answer every transfer question or automatically make a transfer lawful. Under the EU GDPR, transfers outside the EEA rely on mechanisms such as an adequacy decision or appropriate safeguards, including the Commission's Standard Contractual Clauses (SCCs). The UK operates its own mechanisms, including the International Data Transfer Agreement and the UK addendum, and the DUAA 2025 introduced a revised approach to assessing transfers. "EU hosting" offered as a complete transfer assessment is a warning sign.
Security is a GDPR requirement (integrity and confidentiality), not an optional extra. A practical admissions CRM should support single sign-on (SSO), multi-factor authentication, least privilege, field and document restrictions, encryption in transit and at rest, secure backups and tested recovery, vulnerability management and penetration testing, logging, session controls, access reviews, secure development, incident response, subprocessor security, secure exports, careful handling of integration credentials, and resilience.
Two cautions apply. Encryption alone does not create compliance, and no certification proves GDPR compliance. Certifications such as ISO 27001 or SOC 2 describe the scope of an information security management system or a set of controls; they are evidence of security practice, not a substitute for the institution's own accountability. Any specific Full Fabric certification claims should be confirmed against current official material on the security and GDPR and Trust Center pages. Integrations deserve attention because they are where governed data becomes mobile: each connection should be defined, authenticated, minimal, logged and reviewed when it changes.
AI is now routine in admissions tooling, engaging fairness, transparency, data minimisation and, where decisions are significant and solely automated, the provisions covered in requirement 14. The governance questions are practical: does a human meaningfully review consequential outputs, or is the review a formality? Is AI access restricted by role, are the criteria transparent and auditable, is special category data kept out of scoring unless lawful and necessary, and can a reviewer override the system? In both the EU and UK frames, the safe pattern is the same: keep meaningful human involvement in consequential decisions, document the logic, and be able to explain and challenge outcomes. Full Fabric's article on AI in higher education admissions explores this further.
Use these to test whether a platform can support your decisions, and ask the vendor to demonstrate the capability rather than describe it.
A phased approach keeps policy ownership inside the institution while the platform is configured to reflect it.
Phase 1: Map admissions data. Collection points, systems, forms, imports, agents, integrations, documents, teams, exports and communications.
Phase 2: Define purposes and ownership. For each activity, document the purpose, owner, lawful basis, relevant Article 9 condition where applicable, required fields, recipients, system of record and retention policy.
Phase 3: Configure privacy and consent. Privacy notices, notice versions, consent requests, preference centres, opt-outs, Article 14 workflows and suppression.
Phase 4: Configure access. Map roles and permissions across recruitment, admissions, reviewers, finance, registry, IT, student services and external users.
Phase 5: Clean and migrate data. Duplicates, missing source information, obsolete consent records, unnecessary fields, ungoverned documents, inactive records and imported lists.
Phase 6: Configure retention and rights workflows. Test access, rectification, restriction, erasure, objection, export, archival, purge, legal holds and withdrawal, and set up complaint logging.
Phase 7: Validate integrations and vendors. Data exchanged, authentication, processors, subprocessors, transfer mechanisms, error handling, logging and termination arrangements.
Phase 8: Train and review. Train admissions and recruitment staff on lawful basis versus consent, marketing preferences, sensitive data, exports, access, incident escalation, rights requests, complaints and AI use, and review the configuration periodically.
Full Fabric is a purpose-built higher education platform: a CRM and student lifecycle platform connecting relationship management, recruitment, admissions, enrolment, student information, records, communications and reporting around one connected record per person. Built for European higher education, it is designed to reduce duplicated records and unmanaged handoffs, and to support GDPR-aligned operations through configurable controls: role-based access, consent and preference management, privacy-notice workflows, auditability, retention, archival and purging, individual-rights workflows and data export, and integrations with institutional systems.
What Full Fabric does not do is make an institution GDPR compliant automatically. Compliance is not delivered by software; it is the outcome of decisions, policies, configuration, training and governance the institution owns. Full Fabric provides the operational layer on which those decisions are expressed and enforced. It is commonly a processor when acting on an institution's documented instructions, though roles must be assessed for the specific activity, and it does not provide legal advice or replace the institution's DPO or legal advisers. That boundary applies to any admissions CRM: the platform turns privacy decisions into repeatable operational controls, and responsibility for those decisions stays with the institution.
GDPR compliance in higher education admissions is an institutional achievement, supported by software but never delivered by it. The institution defines purposes and lawful bases, sets retention, provides privacy information, governs access, handles rights requests and complaints, and maintains accountability, while a capable admissions CRM makes each of those decisions easier to implement, enforce, audit and review.
The test to apply to any platform is straightforward. Does it help the institution know why applicant data was collected, which lawful basis applies, what the applicant was told, who can see the record, how long it is kept, and how a rights request would be answered, with evidence at every step? A CRM that merely stores data does not pass; nor does one that adds consent checkboxes without data governance. A CRM that turns privacy and governance decisions into operational controls, while leaving those decisions where they belong, does. Institutions should confirm their approach with their DPO and qualified legal advisers.
No. Compliance is the outcome of institutional decisions, policies, configuration, training and governance, not a product feature. A CRM makes those decisions easier to implement and evidence, but the institution determines its purposes, lawful bases, retention and access, and remains accountable. Treat any vendor claiming to deliver compliance with caution.
Not necessarily. Consent is one of six lawful bases, and often not the most appropriate for core admissions processing, which may rest on steps before a contract, performance of a contract, public task or legal obligation depending on the institution. The appropriate basis must be determined and documented before processing begins, ideally with the institution's DPO.
It includes information revealing racial or ethnic origin, religious or philosophical beliefs, health, sexual orientation, and biometric data used for identification. Disability and accessibility disclosures and health declarations typically fall here. Criminal offence data has separate rules and is not special category data. Processing special category data requires both an Article 6 lawful basis and an Article 9 condition, plus safeguards.
There is no universal period; retention depends on the institution's purposes and legal obligations, and different records may need different treatments. The institution should set a schedule with its DPO and legal advisers, and a CRM should make it enforceable through scheduled review, archival, anonymisation, purging and legal holds, rather than a single deletion date.
Where consent is used: the specific purpose, channel, programme or category, date and time, source, the exact wording shown, the version, the affirmative action taken, and any withdrawal or suppression status. It should keep notice acknowledgement separate from consent, since seeing a privacy notice is not the same as consenting to a purpose.
They can request erasure, but it is not absolute. It is subject to exemptions, for example where the institution must retain data for a legal obligation or to establish or defend legal claims. A CRM should help locate connected records, apply restriction where needed and document the decision, but qualified staff must review each request, including any third-party data it touches.
SSO, multi-factor authentication, role-based access and least privilege, field and document restrictions, encryption in transit and at rest, secure and tested backups, vulnerability management and penetration testing, logging and access reviews, incident response and secure exports. Encryption alone does not create compliance, and certifications describe scope rather than proving GDPR compliance.
It should help locate every record connected to one person, identify duplicates, export data, record and assign the request, verify identity, track the deadline, flag third-party information and exemptions for review, and document the response. It supports the workflow rather than completing it automatically, because judgement is required on exemptions and on balancing rights.
Operational messages tied to an application (confirmations, reminders, offers) are generally distinct from direct marketing (promotions for unrelated future programmes). Direct marketing must follow the applicable GDPR and ePrivacy or PECR rules. Consent may be required, although a limited soft opt-in may be available in some circumstances where all relevant conditions are met. The institution assesses the purpose and applicable law, and the CRM should apply suppression and preferences consistently across every channel.
With care. Under the EU GDPR, Article 22 restricts decisions based solely on automated processing that produce legal or similarly significant effects, so meaningful human involvement in consequential admissions decisions matters. The UK, following the Data (Use and Access) Act 2025, applies a more permissive but still safeguarded model from February 2026. In both cases, keep human oversight, document the logic, restrict special category data, and be able to explain and challenge outcomes. Confirm the current position with your DPO.
Full Fabric provides configurable privacy, consent, access, retention, audit and individual-rights workflows to support GDPR-aligned higher education operations. The institution remains responsible for its policies, lawful bases, configuration and compliance decisions.
