Why Data Catalogs Miss the Real Risks in Data Security Assessment

Many organizations start data security work by building a data catalog. That step is necessary: without knowing what tables, fields, interfaces, files, and systems exist, downstream tasks like classification, access control, masking, and sharing approval cannot proceed. However, a catalog only answers "what data exists." Real risk arises from "who uses the data, for what purpose, through what means, and within what boundaries."

1. Relying Solely on Catalogs Underestimates True Risk

A data catalog is a map, not the full terrain. The same field—say, a phone number—carries different risk depending on context: used for login verification, exported to an external spreadsheet, fed into profiling, precision marketing, cross-system sharing, or model training. Risk assessment must therefore go beyond "Is this personal or important data? What level?" and ask:

Who is using it?

What is the purpose? Does it exceed original authorization or business necessity?

Has copying, export, sharing, delegated processing, or joint processing occurred?

Are there logs, approvals, contracts, interface records, and remediation evidence to support the activity?

If these questions cannot be answered, the assessment remains on paper even with a perfect catalog. The common pitfall is equating "inventory complete" with "risk understood." A catalog proves data exists; processing activities explain how risk materializes.

2. The Real Trouble: Data Mutates as It Flows

Data security risk rarely stays inside a single database. It may move from a business system to a data platform, then to a reporting system, exported to a spreadsheet, imported into a collaboration platform, and finally used for algorithm training, statistical analysis, external integration, or special projects. Each step alone may have a legitimate purpose, but chained together the risk profile changes.

For example, data in the source system has access control and operation logs. In the data warehouse, fields are recombined. In reports, permission granularity coarsens. After export, it leaves system audit. In model training, purpose expands and inference risks appear. Assessing only "what the source data is" misses these intermediate links. The Network Data Security Risk Assessment Measures defines assessment as risk identification, analysis, and evaluation for both network data and network data processing activities—placing "processing activities" on equal footing with "data itself." Data security is no longer about protecting a batch of fields but about protecting a continuous set of business behaviors.

3. A Practical Observation Framework: Four Questions to Validate an Assessment

To judge whether a risk assessment is truly effective, check if it answers four questions:

Data Items: Which data are processed? Do they involve personal information, important data, or sensitive business data? Common gap: listing only tables, not the sensitivity of combined fields.

Processing Activities: Is data collected, stored, processed, transmitted, provided, disclosed, or deleted? Common gap: reviewing only system inventories, ignoring exports, APIs, sharing, and model training.

Usage Scenarios: Who uses it for what purpose? Is it necessary, legitimate, and bounded? Common gap: writing "business need" without specifying roles, processes, and concrete purposes.

Responsibility Evidence: Are there approvals, contracts, logs, permissions, remediation, and retention records? Common gap: having policy documents but lacking verifiable process evidence.

This framework is not a new form; it underscores a basic fact: data security risk does not auto-generate from field names—it forms in usage scenarios. The same dataset under internal statistics, cross-department sharing, third-party delegation, AI training, or public display carries completely different risks. A mature assessment articulates these differences rather than compressing everything into "high, medium, low."

4. Risk Assessment Is Not a One-Off Compliance Act but a Business Accountability Mechanism

Many treat risk assessment as "producing a report." Reports matter—the Measures mandate annual assessments for important data processors, report retention, submission, and remediation, and impose authenticity, validity, and completeness duties on assessment bodies. But viewing it only as documentation underestimates its impact on daily data governance.

Risk assessment changes how an organization answers questions. Historically, data security knowledge was fragmented: business knows usage, tech knows systems, security knows risk, legal knows policy, vendors know interfaces. Each holds a piece; assessment must stitch them into a complete chain. Hence it inherently requires cross-department collaboration—business, technology, legal, compliance, security, operations, procurement, and supplier management—not a solo security document.

An assessment conclusion that cannot be pinned to accountability loses value. Who approved this sharing? Who confirmed the purpose? Who configured interface permissions? Who verified masking? Who owns scheduled deletion? Who closes the loop on findings? These granular questions determine whether assessment shifts from "compliance material" to "risk governance."

5. AI Applications Make Processing Activities Harder to Describe

Traditional processing activities—collection, storage, processing, transmission, query, export, sharing—are relatively easy to describe. AI introduces knowledge-base construction, vector retrieval, model fine-tuning, agent tool calls, auto-summarization, intelligent review, decision support, and multimodal recognition. These may not look like "exporting a table" but can alter data scope, access patterns, and risk outcomes.

For instance, a business knowledge base appears to aid retrieval, but without source tracking, permission inheritance, sensitive-data filtering, and call logs, it can recombine information previously scattered across systems. An agent seems to automate workflows, yet if it reads multi-system data, calls interfaces, generates artifacts, and triggers actions, it is no longer a simple Q&A tool.

In such scenarios, assessment cannot stop at the catalog. It must further ask: Which data are used in training, retrieval, generation, invocation, and feedback? Can model outputs expose raw information? Does the agent inherit a user's full permissions? Are prompts, logs, vector stores, and intermediate results governed? Can evidence chains be reconstructed when erroneous calls or unauthorized access occur? This is not to paint AI as dangerous, but to signal a trend: risk assessment must keep pace with new processing forms. As data shifts from "being queried" to "being understood and invoked by models," assessment must evolve from static asset inventory to dynamic process scrutiny.

6. Good Assessment Ultimately Makes Data More Usable

Data security risk assessment is not meant to halt data flow. On the contrary, sound assessment enables data to flow more confidently within clear boundaries. Much data "unwilling or afraid to move" not because it lacks value, but because responsibility is unclear, risk is invisible, and no one can explain incidents.

When assessment clarifies data items, processing activities, usage scenarios, and responsibility evidence, data sharing, business collaboration, public services, industry large models, and agent applications gain trust. Providers know how data will be used; consumers know boundaries; managers know risks, owners, and remediation paths; auditors have traceable evidence.

The true value of data security risk assessment is not generating another report, but moving data utilization from "relying on experience, coordination, and fear of incidents" to "grounded in evidence, bounded, traceable, and closed-loop." In the coming period, organizations will continue building catalogs, classification, and processes. The more critical question: when a real data processing activity occurs, can we explain why it is necessary, where the risk lies, what the boundaries are, and who bears responsibility? That is what risk assessment must ultimately reveal.

Sources and References

Cyberspace Administration of China: Network Data Security Risk Assessment Measures , published 2026-06-18, effective 2026-08-20. URL: https://www.cac.gov.cn/2026-06/18/c_1783525609815499.htm

CAC Expert Interpretation: Establishing and Improving the Data Security Risk Assessment System to Build a Solid National Data Security Barrier , 2026-06-18. URL: https://www.cac.gov.cn/2026-06/18/c_1783525613011453.htm

CAC Expert Interpretation: High-Quality Conduct of Network Data Security Risk Assessment to Promote Long-Term Development of Network Data Security Governance , 2026-06-18. URL: https://www.cac.gov.cn/2026-06/18/c_1783525612886783.htm

National Data Administration: Implementation Plan for Promoting High-Quality Industry Dataset Construction , 2026-06-03. URL: https://www.nda.gov.cn/sjj/zwgk/tzgg/0608/20260608172117399715004_pc.html