Scoping Read Access for External Auditors

Part of: Access Control and Redaction for Lineage Records

An external auditor needs to see enough lineage to form an independent judgement and no more than the engagement covers. Both halves are real constraints, and organisations routinely fail one or the other — either by granting a broad read role that exceeds the mandate, or by curating an export so heavily that the auditor cannot verify anything and says so in the report. This how-to scopes auditor access so that it is defensible in both directions.

The principle that resolves most of the tension: give the auditor the ability to run their own queries within a bounded scope, rather than giving them answers you chose. An auditor who can only read what you decided to show them will, correctly, treat the evidence as management representation rather than as verified fact.

Prerequisites

  • An engagement scope in writing: which datasets, which period, which questions.
  • Classification on lineage records, per Access Control and Redaction for Lineage Records.
  • Row-level enforcement rather than application filtering.
  • An access log the auditor can also see.

Scope by Question, Not by Table

Granting SELECT on the lineage schema is the fast answer and it is almost always wrong in both directions at once.

Three ways to give an auditor access Broad schema read exceeds the mandate; a curated export cannot be independently verified; a scoped role with query capability satisfies both constraints. DESIGN WITHIN MANDATE? INDEPENDENT? SELECT on the schema "it is read-only" no — far exceeds yes a curated export a spreadsheet, emailed yes no — you chose what they see scoped role, own queries bounded by policy yes yes

Derive the scope from the engagement letter mechanically. The datasets named, plus their ancestry to whatever depth the engagement covers, within the stated period — that is a query, and it defines a role rather than requiring a judgement call per request.

Express the scope as data rather than as a hand-built set of grants. A scope table listing the datasets and the period, joined to by the access policy, can be reviewed by both sides and changed by amending a row when the engagement is extended.

Agree the scope with the auditor before implementing it. A scope derived unilaterally from the engagement letter will be read as management limiting the audit, whereas one both parties reviewed is a shared constraint. The conversation also surfaces questions the letter did not anticipate, which is cheaper to discover now than during fieldwork.

Include the ancestry, not just the named datasets. An auditor asked to verify a product’s provenance and given access only to that product can verify nothing, and the mandate implicitly covers what the product was built from.

Time-Box Everything

Access granted for an engagement should end when the engagement does, and the only reliable way to achieve that is to make it expire without anyone acting.

Set an expiry on the role at creation, matched to the engagement end plus a stated grace period. Extension should be an explicit act with a recorded reason.

Scope the data period as well as the access period. An engagement covering last financial year should not expose this month’s lineage, and a period predicate in the policy is easier to defend than a promise that the auditor will not look.

Revoke on completion rather than on expiry where you can. The expiry is the backstop; a prompt revocation when the report is signed is the control.

Keep the account, not the access. Deleting the auditor’s identity removes the audit trail of what they read, which is the record you may need if their findings are later disputed.

The Auditor Should See the Access Log Too

An audit trail visible only to the audited party is worth less than it costs, and sharing it is cheap.

A shared access log serves both parties Each query is logged with its scope-check outcome, and the log is readable by the auditor as well as the organisation. TIME QUERY ROWS SCOPE 09:14 ancestry of parcels_v3 18 in scope 09:21 quality history, 2025 Q3 204 in scope 09:33 ancestry of hydrology_v9 0 out of scope The zero-row row matters: it shows the boundary held, and shows where it was. Both parties read the same log — neither has to take the other's word for it.

The out-of-scope row is the one that earns the log its place. It demonstrates to the organisation that the boundary was enforced, and it shows the auditor exactly where their view ends — which is far better than an empty result they might read as an absence of data.

Return an explicit out-of-scope response rather than an empty set. “This entity exists and is outside the engagement scope” is a different fact from “no such entity”, and an auditor who cannot distinguish them will report the ambiguity.

Log the query text, the row count and the scope outcome. Logging the returned data itself is usually neither necessary nor proportionate, and it creates a second copy of everything.

Give Them the Schema and the Rules

An auditor working against an undocumented schema will misinterpret it, and the misinterpretation will appear in the report as a finding.

Provide the data model, the classification scheme, the canonicalisation specification if records are signed, and the definition of every derived figure they will see. All of it is documentation that should exist anyway.

Provide the redaction rule in summary. Telling an auditor that a category of location is withheld under a stated policy is more defensible than presenting an export that appears complete and is not.

Provide a worked example they can reproduce. One dataset traced end to end, with the query, the result and the interpretation, lets them calibrate against a known case before drawing conclusions from an unknown one.

Give Them a Replica, Not the Production Store

Where the auditor’s access lands is as much a scoping decision as what they can see, and the default of pointing them at production creates problems in both directions.

An auditor replica, frozen and policy-carrying A replica restored to the engagement cut-off, carrying the same row-level policies, isolates audit queries from production load and fixes the evidence date. production live, changing hourly restore audit replica frozen at the cut-off date same policies, same roles auditor A frozen replica means findings refer to a fixed state both parties can return to. Against production, a finding raised on Tuesday may be unreproducible by Thursday. The replica must carry the policies, not just the data. A restore that drops row-level security produces an unprotected copy of everything.

The policy warning at the bottom is not hypothetical: several restore paths recreate tables without their policies, and the resulting replica is a complete unrestricted copy of the lineage store sitting on infrastructure provisioned in a hurry for an audit.

The frozen cut-off is what makes findings tractable. An auditor querying live data raises findings against a moving target, and the discussion becomes about whether the state has since changed rather than about the finding.

Record the replica’s provenance — which backup, taken when, restored how. It is a dataset like any other and the audit will, reasonably, ask.

Destroy the replica at engagement close, and record that it was destroyed. An audit replica left running is a full copy of the lineage store with a relaxed access model and no owner.

Verification

Assert the scope boundary by querying, as the auditor role, for an entity known to be outside it, and confirming an explicit out-of-scope response rather than an empty result or an error.

Assert the period predicate with a record just inside and just outside the engagement window. Boundary handling on dates is where scope leaks.

Assert expiry by advancing the clock in a test environment past the role’s end date and confirming access stops without any manual action.

Assert the shared log is readable by the auditor role and that it contains their own queries and no one else’s.

Gotchas & edge cases

  • Access ends before the report is written. Auditors draft findings after the engagement window, and a scope that expires the day fieldwork ends leaves them unable to check a detail. Set the expiry against the report date, not the fieldwork date, and say so in the grant.
  • Screenshots leave no log. A shared access log records queries, not what was captured from the screen. It evidences the boundary, not the whole disclosure, and should be described that way.
  • Ancestry crosses the scope boundary by design. A named dataset’s chain will reach entities outside the engagement, and the policy must decide whether the auditor sees them, sees them masked, or sees a boundary marker. Decide before they ask.
  • Read-only is not the same as scoped. A role granted SELECT and nothing else can still read every row it is not policy-restricted from, and “they only have read access” is frequently offered as though it answered the scoping question. It answers the integrity question instead.
  • Query capability is a denial-of-service surface. An unbounded traversal by an auditor can take out the production database. Give them a replica, and set statement timeouts.
  • A scope that is too narrow becomes a finding. An auditor unable to verify a control will report the limitation, and a report noting restricted access reads worse than the access would have.
  • Auditors keep copies. Anything they can query, they can export. Access scope is a limit on what leaves, not merely on what is seen.
  • Findings need a right of reply. A scope that prevents the organisation from seeing what evidence a finding rests on makes the finding unchallengeable, which serves nobody.
  • Two auditors, two scopes. Concurrent engagements need separate roles and separate logs; sharing a role loses the attribution that makes the log useful.