03 · What You Need to Know
Start With Who Makes the Decisions About the Data
The principal investigator is not automatically the legal controller
Researchers often assume that the principal investigator must be the data controller because the PI leads the study. That can be incorrect.
Under GDPR-style frameworks, a controller is the natural or legal person, public authority, agency, or other body that determines the purposes and means of processing personal data. The controller has substantial responsibility for ensuring and demonstrating compliance. GDPR Article 24, for example, requires controllers to implement appropriate technical and organizational measures and to review and update them where necessary.
In institutional research, the relevant controller may therefore be a university, hospital, research institute, company, sponsor, government agency, or another entity. Whether an individual investigator is personally a controller depends on the actual arrangement and applicable law, not merely their academic title.
This is why researchers should distinguish broad responsibility for protecting data from the more specific question of who is the controller, custodian, or steward in the project.
The controller decides the purposes and means of processing
The controller role follows substantive decision-making. UK Information Commissioner's Office guidance describes controllers as the main decision-makers exercising overall control over the purposes and means of processing. Controllers carry the highest level of compliance responsibility under the UK GDPR framework.
Questions that can help identify this role include: Who decided why the personal data would be collected? Who determines the research or operational purposes for which they are used? Who makes the important decisions about what happens to them? Which organization has authority over the processing?
The answers matter more than what a folder, protocol, or spreadsheet happens to call someone.
A processor handles personal data on the controller's behalf
A processor processes personal data for the controller rather than determining an independent purpose for using them. Examples in research might include some cloud providers, survey platforms, transcription companies, laboratory services, data-hosting providers, or other contractors, depending on the actual arrangement.
Calling a vendor a "service provider" does not settle its legal role. You have to examine what it actually does with the information and who determines the relevant purposes and means.
Under GDPR Article 28, controllers using processors must select processors providing sufficient guarantees and establish the required contractual arrangements. Processors themselves also have direct obligations under the GDPR.
The Philippine framework uses the terms personal information controller (PIC) and personal information processor (PIP). National Privacy Commission materials describe a PIC as the person or organization controlling the collection, holding, processing, or use of personal information, while a PIP processes personal data outsourced to it by a PIC.
Outsourcing the work does not necessarily outsource accountability
This is one of the most consequential points for researchers using third-party platforms. Giving data to another company does not necessarily transfer away the controller's responsibility.
Under the Philippine Data Privacy Act implementing rules, a personal information controller remains responsible for personal data under its control or custody, including information outsourced or transferred to a personal information processor or third party, whether domestically or internationally. The controller must use contractual or other reasonable means to provide a comparable level of protection.
Similarly, GDPR Article 28 requires a controller to use processors providing sufficient guarantees for compliant and protective processing.
So "the data are on someone else's server" is not, by itself, a governance strategy.
Researchers and research staff still have direct operational responsibilities
Even when the institution is the legal controller, individual researchers are not relieved of responsibility. They may be entrusted with access to personal data and expected to follow the institution's policies, ethics approval, research protocol, security procedures, contractual restrictions, and instructions.
Depending on their role, researchers may need to use approved storage, protect authentication credentials, avoid unauthorized copying, maintain confidentiality, restrict access, use appropriate transfer methods, follow retention schedules, keep identifiers separate where required, and report suspected incidents promptly.
These responsibilities can arise from employment, professional duties, institutional policy, contracts, research ethics, confidentiality obligations, and data protection law. Their exact legal characterization varies by jurisdiction.
Watch Out
Do not assume that because your institution is the legal controller, you personally have no responsibility for how you handle participant data. Organizational accountability and individual duties can exist at the same time.
Collaborators can have different roles in the same project
Multi-institutional research makes the picture more complicated. Two institutions might jointly determine the purposes and means of particular processing and therefore qualify as joint controllers under GDPR-style frameworks. Alternatively, each institution might act as a separate controller for different processing activities. One organization might even process particular information on another's behalf.
ICO guidance notes that organizations are joint controllers when they jointly determine the purposes and means of the same processing, but not merely because they happen to process the same data for different purposes.
The scientific label "collaborator" therefore tells you almost nothing about the legal data protection relationship. A co-author, external statistician, laboratory, international partner, and coordinating center may each occupy different roles.
Before releasing participant information, establish whether the collaborator actually has a legitimate basis and need to receive those data.
Responsibility should be determined before data are collected
Research teams sometimes discover their data governance structure only when a data-sharing agreement is requested or, less pleasantly, when something goes wrong.
Roles should instead be mapped during study design. Identify which organization determines the processing, which parties process information on its behalf, which collaborators independently determine purposes, who provides infrastructure, who can authorize access, who responds to participant rights requests, who manages security incidents, and who decides whether data may be transferred or retained.
Doing this early can also reveal whether a data-sharing or data-transfer agreement is needed.
Security responsibility exists throughout the data lifecycle
Protection does not begin when data reach the university server. It begins when information is collected and continues through use, storage, access, analysis, sharing, transfer, archiving, and disposal.
National Privacy Commission guidance emphasizes access control as part of protecting personal and sensitive information and describes authentication, authorization, auditing, and access approval as common aspects of access-control policy.
For research teams, this means responsibility can attach to mundane actions that never appear in the final journal article: where a fieldworker downloads a file, whether an assistant shares a password, whether a collaborator receives identifiers, whether a laptop is encrypted, or whether a departing team member still has access.
Different responsibilities do not mean fragmented protection
A well-governed study should not rely on every participant-data decision being independently reinvented by whoever happens to have the file open that day.
Organizations need policies and technical controls. Study leaders need to define access and procedures. Team members need to follow them. Processors need appropriate contractual and security arrangements. Collaborating institutions need clarity about their respective roles. Incident-response routes need to be known before an incident occurs.
The result is layered responsibility. Several parties may contribute to protection even though their legal obligations are not identical.
04 · A Practical Example
Who Is Responsible in a Multi-Institution Research Project?
Hypothetical Example
A university-led interview project
University A leads a study and determines its research purposes and core data-processing arrangements. Participants are interviewed by University A researchers. Audio files are sent to a contracted transcription company. A researcher at University B later receives pseudonymized transcripts for an agreed analysis.
University A
The project determines that University A is the controller under the applicable framework. It carries controller-level responsibility for the processing, including appropriate governance, security, transparency, and oversight of processors.
Principal investigator
The PI implements the approved project within University A's governance structure, ensures team members understand the data procedures, approves appropriate access, and escalates privacy or security issues through institutional channels.
Research assistant
The assistant accesses only the information required for their role, uses approved systems, maintains confidentiality, follows the protocol, and reports any suspected disclosure or loss promptly.
Transcription company
If it processes recordings only on University A's documented instructions, it may act as a processor under the applicable framework and must satisfy the relevant contractual and legal requirements.
University B
Its role must be determined from what it actually does with the pseudonymized transcripts. Being described as a collaborator does not by itself establish whether it is a separate controller, joint controller, processor, or another type of recipient.
Now suppose the transcription company suffers a security incident. University A cannot simply conclude that the event is entirely the vendor's problem. The parties must follow the applicable contractual and legal incident procedures, and controller-level obligations may remain with University A even though the immediate technical failure occurred at the processor.
