Chapter 49 — Data-access governance and insider risk

In one sentence

Most access to sensitive data is technically authorized and still a risk, so governance — just-in-time elevation, behavioral monitoring, periodic recertification, and separation of duties — is how you keep "authorized" and "appropriate" from silently drifting apart.

Where we are

Every prior chapter in this Part assumed someone legitimately needs access to RESTRICTED data — support, engineering, analytics, finance. This chapter governs that legitimate access so it stays scoped, time-boxed, monitored, and reviewed, rather than accumulating into standing broad privilege nobody remembers granting.

How it works

Just-in-time (JIT) access — the default should be no standing access:

   Instead of a permanent grant ("alice has prod DB read access,
   forever, since she joined the on-call rotation two years ago"), access
   is REQUESTED, approved (often by an automated policy or a peer for
   routine cases, a manager for sensitive ones), granted for a BOUNDED
   TIME (an hour, a shift, the duration of an incident), and AUTO-REVOKED.
   Tools: Teleport (infra/DB/k8s access with session recording built in),
   Sym, ConductorOne, cloud-native options (AWS IAM Identity Center
   permission sets with a session duration, Entra ID Privileged Identity
   Management (PIM) for Azure role activation).
   BENEFIT beyond least-privilege-in-the-moment: it converts "who CAN
   access this" (a large, slowly-reviewed list) into "who DID access this,
   when, and why" (a small, naturally self-documenting log) -- which is
   both easier to review and inherently narrower.

Break-glass access — the deliberate exception, not the norm:

   Some situations need immediate, broader access than any JIT workflow
   can approve fast enough (an active incident, Ch 55). BREAK-GLASS is a
   documented, PRE-APPROVED emergency path: using it is easy in the
   moment (no waiting on an approver) but HEAVILY logged, immediately
   ALERTS a separate party (security/leadership) the moment it's used, and
   REQUIRES a POST-HOC JUSTIFICATION within a defined window. The bar
   for using it should be "clearly warranted", and its usage RATE is
   itself a metric worth watching -- frequent break-glass use usually
   means your normal JIT process is too slow or too narrow, not that
   people are careless.

Data Loss Prevention (DLP) — catching data as it tries to leave:

   Content-inspection controls at the points data typically exfiltrates
   through: email (outbound scanning for PAN-shaped strings, PII
   patterns, or classification-tagged (Ch 41) documents), endpoint
   (USB/upload/clipboard monitoring), cloud storage/CASB (a Cloud Access
   Security Broker inspecting uploads/downloads to sanctioned and,
   critically, UNSANCTIONED "shadow IT" cloud services).
   DLP is IMPERFECT (pattern-matching has false positives/negatives,
   determined exfiltration finds gaps -- encoding, screenshots, verbal
   disclosure) -- treat it as ONE layer catching the CARELESS and the
   OPPORTUNISTIC, not a guarantee against the DETERMINED, which is why
   the other controls in this chapter matter independently.

User and Entity Behavior Analytics (UEBA) — the volume/pattern signal:

   The same idea as Ch 48's Database Activity Monitoring, generalised
   across ALL systems an identity touches (not just the database): baseline
   NORMAL behaviour per user/service (typical access volume, typical
   hours, typical systems touched, typical data categories accessed), and
   alert on statistically significant DEVIATION -- an engineer suddenly
   querying 10x their normal number of customer records, a service
   account authenticating from a new geography, an account accessing
   systems it's never touched before.
   This is the layer that catches BOTH a compromised legitimate account
   (Ch 48's worked example) AND a genuine insider whose intent has
   changed -- neither necessarily violates any single access-control
   rule, which is exactly why pattern-based detection is a separate,
   necessary layer from authorization.

The "engineer queries prod directly" problem, solved structurally:

   A recurring tension: engineers need to debug production issues, which
   often means looking at real data, which is exactly the access this
   whole Part exists to constrain. STRUCTURAL answers, in order of
   preference:
     1. Provide SAFE QUERY TOOLS: a read-replica with dynamic masking
        (Ch 48) as the DEFAULT way to look at "production data" for
        debugging -- most debugging needs don't actually require
        unmasked PII.
     2. For the genuine exceptions: JIT access (above) with a SHORT
        duration, tied to a specific ticket/incident, with SESSION
        RECORDING (Teleport and similar PAM tools do this natively --
        every command/query in the session is logged and, often,
        replayable).
     3. QUERY AUDITING regardless of path: every privileged query against
        a RESTRICTED data store is logged with who/what/when/why (the
        ticket reference), reviewed on a cadence proportional to
        sensitivity.
   The goal isn't "engineers can never see real data" (often impossible
   and sometimes counterproductive) -- it's "every instance of seeing real
   data is time-boxed, attributable, and reviewable", which is a
   fundamentally different, achievable, and auditable posture.

Access recertification — closing the drift loop:

   PERMANENT access, once granted, tends to accumulate and never get
   revisited ("permission creep") -- someone changes teams and keeps their
   old system's access "just in case", a contractor's engagement ends but
   their account doesn't get disabled, a one-time project grant outlives
   the project by years.
   ACCESS RECERTIFICATION is a periodic (quarterly for sensitive systems,
   semi-annual/annual for lower-risk ones) process where the DATA OWNER
   or the person's MANAGER must actively re-affirm "yes, this person
   still needs this access, for this reason" -- access not re-affirmed by
   a deadline is automatically revoked, not left pending indefinitely.
   This is a standard, explicitly evaluated control in SOC 2 and ISO
   27001 audits (Ch 61) precisely because permission creep is one of the
   most common, most preventable sources of unnecessary standing risk in
   real organisations.

Insider-threat considerations and offboarding (technical + organisational):

   An effective insider-risk posture is technical, HR, and legal working
   together -- not a purely engineering problem -- but the ENGINEERING
   pieces are concrete:
     [ ] OFFBOARDING: access revoked THE SAME DAY as termination/departure
         -- across EVERY system (this is exactly what your Ch 41 data-flow
         map and system inventory make tractable rather than "did we
         remember everywhere Bob had access?").
     [ ] A KNOWN PATTERN worth monitoring for (with HR/legal involvement,
         not unilaterally by engineering): unusual data access or bulk
         downloads in the weeks BEFORE a resignation is announced --
         UEBA's behavioural baseline is exactly the mechanism that would
         surface this, treated with appropriate care and process, not as
         a blanket surveillance justification.
     [ ] PRIVILEGED ACCESS MANAGEMENT (PAM) tools (CyberArk, HashiCorp
         Boundary, Teleport) generalise JIT + session recording +
         credential vaulting across infrastructure/admin access broadly
         (this connects forward to Ch 63's enterprise identity chapter --
         PAM is the infra-wide version of the JIT pattern this chapter
         applies to data specifically).

Worked example

Recertification catching what nobody remembered to revoke.

   SecureShop runs a quarterly access recertification for its `customer-
   restricted-data` system group (from the Ch 41 inventory). The process
   emails each data owner a list of current grants for their system,
   requiring an explicit "still needed" confirmation per person within
   two weeks; unconfirmed grants auto-revoke.

   THIS QUARTER'S FINDINGS:
     - a contractor engaged for a THREE-MONTH data-migration project
       (concluded five months ago) still has standing read access to the
       `orders` production replica -- their contract manager confirms the
       engagement ended; the grant is revoked. Nobody had maliciously
       intended this; the offboarding process for CONTRACTORS specifically
       had a gap that full-time-employee offboarding didn't (a common,
       specific failure mode worth checking for explicitly).
     - an engineer who ROTATED from the payments team to the marketing
       team eight months ago still has their old `payments-restricted`
       group membership; their new manager doesn't recognise the need,
       confirms with the old team lead that it's stale, and it's revoked.
     - a service account created for a NOW-DECOMMISSIONED integration
       still has a live grant with nobody left to confirm or deny it
       (its original requester left the company) -- escalated to security
       for investigation rather than auto-revoked-and-forgotten, since an
       orphaned grant with no clear owner is itself a finding worth
       understanding, not just clearing.

   NONE of these three would have been caught by RLS, encryption, DAM, or
   UEBA -- each grant was to a real, authenticated, non-anomalous-looking
   identity, used rarely or not recently enough to trip a behavioural
   baseline. Recertification is the layer that catches STALE-BUT-VALID
   access precisely because it doesn't wait for anomalous BEHAVIOUR --
   it re-asks the authorization QUESTION on a schedule, regardless of
   activity.

Practice (60 min)

Design a quarterly access-recertification process for one real system: who is the "data owner" who confirms grants, what happens to unconfirmed access, and how would you generate the review list from your existing access records.
Set up (or simulate) JIT access for one sensitive resource: a request/ approval step, a bounded session duration, and automatic revocation. Time how long a grant actually persists versus how long it would have under a standing-access model.
Write your organisation's break-glass procedure for one critical system: how it's invoked, who is alerted immediately, and what the post-hoc justification requirement is. Simulate using it once and confirm the alert fires.
Establish a UEBA baseline (even a simple one: average daily query count per account from Ch 48's audit log) for a handful of real accounts; inject a simulated anomalous access pattern and confirm it would be flagged.
Audit your own offboarding process: pick a departed contractor or employee (real or simulated) and verify, system by system from your Ch 41 inventory, that access was actually revoked and on what day relative to departure.

Common mistakes

Standing access as the default, JIT as the exception. Invert this: no standing access to RESTRICTED data unless specifically justified; JIT/ time-boxed as the default pattern.
Break-glass with no alerting or follow-up. An emergency path nobody monitors becomes a permanent, unaudited backdoor.
Treating DLP as sufficient on its own. It catches carelessness and opportunism, not determined exfiltration — it's one layer, not the control.
No recertification, or recertification that's a rubber-stamp "approve all" click. The value is in someone actually re-evaluating necessity; make the default for non-response REVOKE, not "assume still needed."
Contractor and service-account offboarding treated as an afterthought compared to employee offboarding. The worked example's most common finding in real organisations is exactly this gap.
UEBA/DAM baselines never established or never revisited as normal usage patterns legitimately change (a team grows, a new feature increases query volume) — stale baselines produce alert fatigue in both directions.
Insider-risk monitoring run unilaterally by engineering/security without HR and legal involvement. Both a governance failure and, in many jurisdictions, a legal one.

Check yourself

What does just-in-time access convert a standing "who CAN access this" list into, and why is that easier to govern?
What makes break-glass access safe to have despite bypassing the normal approval flow?
Why is DLP described as catching "the careless and the opportunistic" rather than "the determined" — and what follows from that limitation?
What does access recertification catch that behavioral monitoring (UEBA) does not, and why?
Give three structural answers to "engineers need to debug with real production data" that don't require unmasked standing access.
Why is contractor/service-account offboarding a specific, separate risk from employee offboarding?