skip to content

What does a periodic access review of a data platform check, and how do read logs keep it from becoming a rubber stamp?

level: middleimportance: should knowfreq 40%

answer

  1. who has what, still needed?
  2. owners attest, not the platform team
  3. unused grants are the evidence
  4. leavers and movers
  5. expiry beats review

basics

~20 s

An access review asks each data owner to confirm that every holder of access to their data still needs it. Read logs show which grants were never used, so owners revoke on evidence instead of approving everything by default.

solid answer

~40 s

A periodic **access review** (recertification) lists, per dataset or role, **who holds access** and asks the **data owner** to confirm each holder still needs it; unconfirmed access is revoked. It also catches **movers and leavers** whose access outlived their role. Without evidence, owners approve whole lists because checking is slow — the rubber stamp. **Read logs** fix that: for each grant, show when the holder last queried the data. Access unused for, say, 90 days is proposed for revocation by default and must be actively kept. I would also shrink what needs reviewing by making access **time-bound** from the start — grants that expire unless renewed — and by granting to roles or policies rather than individuals, so the review is about a few groups, not thousands of entries.

go deeper

for a junior

Know that access reviews periodically confirm that people still need the access they hold.

for a middle

Explain what a review covers, including movers, leavers and service accounts, and how read logs support revocation.

for a senior

Design reviews that default to revoking unused access and reduce the review surface with expiring and group-based grants.

for a principal

Set the review cadence and scope by data sensitivity and make owners accountable for the outcome, not only for completing the task.

## Why reviews exist Access accumulates. People change teams and keep their old grants; projects end and their service accounts stay; temporary access for an incident is never removed. Over time the set of people who **can** read sensitive data drifts far from the set who **need** to. A periodic **access review** — also called **recertification** — is the control that pulls it back, and auditors of security and privacy programmes routinely ask for evidence that it happens. ## What a review checks 1. **Current holders**: every user, group and service account with access to the dataset or role, including access inherited through nested roles. 2. **Still needed**: the data owner (not the platform team) attests that each holder still has a business need. 3. **Right level**: whether the holder needs full access or would be served by masked or aggregated data. 4. **Movers and leavers**: holders whose department or employment status changed since access was granted. 5. **Privileged and service accounts**: accounts that can read everything, which deserve the closest look. ## Why reviews become rubber stamps Owners are handed a list of hundreds of names with no context and a deadline. Checking each one is slow, and the cost of wrongly revoking seems higher than the cost of approving, so they approve everything. The review then produces evidence of a process, not a reduction in access. ## Evidence from read logs Query and access logs change the default: | Evidence per holder | Suggested action | |---|---| | Read the data in the last 30 days | keep, unless the role changed | | No reads for 90+ days | revoke unless the owner actively keeps it | | Never read since the grant | revoke by default | | Holder has left or moved teams | revoke; re-request if still needed | The owner now reviews exceptions instead of whole lists. ## Reducing the review burden - **Time-bound access**: grants carry an expiry and must be renewed, so stale access removes itself. - **Group-based grants**: access goes to roles or attribute policies tied to HR data, so leaving a team removes access automatically. - **Just-in-time elevation**: sensitive access is requested for a task and expires after it, logged. ## Why interviewers ask it It separates candidates who know that access control is a lifecycle from those who think it ends at the grant. The strong answer names the **owner's attestation**, uses **usage evidence** to make revocation the default, and designs access so that less needs reviewing.

  • Why should the data owner, not the platform team, attest in the review?
    The platform team knows who has access but not who needs it. Need is a business judgement about the data's purpose, which the owner is accountable for, and auditors expect the attestation to come from that accountability.
  • How do you handle service accounts in an access review?
    Map each to an owning team and system, check with read logs that it still runs, and review what it can read against what the system uses. Unowned or unused service accounts are disabled first, because nobody will notice their access otherwise.

saying these in an interview costs you the question

  • Letting the platform team approve access on behalf of data owners
  • Reviewing hundreds of names with no usage evidence
  • Treating a completed review as proof that access is appropriate
  • Forgetting service accounts and inherited access through nested roles