What is data privacy?

No. Data security is mainly about protecting information from unauthorized access, alteration, loss, or damage. Data privacy is about whether information is collected and used appropriately, transparently, and for a defined purpose. Strong privacy practices usually depend on security controls, but security alone does not answer whether an organization should collect a particular data point in the first place.

Personal data is information relating to an identified or identifiable person. It can include obvious identifiers such as names and email addresses, but also location data, IP addresses, cookie identifiers, or other online identifiers when they can be linked to a person directly or indirectly. Whether a data point is personal data depends on the information available and the context in which it is used.

Common data protection frameworks emphasize lawfulness, fairness and transparency; purpose limitation; data minimization; accuracy; storage limitation; integrity and confidentiality; and accountability. These principles encourage organizations to collect only what they need, use it for clear purposes, keep it accurate and secure, avoid retaining it longer than necessary, and be able to demonstrate responsible handling.

Consent is one possible way an organization may obtain permission for a particular processing activity, but privacy is broader than consent. Privacy also includes purpose limitation, minimization, security, retention, access, deletion, and transparency. Whether consent is required—and what form it must take—depends on the applicable law, the type of data, and the processing activity.

Start by defining the questions the analytics must answer and collect only the data needed for those questions. Avoid collecting sensitive fields, mask or block identifiers, explain the practice clearly, provide consent or opt-out choices where required, restrict access, set retention limits, and test the configuration regularly. Teams should document decisions and verify them against the laws and policies that apply to their organization.

A data controller generally decides why personal data is processed and the main means of processing. A data processor handles personal data on the controller’s behalf and according to documented instructions. In practice, contracts and local laws define the responsibilities in more detail, so organizations should confirm the roles for each processing activity.

Truly anonymized data cannot reasonably be linked back to an identifiable person and may fall outside personal-data rules, depending on the applicable framework. Pseudonymized data is different: it replaces direct identifiers but can still be linked back using additional information, so it generally remains personal data. Anonymization claims should be assessed carefully, especially when datasets can be combined.

Session replay can reveal the content and behavior a person experienced, so teams should decide what may be captured before enabling it. Privacy-aware implementation can include blocking collection of sensitive fields, masking or redacting content, limiting access, defining retention periods, and providing appropriate notices or choices. Teams should test representative pages and app screens to confirm that the controls work as intended.

Create a simple inventory of the data you collect, why you collect it, where it goes, who can access it, and how long you keep it. Then identify unnecessary fields and high-risk flows, prioritize controls such as masking, access restrictions, retention, and deletion, and review the result with privacy, security, and legal stakeholders. Revisit the inventory when products, vendors, or regulations change.