Thomas · Procurement scaffolding that pays back on the second mandate
The Head of IT at a tier-1 automotive supplier is hit with a Catena-X mandate covering two legal entities and runs a six-week vendor evaluation against ISO 27001, TISAX-aligned, dedicated-tenancy criteria. The procurement scaffolding he builds the first time turns the second mandate, four months later, into a half-day task.
Scenario
Thomas is Head of IT at a tier-1 automotive supplier in Stuttgart with 1,200 employees and two separate legal entities, the manufacturing operation and a logistics subsidiary. His company supplies transmission components to three OEMs. On a Friday afternoon he receives a formal letter from one of his largest OEM customers requiring Catena-X participation for both legal entities by a date five months away. The letter specifies that the company must be able to exchange Digital Product Passport data and carbon footprint traceability information in the required format. Non-compliant suppliers will be placed under review at the next sourcing cycle.
Thomas has a team of twelve covering helpdesk, enterprise systems, and network infrastructure. They are competent at what the business has historically required, keeping SAP operational, managing Active Directory, handling EDI integrations, but they have no experience with Kubernetes, connector infrastructure, or dataspace protocols. Thomas assessed this himself when the mandate arrived: he read the EDC documentation for two hours on Saturday morning and concluded that building and operating this internally would take his two best engineers six months and leave the company with a connector environment nobody on the team fully understood. He is not going to do that.
He has also received an informal signal from a second OEM customer that a similar mandate is likely within the year. The solution he procures now needs to handle two legal entities today and scale to a second dataspace participation without a new procurement cycle.
Storyline
Step 1: Translating the mandate into a procurement requirement
Action
Thomas reads the OEM’s letter and the attached technical specification. He maps the requirements against his team’s capabilities and writes a one-page internal assessment for his CEO: the mandate requires infrastructure his team cannot build or operate reliably, the timeline rules out an internal build, and the appropriate response is a managed service with a formal SLA and compliance certification that the company’s security team can review. He recommends a procurement process with a six-week evaluation window. His CEO reads the assessment and replies with one instruction: make sure it passes the security review.
Thoughts
“The CEO’s instruction is not unreasonable, it is the right instruction. If I bring in a managed service that fails the security review six months from now, that is a worse outcome than a delayed procurement. I need to run the security assessment in parallel with the commercial evaluation, not after it.”
Emotions
Methodical and clear on his constraints. Thomas has managed enough IT procurement to know that the security review is the timeline risk, not the vendor selection. He structures the process accordingly.
Step 2: Defining procurement criteria
Action
Thomas writes a procurement brief covering five criteria: ISO 27001 certification as a minimum compliance baseline, TISAX awareness as a forward-looking requirement given the automotive sector context, dedicated resource isolation with no shared tenancy between his company’s two legal entities or with other customers, a formal SLA with defined uptime commitments and escalation paths, and EU-sovereign infrastructure. He adds a sixth criterion after a conversation with his security lead: the vendor must be able to provide architecture documentation detailed enough for an independent security assessment. He sends the brief to four vendors identified through an IDSA ecosystem directory and a recommendation from a peer Head of IT at another tier-1 supplier.
Thoughts
“Six criteria, four vendors. I expect at least two to fail on the first pass. The TISAX requirement will eliminate anyone who has not thought seriously about automotive sector compliance, and the dedicated tenancy requirement will eliminate anyone whose business model depends on shared infrastructure economics.”
Emotions
Efficient and experienced. Thomas has run vendor evaluations before and knows which criteria do the filtering work quickly. He is not expecting to evaluate four vendors in depth.
Step 3: Shortlisting and initial briefings
Action
Thomas reviews the four vendor responses. One vendor cannot provide ISO 27001 certification and is eliminated. One runs on shared infrastructure only and cannot accommodate the dedicated tenancy requirement. Two vendors, including Kaphera, clear all six criteria. Thomas schedules one-hour briefings with both. In Kaphera’s briefing, he asks three questions he does not put in writing: what happens operationally if a Kaphera engineer makes a mistake that affects his production connector, who is the named escalation contact for enterprise issues, and what the realistic timeline is for a full security architecture review. He receives direct answers to all three. He schedules the security architecture session for the following week.
Thoughts
“The three questions I didn’t put in writing are the ones that tell me whether the people running this actually understand production operations or whether they’ve only ever managed the happy path. Direct answers without deflection is the right signal.”
Emotions
Evaluating the team as much as the product. Thomas is not buying software; he is entering an operational relationship. The quality of the answers to his off-script questions matters as much as the formal procurement criteria.
Step 4: Security architecture review
Action
Thomas’s security lead joins a two-hour technical session with Kaphera’s engineering team. They walk through the platform architecture, the network isolation model between tenants, the secrets management approach, the certificate lifecycle, and the incident response process. Thomas’s security lead asks for the source code of the platform layer, confirming it is source-available and can be shared with the company’s security assessor. He asks specifically how tenant isolation is enforced and what the blast radius of a misconfiguration affecting one tenant is on other tenants. He receives a detailed architectural answer and a commitment to provide a written response within forty-eight hours. Thomas’s security lead leaves the session satisfied. He tells Thomas it is the most substantive vendor architecture session he has attended.
Thoughts
“My security lead saying it was the most substantive session he’s attended is the strongest signal I’ve had in this evaluation. He is not easily impressed and he does not say things like that to be polite.”
Emotions
Increasingly confident. The security architecture session has resolved the main risk Thomas was carrying. The remaining steps are commercial negotiation and configuration, problems he knows how to manage.
Step 5: Commercial negotiation: SLA, pricing, and dual-entity structure
Action
Thomas negotiates the commercial terms covering three areas. First, the SLA: he needs a minimum uptime commitment with defined response times for critical issues and a named escalation contact, not a generic support queue. Second, the pricing: the dedicated tier pricing needs to be structured as a fixed monthly cost per legal entity so he can present it as a predictable operational line item in the IT budget, not a variable consumption model. Third, the dual-entity structure: he needs both legal entities, the manufacturing operation and the logistics subsidiary, to have separate connector identities within the same dedicated deployment, with independent access controls and independent audit logs. All three are agreed within two negotiation rounds. Thomas countersigns the agreement and sends the signed copy to his CEO with a note that the security review will follow standard process timelines.
Thoughts
“The dual-entity structure question is the one I was most uncertain about commercially, I was not sure whether it would be treated as two separate deployments at double the cost or as a configuration within one. The answer, one dedicated deployment, two legal entity contexts, one monthly cost, is the right commercial model for our situation.”
Emotions
Relieved and ready to move. The commercial negotiation was straightforward compared to the security evaluation. Thomas is now in implementation mode.
Step 6: Security review and sign-off
Action
Thomas submits the Kaphera platform architecture documentation, ISO 27001 certification, and the written tenant isolation response to his company’s internal security review process. The review takes eight weeks, standard for the company’s third-party infrastructure assessments. Two findings are returned: one requesting clarification on the certificate rotation policy, one requesting additional documentation on the data residency confirmation for the EU infrastructure commitment. Thomas raises both with Kaphera. Both are addressed in writing within one week. The security review is closed. His security lead signs off. Thomas informs his CEO.
Thoughts
“Eight weeks is eight weeks I cannot compress. But both findings were addressed quickly and cleanly, which means the security team’s concerns were legitimate questions rather than fundamental objections. That is the difference between a slow process and a blocked one.”
Emotions
Patient and measured. Thomas managed his CEO’s expectations around the eight-week window at the start of the process. The clean resolution of both findings means he arrives at sign-off with the credibility intact.
Step 7: Technical onboarding: dual legal entity configuration
Action
Thomas’s senior engineer joins the Kaphera onboarding process. Together with the Kaphera onboarding team they provision the dedicated deployment, configure two separate legal entity contexts, the manufacturing operation and the logistics subsidiary, with independent access controls and audit logs, and initiate the Tractus-X dataspace onboarding for both. The onboarding flow for each entity follows the same steps as a standard participant onboarding but with the dedicated deployment’s isolated resources underneath. Thomas’s engineer documents the configuration in the company’s IT runbook. Thomas reviews the web console to confirm the dual-entity structure is correctly reflected and that both entities appear as independent participants in the dataspace profile.
Thoughts
“The runbook documentation is the step my engineer will thank me for in six months when he’s on holiday and someone calls about the connector. If it’s not documented, it doesn’t exist.”
Emotions
Thorough and operationally minded. Thomas is already thinking about the handoff to steady-state operations. The onboarding is the event; the runbook is the asset.
Step 8: Validation with the OEM customer’s procurement team
Action
Thomas initiates a test data exchange with the OEM customer’s technical team, a Digital Product Passport dataset for a component family in scope for the mandate. The exchange completes successfully. The OEM’s procurement system registers the company as a compliant Catena-X participant. Thomas receives a formal confirmation from the OEM’s supplier management team. He forwards the confirmation to his CEO with the original mandate letter and a note: requirement met, both legal entities active, three months before the deadline. His CEO forwards it to the board.
Thoughts
“Three months ahead of the deadline. The security review timeline was the risk I managed. Everything after the security sign-off ran faster than I planned for.”
Emotions
Satisfied and professionally settled. The board confirmation is the outcome Thomas needed. The three months of margin before the deadline is not a detail, it is the evidence that his assessment at Step 1 was correct and his process was sound.
Step 9: Steady-state operations and the second OEM signal becomes a mandate
Action
Four months after the first connector goes live, the second OEM customer issues a formal MDS participation mandate. Thomas logs into the Kaphera Cloud console, navigates to the MDS dataspace profile, and initiates onboarding for both legal entities. The process is identical to the Tractus-X onboarding his engineer documented in the runbook. His engineer handles the initiation without Thomas’s direct involvement. The MDS onboarding completes in standard timelines. Thomas sends a note to the second OEM’s procurement contact confirming participation is in process. He does not initiate a new procurement cycle. He does not run a new security review. He sends an email to his Kaphera account contact to inform them of the expanded scope.
Thoughts
“The second mandate took my engineer half a day to initiate. The first one took five months of procurement, security review, and negotiation. The difference is that the first one built the foundation the second one runs on.”
Emotions
Operationally confident. The second mandate is not a new problem. It is an expansion of a solved one. Thomas is aware that this is exactly the outcome he was designing for when he asked about the dual-entity structure and the SLA terms in the original negotiation.
Step 10: Thomas becomes a peer reference
Action
At a regional automotive IT directors forum, Thomas is asked by two peers, both facing similar Catena-X mandates from the same OEM customer, how his company handled the implementation. He describes the process: the procurement criteria, the security review timeline, the dual-entity structure, and the dedicated tier choice. He does not recommend Kaphera by name in the group session, but both peers contact him privately afterwards. He sends both of them his procurement brief and his security review summary, with the vendor name included. One of them proceeds with Kaphera within three months.
Thoughts
“The procurement brief I wrote at the start of this process has now been used by two other IT directors. That document is doing more work than I expected when I wrote it.”
Emotions
Quietly useful. Thomas is not an enthusiast or an advocate in any public sense. He is a Head of IT who solved a problem correctly and will share how he did it with peers who ask. That is the referral his network responds to.
Key features
🏢 Dedicated deployment with multi-entity organisational model: single dedicated infrastructure instance supporting multiple legal entities with independent connector identities, access controls, and audit logs under one commercial arrangement
📋 ISO 27001 and TISAX-aligned compliance documentation: certification and architecture documentation structured for submission to third-party security assessors, including written responses to standard tenant isolation and data residency questions
🔒 Source-available platform layer for independent security review: platform source shareable with the customer’s internal security assessor or an independent auditor without requiring NDA negotiation or vendor mediation
📞 Named escalation contact with defined SLA response times: enterprise support model with a specific person accountable for critical issue escalation, not a tiered support queue
💶 Fixed monthly pricing per legal entity: predictable cost structure presentable as an operational line item in an IT budget without consumption-based variability
🌍 EU-sovereign infrastructure with written data residency confirmation: documented commitment to European cloud providers with written data residency confirmation suitable for internal security review submission
🔄 Consistent onboarding flow across dataspace profiles: second and subsequent participations follow the same process as the first, enabling expansion without a new procurement cycle or security review
📖 Configuration runbook support: onboarding process documented in a format the customer’s IT team can follow for ongoing operations and future onboarding, reducing dependency on the vendor for routine tasks
Related
- thomas-brandt: the protagonist: Head of IT at a tier-1 automotive supplier with two legal entities
- participant: the archetype: dataspace participants procuring a managed connector under formal IT-procurement and security review
- kaphera-cloud-managed-server: the dedicated-tier managed server his procurement converged on
- kaphera-cloud-managed-console: the multi-entity console he uses to monitor both legal entities under one commercial arrangement
- participant-playbook: sales motion for the participant archetype