The platform engineering conversation in Europe has fundamentally shifted. Regulatory frameworks like NIS2, DORA, the Cyber Resilience Act (CRA), and the AI Act are no longer distant concerns - they are active delivery requirements that reshape how organizations build and operate internal developer platforms. For European consultancies, this regulatory pressure is not a headwind; it is a competitive advantage waiting to be captured.
Main insights
- EU regulations are transforming platform engineering conversations from speed-focused to compliance-aware
- Compliance must be structural from day zero, not layered on top of existing platforms
- European consultancies hold a competitive edge through deep experience with diverse organizational contexts and regulatory environments
- A shared platform engineering vocabulary dramatically improves client conversations and accelerates project outcomes
Dries Dams, Managing Partner and Solution Architect at BRYXX and a certified platform engineering professional, brings hands-on experience working with enterprise clients across the Benelux region and the broader European market. His perspective reveals how consultancies are building platform engineering practices that address both technical delivery and regulatory compliance - and winning projects because of it.
You can watch the full discussion here if you missed it.
The regulatory shift: From "how fast" to "how compliant"
Two years ago, most platform engineering conversations centered on deployment velocity. Today, that question has evolved significantly.
"The conversation has shifted from how do we deploy faster to how do we deploy faster while also staying compliant," Dams explains.
The regulatory drivers are concrete and immediate:
- NIS2 came into force in October 2024, creating supply chain security obligations across sectors
- DORA hit the financial sector in January 2025, requiring well-defined Internal Developer Platforms (IDPs) with observability and audit trailing
- CRA (Cyber Resilience Act) addresses vulnerability management and secure development practices
- AI Act phases in through August 2026, adding another layer of compliance requirements for AI-enabled systems
The gap is most acute in mid-sized organizations. "Large enterprises have compliance teams," Dams notes. "Unfortunately, they often don't talk to platform teams too often. But in mid-sized organizations, they often don't have a platform team and they don't have a compliance team, which means they are exposed."
This is precisely where consultancies can deliver outsized value.
Compliance as structure, not a layer
The most important architectural insight from Dams is straightforward: compliance cannot be retrofitted. "Compliance isn't a layer on top or something you add on top. It's structural from day zero," he emphasizes.
In practice, this means every IDP engagement can - and we recommend it does - conclude with a compliance framework as a concrete deliverable. EU regulation is not introducing new engineering ideals; it is making clients understand why those ideals were always worth pursuing.
But there is a critical organizational dimension that many teams miss: "A compliant platform run by non-compliant teams is not actually compliant. Technology alone never solves compliance issues."
This reframes the platform team's mandate. You are not just building infrastructure - you are shaping behavior. That means:
- Training development teams on compliance requirements
- Enforcing policies through golden paths (the paved roads that make the right way the easy way)
- Making compliance the default, not the exception
- Ensuring the easiest path through the platform is also the compliant one
Dams calls this compliance by default: if teams simply use the platform, their workloads are secure and compliant. Making things non-compliant must require deliberate effort.
The three-customer model: Infrastructure, developers, and security
Platform engineering traditionally served two customer groups: infrastructure teams needing building blocks, and developers needing access to those resources. The regulatory environment has introduced a third critical customer: security and compliance teams.
"We now have a third customer and that's security," Dams explains. "How do we make sure that what they value - having those compliance rules in there, having everything secure - we're just helping them get it to infrastructure and development people."
It's no longer sufficient to optimize for developer experience and infrastructure efficiency alone. The platform team must serve as the bridge between all three constituencies, translating security requirements into platform guardrails that developers encounter naturally rather than as friction.
Why European consultancies have a competitive advantage
European consultancies are particularly well-positioned to navigate this landscape for three structural reasons.
Cross-organizational knowledge. Consultancies see how different organizations solve the same problems. "We see a lot of those different perspectives. We see a lot of those different conversations. We have a lot of different ideas of what works and what doesn't," Dams notes. This institutional knowledge is difficult for any single organization to build internally.
Regulatory familiarity. European consultancies have operated within complex regulatory environments for years - GDPR, EUCS, and sector-specific frameworks. The newer regulations are challenging, but not unfamiliar territory.
Contextual diversity. Unlike markets dominated by large tech companies, Europe has a high density of mid-sized organizations with different constraints. "How can you compare yourself to those giants that we have across the pond? We don't have the same budgets. We don't have the same amount of people. Even culture is completely different." This diversity has trained European consultancies to adapt solutions rather than apply one-size-fits-all playbooks.
The power of shared vocabulary
One of the most practical benefits of platform engineering frameworks is the shared vocabulary they provide. Dams describes a clear before-and-after in client conversations.
"Three years ago, we had that same conversation with a customer, but it stayed very vague, very difficult to define. Now you go into that same conversation and you can really pinpoint the pain points."
With platform engineering terminology, consultancies can define what the developer control plane means in practical terms, explain how tools and systems integrate, build concrete roadmaps showing which components to tackle first, and make abstract concepts tangible through diagrams and frameworks.
"This time with that vocabulary, with that framework, with that thing you can point at, with that nice little roadmap - that really made the difference. We're now implementing that platform, where three years ago that would never have worked with that same customer."
Don't start with tooling
A consistent theme in Dams' experience is the danger of leading with tool selection. "Don't start with tooling. That's one of the most common mistakes. Usually management picks a nice developer portal, but that often works wrong."
Instead, we recommend this sequence:
- Start from the value stream - understand what the business actually needs to deliver
- Work on team structure, often using frameworks like Team Topologies
- Define your architecture and platform boundaries
- Only then select tooling that serves those decisions
This process-first approach ensures tools serve the organization's actual needs rather than driving platform design by accident.
The CRA as opportunity, not burden
While many organizations view the CRA as a compliance burden, its requirements map directly onto what platform teams should already own:
- Vulnerability management and awareness
- End-to-end secure development practices
- Incident reporting
- Observability and security monitoring
"Why wouldn't you as a platform team really be owning the vulnerability landscape in your organization?" Dams asks. The same logic applies to incident management. "Most engineers still perceive incident management as a hassle or something that needs to be done. But if you have a good incident management system, no matter which tool, it's golden. It's a knowledge base you build over years."
The CRA does not ask platform teams to do something foreign. It asks them to formalize and demonstrate what good platform engineering already delivers.
If you enjoyed this, find here more great insights and events from our Platform Engineering Community.
If you want to dive deeper, explore our instructor-led Platform Engineering Certified Leader course and connect with peers from large-scale enterprises who are driving cultural transformation.
Key takeaways
- Compliance must be structural from day zero. Retrofitting compliance onto an existing platform is expensive and incomplete. Build governance, auditability, and policy enforcement into your IDP architecture from the start - and make the compliant path the default path for every developer on the platform.
- Platform teams now serve three customers. Infrastructure teams, development teams, and security and compliance teams all have legitimate requirements from your platform. Designing for all three from the outset prevents costly rework and positions the platform team as a strategic partner rather than a bottleneck.
- Shared vocabulary transforms client conversations. Platform engineering frameworks give consultancies and practitioners a concrete language for scoping problems, building roadmaps, and aligning stakeholders. This shared vocabulary is what turns vague DevOps conversations into funded, executable projects.
- Process before tooling, always. Starting with a developer portal or any other tool before defining your value stream and team structure is one of the most common and costly mistakes in platform engineering. Define the problem first, then select the tooling that solves it.
