Data lineage for compliance: NIS2 asset management starts with data

Data lineage for compliance is the part of NIS2 asset management that a hardware inventory leaves out. Lineage is the record of where data comes from and which systems it passes through. The NIS2 Directive lists asset management among its minimum measures. The Polish National Cybersecurity System Act (KSC), which implements NIS2 in Poland, makes it part of the ISMS that most essential and important entities must run from 3 April 2027.

A list of servers and laptops does not tell an auditor which data you hold, who owns it and where it flows. A data catalog, named data owners and lineage do. Our data governance and metadata service builds that layer.

What does NIS2 require for asset management?

Article 21(2)(i) of the NIS2 Directive names "human resources security, access control policies and asset management" as one of the minimum measures. In Poland, the amended KSC Act (Journal of Laws 2026, item 252) lists asset management as an ISMS measure in Art. 8(1)(2)(m), next to access control policies in letter (n).

Neither text says what the inventory must contain. The most detailed EU wording is section 12 of the annex to Implementing Regulation (EU) 2024/2690. It applies directly to cloud and data center providers, MSPs, MSSPs and some other digital service providers. For everyone else it is a useful benchmark:

• Classification (12.1): classification levels for all assets, including information, based on confidentiality, integrity, authenticity and availability.
• Inventory (12.4.1): a complete, accurate, up-to-date and consistent inventory, with changes to its entries recorded in a traceable manner.
• Content (12.4.2): the list of operations and services, and the network and information systems and other assets that support them.
• Review (12.4.3): regular review and update of the inventory, with a documented history of changes.

Section 12 does not use the word "owner" and sets no fixed review interval. Owners follow from how an ISMS works: someone has to decide the classification and approve access. The KSC Act adds the technical documentation of the information system (Art. 10(3)(4)) and records proving that the required steps were carried out (Art. 10(4)).

Why is a list of servers not an asset inventory?

Because classification is about information, not hardware. A CMDB entry says that a database server runs PostgreSQL in a given data center. It does not say that one schema holds customer contact data, another holds invoices and a third is an unmasked copy of production for testing. Without that, you cannot set a confidentiality level for the server.

The same goes for availability. Point 12.1.2(c) of the regulation asks you to align the availability requirements of assets with the recovery objectives in your business continuity and disaster recovery plans. A recovery time objective is set per service and per data set, not per rack.

An inventory filled in at a workshop is also out of date within weeks. New tables, SaaS exports and reports appear all the time. A catalog that reads metadata from the platform stays current with little effort. A spreadsheet maintained by hand does not, and "up-to-date" is the requirement it fails first.

What goes into a data catalog for NIS2?

Keep it small: one entry per data set that supports a service in scope, with fields the auditor can check against the platform. A workable minimum:

A yes/no field for personal data helps with the GDPR record of processing activities as well. Keep the two documents separate, though: they have different owners, and in Poland they answer to different authorities (the data protection authority UODO and the competent cybersecurity authority under the KSC Act).

Who is the data owner, and who is the technical owner?

The data owner is a business role: the person who decides how sensitive a data set is, who may read it and how long it is kept. The technical owner keeps it running. When the two roles are merged, IT ends up classifying sales or HR data it does not use and cannot judge.

Tools record ownership in the technical sense. In Databricks Unity Catalog every securable object has an owner who holds all privileges on it, including the right to grant privileges to others. Make that owner a group, such as the platform team, rather than a person who may leave. Record the business owner separately, for example as a tag.

In dbt, every group of models has an owner with a name or email, and exposures (dashboards, applications) need an owner too. Free-form meta keys, such as a business owner or a classification, end up in the generated documentation. That gives you ownership in the same repository as the code.

How do you show data lineage for compliance?

Lineage answers two audit questions: where does this data come from, and what is affected if this source is compromised or unavailable. Both feed the risk assessment that the KSC Act requires in Art. 8(1)(1). The tooling depends on your platform:

• Databricks: Unity Catalog captures lineage automatically for queries run on Databricks, down to column level, for tables registered in Unity Catalog. Catalog Explorer keeps it indefinitely, while the system tables system.access.table_lineage and system.access.column_lineage keep a rolling 1-year window.
• dbt: the project graph is lineage between sources, models and exposures. Keep the generated documentation for each release, so you can show what the flow looked like on a given date.
• Other tools: OpenLineage, a project of the LF AI & Data Foundation, is an open standard for collecting lineage metadata from running jobs.
• No data platform: one YAML or CSV file per service in a Git repository, with sources and targets written by hand. Git history is the traceable record of changes that point 12.4.1 asks for.

Mind the retention. Art. 10(7) of the KSC Act requires security documentation to be kept for at least 2 years after it is withdrawn from use. If lineage is part of your evidence, export dated snapshots instead of relying on a 1-year window in a system table.

What does an auditor sample in asset management?

An auditor does not read the whole inventory. Prepare for a walk-through like this one:

1. Pick a service from the list of services and ask for the assets that support it.
2. Pick one data set and ask for its business owner, classification and date of the last review.
3. Compare who has access with the access control policy (Art. 8(1)(2)(n) of the KSC Act) and with the classification.
4. Ask for the change history: when the entry was created, who changed the classification and why.
5. The auditor looks for a table in the platform that is missing from the inventory. One such gap puts "complete and accurate" in doubt for the whole list.

Essential entities that were in scope on 3 April 2026 and were not operators of essential services must complete their first formal KSC audit (Art. 15) by 3 April 2028; other essential entities have 24 months from meeting the criteria (Ministry of Digital Affairs, as of 13 October 2026). We do not perform the formal KSC audit. Our pre-audit review runs this sample before the auditor does.

An asset inventory plan for the weeks before 3 April 2027

As of 13 October 2026, you have just under 25 weeks left. A schedule that leaves time for a test run:

1. Weeks 1-2: list the services in scope and name a business owner for each.
2. Weeks 3-6: pull metadata from the platforms (Unity Catalog, dbt, database catalogs) into one catalog and add the fields from the table above.
3. Weeks 7-10: owners classify their data sets; IT records the lineage of each service.
4. Weeks 11-14: compare access rights with the classification and close the gaps.
5. Weeks 15-20: write the asset management policy and the review procedure, with the next review date in the calendar.
6. Weeks 21-24: run a sample the way an auditor would and fix what it finds.

This fits into the wider NIS2 implementation plan for Poland. Access rights are covered in IAM as the foundation of organizational security, and the basics of ownership in data governance as an introduction to AI. If you already run an ISMS under ISO/IEC 27001, its Annex A has controls for asset inventory and classification you can reuse; see what ISO/IEC 27001 is.

If your company or its Polish subsidiary is in scope, see our NIS2 compliance in Poland page or contact us.