A common mistake is assuming that faster storage, larger lakes, or more compute automatically create business value. In practice, organisations can still fail to extract value if the data is inconsistent, poorly classified, or not trusted by users. The real issue is often people, process, and governance, not just infrastructure. Data quality must be continuous, operational, and tied to use cases.
Storage scale is not the same as usable data quality
The mistake is treating data quality as an infrastructure problem instead of a business control problem. Bigger storage, faster pipelines, and more compute can move more records, but they do not make the underlying data trustworthy, consistent, or fit for the use case. If the data model, definitions, ownership, and validation rules are weak, scale simply increases the amount of bad data flowing through the organisation.
Teams also confuse volume with value. A larger lake can hold more sources, but without classification, lineage, and agreed semantics, users still spend time reconciling conflicting fields and questioning whether the output is reliable. That is why data quality should be judged by whether people can confidently act on the data, not by how efficiently it is stored or processed. For a broader operating model, see the Ultimate Guide to NHIs, which also highlights why lifecycle, ownership, and governance determine whether control is real or nominal.
Continuous quality also matters more than one-time cleanup. Data degrades as systems change, schemas drift, and upstream sources introduce inconsistency. When quality checks are bolted on after ingestion, teams discover problems too late and at too much scale to correct cheaply. Operational quality means defining standards, validating at key points, and measuring whether trusted datasets stay trusted as they move through the pipeline.
Why scale hides the real failure modes
At scale, the most common failures are not storage bottlenecks but weak definitions and weak accountability. Different teams may use the same field to mean different things, duplicate entities may never be reconciled, and stale reference data may be reused because no one owns correction. Those are governance failures, not throughput failures.
Scale can also create a false sense of maturity. If ingestion is automated and processing is fast, teams assume the platform is healthy, even when data quality issues are spreading across reports, models, and operational decisions. The result is a system that is technically efficient but operationally unreliable. For teams dealing with control sprawl and ownership gaps, the NHI and Secrets Risk Report offers a useful parallel on how scale without visibility creates risk.
One practical sign of this problem is that data quality work becomes reactive. People fix one dashboard, one model, or one workflow, but the underlying defect keeps returning because the organisation has not defined a durable rule set for classifying, stewarding, and validating the data.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 and SOC 2 (AICPA) define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV — Govern | Data quality failures are governance failures that need ownership and policy discipline. |
| ID — Identify | Quality depends on knowing which datasets matter and where they are used. | |
| PR.DS — Data Security | Classification, integrity, and trust in data are central to quality outcomes. | |
| Recommendation — Assign data ownership and govern quality controls as an ongoing risk-management activity. Inventory critical datasets and map their business use and dependencies. Apply data integrity and classification controls to keep critical datasets trustworthy. | ||
| ISO/IEC 27001:2022 | A.5.9 — Inventory of information and other associated assets | Data quality work starts by knowing which data assets exist and matter. |
| A.5.12 — Classification of information | Quality and trust depend on consistent classification and handling rules. | |
| A.5.15 — Access control | Poorly governed access can undermine trust in who may change or rely on data. | |
| Recommendation — Maintain an inventory of key datasets, owners, and business purposes. Classify data consistently so quality rules and handling expectations are explicit. Restrict who can alter critical data and who can approve quality exceptions. | ||
| CIS Controls v8 | 1 — Inventory and Control of Enterprise Assets | You need visibility into the data sources and systems that shape quality. |
| 3 — Data Protection | Quality depends on preserving integrity, classification, and handling discipline. | |
| 8 — Audit Log Management | Traceability helps teams detect when data quality degrades or changes unexpectedly. | |
| Recommendation — Maintain an accurate inventory of data-producing systems and critical datasets. Protect critical data from uncontrolled alteration and inconsistent handling. Log key data changes so drift and integrity issues can be investigated. | ||
| SOC 2 (AICPA) | CC8.1 — Change Management | Data quality often breaks when upstream changes are not controlled. |
| Recommendation — Control schema and pipeline changes so they do not silently degrade data quality. | ||
Practitioner Guidance
What to prioritise: Start with the few data assets that directly drive operational decisions, customer-facing outputs, or regulated reporting. If those datasets are not trusted, improving the storage layer will not change the business outcome.
What to verify: Confirm that each critical dataset has an owner, a definition, known quality rules, and a way to detect drift. If teams cannot explain what “good” looks like for the data, the issue is governance maturity, not platform size.
What good looks like: Trusted datasets are measurable, continuously checked, and corrected close to the source. Users can identify where the data came from, what changed, and whether it is safe to use without building their own shadow controls.
Practitioner takeaway: The decisive test is not whether the platform can store or move more data, but whether the organisation can keep the data reliable enough for people and systems to use with confidence.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 23, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
