Supply Chain Obligations Need a Data Architecture

Supply chain compliance rarely fails due to a lack of willingness. It fails because companies do not manage their suppliers, locations, and proofs as a coherent database.

The legal framework shifts priorities, not data tasks

The European supply chain directive CSDDD was significantly simplified in 2026. According to the current version, it initially applies to companies with more than 5,000 employees and a net turnover of more than 1.5 billion Euro. The application begins on July 26, 2029, and member states must implement the requirements by July 2028. This temporarily eases pressure on many programs. However, it does not solve a single data problem.

In Germany, the Supply Chain Act continues to apply until the European regulation is transposed into national law. The reporting obligation was politically scaled back, and the BAFA currently does not accept reports through its portal. Nevertheless, risk analyses, prevention, remediation, complaint mechanisms, and documentation remain the core of due diligence obligations. Those who turn this into a mere reporting project are building a short-term response to a long-term control problem.

For many medium-sized suppliers, pressure also arises not from the immediate legal scope of application. Large customers demand origin information, risk disclosures, certificates, and robust evidence along their own supply chain. This makes the ability to provide data quickly and consistently a business condition.

Those who turn this into a mere reporting project are building a short-term response to a long-term control problem.

The Gap Lies Between the Creditor Master and the Supply Chain

An ERP system knows the creditor. It knows invoices, payment terms, and often the legal entity. For due diligence, that’s not enough. Relevant information also includes production sites, group structures, goods flows, materials used, subcontractors, risk areas, and the validity of proofs. This information often resides in purchasing, quality management, compliance, sustainability, and external portals. It follows different identifiers and update cycles.

The first architectural decision is therefore: What is the canonical identity of a supplier? A supplier number alone rarely fulfills this role. A data model must separately map legal entity, economic group, location, and supply relationship. A group can produce in several countries. A location can supply various customer companies. If these levels are mixed, risks cannot be precisely assigned or traceably assessed.

CIOs should not create another shadow master alongside the ERP for this purpose. A leading supplier object with a stable identifier and clear relationships to ERP, procurement, product data, and risk sources makes sense. The data does not have to physically reside in one system. What’s crucial is that each application references the same entity and adopts changes traceably.

Traceability Begins with Relationships Between Data

The demand for transparency down to deeper supply chain levels can lead to an unrealistic goal: mapping every single upstream stage in its entirety. Neither CSDDD nor LkSG require a complete world map of all business relationships. The standard is risk-based due diligence. The architecture must therefore be able to show which data is available, which assumptions apply, and why a company conducts in-depth checks at a particular point.

For this, a relationship model is needed instead of a supplier list. A component refers to material groups. Material groups point to regions of origin or production sites. Sites are related to suppliers and risk assessments. Additionally, time references are added: A certificate was valid at the time of release but may have expired today. Without an effective date and versioning, an audit results in a collection of plausible files, but not a provable decision chain.

Especially with indirect suppliers, the IT system should distinguish between confirmed facts, supplier self-assessments, external hints, and derived risk assessments. The origin of the information belongs in the data model. It determines whether a traffic light is treated as a reliable indicator or just a claim.

Proof requires an unalterable audit trail

Compliance teams don’t just ask which risk was known. They need to demonstrate who assessed it when, what action was decided on, and whether its impact was tested. This chain cannot be reliably reconstructed from emails, presentations, and files on team drives. It requires a digital process with a clear reference to supplier, risk, decision, responsible parties, and evidence.

A good design separates operational systems from audit logic. The ERP remains responsible for orders and purchase approvals. The procurement system controls tenders and contracts. A compliance or data platform brings together risk events, audits, measures, and evidence. Interfaces only transfer the attributes that are needed. This reduces copy errors and prevents sensitive information from ending up uncontrolled in purchase lists or analysis tools.

Automation pays off primarily for recurring checks: expiring proofs, missing mandatory fields, changes to company data, new country or product group risks, and overdue measures. It doesn’t replace evaluation. It ensures that departments use their time on cases with real relevance. Each automatic rule needs an owner, a data source, and a documented procedure for false alarms.

Many Projects Fail Due to Incorrect Ownership

The widespread misconception is that compliance defines the requirements and IT delivers a tool. In reality, the operating model determines data quality. Procurement is responsible for many source data, departments know products and supply relationships, sustainability evaluates content, legal defines the framework, and IT is responsible for integration, access, and traceability. If this division is missing, mandatory fields are introduced but not maintained.

Another mistake is trying to clean all data before the start. Master data quality rarely improves through a one-time large project. Prioritization by risk and procurement volume is better. For the most critical supply relationships, binding identities, data owners, and quality rules apply first. The patterns gained can then be transferred to other groups.

The next 90 days should therefore deliver three results: a binding data model for supplier, location, relationship, and proof, a map of leading systems, and a pilot for a risk-relevant product group. The pilot shows early on which information is realistically available from suppliers and where contract clauses or processes need to be adjusted.

From Compliance Data to an Operational Early Warning System

The data foundation can fulfill more than just regulatory obligations. When supplier relationships, locations, material groups, and proofs are consistently linked, dependencies are identified earlier. A production outage, a regional risk, or an expiring certificate is then assigned to a specific procurement, product line, and area of responsibility. This improves communication between purchasing, production, and risk management.

However, the operational benefit only arises if the architecture is integrated into decision-making processes. A risk assessment that disappears into a separate portal after contract signing protects neither delivery capability nor reputation. A risk signal must reach procurement approvals, supplier development, and escalations. Data architecture thus becomes the connecting element between compliance and control.

The regulatory simplification in 2026 is therefore no reason to postpone the task. It creates time for a better implementation. CIOs should use it to turn scattered documents into a verifiable data chain. Those who only start working on it when faced with a customer inquiry or an audit pay the price of missing architecture under time pressure.

Frequently Asked Questions

Image source: AI-generated (July 2026)

More from the MBF Media Network