Platform strategy 2026.

An Evidence-Based Framework for Regulated Enterprises

L1: Executive Summary

Strategic Context: The Divergence of Adoption and Value

The enterprise technology landscape currently faces a paradoxical trajectory regarding cloud-native infrastructure. While Gartner predicts that by 2026, 80% of large software engineering organizations will have established dedicated platform engineering teams, empirical data suggests a looming crisis of efficacy.¹ Contemporary research indicates that up to 70% of these platform initiatives fail to deliver measurable business value, often leading to team disbandment or restructuring within 18 months of inception.¹ For regulated entities operating under the strictures of the European Union’s Cyber Resilience Act (CRA), the Dutch Baseline Informatiebeveiliging Overheid (BIO2), and NIS2, this high failure rate represents not merely a sunk cost but a systemic risk to digital sovereignty and compliance postures.⁴

The divergence between adoption rates and value realization is rarely a consequence of technical incapacity regarding the underlying container technologies—Docker and Kubernetes. Rather, it stems from a fundamental misalignment between technical abstraction levels, organizational structure, and the cognitive capacity of human teams. The “build it and they will come” philosophy, which treats platforms as purely technical projects, is objectively obsolete. This report presents a comprehensive, evidence-based strategy to navigate these risks, leveraging the Team Topologies framework to align technical architecture with organizational design. The central thesis of this research is that a platform must function as a compelling internal product that reduces, rather than amplifies, the cognitive load on stream-aligned teams, thereby enabling the “fast flow” of value required by modern market dynamics.⁶

Top 10 Strategic Findings

The following findings represent a synthesis of empirical data from the DORA 2025 State of AI-Assisted Software Development report, the CNCF Platform Engineering Maturity Model, and peer-reviewed research on software supply chain security.

1. Platform Failure is Organizational, Not Technical: The primary driver of the 70% platform team failure rate is the absence of a “Platform-as-a-Product” mindset. Teams that treat their platform as a mandatory technical substrate rather than a compelling product with active user feedback loops fail to achieve voluntary adoption. Successful implementation requires a shift where platform engineers are not merely ticket-resolvers but product owners who measure success through developer satisfaction and cognitive load reduction.¹
2. Cognitive Load is the Primary Design Constraint: Research by Dr. Laura Weiss and the Team Topologies authors identifies “team cognitive load” as the binding constraint on delivery performance. When platform complexity exceeds a team’s cognitive capacity, delivery performance collapses regardless of the sophistication of the underlying tooling. Successful platforms must be designed explicitly to maintain cognitive load within manageable limits, utilizing the “Thinnest Viable Platform” (TVP) principle to abstract complexity without obscuring necessary context.⁶
3. DORA 2025 Archetypes Redefine Performance: The transition in DORA research from four performance tiers to seven distinct team archetypes—such as “Harmonious High-Achievers” versus “Legacy Bottlenecks”—reveals that AI and platform tooling act as amplifiers of existing organizational traits. Introducing complex container orchestration to a “Legacy Bottleneck” team without antecedent structural change accelerates instability rather than throughput.⁸
4. Kubernetes is Not a Default Strategy: The “Thinnest Viable Platform” principle dictates that Kubernetes should only be adopted when workload complexity warrants the orchestration overhead. Premature adoption correlates with a 49% increase in cloud spend and significant operational friction. For many workloads, simpler abstractions such as Docker Compose for local development or serverless container runtime environments offer superior “Time-to-Value” with drastically lower cognitive overhead.¹⁰
5. Security Must Shift from Gatekeeping to Guardrails: To meet the rigorous requirements of the EU CRA and BIO2 without stifling delivery flow, security controls must be embedded in the platform via admission controllers and policy-as-code (e.g., OPA/Gatekeeper). The traditional “Security Bolt-On” anti-pattern, relying on manual reviews at the end of the lifecycle, is mathematically incapable of scaling to the volume of changes in a microservices architecture.⁴
6. SBOMs Are Mandatory but Immature: While the EU CRA mandates Software Bills of Materials (SBOMs) by late 2026, systematic literature reviews by O’Donoghue et al. (2025) identify 11 critical barriers to their effective use. Significant discrepancies in tooling—where scanners like Trivy and Grype report vastly different vulnerability counts for identical artifacts—mean that strategy must focus on SBOM quality, ingestion, and analysis rather than mere generation.¹⁴
7. FinOps Integration is Non-Negotiable: In shared Kubernetes environments, cost visibility inherently degrades, leading to the “FinOps Neglect” failure mode. Implementing the FOCUS 1.3 specification for unit economics is essential to correlate cloud spend with business value, preventing the scenario where infrastructure bills detach from organizational reality.¹²
8. Observability Requires a “Golden Signals” Standard: Ad hoc monitoring fails at scale. A standardized observability architecture based on Latency, Traffic, Errors, and Saturation (the Golden Signals) is required to enable Site Reliability Engineering (SRE) practices. Without this standardization, error budgets cannot be calculated, and reliability becomes anecdotal rather than empirical.¹⁷
9. The “50/50” Rule for Platform Teams: Successful platform transformations, exemplified by the Adidas case study, allocate approximately 50% of engineering effort to platform feature development and 50% to user enablement (internal marketing, documentation, consulting). Neglecting the enablement vector is a leading indicator of platform stagnation and low adoption.⁷
10. Regulatory Deadlines Define the Roadmap: The EU CRA reporting obligations commence in September 2026, with full applicability following in late 2027. Platform strategy must effectively “work backward” from these dates to ensure that supply chain transparency mechanisms—specifically reproducible builds and artifact signing—are operational well in advance.⁴

Strategic Decision Matrix: Container Abstraction Levels

The following matrix guides the fundamental architectural decision of where to run containerized workloads, challenging the assumption that Kubernetes is the universal answer for all scenarios.

Top 5 Strategic Risks and Mitigation

Investment Case: The “Stop / Start” Framework

Stop Doing:

• Treating the platform as a “project” with a fixed end date and capitalizable budget only.
• Mandating Kubernetes for simple, low-traffic applications where operational overhead outweighs benefits.
• Allowing security teams to act as late-stage gatekeepers utilizing manual reviews.
• Measuring success solely by “uptime,” “number of features shipped,” or “cost reduction.”

Start Doing:

• Funding the platform as a long-term product with a dedicated product owner and sustainable operating budget.
• Measuring “Cognitive Load,” “Time-to-Hello-World,” and “Developer Net Promoter Score” as key KPIs.
• Integrating FinOps and Security into the earliest stages of the Golden Path templates.
• Adopting the “50/50” rule: 50% engineering effort, 50% user enablement and internal marketing effort.

L2: Stakeholder Perspective Analysis

To avoid the “Conway’s Law Violation” [Failure Mode FM6], the container platform strategy must be rigorously analyzed from the perspective of the distinct roles that interact with it. A platform that optimizes for the Enterprise Architect but disrupts the flow of the Software Developer is, by definition, a failed platform in a Team Topologies model.

L2.1 Software Developers

The Gap: The standard industry narrative posits that “containers simplify development” by ensuring environmental consistency between development and production. However, for the individual developer, transitioning from a monolithic architecture to a distributed microservices architecture on Kubernetes often increases friction in the “inner loop” (the cycle of code -> build -> test -> debug).²¹ The latency introduced by waiting for a CI pipeline to build a container image, push it to a registry, and deploy it to a remote cluster breaks the creative flow state that is essential for complex problem solving.

Required Capabilities:

• Inner Loop Optimization: The platform must support sophisticated tooling that bridges the local-remote gap. Tools like Tilt, Skaffold, or Telepresence allow for live-reloading of code into a cluster or hybrid local/remote execution.²² This capability preserves the rapid “save-and-refresh” feedback loop developers rely on, preventing the context switching that destroys productivity.
• Golden Paths: The platform must provide self-service templates (scaffolding) that bootstrap a new service with all logging, metrics, security configurations, and CI/CD pipelines pre-wired. This capability reduces the “time-to-first-commit” from days to minutes, allowing developers to focus on business logic immediately.²⁴
• Abstraction of Complexity: Developers should ideally interact with a high-level abstraction (e.g., a simplified app.yaml or a portal like Backstage) rather than raw Kubernetes manifests. Unless a team is designated as a “Complicated Subsystem” team requiring low-level control, the cognitive overhead of managing comprehensive Kubernetes YAML files is an anti-pattern.²⁵

Team Topologies Alignment:

• Stream-Aligned Teams: These are the primary consumers of the platform. Their cognitive load must be minimized to allow focus on domain logic.
• Platform Team: Responsible for building the “Golden Paths” and maintaining the inner-loop tooling that abstracts the underlying complexity.

L2.2 Testers

The Gap: In traditional environments, testing environments are static, scarce, and prone to configuration drift. While containerization offers the theoretical promise of ephemeral environments, without specific platform support, testers often struggle with test data management, environment provisioning latency, and the complexity of reproducing distributed failures.

Required Capabilities:

• Ephemeral Environments: The platform must possess the capability to spin up a full application stack (typically isolated in a unique namespace) for every Pull Request (PR). These environments must be torn down automatically after testing to manage costs. This capability eliminates the “staging environment bottleneck” where multiple teams queue to test changes.²²
• Contract Testing: In a microservices architecture, relying solely on end-to-end testing leads to slow and flaky test suites. The platform should support contract testing frameworks (e.g., Pact) to verify service interactions at the API level without requiring the simultaneous instantiation of the entire ecosystem.
• Chaos Engineering: As reliability becomes a core testing concern, tools like Chaos Mesh or Litmus should be available to test system resilience against pod failures, network latency, and resource exhaustion, simulating real-world instability in a controlled manner.²⁶

Evidence: DORA research consistently confirms that loosely coupled architectures supported by fast feedback loops (enabled by ephemeral environments) are a strong predictor of high software delivery performance.⁸

L2.3 DevOps Engineers

The Gap: The term “DevOps” is frequently conflated with “Platform Engineering,” leading to significant role confusion. In a strict Team Topologies model, DevOps is a cultural practice, not a specific role. However, the specialists facilitating this flow (often embedded in platform or enabling teams) require specific tooling that bridges the gap between source code and runtime infrastructure.

Required Capabilities:

• GitOps: The management of cluster state via Git repositories (using tools like ArgoCD or Flux) provides an immutable audit trail and a simplified rollback mechanism. This is an essential capability for regulated environments requiring strict change control evidence.²⁷
• Progressive Delivery: The platform must support advanced deployment strategies such as Canary deployments or Blue/Green rollouts (e.g., via Argo Rollouts or Flagger). This decouples “deployment” (installing the code) from “release” (shifting production traffic), allowing for safer, data-driven releases.²⁷
• Infrastructure as Code (IaC): Standardization on tools like Terraform, Crossplane, or Ansible to manage non-Kubernetes resources (cloud databases, message queues) alongside cluster resources is critical to prevent configuration drift and ensure reproducibility.

L2.4 Site Reliability Engineers (SRE)

The Gap: SREs are often tasked with “keeping the lights on” for opaque containerized workloads. Without strict observability standards and resource governance, they cannot effectively debug incidents, manage capacity, or enforce reliability contracts.

Required Capabilities:

• SLO/SLI Framework: The platform must expose standard metrics to allow the definition of Service Level Indicators (SLIs) and Service Level Objectives (SLOs). This moves the conversation from “is the server up?” to “is the user happy?”
• Golden Signals: Automated, standardized dashboards for every service showing Latency, Traffic, Errors, and Saturation must be generated without manual intervention.¹⁷
• Resource Management: Strict enforcement of Resource Requests and Limits, combined with the usage of Vertical Pod Autoscalers (VPA) to inform right-sizing. This is essential to prevent the “noisy neighbor” problem in shared multi-tenant clusters.

Team Topologies Alignment:

• Enabling Team: SREs often function best as an enabling team, teaching stream-aligned teams how to define and monitor their own SLOs, rather than a centralized team that owns reliability for the entire organization.⁷

L2.5 Security and Privacy Engineers

The Gap: Security is traditionally positioned as a “gate” at the end of the delivery lifecycle. In fast-moving container platforms, this model acts as a bottleneck. Security must be “shifted left” (into the build time) and “shielded right” (runtime protection) to be effective.

Required Capabilities:

• Supply Chain Security: Implementation of Sigstore and SLSA (Supply-chain Levels for Software Artifacts) frameworks to sign container images and verify their provenance. This is a critical requirement for meeting impending EU CRA obligations.²⁰
• Admission Control: The implementation of policies (using Kyverno or OPA/Gatekeeper) that prevent insecure workloads (e.g., running as root, privileged escalation) from ever being scheduled on the cluster.¹³
• SBOM Management: A comprehensive workflow to generate, store, and continuously scan Software Bills of Materials (SBOMs). This addresses the “vulnerability exploitability” barrier identified by O’Donoghue et al., ensuring that new CVEs are detected in deployed software immediately.¹⁵
• Data Residency: Kubernetes node affinity rules and taints/tolerations to ensure that data processing occurs only on nodes located within specific geographic boundaries (e.g., EU-only nodes) to comply with GDPR and BIO2 sovereignty requirements.

L2.6 Solution Architects

The Gap: Architects often struggle with “Resume Driven Development,” where teams select Kubernetes for simple applications that do not warrant the complexity.

Required Capabilities:

• Decision Frameworks: Access to explicit decision matrices (like the “Thinnest Viable Platform” matrix in L1) to empower architects to push back on unnecessary complexity and select the appropriate abstraction level.
• Interoperability Standards: Ensuring the platform is built upon open standards (CNCF) to avoid vendor lock-in. This is a key requirement for maintaining long-term strategic agility and exit strategies.¹⁰

L3: Observability and Reliability Architecture

To achieve the status of a “Harmonious High-Achiever” as defined in the DORA 2025 report ⁹, the platform must provide robust observability not merely as an add-on tool, but as an intrinsic, built-in feature of the “Golden Path.”

3.1 The Three Pillars & OpenTelemetry

The architecture must standardize on OpenTelemetry (OTel) for data collection to ensure vendor neutrality and unified data models.

1. Metrics: Collected in Prometheus format. The focus must be strictly on the Golden Signals to avoid metric fatigue and storage bloat.¹⁷
2. Logs: Structured JSON logs must be enforced, automatically correlated with Trace IDs to allow for seamless context switching during debugging.
3. Traces: End-to-end distributed request tracing is mandatory to visualize latency across microservices and identify bottlenecks in the mesh.

3.2 Golden Signals & SLO Framework

Reliability is defined by the user’s experience, not server uptime. The platform must provide visibility into the four Golden Signals:

• Latency: The time taken to service a request (crucially distinguishing between the latency of successful requests vs. failed requests).
• Traffic: A measure of the demand placed on the system (e.g., requests per second).
• Errors: The rate of requests that fail (explicitly defined, e.g., HTTP 5xx, non-200 responses).
• Saturation: A measure of how “full” the service is (CPU/Memory usage vs. Limits).¹⁷

Standardized Dashboarding: Every service deployed via the platform should automatically receive a generated Grafana dashboard visualizing these four signals without manual configuration by the developer. This lowers the barrier to entry for SRE practices.

3.3 Observability Maturity Model

L4: Security, Privacy, and Governance Architecture

This section maps the technical capabilities of the container platform to the regulatory obligations of the EU Cyber Resilience Act (CRA), NIS2, Dutch BIO2, and NIST SP 800-190.

4.1 Threat Model & Hardening (NSA/CISA & NIST 800-190)

The NSA/CISA Kubernetes Hardening Guide ²⁹ identifies five key hardening domains. The platform architecture must explicitly address each:

1. Pod Security:

• Control: Enforce “Restricted” Pod Security Standards (PSS) globally.
• Mechanism: Admission controllers (Kyverno or Gatekeeper) must be configured to reject pods running as root, sharing the host network, or with privileged: true.
• Evidence: NIST 800-190 §3.1 explicitly warns against mixed-sensitivity workloads without strong isolation.

2. Network Separation:

• Control: Implement a “Deny-all” default NetworkPolicy for all namespaces.
• Mechanism: Explicit allow-listing for service-to-service communication. Namespace isolation alone is insufficient for security segmentation.

3. Authentication & Authorization:

• Control: Strict RBAC with Least Privilege principles.
• Mechanism: Disable the automounting of ServiceAccount tokens by default. Integrate authentication with a corporate Identity Provider (OIDC) to ensure MFA and centralized user lifecycle management.

4. Log Auditing:

• Control: Enable and persist Kubernetes Audit Logs.
• Mechanism: Ship audit logs to a tamper-proof external store (SIEM) for forensic retention.

5. Upgrades & Application Safety:

• Control: Regular control plane and worker node patching.
• Mechanism: Automated node rotation and aggressive scanning of images before deployment to prevent known CVEs from entering production.

4.2 Supply Chain Security (EU CRA Compliance)

The EU CRA ⁴ mandates secure development lifecycles, vulnerability reporting, and supply chain transparency.

• SBOM (Software Bill of Materials):

• Requirement: A complete, machine-readable inventory of all software components.
• Implementation: Generate SBOMs (in SPDX or CycloneDX format) at build time using tools like Syft.
• Caveat: Acknowledge the “Analysis Tooling” barrier identified by O’Donoghue et al..¹⁵ Scanners often disagree on vulnerability counts. Mitigation requires using multiple scanners (e.g., Trivy + Grype) and implementing human triage processes for critical components to avoid false positive fatigue.
• Provenance & Integrity:

• Requirement: Cryptographic proof that the binary was built from the source code it claims to be.
• Implementation: Target SLSA Level 2/3. Use Sigstore/Cosign to sign images in the CI pipeline and verify these signatures at the cluster admission controller level.²⁰
• Regulatory Map: CRA Annex I (Essential Cybersecurity Requirements).

4.3 BIO2 Compliance Mapping

The Dutch BIO2 Framework ⁵ is structured in accordance with ISO 27001/27002.

L5: Platform Operating Model and Team Design

Adopting Kubernetes without adopting a compatible organizational structure is a primary failure mode.³ We leverage the Team Topologies framework to define a sustainable operating model that manages cognitive load.

5.1 Team Types & Responsibilities

1. Platform Team:

• Mission: Build the “Thinnest Viable Platform” (TVP) that significantly reduces cognitive load for stream-aligned teams.
• Responsibility: Maintains the Kubernetes clusters, the IDP (Internal Developer Platform), CI/CD templates, and the “Golden Paths.” They treat the platform as a product.
• Metric: User satisfaction (NPS), Platform Adoption Rate, and Cognitive Load assessments.¹

2. Stream-Aligned Teams (Product Teams):

• Mission: Deliver business value (features) to customers rapidly and safely.
• Responsibility: Build and run their applications (“You Build It, You Run It”). They “consume” the platform services via self-service APIs and templates.
• Metric: DORA metrics (Deployment Frequency, Lead Time, Change Failure Rate).

3. Enabling Teams:

• Mission: Grow capabilities and bridge knowledge gaps in stream-aligned teams.
• Context: A “Security Enabling Team” helps product teams understand threat modeling. An “SRE Enabling Team” teaches them how to define and monitor SLOs.
• Interaction: “Facilitation” mode (temporary engagement), not “X-as-a-Service” (permanent dependency).⁷

4. Complicated Subsystem Teams:

• Mission: Manage heavily specialized components requiring deep domain expertise (e.g., a custom AI inference engine or a legacy mainframe wrapper).
• Justification: Only form this team if the cognitive load to manage the subsystem is too high for a standard stream-aligned team to bear.

5.2 Cognitive Load Management

Using Dr. Laura Weiss’s research, we treat cognitive load as a finite capacity constraint that must be managed.

• Intrinsic Load: The essential skills required for the task (e.g., Java programming, Business Domain Logic). Keep.
• Extraneous Load: The unnecessary complexity of the environment (e.g., configuring K8s Ingress, managing TLS certs, debugging obscure YAML errors). Eliminate via the Platform.
• Germane Load: The effort dedicated to learning and value-add thinking (e.g., optimizing algorithms, learning new frameworks). Maximize.

The Teamperature Model: The organization should regularly survey teams to assess if the platform is effectively offloading Extraneous Load. If developers report spending >20% of their time fighting infrastructure or configuration, the platform is failing its primary directive.⁶

5.3 FinOps Integration

To avoid “FinOps Neglect” [Failure Mode FM5], the platform must integrate financial governance from day one.

• FOCUS 1.3: Adopt the FinOps Open Cost and Usage Specification to normalize billing data across providers.¹⁶
• Cost Allocation:

• Mechanism: Use tools like Kubecost or OpenCost to provide visibility.
• Strategy: Enforce a strict tagging policy where every namespace must have a cost-center label.
• Shared Costs: Allocate shared cluster costs (control plane, monitoring, networking) proportionally based on CPU/Memory requests (reserved capacity) rather than just usage. This incentivizes teams to right-size their resource requests.¹²

L6: Implementation Roadmap and Investment Case

This roadmap explicitly acknowledges the “70% failure rate” statistic by front-loading value delivery and adoption, rather than focusing solely on technical architecture.

Phase 0: Foundation (Months 0-3)

• Goal: Establish the “Thinnest Viable Platform” and governance baseline.
• Key Activities:

• Define the “Golden Path” for one pilot application (Docker-based, locally executable).
• Establish the Platform Team (composed of Senior Engineers + a Product Owner).
• Implement basic image scanning (Trivy) in the CI pipeline.
• Decision Gate: Do we have a pilot team willing to collaborate? (If no, stop and reassess value proposition).

Phase 1: Platform MVP (Months 3-9)

• Goal: A usable, self-service platform for early adopters.
• Key Activities:

• Deploy Managed Kubernetes (AKS/EKS) with GitOps (ArgoCD) for state management.
• Implement “Inner Loop” tooling (Skaffold or Tilt) to ensure developer productivity.
• Automate the generation of Golden Signal dashboards.
• Metric: “Time to Hello World” < 30 mins.
• Risk: Over-engineering. Constraint: Use managed services wherever possible instead of self-hosted components.

Phase 2: Production Hardening (Months 9-18)

• Goal: Scale to critical workloads; focus on Compliance & Efficiency.
• Key Activities:

• Enforce Network Policies and Admission Control (BIO2/NIST compliance).
• Implement FinOps chargeback/showback reports to business units.
• Roll out SLSA/Sigstore signing to prepare for CRA requirements.
• Metric: Change Failure Rate < 5%; Cloud spend variance < 10%.

Phase 3: Platform Excellence (Months 18-36)

• Goal: Organizational scale, optimization, and innovation.
• Key Activities:

• Deploy an Internal Developer Portal (e.g., Backstage) for a unified service catalog.
• Implement Advanced SRE practices (Chaos Engineering, Automated Canary deployments).
• Achieve full EU CRA compliance (automated SBOM exchange).
• Metric: 80% of teams using the platform (voluntary adoption).

Investment Case

• Cost Drivers: Platform team salaries (high-skill requirement), Tooling costs (Enterprise licenses for security/registry), Cloud training and upskilling.
• ROI:

• Efficiency: Reduction in “Extraneous Load” allows 20-30% more capacity for feature delivery.³³
• Risk: Prevention of supply chain attacks (average cost of breach far exceeds platform cost).
• Speed: DORA “Elite” performers deploy 208x more frequently than low performers, enabling faster market response.²⁶

L7: Annexes, Templates, and Decision Tools

Annex A: Failure Mode Catalogue

Annex B: Glossary

• Thinnest Viable Platform (TVP): The minimal set of APIs, documentation, and tools needed to accelerate teams, avoiding bloat.
• Golden Path: An opinionated, supported, and automated path to production that represents the “path of least resistance” for developers.
• Stream-Aligned Team: A team aligned to a single, valuable stream of work (e.g., a product feature), empowered to deliver independently.
• Cognitive Load: The total amount of mental effort being used in the working memory.

Annex C: Evidence Base & References

This report synthesizes data from the following key sources:

• ⁸ DORA 2024/2025 Reports (Team Archetypes, AI impact).
• ⁶ Team Topologies 2nd Edition (Cognitive Load, Teamperature).
• ⁴ EU Cyber Resilience Act (Timelines, Requirements).
• ¹³ NIST SP 800-190 & NSA/CISA Hardening Guides.
• ¹⁴ O’Donoghue et al. (2025) SBOM Systematic Literature Review.
• ¹ Platform Engineering Failure Rates (Gartner/Fast Flow Conf).
• ¹² FinOps Foundation & FOCUS Specification.

This report provides a scientifically grounded, audit-ready framework for container platform strategy, specifically tailored to the rigorous demands of regulated enterprise environments.

Geciteerd werk

1. Why Up to 70% of Platform Engineering Teams Fail to Deliver Impact – The New Stack, geopend op februari 11, 2026, https://thenewstack.io/why-up-to-70-of-platform-engineering-teams-fail-to-deliver-impact/
2. Unlock Infrastructure Efficiency with Platform Engineering – Gartner, geopend op februari 11, 2026, https://www.gartner.com/en/infrastructure-and-it-operations-leaders/topics/platform-engineering
3. Platform Engineering 80% Adoption Hides 70% Failure Rate | byteiota, geopend op februari 11, 2026, https://byteiota.com/platform-engineering-80-adoption-hides-70-failure-rate/
4. The Cyber Resilience Act – Summary of the legislative text | Shaping Europe’s digital future, geopend op februari 11, 2026, https://digital-strategy.ec.europa.eu/en/policies/cra-summary
5. Government Information Security Baseline – Digital Government, geopend op februari 11, 2026, https://www.nldigitalgovernment.nl/overview/government-information-security-baseline/
6. Tap into Fast Flow with Team Topologies & Platform Engineering | gotopia.tech, geopend op februari 11, 2026, https://gotopia.tech/articles/354/tap-into-fast-flow-with-team-topologies-and-platform-engineering
7. Adidas: Transforming Through Team Topologies and Platform …, geopend op februari 11, 2026, https://teamtopologies.com/2nd-edition-case-studies/adidas-transforming-through-team-topologies-and-platform-engineering
8. Announcing the 2025 DORA Report | Google Cloud Blog, geopend op februari 11, 2026, https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report
9. DORA Report 2025 Key Takeaways: AI Impact on Dev Metrics – Faros AI, geopend op februari 11, 2026, https://www.faros.ai/blog/key-takeaways-from-the-dora-report-2025
10. Beyond the Hype: Building Actually Useful Platforms with the CNCF Maturity Model (and a Healthy Dose of Realism), geopend op februari 11, 2026, https://blog.eisele.net/2025/02/cncf-platform-engineering-maturity-model-tvp-guide.html
11. MVP or TVP? Why Your Internal Developer Platform Needs Both …, geopend op februari 11, 2026, https://thenewstack.io/mvp-or-tvp-why-your-internal-developer-platform-needs-both/
12. A Practical Guide to FinOps: Implementing Cloud Unit Economics – The 4Geeks Blog, geopend op februari 11, 2026, https://blog.4geeks.io/a-practical-guide-to-finops-implementing-cloud-unit-economics/
13. Guide to NIST SP 800-190 compliance in container environments, geopend op februari 11, 2026, https://www.redhat.com/en/resources/guide-nist-compliance-container-environments-detail
14. [2506.03507] Software Bill of Materials in Software Supply Chain Security A Systematic Literature Review – arXiv, geopend op februari 11, 2026, https://arxiv.org/abs/2506.03507
15. Software Bill of Materials in Software Supply Chain Security: A Systematic Literature Review, geopend op februari 11, 2026, https://arxiv.org/html/2506.03507v1
16. FOCUS Specification, geopend op februari 11, 2026, https://focus.finops.org/focus-specification/
17. What are golden signals? – Dynatrace, geopend op februari 11, 2026, https://www.dynatrace.com/knowledge-base/golden-signals/
18. Google SRE monitoring ditributed system – sre golden signals, geopend op februari 11, 2026, https://sre.google/sre-book/monitoring-distributed-systems/
19. The Cyber Resilience Act: A Guide for Manufacturers | TXOne Networks, geopend op februari 11, 2026, https://www.txone.com/blog/cra-guide-for-manufacturers/
20. Practical Supply Chain Security: Implementing SLSA Compliance from Build to Runtime – Sched, geopend op februari 11, 2026, https://static.sched.com/hosted_files/kccncna2024/0b/Practical%20Supply%20Chain%20Security_%20Implementing%20SLSA%20Compliance%20from%20Build%20to%20Runtime.pdf.pdf
21. The outer loop vs. the inner loop of agents. A simple mental model to evolve the agent stack quickly and push to production faster. : r/AI_Agents – Reddit, geopend op februari 11, 2026, https://www.reddit.com/r/AI_Agents/comments/1n1zjwd/the_outer_loop_vs_the_inner_loop_of_agents_a/
22. Top 5 Skaffold alternatives for Kubernetes development and deployment in 2026 | Blog, geopend op februari 11, 2026, https://northflank.com/blog/skaffold-alternatives
23. Skaffold vs.Telepresence: Comparing Kubernetes Inner Development Loop Tools, geopend op februari 11, 2026, https://blog.getambassador.io/skaffold-vs-telepresence-comparing-kubernetes-inner-development-loop-tools-c8abd70545e5
24. Define the problem space – Platform engineering – Microsoft Learn, geopend op februari 11, 2026, https://learn.microsoft.com/en-us/platform-engineering/problem-space
25. CNCF Platforms White Paper, geopend op februari 11, 2026, https://tag-app-delivery.cncf.io/whitepapers/platforms/
26. Accelerate State of DevOps Report 2024 – DORA, geopend op februari 11, 2026, https://dora.dev/research/2024/dora-report/
27. Platform Engineering Maturity Model | CNCF TAG App Delivery, geopend op februari 11, 2026, https://tag-app-delivery.cncf.io/whitepapers/platform-eng-maturity-model/
28. Scaling Up Supply Chain Security: Implementing Sigstore for Seamless Container Image Signing, geopend op februari 11, 2026, https://openssf.org/blog/2024/02/16/scaling-up-supply-chain-security-implementing-sigstore-for-seamless-container-image-signing/
29. CISA and NSA Release Kubernetes Hardening Guidance, geopend op februari 11, 2026, https://www.cisa.gov/news-events/alerts/2021/08/02/cisa-and-nsa-release-kubernetes-hardening-guidance
30. Updated: Kubernetes Hardening Guide – CISA, geopend op februari 11, 2026, https://www.cisa.gov/news-events/alerts/2022/03/15/updated-kubernetes-hardening-guide
31. Baseline information security for government 2, BIO2, geopend op februari 11, 2026, https://www.bio-overheid.nl/media/jcdfql4p/20250924-baseline-information-security-for-government-2-bio2-v12-final.pdf
32. Teamperature – Managing cognitive load for healther teams, geopend op februari 11, 2026, https://www.teamperature.com/
33. Platform Engineering: Rapid Adoption and Impact | Industry Insight – CloudBees, geopend op februari 11, 2026, https://www.cloudbees.com/platform-engineering-research
34. Key findings from Literature review | Download Scientific Diagram – ResearchGate, geopend op februari 11, 2026, https://www.researchgate.net/figure/Key-findings-from-Literature-review_tbl1_377107512
35. (PDF) Software Bill of Materials in Software Supply Chain Security A …, geopend op februari 11, 2026, https://www.researchgate.net/publication/392405680_Software_Bill_of_Materials_in_Software_Supply_Chain_Security_A_Systematic_Literature_Review
36. EU Cyber Resilience Act: Key 2026 milestones toward CRA compliance – Hogan Lovells, geopend op februari 11, 2026, https://www.hoganlovells.com/en/publications/eu-cyber-resilience-act-getting-ready-for-cra-compliance-in-2026