03 · What You Need to Know
Not Every Incident Has the Same Consequences, but Every Incident Needs Assessment
Accidental disclosure can happen in very ordinary ways
Research data incidents do not require sophisticated hacking. Many begin with routine mistakes.
A researcher selects the wrong email address from autocomplete. A spreadsheet containing hidden identifying columns is shared instead of the intended analytical file. A cloud permission is set to "anyone with the link." A research assistant leaves a laptop on public transport. A paper participant list is discarded incorrectly. A collaborator forwards a dataset to someone outside the authorized team.
The technical simplicity of an incident does not determine its seriousness. What matters is what happened to the information and what consequences may follow.
Loss is not limited to someone reading the data
Privacy incidents can affect confidentiality, integrity, or availability.
Confidentiality is affected when personal data are disclosed or made accessible to someone who is not authorized to receive them.
Integrity is affected when data are changed, corrupted, or altered without authorization or in a way that makes them unreliable.
Availability is affected when authorized researchers lose access to data, for example because files are accidentally deleted, encrypted by ransomware, or stored only on a device that is lost.
A single incident can affect more than one of these dimensions. Losing the only copy of an encrypted research dataset may present little confidentiality risk if the encryption is robust, yet it can create a serious availability and research-integrity problem.
A security incident and a personal data breach are related but not always identical
The Philippine National Privacy Commission distinguishes security incidents from personal data breaches. NPC Circular No. 16-03 provides a breach-management framework intended to ensure timely discovery, containment, assessment, mitigation, documentation, and notification where required.
Not every security incident involving a research system necessarily becomes a personal data breach. Conversely, once personal data have been affected in the relevant way, the incident may require assessment under breach rules.
This distinction is useful because researchers should not spend valuable time attempting to make the final legal classification themselves. Report the event internally and allow the responsible privacy or incident-response personnel to determine whether it meets the applicable definition and notification threshold.
Containment comes first, but preserve the facts
Reasonable immediate containment depends on what happened. You might revoke a sharing link, disable a compromised account, retrieve a document, ask an unintended recipient not to access or further distribute a file, disconnect an affected system, or contact institutional IT to secure an account.
At the same time, avoid destroying information that may be needed to investigate the incident. Preserve relevant emails, timestamps, access logs, file names, recipient details, screenshots, system alerts, or other evidence according to institutional instructions.
The goal is to stop continuing exposure without erasing the trail needed to understand what occurred.
Report the incident even if you think you fixed it
Suppose you email a participant spreadsheet to the wrong colleague. Five minutes later, the colleague confirms that they deleted it without opening the attachment.
That information is relevant and may substantially reduce the assessed risk. It does not mean the incident should disappear from institutional view.
The responsible organization may need to document what happened, verify containment, assess whether additional copies exist, determine what personal data were involved, consider legal notification requirements, and identify whether a procedural or technical change could prevent recurrence.
Under the Philippine Data Privacy Act implementing rules, all security incidents and personal data breaches must be documented through written reports, including incidents that do not meet the threshold for mandatory breach notification.
Do not investigate indefinitely before reporting
Some legal frameworks impose short breach-notification timelines. Under the EU GDPR, for example, a controller must notify the competent supervisory authority without undue delay and, where feasible, within 72 hours after becoming aware of a reportable personal data breach. Processors must notify controllers without undue delay after becoming aware of a breach.
Philippine breach rules likewise contain a 72-hour notification framework for breaches meeting the applicable notification criteria.
Individual researchers therefore should not consume much of that window conducting their own informal investigation before telling the institution. Report what you know, identify what remains uncertain, and continue gathering information through the designated response process.
Write down what you know, not what you assume
Useful early information can include when the incident occurred and when it was discovered, which systems or devices were involved, what files or records may be affected, approximately how many participants may be involved, what categories of information were present, who may have received or accessed the data, whether encryption or other protections were applied, and what containment actions have already been taken.
Distinguish confirmed facts from possibilities. "The attachment was sent to the wrong address" is a fact. "Nobody opened it" is not a fact unless there is evidence supporting that conclusion.
ICO breach-response guidance similarly recommends beginning a log immediately and recording facts as they emerge, including what happened, who was involved, the timeline, and actions taken.
The sensitivity and identifiability of the data matter
A misplaced file containing anonymous aggregate statistics creates a different risk from one containing participant names, health information, financial data, passwords, identification numbers, or detailed interview narratives.
Assessment may consider the nature and sensitivity of the information, the number and characteristics of affected people, how easily individuals can be identified, who received the information, whether it was encrypted, whether the data can be recovered, and the possible consequences of misuse or disclosure.
Philippine mandatory-notification rules specifically consider sensitive personal information and other information that may enable identity fraud, together with unauthorized acquisition and the likelihood of real risk of serious harm.
Encryption can materially change the risk assessment
If an encrypted laptop or USB drive is lost, effective encryption may make the personal data unintelligible to whoever obtains the device. That can substantially reduce confidentiality risk.
But do not decide from memory that the device was "probably encrypted." The incident team may need to confirm what encryption was enabled, whether the device was locked, whether credentials were stored with it, and whether remote access or synchronization creates additional exposure.
Under the EU GDPR, appropriate protection such as encryption can affect whether communication to affected individuals is required in particular circumstances.
Asking an unintended recipient to delete the data can help, but it is not the entire response
If information was sent to the wrong person, promptly contacting the recipient may help contain the disclosure. Depending on institutional advice, they may be asked not to open, copy, forward, or retain the information and to confirm deletion.
That confirmation becomes part of the risk assessment. It does not retroactively mean the disclosure never occurred.
Researchers should also avoid sending further sensitive information while trying to correct the first mistake. Incident response occasionally produces sequels nobody requested.
Participant welfare may require action before the legal analysis is complete
Some incidents create immediate risks to participants. Exposed credentials may need to be reset. A disclosure involving safety-sensitive information may require urgent protective measures. Financial or identity information may justify advice on protective steps.
The incident-response team should consider mitigation alongside legal notification. Philippine NPC breach-management guidance specifically includes actions to mitigate possible harm, limit damage or distress, recover compromised information, and prevent recurrence.
Do not contact participants independently unless the response plan calls for it
A researcher who discovers a mistake may understandably want to apologize to participants immediately. Premature notification can, however, provide incomplete or inaccurate information, interfere with an investigation, create inconsistent messages, or omit legally required content.
Report internally first unless there is an immediate safety reason requiring another response. The responsible organization can determine who should contact affected participants, when, through which channel, and with what information.
Research governance obligations may exist beyond privacy law
A serious incident can also affect ethics approval, sponsor obligations, contractual commitments, research integrity, clinical governance, institutional security, or the safety of continued data collection.
Depending on the study, the institution may need to inform an ethics committee, sponsor, collaborating institution, funder, data provider, information-security team, or another authority in addition to any privacy regulator.
Those obligations should be coordinated rather than handled independently by individual researchers.
Do Not Hide Small Mistakes
A seemingly minor incident can often be contained quickly when reported early. Delayed reporting can turn a manageable disclosure into a larger problem by allowing access, copying, forwarding, or regulatory deadlines to continue while the research team hopes the issue disappears.
The incident should lead to prevention, not only closure
Once the immediate problem is contained, determine why it occurred. Was autocomplete responsible? Were access permissions too broad? Did staff use an unapproved personal device? Was a dataset insufficiently minimized? Was sensitive information unnecessarily attached to email?
The response may involve technical changes, revised procedures, staff training, tighter permissions, new transfer tools, better labeling, encryption, or changes to the data management plan.
The aim is not merely to identify who clicked the wrong button. A useful investigation asks what made that button capable of causing so much damage.
