CompTIA Data+ DA0-002 · Free study guide

Objective 5.3 — Compare privacy and protection practices

Privacy governs appropriate use of information about people. Protection supplies controls that reduce unauthorized access, disclosure, alteration, and loss. The two reinforce each other, but they are not identical. A strongly encrypted data set can still violate privacy if an authorized analyst uses it for an unapproved purpose.

Role-based access and least privilege

Role-based access control, or RBAC, assigns permissions to defined job roles and assigns people or service accounts to those roles. A finance analyst receives the approved finance-analyst permissions rather than a collection of one-off grants. RBAC makes access more consistent, reviewable, and easier to revoke when duties change.

Least privilege limits each identity to the access and actions needed for its current task. A reporting service that reads approved views does not need permission to alter source tables. A contractor working on one region does not need a global customer export.

RBAC does not guarantee least privilege. A role can be designed too broadly, and accumulated memberships can create excessive combined access. Review roles, members, dormant accounts, service identities, and temporary exceptions. Time-limited elevation is safer than a permanent administrative grant.

Encryption in transit and at rest

Encryption in transit protects data while it crosses a network, commonly through protocols such as TLS. It reduces interception and tampering between a database, application, BI tool, or external recipient.

Encryption at rest protects stored data on disks, object stores, databases, backups, and managed devices. Depending on the risk, protection can operate at the storage, database, field, or file level.

Encryption is only as strong as its key management and endpoint controls. Keys should have restricted access, rotation, recovery, and audit procedures. Storing the key beside an unrestricted encrypted file weakens the control. An authorized query can still return readable data, and malware on an unlocked analyst device can capture data after decryption.

Hashing is designed as a one-way representation; encryption is reversed with an authorized key.

Approved data use and sharing

Access permission does not grant unlimited use. Approved data use connects a purpose, population, fields, method, retention period, and accountable owner. Reusing data for a materially different purpose may require a new review even when the analyst can technically query it.

Apply data minimization: use only the records and fields needed. A payment-trend analysis rarely needs names or full card numbers. A regional staffing report may need aggregated counts rather than employee-level records.

Data sharing includes internal exports, shared dashboards, email attachments, vendor transfers, research files, and public releases. Before sharing, confirm recipient identity and authority, permitted purpose, minimum fields, secure transfer, downstream controls, retention, and deletion. Contracts or data-sharing agreements may define these duties.

PII and PHI

Personally identifiable information, or PII, is information that identifies or can reasonably be linked to a person. Direct identifiers include names, government identifiers, account numbers, and email addresses. Indirect or quasi-identifiers such as birth date, postal code, employer, and detailed location can identify someone when combined.

PHI refers to health information associated with an identifiable person, commonly called protected health information in United States healthcare regulation. Diagnoses, treatment, visit dates, and medical record numbers can be PHI when handled by a covered organization or partner. Not every wellness statistic is regulated in the same way, but health data remains sensitive and requires approved classification.

Use the scenario’s jurisdiction and organizational context rather than assuming one law from the presence of a health-related field.

NIST guidance

The National Institute of Standards and Technology, or NIST, publishes frameworks and technical guidance for managing cybersecurity, privacy, identity, and information risks. Organizations use NIST resources to identify risks, choose controls, assess maturity, communicate expectations, and improve processes.

NIST guidance is not itself a universal privacy law. A contract or policy may require a particular publication, but “NIST compliant” without a scope, controls, and evidence is too vague.

Anonymization, pseudonymization, tokenization, and masking

These techniques reduce exposure in different ways.

Anonymization can use aggregation, suppression, generalization, or other methods. It must consider linkage attacks using outside data. Retaining a lookup table means the result is pseudonymized, not fully anonymized.

Pseudonymization reduces direct exposure while allowing authorized reconnection. The mapping and remaining attributes require protection, and the data generally remains personal data.

Tokenization is useful when systems need a stable substitute without repeatedly exposing the original value. Masking may be static in a test copy or dynamic in a query result. Showing only the last four digits is masking, not anonymization.

Encryption protects confidentiality but preserves the original value for anyone with the key. It should not be described as anonymization.

Scenario: sharing patient outcomes for research

A hospital partner requests patient outcomes for an approved study. Researchers need age range, treatment, month, and outcome, but not operational identifiers. Very rare conditions and exact locations could still reveal people.

The hospital grants access through a least-privilege research role and uses an approved workspace instead of emailing a file. Direct identifiers are removed, dates and ages are generalized where the protocol allows, and rare combinations are suppressed or grouped. If follow-up requires reconnection, protected tokens are used and the mapping stays with a separate authorized service; the data is pseudonymized, not called anonymous. Encryption protects the workspace and transfer, while use, retention, exports, and deletion follow the agreement. NIST-aligned risk assessment can help select controls, but it does not replace healthcare and privacy obligations.

Exam traps

• Assuming RBAC automatically produces least privilege.
• Confusing authentication with authorization.
• Choosing at-rest encryption when the stated risk is network interception, or vice versa.
• Treating encryption as protection against every action by an authorized user.
• Using technically accessible data for an unapproved purpose.
• Assuming removal of names makes a data set anonymous.
• Treating all health-related information as identical under every jurisdiction.
• Calling pseudonymized or tokenized data fully anonymous while a mapping exists.
• Assuming masked display means the underlying stored value is protected.
• Treating NIST as a universal law or a software product.

Readiness checklist

• I can explain how RBAC and least privilege work together and where they differ.
• I can choose in-transit and at-rest encryption for the risk described.
• I can explain why key management and endpoint security still matter.
• I can evaluate approved use and sharing beyond simple access permission.
• I can identify direct and indirect PII and recognize PHI context.
• I can describe NIST as risk and control guidance rather than a universal law.
• I can distinguish anonymization, pseudonymization, tokenization, masking, hashing, and encryption.
• I can identify re-identification risk in small groups or combined fields.
• I can design a minimized, controlled sharing workflow for sensitive data.