Sophie · A mobility-consortium procurement audit-ready by design
The Head of Digital Infrastructure at a European mobility-sector consortium has eighteen months to launch a multi-participant road-safety dataspace that has been publicly committed to a European Commission working group. Burned once by a proprietary connector provider, she runs a procurement that puts source auditability, EU-sovereign infrastructure, and a defensible governance posture above everything else.
Scenario
Sophie is Head of Digital Infrastructure at a European mobility sector consortium. The consortium’s board has formally committed to launching a shared dataspace for road safety data exchange, the Data for Road Safety initiative, with twelve founding participants including national road authorities, fleet operators, and three major OEMs. The commitment was made to a European Commission working group, which means the timeline is public and the reputational stakes if it slips are significant. Sophie has eighteen months to go from board commitment to an operational dataspace with founding participants actively exchanging data.
She has managed infrastructure providers before, but she has never procured a dataspace platform. Her previous managed connector service, operated by a third party, was proprietary, and when that provider changed their pricing model after a funding round, she had no leverage and no exit path. She has been explicit with her team that the next procurement will require source auditability as a hard requirement. She also needs the platform to handle a level of participant diversity that her previous provider could not: some founding participants are large public institutions who will go through a six-month vendor security assessment, and others are mid-size fleet operators who need to be onboarded and operational within weeks.
Storyline
Step 1: Translating the board commitment into an infrastructure requirement
Action
Sophie takes the board resolution and the European Commission commitment document and writes an infrastructure requirements specification. She maps the twelve founding participants to their likely onboarding timelines, public institutions at six months, commercial participants at six to eight weeks, and identifies the governance configuration she will need: a formal dataspace profile, an identity model based on the IDSA trust framework, credential issuance for participant onboarding, and a policy layer that enforces the data access rules the working group agreed during the initiative design phase. She adds three non-negotiable procurement criteria based on her previous experience: ISO 27001 certification, source auditability of the operational layer, and EU-sovereign infrastructure.
Thoughts
“The board committed to this publicly. If we miss the timeline or a participant has a data incident in the first six months, I am the person explaining it at the next working group meeting. The procurement criteria are not preferences, they are the conditions under which I can defend this decision under scrutiny.”
Emotions
Determined and clear-eyed. Sophie has been in this role long enough to know that the requirements she writes now are the ones she will be held to when something goes wrong later. She is not writing for the procurement process; she is writing for the post-incident review.
Step 2: Market evaluation
Action
Sophie issues a request for information to four managed connector providers she has identified through the IDSA ecosystem and a recommendation from the European Commission’s dataspace support centre. She reviews the responses against her three non-negotiable criteria. Two providers are immediately eliminated: one cannot provide ISO 27001 certification, the other runs on AWS us-east-1 and has no EU infrastructure commitment. The remaining two, one of which is Kaphera, both clear the baseline criteria. She requests a technical briefing from each.
Thoughts
“The AWS us-east-1 answer was delivered with complete confidence, which tells me they have never had this conversation with a public institution before. That is not a provider I can bring to a consortium board.”
Emotions
Methodical and slightly weary. This is not the first time Sophie has run a procurement where half the field eliminates themselves in the first round. She is not surprised. She is focused on the two remaining options.
Step 3: Technical briefing and source auditability assessment
Action
Sophie’s technical lead joins a two-hour briefing with the Kaphera team. Kaphera walks through the platform architecture, the licensing model, Apache 2.0 for the EDC operator, source-available for the platform layer, and the production track record, including the MDS deployment with over 150 active connectors. Sophie asks directly whether she can share the platform source with her consortium’s security assessor for independent review. The answer is yes, without qualification. She asks what happens to her dataspace if Kaphera is acquired. The steward-ownership structure is explained. She asks for the governance documentation in writing. After the briefing, she asks her technical lead for an independent assessment of the operator architecture.
Thoughts
“The source-available answer is the first time a provider has said yes to that question without hesitation or qualification. The steward-ownership documentation will need to go to our legal team, but the structure is credible. The MDS production track record is the reference I needed, I am not going to be their first governance authority.”
Emotions
Cautiously confident for the first time in this process. Sophie has been in enough vendor briefings to distinguish between a polished sales presentation and a team that actually understands what they are operating. The Kaphera briefing reads as the latter. She is not ready to commit, but the direction is clear.
Step 4: Formal vendor security assessment
Action
Sophie initiates the consortium’s formal vendor security assessment process, which involves sharing Kaphera’s ISO 27001 certification, the platform architecture documentation, and a portion of the source code with an independent security assessor. The assessment takes eleven weeks. During that period Sophie maintains a parallel evaluation of the second provider, which she does not close until the assessment result is in hand. The assessment returns two findings, both minor, both addressed by Kaphera in writing within two weeks. Sophie presents the assessment result and Kaphera’s responses to the consortium’s security committee. The committee approves the procurement.
Thoughts
“Eleven weeks is eleven weeks I cannot get back. But the assessment gave the security committee something concrete to approve rather than a vendor’s assurances. That is the difference between a decision I can defend and one I cannot.”
Emotions
Patient and procedurally disciplined. Sophie has run this process before and knows that the assessment timeline is the one thing she cannot compress. She uses the period to prepare the dataspace profile configuration and the participant onboarding documentation so that she is not starting from zero when the approval comes through.
Step 5: Dataspace profile registration and identity model configuration
Action
Sophie and her technical lead sit with the Kaphera onboarding team for three sessions over two weeks. In the first session they register the Data for Road Safety dataspace profile, define the IDSA-aligned identity model, and configure the trust anchors the profile will recognise. In the second session they define the onboarding validation steps, the credential types participating organisations must hold, the verification checks the platform will run, and the manual review gate Sophie’s team retains for public institution participants. In the third session they configure the policy layer: a purpose-limitation constraint on road safety data, an audit log requirement for every data access, and a data retention policy that aligns with the working group’s agreed terms. Sophie reviews the final configuration in the web console and signs it off. Her technical lead commits it to a version-controlled repository.
Thoughts
“The manual review gate for public institution participants was the configuration I was most uncertain about, I needed to be able to hold the onboarding process at a point where my team reviews the participant’s documentation before their connector is activated. The platform supports it. That is a requirement I was not sure any managed service would handle without a custom implementation.”
Emotions
Relieved and increasingly invested. The configuration sessions have given Sophie a detailed working knowledge of how the platform operates, which is the condition she needs to be in before she takes it to the first participant onboarding. She is not going to explain this to a consortium member by reading from a vendor’s documentation.
Step 6: Coordinating participant onboarding across a diverse base
Action
Sophie manages the onboarding of the twelve founding participants in three cohorts based on their readiness timeline. The three OEM participants, technically capable, familiar with EDC from Catena-X, onboard themselves through the console and CLI with minimal support, completing the process in under a week each. Four mid-size commercial participants, fleet operators and a logistics provider, onboard through the console with one guided session each, supported by a one-page onboarding guide Sophie’s team prepared in advance. The five public institution participants go through the manual review gate: their onboarding is initiated by Sophie’s team on their behalf, their documentation is reviewed, and their connector is activated once the review is complete. The slowest public institution takes nine weeks from initiation to activation, primarily due to their own internal approval process rather than the platform.
Thoughts
“The nine weeks for the last public institution is not a platform problem, it is a procurement problem on their side. The platform held the onboarding in the correct state and sent the right status updates throughout. What I need now is a way to show each participant their own onboarding status without them emailing me to ask where they are in the process.”
Emotions
Operationally stretched but in control. Managing twelve onboarding processes simultaneously across three cohorts is the most demanding period of the project. The platform’s status tracking reduces the coordination overhead, but Sophie is still the human escalation point for every participant who cannot find the answer in the documentation.
Step 7: First live data exchange and steering group demonstration
Action
Sophie coordinates the first live data exchange between two OEM participants, a road hazard notification dataset exchanged under the purpose-limitation constraint configured in Step 5. She runs through the exchange in a steering group session, using the web console to show the contract negotiation, the policy enforcement, and the audit log entry that records the access. One steering group member, a representative of a national road authority, asks whether the audit log can be exported in a format their own compliance system can ingest. Sophie notes it as a follow-up requirement and logs it with Kaphera’s team. The steering group approves the transition from pilot to operational phase.
Thoughts
“The audit log export question will come up from every public institution participant eventually. I need a concrete answer before the next steering group session, not a roadmap commitment.”
Emotions
Satisfied and alert. The live exchange worked. The policy enforcement held. The audit log showed exactly what the steering group needed to see. The export question is a real requirement that she should have anticipated, she logs it honestly rather than deferring it.
Step 8: Steady-state governance and participant management
Action
Sophie’s team operates the dataspace on a week-to-week basis through the Kaphera web console. They monitor participant connector status, review the audit log for policy compliance, and handle credential renewal notifications as they arise. When the IDSA trust framework releases an updated specification that affects the credential type requirements, Kaphera’s team notifies Sophie two weeks in advance and handles the platform-side update without requiring her team to take any action. Sophie communicates the change to participants and manages the three who need to reissue their credentials through her team’s review gate.
Thoughts
“The two-week advance notice on the specification change is what I needed to communicate to participants in time. If that notification had come the day of the update, I would have had twelve angry participants and no lead time to manage them.”
Emotions
Operationally settled. The steady-state governance rhythm is manageable. The platform handles the infrastructure layer; Sophie’s team handles the participant relationships and the governance decisions. The division of responsibility is working as designed.
Step 9: External audit and compliance reporting
Action
A European Commission auditor requests access to the dataspace’s governance documentation and audit logs as part of a routine review of the Data for Road Safety initiative. Sophie exports the relevant audit log sections from the Kaphera console and prepares a governance report covering the dataspace profile configuration, the identity model, the policy constraints in place, and the onboarding validation steps applied to each participant. The auditor asks whether the platform’s operational layer can be independently inspected. Sophie provides the source-available repository link and the platform architecture documentation. The audit concludes without findings.
Thoughts
“The source-available answer to the auditor’s question is the one I could not have given with my previous provider. That single moment, being able to point to the code rather than asking the auditor to trust a vendor’s assurances, is worth every week of the procurement process.”
Emotions
Quietly vindicated. The procurement criteria she set at the beginning of the process, source auditability, EU infrastructure, ISO 27001, each paid off at a different point in the project. The audit is the moment the source auditability criterion justified itself most clearly.
Step 10: Expanding the dataspace to new participants and use cases
Action
Following the European Commission audit, three additional national road authorities request to join the dataspace. Sophie manages their onboarding through the existing manual review gate, applying the same validation process as the founding public institution participants. The consortium’s working group also agrees to add a second use case, near-real-time weather condition sharing, which requires a new policy set and a modification to the existing negotiation flow. Sophie configures the new policy set in the console and coordinates with Kaphera’s team on the negotiation flow modification. The three new participants are active and the new use case is live within six weeks of the working group decision.
Thoughts
“Six weeks from working group decision to live use case, including three new participant onboardings. That is the number I will use in the next board report. A year ago I would not have been able to give a number at all.”
Emotions
Confident and genuinely proud. The dataspace is operating at a level of reliability and responsiveness that Sophie did not expect when she started the procurement. The six-week expansion timeline is the proof point she needed to make the case for the next phase of the initiative.
Key features
🏛 Formal governance configuration interface: dataspace profile registration, identity model definition, trust anchor configuration, and onboarding validation steps accessible through a structured console and version-controllable via CLI
🔒 Manual review gate for participant onboarding: ability to hold the onboarding process at a defined checkpoint where the governance authority’s team reviews participant documentation before connector activation
📋 Use-case policy authoring with audit enforcement: purpose-limitation constraints, data retention policies, and audit log requirements configurable per use case and enforced at the contract negotiation layer
📊 Participant onboarding status tracking: real-time visibility into where each participant is in the onboarding process, reducing inbound status requests from participants to the governance team
🔍 Source-available platform layer: platform source readable and shareable with independent security assessors, enabling procurement processes that require code-level auditability
📁 Audit log export: compliance-ready export of access logs in formats that external auditors and participant compliance systems can ingest independently
🔔 Advance notification of upstream specification changes: two-week minimum notice of IDSA or dataspace specification changes affecting credential types or trust anchors, with platform-side updates handled without governance team intervention
🌍 EU-sovereign infrastructure with verifiable governance structure: deployment on European cloud providers with a steward-ownership model that satisfies public institution procurement requirements around long-term provider independence
Related
- sophie-renard: the protagonist: Head of Digital Infrastructure at a European mobility consortium standing up the Data for Road Safety initiative
- governance-authority: the archetype: organisations defining and operating dataspace rules across diverse participant bases
- kaphera-cloud-managed-console: the governance console she uses to register the dataspace profile, define policies, and review participant onboarding
- kaphera-cloud-managed-server: the managed platform underneath her dataspace, including the manual-review gate for public-institution participants
- governance-authority-playbook: sales motion for the governance-authority archetype