Security and Data Governance: least privilege and accountability
What this domain tests
Security and Data Governance tests whether access to data is controlled, monitored, and accountable. Questions cover the CIA triad, access models, encryption, secrets, classification, ownership, logging, incident response, and vendor risk.
Core rules
- Protect confidentiality, integrity, and availability with layered controls; no single control is sufficient.
- Apply least privilege and need-to-know. Use role-based access control for broad job functions and attribute-based access for finer conditions such as region or purpose.
- Grant access for a defined period with an approval record; review entitlements quarterly and remove them at offboarding.
- Encrypt data in transit with TLS and at rest with managed keys; separate key management from data storage.
- Classify data (public, internal, confidential, restricted) and label PII, credentials, and health data explicitly.
- Keep secrets in a vault, never in code, notebooks, or environment files committed to version control.
- Log access to sensitive data with who, what, when, and why; alert on anomalous volume or off-hours export.
- Maintain an incident response plan with roles, notification timelines, and evidence preservation.
Worked example
An analyst needs customer emails for a churn study. Reasoning: the purpose is legitimate but the full identifier is not necessary. You grant a time-bound role that exposes a masked email column plus a stable customer key, require an approved ticket, log every query, and disable bulk export to local devices. The analyst joins on the key, so the model never needs the raw address. After 30 days the grant expires automatically. If the study requires contact for outreach, a separate approved workflow releases the address. This satisfies least privilege and purpose limitation while preserving reproducibility.
Traps that cost marks
- Shared service accounts and credentials that defeat attribution.
- Copying production PII into development or notebooks.
- Logging full request bodies that contain tokens or personal data.
- Giving administrators broad standing access for convenience.
- No offboarding check, leaving former staff with access.