---
title: "How We Handle a Data Subject Access Request: Our DSAR Process Explained"
description: "Learn how MeetWho handles Data Subject Access Requests (DSARs), including request submission, identity verification, response timelines, privacy safeguards, and how users can exercise their data rights."
canonical: "https://meetwho.app/blog/how-we-handle-a-data-subject-access-request-dsar-process"
language: "en"
published: "2026-08-07T18:04:23.859+00:00"
updated: "2026-08-11T07:19:57.252312+00:00"
reading_time_minutes: "16"
author: "Yağız Gürbüz"
author_url: "https://meetwho.app/author/yagiz-gurbuz"
source: "MeetWho — the networking layer for events and communities"
license: "Quote with attribution and a link to the canonical URL."
---

# How We Handle a Data Subject Access Request: Our DSAR Process Explained

## TL;DR

- Learn how MeetWho handles Data Subject Access Requests (DSARs), including request submission, identity verification, response timelines, privacy safeguards, and how users can exercise their data rights.
- A Data Subject Access Request, commonly shortened to DSAR or subject access request, is a request from an individual seeking access to personal data that an organisation holds or processes about them.
- Personal data can include information that identifies a person directly as well as information that relates to an identifiable individual.
- A well-defined DSAR process helps remove uncertainty from privacy requests.
- MeetWho combines event creation, attendee registration and intelligent networking within one platform.

## Key questions

**What Is a Data Subject Access Request (DSAR)?**

A Data Subject Access Request, commonly shortened to DSAR or subject access request, is a request from an individual seeking access to personal data that an organisation holds or processes about them. Under the EU General Data Protection Regulation (GDPR), the right of access is primarily established by Article 15, while Article 12 sets out requirements concerning transparent communication and the exercise of data su

**Why a Clear DSAR Process Matters for Users?**

A well-defined DSAR process helps remove uncertainty from privacy requests. Users should be able to understand what happens after a request is made, why certain information may be required to verify the requester and how the organisation works to avoid disclosing personal information to an unauthorised person.

**How We Handle a Data Subject Access Request at MeetWho?**

A practical DSAR workflow needs to balance two objectives: making it possible for an individual to exercise their access rights and protecting personal information from inappropriate disclosure. The process can therefore involve receiving and understanding the request, confirming the requester's identity where necessary, identifying relevant personal data and preparing an appropriate response.

**What Information Can Be Included in a DSAR Response?**

A DSAR may involve more than providing a copy of isolated personal data fields. The specific content of a response depends on the request and the applicable legal framework.

**How MeetWho Protects Privacy During Data Requests?**

MeetWho is designed around the idea that professional networking works better when relevance and permission come before indiscriminate exposure. That privacy principle is also relevant when considering a personal data access request : information should be made available to the correct person while unnecessary disclosure should be avoided.

**DSAR Process Checklist for Users**

Users can make a DSAR request easier to understand by providing enough context to identify the relevant account and information without sending unnecessary sensitive data. Identify your account: Use information that helps connect the request to the relevant MeetWho account.

## Full article

Title: "DSAR Process Explained: How We Handle Data Requests"

 Description: "Understand MeetWho’s DSAR process, how users request personal data access, verification steps, response timelines, and privacy practices."

# How We Handle a Data Subject Access Request: Our DSAR Process Explained

 **DSAR process**, or Data Subject Access Request process, gives individuals a structured way to ask an organisation whether it processes their personal data and, where applicable, receive access to that information. For a platform such as MeetWho, where event registration, professional profiles and permission-based networking can involve personal information, handling these requests carefully is an important part of transparent data practices.

 This guide explains **how we handle a Data Subject Access Request**, what a DSAR means in practice, why identity verification may be necessary, and what users can generally expect as a request progresses. It is intended as a practical explanation of the process rather than legal advice; the exact rights, obligations and exceptions applicable to any request depend on the relevant data protection law and circumstances.

## What Is a Data Subject Access Request (DSAR)?

 A Data Subject Access Request, commonly shortened to **DSAR** or subject access request, is a request from an individual seeking access to personal data that an organisation holds or processes about them. Under the EU General Data Protection Regulation (GDPR), the right of access is primarily established by Article 15, while Article 12 sets out requirements concerning transparent communication and the exercise of data subject rights.

 A DSAR is broader than simply asking, “What is my name and email address in your database?” Depending on the circumstances and applicable law, a person may be entitled to confirmation that their personal data is being processed, access to that personal data and specified contextual information about how it is used. Authoritative guidance from the [European Data Protection Board](https://edpb.europa.eu/) and the UK [Information Commissioner’s Office](https://ico.org.uk/) provides further detail about subject access rights and organisational responsibilities.

### Understanding Personal Data Access Rights

 Personal data can include information that identifies a person directly as well as information that relates to an identifiable individual. In an event technology context, this may include account details, event registration information, professional profile information or other records associated with a user's interaction with a platform.

 A **personal data access request** is therefore an important transparency mechanism. It allows an individual to understand what information may be associated with them and provides an opportunity to identify potential inaccuracies or raise other privacy-related questions.

 A DSAR should also be distinguished from other data protection requests. Accessing data, correcting inaccurate information and requesting deletion are related but separate rights. For example, a user who wants to see what information is held about them is making an access request, while someone asking for qualifying personal data to be erased may instead be exercising a right to erasure, where that right applies.

## Why a Clear DSAR Process Matters for Users

 A well-defined **DSAR process** helps remove uncertainty from privacy requests. Users should be able to understand what happens after a request is made, why certain information may be required to verify the requester and how the organisation works to avoid disclosing personal information to an unauthorised person.

 This is particularly relevant for event platforms because a single event experience may involve several types of personal information. An attendee might register for an event, create a professional profile, describe what they are working on or looking for, and choose whether to participate in networking. Those different interactions can create distinct categories of information that need to be considered carefully when a valid access request is reviewed.

### Building Transparency Between Platforms and Users

 MeetWho combines event creation, attendee registration and intelligent networking within one platform. Organisers can manage registrations, approvals, waiting lists, event communications and QR-based check-in, while participants can create professional profiles and specify whom they would like to meet and how they can help others.

 Privacy is especially important in this model because networking is not intended to mean unrestricted access to every participant. MeetWho uses organiser settings and participant permission as part of the networking experience. Rather than treating an event attendee list as something that should automatically be exposed to everyone, the platform is designed to recommend relevant people among users who have permitted that form of participation.

 That principle also matters when handling privacy rights. Paid access does not provide a way to unlock hidden profiles or private contact information, and MeetWho does not sell participant lists. A transparent **data access request process** should follow the same broader principle: personal information should be handled deliberately and disclosed only to the appropriate requester in accordance with applicable requirements.

## How We Handle a Data Subject Access Request at MeetWho

 A practical DSAR workflow needs to balance two objectives: making it possible for an individual to exercise their access rights and protecting personal information from inappropriate disclosure. The process can therefore involve receiving and understanding the request, confirming the requester's identity where necessary, identifying relevant personal data and preparing an appropriate response.

 The precise handling of an individual request can depend on its scope, the information involved and the law that applies. A narrowly defined request may be easier to identify and process than a broad request involving several services, events or account interactions.

### Step 1 — Receiving the Data Access Request

 The first stage is understanding what the individual is asking for. A useful request should make it possible to identify the relevant account or relationship with the service and describe the personal information being requested as clearly as reasonably possible.

 A person does not generally need to know technical database terminology to exercise a subject access right. However, useful context can make a request easier to understand. Depending on the situation, that could include the email address associated with the account, the relevant event or the approximate period in which the platform was used.

 For example, a request could concern information connected with:

 
- **Account details:** information associated with a MeetWho account or professional profile.
- **Event participation:** registration or participation information linked to an event.
- **Networking preferences:** information a participant has provided about interests, goals or preferred connections.
- **Platform interactions:** other personal information associated with relevant use of MeetWho, where applicable.

 These examples describe possible categories rather than guaranteeing that every category exists for every user. The information available depends on how the individual has actually used the platform.

### Step 2 — Verifying the Requester’s Identity

 Before personal information is provided, it may be necessary to establish that the person making the request is entitled to receive it. Identity verification is not simply an administrative obstacle; it can be an important safeguard against giving one person's information to somebody else.

 The level of verification should be proportionate to the circumstances and the information involved. Data protection guidance generally cautions organisations against collecting unnecessary additional personal information solely for verification. At the same time, where there are reasonable doubts about identity, applicable law may permit an organisation to request additional information necessary to confirm who is making the request.

 This matters especially when event participation and professional networking data are involved. A **GDPR data access request** should increase transparency without creating a new privacy risk for the requester or for other individuals whose information may appear in related records.

 Once the request and, where required, the requester's identity have been appropriately established, the next stage is to review the relevant personal data, consider information involving other people and prepare the response in a secure and understandable form.

### Step 3 — Reviewing and Preparing Relevant Personal Data

 After a request has been received and any necessary identity checks have been completed, the next stage of the **DSAR process** is to identify the personal data that falls within the scope of the request. This review should focus on information relating to the requester while also considering whether any records contain personal information about other people.

 In an event and networking environment, relevant information may come from more than one type of interaction. A participant might have created an account, registered for events, added professional profile details, selected networking preferences or interacted with other permitted users. The scope of a response therefore depends on how the individual has used the service and what information is actually associated with their account or activity.

 Data Category Examples That May Be Relevant 
 Account data Name, email address and profile information 
 Event data Registrations, participation records or event-related information 
 Professional profile data Work interests, goals and information provided for networking 
 Networking preferences People or professional interests a participant has indicated they want to connect with 
 Interaction data Relevant platform interactions associated with the individual, where applicable 
 

 These examples are illustrative rather than an exhaustive statement of what every request will contain. MeetWho should not imply that a particular category of data exists for every user when that person may never have used the corresponding feature.

 The review stage also requires care where information relates to more than one person. For example, a record connected with professional networking could potentially contain information concerning both the requester and another participant. Data access rights do not automatically remove the privacy rights of other individuals, so responses may need to be assessed carefully before information is disclosed.

### Step 4 — Providing the DSAR Response

 Once the relevant information has been identified and reviewed, the response should be provided in an understandable and appropriately secure form. Under GDPR Article 12, organisations are expected to communicate information relating to data subject rights in a concise, transparent, intelligible and easily accessible way.

 The GDPR generally requires organisations to respond to a qualifying request without undue delay and, in principle, within one month of receiving it. That period can be extended by up to two further months in certain cases, taking into account the complexity and number of requests, provided the individual is informed of the extension and the reasons for it within the initial one-month period. The exact timing and legal requirements can vary depending on the law that applies.

 A **Data Subject Access Request process** should therefore be designed around both completeness and clarity. Sending large amounts of unexplained technical information may not help a user understand how their data is being processed. Where appropriate, contextual information can make the response easier to interpret.

## What Information Can Be Included in a DSAR Response?

 A DSAR may involve more than providing a copy of isolated personal data fields. Under GDPR Article 15, an individual can also have rights to information about matters such as the purposes of processing, categories of personal data, certain recipients or categories of recipients, retention information where applicable and the source of data when it was not collected directly from the individual.

 The specific content of a response depends on the request and the applicable legal framework. A person who used MeetWho only to register for a single event may have a different data footprint from someone who created a detailed professional profile and actively used permission-based networking features.

### Examples of Personal Data a User May Request

 For practical purposes, a user may ask about the information associated with a particular part of their MeetWho experience. Examples could include profile information they supplied, records relating to event registration or relevant networking preferences connected with their account.

 It is important not to confuse data access with unrestricted access to information about other participants. A DSAR concerns the requester's personal data. It does not create a general right to view private attendee lists, hidden profiles, private contact details or information belonging to other users.

## How MeetWho Protects Privacy During Data Requests

 MeetWho is designed around the idea that professional networking works better when relevance and permission come before indiscriminate exposure. That privacy principle is also relevant when considering a **personal data access request**: information should be made available to the correct person while unnecessary disclosure should be avoided.

 MeetWho combines event management with Event Networking Intelligence. Organisers can create event pages, collect registrations, approve attendees, manage waiting lists, send announcements and reminders, perform QR check-in and determine networking privacy settings. Participants can describe what they are working on, what they are looking for, whom they want to meet and where they may be able to help others.

### Consent-Based Networking Visibility

 MeetWho does not rely on an unrestricted public attendee directory as its core networking model. Instead, networking recommendations are generated among users who have permitted participation, taking into account professional profile information, shared interests and event goals.

 When a relevant match is suggested, the experience can explain why two people may benefit from meeting and offer guidance on how they could begin a conversation. Users can send connection requests and, after a mutual connection is established, use supported networking tools such as messaging, private notes and follow-up reminders.

 This distinction matters for privacy. A Plus membership can provide more networking functionality, but it does not grant access to hidden profiles or private contact details. MeetWho also does not sell participant lists.

### Protecting Event Participant Information

 Event data may involve relationships between organisers, attendees and the platform itself. Organiser settings and participant choices therefore remain important when determining how networking information is displayed and used.

 A privacy-conscious workflow should also minimise unnecessary disclosure during a DSAR. If responsive information contains data connected with another individual, that information may need to be evaluated before it is included in a response. The objective is to respect the requester's access rights without disregarding the rights and freedoms of other participants.

## DSAR Process Checklist for Users

 Users can make a **DSAR request** easier to understand by providing enough context to identify the relevant account and information without sending unnecessary sensitive data.

 
- **Identify your account:** Use information that helps connect the request to the relevant MeetWho account.
- **Describe the scope:** Explain which personal data or period your request concerns.
- **Reference relevant events:** Mention a specific event if it helps identify the information you are seeking.
- **Complete verification if needed:** Provide proportionate information requested to confirm your identity.
- **Review the response:** Check the information provided and raise any follow-up privacy questions where necessary.

 This checklist is intended to make the process more efficient, not to create additional barriers. Individuals should not be expected to understand internal systems or use legal terminology simply to ask for access to their personal information.

 For organisers assessing event technology, the same principles provide a useful benchmark: participant data should be handled transparently, networking visibility should respect user choice and access to additional product features should never become a shortcut around privacy controls.

## Common Questions About the DSAR Process

 Understanding the practical details of a **DSAR process** can make it easier for users to exercise their privacy rights. The answers below address common questions about subject access requests under GDPR while recognising that specific legal requirements may vary depending on jurisdiction and circumstances.

 These explanations are general information rather than legal advice. For authoritative guidance, users and organisations should consult applicable legislation and official resources such as the [European Data Protection Board](https://edpb.europa.eu/) or the [Information Commissioner’s Office](https://ico.org.uk/).

### How Long Does a DSAR Response Take?

 Under GDPR Article 12, organisations generally need to respond to a valid Data Subject Access Request without undue delay and within one month of receiving it. The period may be extended by up to two additional months when necessary because of the complexity or number of requests.

 If an extension applies, the individual should generally be informed within the original one-month period and told why additional time is required. Other privacy laws may establish different response periods, so the applicable legal framework should always be considered.

### Can I Request Deletion Instead of Access?

 Yes, a person can potentially make a deletion request, but access and erasure are separate data protection rights. A DSAR asks an organisation to provide access to personal information, whereas the right to erasure concerns whether qualifying personal data should be deleted.

 The right to erasure is not absolute. Organisations may sometimes have legitimate or legal reasons to retain particular information. Users should therefore clearly state whether they are requesting access, correction, deletion or another privacy-related action.

### Do I Need a Reason to Submit a DSAR?

 Under GDPR, individuals generally do not need to explain why they want to exercise their right of access. The purpose of a **subject access request** is to allow people to understand how their personal data is being processed.

 Providing useful context can nevertheless help clarify the request. For example, identifying a particular account, event or period can make it easier to locate the relevant information without changing the underlying right being exercised.

### Can an Organisation Refuse a DSAR?

 Data access rights are significant, but they are not unlimited in every situation. Applicable law may permit an organisation to restrict or refuse aspects of a request in specific circumstances, including where legal exemptions apply or where fulfilling the request would adversely affect the rights and freedoms of others.

 Under GDPR, organisations may also have specific options concerning manifestly unfounded or excessive requests. Any decision to restrict a request should be based on applicable law rather than convenience, and the organisation may need to explain its decision and available complaint rights.

### Can I Request My Personal Data From MeetWho?

 A user seeking access to personal data associated with their MeetWho use can make a privacy-related request through the appropriate MeetWho contact or privacy channel identified in the platform's current privacy documentation.

 The request should provide enough information to identify the relevant account or interaction. Users should avoid sending unnecessary sensitive documents unless additional verification is genuinely required for the request.

### Why Is Identity Verification Required for a DSAR?

 Identity verification helps reduce the risk of personal data being disclosed to an unauthorised person. If someone could obtain another participant's data simply by knowing their name or email address, the access process itself could become a privacy vulnerability.

 Verification should therefore be proportionate. The goal is to establish reasonable confidence that the requester is entitled to receive the information without unnecessarily collecting more personal data than the situation requires.

## Privacy-Focused Event Networking Starts With User Choice

 Data protection is particularly important in professional events because participants may share information about their careers, interests, goals and people they hope to meet. Effective networking does not require making all of that information publicly accessible.

 MeetWho approaches this differently. Instead of treating networking as an open attendee directory, it analyses permitted profile information, shared interests and event goals to recommend relevant people among participants who have chosen to take part. Each recommendation can help explain why a conversation may be valuable, how the participants could help one another and how they might start talking.

 That same privacy principle appears throughout the product experience. Organisers control networking settings, participant permission takes priority, and paid membership does not unlock hidden profiles or private contact details. MeetWho does not sell participant lists. The objective is not to maximise how many strangers someone can see, but to help people identify the right connections for meaningful, mutually useful conversations.

 For organisers, MeetWho also combines networking with practical event management. Event pages can be created for free, registrations can be collected and reviewed, waiting lists can be managed, announcements and reminders can be sent, and QR-based check-in can support on-site workflows.

 **Create your free event with MeetWho** and manage registration, participants and permission-based networking in one place while helping attendees focus on who is genuinely worth meeting.

 [Create Your Free Event on MeetWho](https://meetwho.app/)

## Final Thoughts on How We Handle a Data Subject Access Request

 A reliable **Data Subject Access Request process** should make privacy rights understandable rather than difficult to exercise. From receiving and clarifying a request through appropriate identity verification, data review and response delivery, each stage should balance transparency with the need to protect personal information.

 For MeetWho users, that principle aligns with the platform's wider approach to event networking: participant choice and privacy come before unrestricted access. Whether someone is registering for an event, building a professional profile or using personalised networking recommendations, the goal is to make data use clearer and connections more relevant.

 Organisations handling DSARs should continue to refer to current requirements under the laws that apply to them. GDPR Article 12, GDPR Article 15, EDPB guidance and regulator resources such as those published by the ICO are appropriate primary references for understanding access rights and response obligations.

 MeetWho’s philosophy is simple: **Know who to meet.** Better event networking should help people discover relevant connections without turning privacy into a trade-off.

### Sources and Further Reading

 
- [European Data Protection Board — Data Protection Guidance](https://edpb.europa.eu/)
- [Information Commissioner’s Office — Right of Access Guidance](https://ico.org.uk/)
- Regulation (EU) 2016/679, GDPR Article 12 — Transparent information, communication and modalities for exercising data subject rights
- Regulation (EU) 2016/679, GDPR Article 15 — Right of access by the data subject

---

Canonical HTML version: https://meetwho.app/blog/how-we-handle-a-data-subject-access-request-dsar-process
Machine-readable site index: https://meetwho.app/llms.txt