Data Quality Recertification¶
Attestation review — instantiates Periodic Review and Reset
Requires the named owner of each data asset, definition, or access grant to re-affirm on a cycle that it still meets standard; anything left un-attested is revoked or quarantined by default.
Data Quality Recertification puts the burden of proof on the owner and makes silence expensive. On each cycle, every data asset in scope — an access grant, a field definition, a shared dataset, a business glossary term — is pushed back to a named accountable person who must actively re-affirm that it is still correct, still needed, and still meets the standard. Its defining move is default revocation: whatever no one re-certifies is automatically expired, quarantined, or removed. Where a check might inspect and then decide what to keep, recertification inverts the default — an asset survives only if a responsible human vouches for it, so entitlements and definitions cannot persist by inertia after their justification has quietly disappeared.
Example¶
A bank's data-governance team runs quarterly recertification on access to the customer-analytics warehouse, which holds sensitive account data. The reference is the least-privilege standard: every grant must map to a current business need. The system emails each dataset owner a list of who currently has access and asks them to attest, per person, keep or revoke. A team lead reviews her list and finds three analysts who moved to other departments six months ago and one contractor whose engagement ended. She attests "keep" for her active team and takes no action on the four stale entries.
Because the workflow defaults to revoke, those four un-attested grants are automatically pulled at the deadline — no one had to remember to remove them. In parallel, a "customer_status" field flagged by owners as ambiguous is quarantined until its definition is refreshed. The stale access simply evaporated because nobody vouched for it, which is exactly the point: the reset happened by default, driven by the absence of an attestation rather than by anyone hunting down the leftovers.
How it works¶
- Hold a live inventory against a standard. Enumerate the assets in scope and the standard each must meet (least privilege, an agreed definition, a freshness rule).
- Route each item to its accountable owner. The person who can actually judge fitness is asked to attest — keep, change, or let lapse — item by item.
- Default to revoke on silence. Anything not affirmatively re-certified by the deadline is expired, quarantined, or removed automatically; inaction is a decision.
- Reset by removal or refresh. Stale grants are pulled; ambiguous definitions are quarantined and re-authored before re-use.
- Trigger off-cycle where risk spikes. A role change or a breach can fire an immediate recertification of the affected assets, ahead of the normal cycle.
Tuning parameters¶
- Cycle length — frequent recertification keeps entitlements tight but fatigues owners into rubber-stamping; long cycles ease the load but let staleness accumulate.
- Default action — revoke-on-silence maximizes hygiene but risks breaking a live dependency someone forgot to affirm; keep-on-silence is safer operationally but defeats the mechanism's purpose.
- Granularity — per-item attestation is precise but heavy; per-group or per-role attestation is lighter but blunter.
- Attestation friction — one-click keep is fast but invites careless approval; requiring a justification slows owners down but forces genuine thought.
- Off-cycle trigger sensitivity — how aggressively role changes and incidents launch an out-of-band recertification.
When it helps, and when it misleads¶
Its strength is that it defeats inertia: things that outlived their justification — orphaned permissions, zombie datasets, definitions no one remembers agreeing to — are cleared without anyone having to notice them individually, because survival requires an active vouch.
Its failure mode is rubber-stamp attestation: when owners face hundreds of items they click "keep" down the list, and recertification becomes theater that launders stale access as reviewed. The classic misuse is scoping the cycle so broadly that no owner can meaningfully judge any single item, violating least privilege[n1] under a veneer of compliance. The guarding discipline is to keep each owner's list small enough to think about, require a reason for non-obvious keeps, and sample attestations for honesty — so a "keep" means something.
How it implements the components¶
reference_state— the standard each asset must still satisfy (least privilege, an agreed definition, a freshness bar) is the reference the owner attests against.accountable_reviewer— a named owner is required to personally re-affirm each item; the attestation carries their accountability.reset_action— the corrective move is removal or refresh: revoking stale grants and quarantining drifted definitions.exception_trigger— a role change or incident fires an off-cycle recertification of the affected assets ahead of the normal interval.
It does not implement the drift_indicator of a live measured error against a physical reference — that's Calibration Check; recertification detects staleness through the absence of a fresh attestation rather than by reading a deviation off an instrument.
Related¶
- Instantiates: Periodic Review and Reset — Data Quality Recertification supplies the owner-attestation-and-default-revoke path through the loop.
- Sibling mechanisms: Audit Cycle · Calibration Check · Financial Reconciliation · Health Checkup · Policy Review · Preventive Maintenance Check · Quarterly Business Review · Retrospective
Editorial Notes¶
Form Classification¶
Form family: Assessment, Review & Assurance
Rationale: Data Quality Recertification operates as a bounded evaluation of existing evidence or work that produces a finding or disposition because it requires the named owner of each data asset, definition, or access grant to re-affirm on a cycle that it still meets standard; anything left un-attested is revoked or quarantined by default.
Independent corroboration: The frozen evidence defines Data Quality Recertification as 'Requires the named owner of each data asset, definition, or access grant to re-affirm on a cycle that it still meets standard; anything left un-attested is revoked or quarantined by default', so its operative form is Assessment, Review & Assurance.
Review outcome: Independent reviewer agreement; medium confidence.
Origin Attribution¶
Primary origin: Security Studies & Intelligence Analysis
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Identity and access governance established periodic owner recertification with revocation when privileges are no longer re-attested; accounting controls, data governance, and metadata stewardship shape its extension to data-quality assets.
Related originating lineages:
- Accounting & Auditing — Control certification supplied periodic accountable attestation and evidence-retention practices.
- Data Science & Analytics — Data governance extended attestation cycles to datasets, field definitions, freshness rules, and business terms.
- Library & Information Science — Metadata stewardship supplied named ownership and periodic review of shared definitions and data assets.
Review resolution: Authoritative security and audit controls document periodic privilege recertification; the entry's broader recertification of datasets, definitions, lineage, and quality rules is a cross-disciplinary synthesis.
Attribution caveat: Access recertification is established; extending default-expire attestation to heterogeneous data-quality assets is a synthesized generalization.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Researched adjudication after independent review; high confidence.
Sources consulted:
- NIST SP 800-171 Revision 3: Protecting Controlled Unclassified Information
- U.S. GAO Federal Information System Controls Audit Manual 2024 Revision
Notes¶
[n1] The principle of least privilege (Saltzer & Schroeder) holds that every user or process should have only the minimum access needed for its legitimate purpose. Recertification is the periodic mechanism that enforces it over time, since privilege granted for a past need tends to outlive the need unless someone is periodically forced to re-justify it. ↩