ResearchConnectX
Data Protection Policy
Last updated: 16 April 2026

Data Protection Policy

Last updated: 16 April 2026

This Data Protection Policy (“Policy”) describes how
ResearchConnectX (“RCX”, “we”,
“us”) manages and protects personal data in connection
with the Service. It is a companion to our Privacy Policy and Researcher
Privacy Policy and should be read alongside them.

This Policy sets out our obligations under the UK General Data
Protection Regulation, the UK Data Protection Act 2018 and, where
applicable, the EU General Data Protection Regulation (collectively,
“data-protection law”). It also describes the technical
and organisational measures we apply to protect personal data.

1. Principles

We process personal data in accordance with the following principles
under data-protection law.

Principle	How we apply it
Lawfulness, fairness, transparency	We only process personal data where we have a valid legal basis; we are open about what we collect and why.
Purpose limitation	We collect personal data for specified, explicit and legitimate purposes and do not process it in a way that is incompatible with those purposes.
Data minimisation	We collect only the data that is adequate, relevant and limited to what is necessary.
Accuracy	We take reasonable steps to keep personal data accurate and up-to-date; Members can correct their own data at any time.
Storage limitation	We retain personal data for no longer than is necessary for the purpose; retention periods are described in this Policy and in the Privacy Policy.
Integrity and confidentiality	We apply appropriate technical and organisational security measures.
Accountability	We maintain records of processing activities and can demonstrate compliance.

2. Legal bases for processing

We rely on the following legal bases set out in Art. 6 GDPR:

Legal basis	Examples of use
Art. 6(1)(a) – Consent	Optional marketing and product-update emails; optional analytics cookies; any processing for which we have asked for and received explicit consent.
Art. 6(1)(b) – Contract performance	Account management, delivery of the Service, billing, messaging and notifications that are necessary to provide the contracted Service to Members.
Art. 6(1)(c) – Legal obligation	Compliance with court orders, law-enforcement requests, tax obligations, and regulatory requirements.
Art. 6(1)(f) – Legitimate interests	Security monitoring; fraud prevention; improving the Service; indexing publicly available academic data; personalising suggestions; responding to enquiries; analytics.

Where we rely on legitimate interests we conduct and document a
legitimate-interests assessment to balance our interests against data
subjects’ rights. Documented assessments are available on request.

Where we process special-category data (Art. 9 GDPR) — which is rare
but may occur where a researcher’s profile incidentally reveals, for
example, political or philosophical views through their research — we
apply an additional legal basis, typically explicit consent or the
research/public-interest ground under Art. 9(2)(j) as implemented in UK
law.

3. Controller and
processor arrangements

3.1 RCX as controller

RCX is the data controller for personal data processed in connection
with the Service, including the data described in the Privacy Policy and
the Researcher Privacy Policy.

Controller details: – Name:
ResearchConnectX – Registered address: [to be completed
prior to launch] – Privacy contact: info@rcx.ac

3.2 RCX as processor

Where RCX processes personal data on behalf of a third party (for
example, where a university uses the institutional dashboard and
supplies employee or student data to us for administration), RCX acts as
a processor. In those cases, a Data Processing Agreement
(“DPA”) is put in place with the controller, setting
out the purpose, subject matter, nature, and duration of the processing
and our respective obligations.

3.3 Subprocessors

We engage subprocessors to help deliver the Service. We maintain a
register of our material subprocessors, which is available on request.
Before engaging a new subprocessor or materially changing an existing
arrangement, we:

• Conduct a due-diligence assessment of the subprocessor’s security
  practices and compliance posture.
• Enter into a written DPA with appropriate contractual clauses.
• Notify institutional controller customers in advance where the
  change may affect their DPA with us.

Current material subprocessor categories include:

Category	Purpose
Cloud infrastructure	Hosting, compute and managed databases (AWS, DigitalOcean)
Object storage	User-uploaded file storage (AWS S3, DigitalOcean Spaces)
Cache and queue	Session management and background job processing (Redis)
Email delivery	Transactional and notification email (Amazon SES)
AI model providers	Embedding generation and natural-language processing
Analytics and telemetry	Product usage analytics and error monitoring
Customer support	Helpdesk ticketing and enquiry management
Payment processing	Subscription billing (independent controller for card data)

4. Technical and
organisational security measures

We implement the following measures proportionate to the risks posed
by our processing activities.

4.1 Access control

• Principle of least privilege. Staff and systems are
  granted only the minimum access required to perform their role or
  function.
• Role-based access control (RBAC). Access to
  production systems and databases is controlled by defined roles and
  reviewed quarterly.
• Multi-factor authentication (MFA). Required for all
  staff with access to production systems, cloud consoles and source-code
  repositories.
• Privileged access management. Privileged access
  (for example, database administrator access) is time-limited, logged and
  subject to approval workflows.
• Offboarding. Access is revoked promptly on
  termination or change of role.

4.2 Encryption

• In transit. All data transmitted between clients
  and our servers is encrypted using TLS 1.2 or higher. Internal
  service-to-service communication is encrypted where technically
  feasible.
• At rest. Personal data stored in our primary
  database (PostgreSQL) and object storage (S3-compatible) is encrypted
  using AES-256 or equivalent.
• Key management. Encryption keys are managed using a
  dedicated key-management service and are rotated on a scheduled
  basis.
• Database backups. Backups are encrypted with the
  same standard and stored in separate, access-controlled locations.

4.3 Network security

• Firewall rules. Production database and internal
  services are not exposed directly to the public internet. Traffic is
  routed through application-layer controls.
• DDoS protection. We use a content-delivery network
  and DDoS-mitigation service to protect the Service from volumetric
  attacks.
• Intrusion detection. We monitor network traffic and
  application logs for anomalous patterns indicative of intrusion or
  abuse.
• Dependency scanning. We scan third-party software
  dependencies for known vulnerabilities and apply security patches on a
  risk-based schedule.

4.4 Application security

• Input validation. All user-supplied input is
  validated server-side using form-request classes; SQL injection and XSS
  are mitigated at the application layer.
• CSRF protection. Cross-site request forgery
  protection is applied to all state-changing HTTP requests.
• Rate limiting. API endpoints and authentication
  flows are rate-limited to prevent credential stuffing and brute-force
  attacks.
• Session management. Sessions are managed via
  secure, HTTP-only, SameSite cookies with configurable expiry. Sessions
  stored in Redis are encrypted.
• Secrets management. API keys, credentials and
  environment-specific secrets are stored in environment variables or a
  dedicated secrets manager and are never committed to source
  control.
• Security headers. HTTP security headers (for
  example, Content-Security-Policy, Strict-Transport-Security,
  X-Frame-Options) are applied to all responses.
• Penetration testing. We commission penetration
  tests on a regular basis and remediate critical findings within defined
  SLAs.

4.5 Operational security

• Logging and monitoring. Application, access and
  security events are logged and retained for a minimum of 12 months.
  Alerts are configured for anomalous events.
• Backup and recovery. Automated database backups are
  taken daily. Backup restoration is tested periodically. Recovery time
  and recovery point objectives are documented in our incident response
  plan.
• Change management. Code changes are subject to peer
  review before deployment. Database migrations are version-controlled and
  tested in a staging environment.
• Asset inventory. We maintain an inventory of
  systems that process personal data.

4.6 Staff and contractor
measures

• Data-protection training. All staff who handle
  personal data receive data-protection training on joining and at least
  annually thereafter.
• Confidentiality obligations. Staff and contractors
  are bound by confidentiality obligations that survive termination of
  employment or engagement.
• Background checks. Appropriate background checks
  are conducted for staff with access to sensitive data, in accordance
  with applicable law and role requirements.
• Vendor assessments. Material vendors and
  subprocessors are assessed for security and compliance before engagement
  and periodically thereafter.

5. International data
transfers

We process and store most personal data within the UK/EEA. Where
personal data is transferred to a third country, we rely on one or more
of the following transfer mechanisms:

• UK adequacy regulations where the destination
  country or sector has been deemed adequate by the UK Secretary of
  State.
• UK International Data Transfer Agreement (IDTA) or
  UK Addendum to the EU Standard Contractual
  Clauses.
• EU Standard Contractual Clauses (SCC) (module 2:
  controller-to-processor or module 1: controller-to-controller, as
  applicable).
• Binding Corporate Rules (BCR) where an intra-group
  transfer involves an entity with approved BCR.
• Art. 49 GDPR derogations in limited, documented
  cases (for example, where transfer is necessary for the performance of a
  contract with you).

We maintain a record of all third-country transfers, the mechanism
relied upon, and the countries of destination.

6. Data Protection
Impact Assessments (DPIAs)

We conduct a DPIA before undertaking any processing that is likely to
result in a high risk to data subjects’ rights and freedoms,
including:

• Large-scale processing of publicly available academic data.
• Deployment of new AI/ML processing involving personal data.
• New uses of profiling or automated decision-making.
• Processing of special-category data.
• Material changes to the matching engine or embedding pipeline.

DPIAs are documented, reviewed by our privacy contact, and updated
when the underlying processing changes materially.

7. Data subject rights
and request handling

We operate the following process for handling data-subject rights
requests.

Step	Action
Receipt	Request received at info@rcx.ac or via Account Settings
Identity verification	We verify the requester’s identity before acting on the request
Acknowledgement	We acknowledge receipt within 5 working days
Response deadline	We respond within 30 days; extensible by up to a further 60 days for complex or numerous requests (with notice)
Response	We provide the requested information or action, or explain any exemption relied upon
Logging	All requests and outcomes are logged for accountability purposes

We do not charge a fee for requests unless they are manifestly
unfounded or excessive. Where a request is refused, we explain the
reason and inform the requester of their right to complain to the
supervisory authority.

8. Personal data breach
management

We maintain a data-breach response procedure that includes:

• Detection and containment. Automated monitoring and
  staff training enable prompt detection. Containment measures are
  activated immediately.
• Assessment. We assess the nature, scope and impact
  of the breach, including the categories and approximate volume of data
  subjects affected.
• Notification to supervisory authority. Where a
  breach is likely to result in a risk to individuals’ rights and
  freedoms, we notify the UK ICO (or relevant EU supervisory authority)
  within 72 hours of becoming aware of the breach, in accordance with Art.
  33 GDPR.
• Notification to data subjects. Where a breach is
  likely to result in a high risk to individuals, we notify affected data
  subjects without undue delay, in accordance with Art. 34 GDPR.
• Documentation. All breaches, whether or not
  notifiable, are documented in our breach register, including facts,
  effects and remedial actions taken.
• Post-incident review. We conduct a post-incident
  review for all significant breaches and implement improvements to
  prevent recurrence.

To report a suspected security vulnerability or breach, contact info@rcx.ac.

9. Records of processing
activities (RoPA)

We maintain a RoPA as required by Art. 30 GDPR, which includes for
each processing activity:

• The name and contact details of the controller and, where
  applicable, processor.
• The purposes of the processing.
• A description of the categories of data subjects and personal
  data.
• The categories of recipients.
• Transfers to third countries and the safeguards applied.
• Envisaged retention periods.
• A general description of security measures.

The RoPA is available to the supervisory authority on request.

10. Subprocessor and vendor
management

10.1 Onboarding

Before engaging a new subprocessor or vendor that will process
personal data, the relevant team must:

1. Complete a security and data-protection questionnaire.
2. Obtain and review the vendor’s privacy policy, security
   certifications (for example, ISO 27001, SOC 2 Type II) and, for
   processors, their technical and organisational measures.
3. Execute a DPA or appropriate contractual clauses.
4. Obtain approval from the privacy contact.

10.2 Ongoing monitoring

Material subprocessors are subject to annual review. If a
subprocessor suffers a security incident that may affect our data or if
they intend to make a material change to their sub-processors, they must
notify us.

10.3 Offboarding

On termination of an engagement, the vendor must delete or return all
personal data within a defined period and certify that deletion has
occurred.

11. Cookies and
similar technologies governance

Our use of cookies and similar technologies is governed by our Cookie
Policy (Section 5 of the Privacy Policy). We apply a consent-management
platform to obtain and record consent for non-essential cookies. Consent
records are retained for at least 3 years. We review our cookie
inventory quarterly and update the cookie table in the Privacy Policy
accordingly.

12. AI and automated
processing governance

Given the prominent role of AI in RCX’s matching engine, we apply the
following additional controls:

• Documentation. We document the inputs, model
  architecture (or provider), outputs and risk profile of each AI feature
  that processes personal data.
• Human oversight. All consequential outputs of the
  matching engine are presented as suggestions to human users; no
  irreversible decision affecting data subjects is made solely by
  automated means.
• Bias and fairness review. We periodically audit the
  matching outputs for evidence of systematic bias with respect to
  protected characteristics. Issues identified are investigated and, where
  necessary, we adjust the feature pipeline or training approach.
• Data minimisation in model training. Where we
  fine-tune models using user data, we apply de-identification and
  differential-privacy techniques where technically feasible.
• Third-party model providers. We select providers
  that contractually agree not to train their general-purpose foundation
  models on our data and that commit to appropriate security
  standards.

13. Policy governance

• Owner: [Privacy Contact / DPO] is responsible for
  maintaining this Policy.
• Review cycle: This Policy is reviewed at least
  annually and following any material change in processing activities,
  applicable law, or supervisory authority guidance.
• Version history: Previous versions of this Policy
  are archived and available on request.
• Training: Material changes to this Policy are
  communicated to relevant staff within 30 days of publication.

14. Contact

Privacy contact: info@rcx.ac

Security disclosures: info@rcx.ac

Registered address: [to be completed prior to
launch]

You have the right to lodge a complaint about our data-protection
practices with:

• UK: Information Commissioner’s Office (ICO) — ico.org.uk
• EU: Your national data-protection authority