Cypher-X

Compliance controls can improve security and cost attribution while making the developer experience markedly worse. In his InfoQ Dev Summit Munich 2025 presentation, Davide de Paolis, an engineering manager of a platform team at Sevdesk and an AWS Community Builder, examines how a platform team can avoid turning that tension into an adversarial relationship.

The talk is a case study in internal cloud governance, especially resource tagging. It is not a claim that the same rollout satisfies an external audit or regulation. In Q&A, de Paolis explicitly separates internal governance from regulatory compliance, where deadlines may be non-negotiable and legal, finance, and security provide a broader mandate.

What You Will Learn

Why replacing self-managed infrastructure can still impose substantial work on product teams.
How Sevdesk narrowed a large tagging policy into minimum viable governance.
Why the team measured existing violations before enabling blocking controls.
How immediate warnings and weekly reports created a soft-enforcement phase.
How AWS Config, EventBridge, Lambda, a queue, Security Hub, GitHub ownership, and Slack fit into the feedback loop.
Why platform teams need to remediate their own violations first.
Which conclusions come from the presentation and which are synthesis.

The Setting: A Platform Reboot

At the time described, Sevdesk built accounting software for small businesses and freelancers. De Paolis reports roughly 15 teams and 80-90 engineers, with most people working remotely.

An earlier platform team had been assembled from experienced product engineers. It pursued a service catalog, an internal developer platform, and a cloud center of excellence while moving workloads from EC2 toward EKS. Although Sevdesk was already committed to AWS, concern about vendor lock-in led the team to operate a substantial collection of alternatives and custom components:

Keycloak for access management.
Rancher as a Kubernetes interface.
Longhorn for block storage.
Harbor as an image registry.
Additional third-party and homegrown services.

According to de Paolis, maintenance, patching, and upgrades consumed so much of the team's capacity that little remained for reusable platform capabilities. The team burned out and was dissolved. He joined a later team charged with rebuilding the platform function and its roadmap.

The replacement team first moved from one AWS account to AWS Organizations and a multi-account structure divided by environment, team, domain, and functions such as security, data, and backups. De Paolis attributes several benefits to this structure:

Isolation of data, infrastructure, and access, limiting the effect of an account compromise.
Policies tailored to an application and environment, including looser sandbox access for experimentation.
Separation of AWS service and API quotas between workloads.
More direct allocation of cloud costs to owners.

The team also reduced its self-managed surface: IAM and AWS Single Sign-On (now IAM Identity Center) replaced Keycloak, EBS replaced Longhorn, and ECR plus Inspector replaced Harbor. Security Hub, AWS Config, and GuardDuty were introduced with the security team.

This simplified platform operations and gave the security team natively integrated controls, but it did not make the migration free. Product engineers now had to switch accounts, learn unfamiliar AWS services, change pipelines from Harbor to ECR, and promote images between accounts. De Paolis's important admission is that the platform team had moved work onto its users even though the target architecture was easier for the platform team to operate.

Documentation Did Not Remove the Friction

The team wrote documentation, held kickoff meetings, and opened a Slack support channel. Developers still repeated questions and criticized the experience; platform engineers became frustrated that people did not read the documents.

The tagging-policy page exposed why "read the docs" was not an adequate answer. It was long, overly detailed, boring, and partly outdated. More fundamentally, documentation could describe accepted tag values but could not prevent a typo or an invalid value.

This shifts the design question from how to document compliance to how to make the desired behavior visible, verifiable, and eventually enforceable.

Separate Validation, Observation, and Enforcement

De Paolis describes several AWS mechanisms with different behavior:

An AWS Organizations tag policy defines tag keys and accepted values. In the example, sevdesk-owner accepted team values and an orphaned value for workloads whose owner was not yet known. A resource could still be created without the tag.
A service control policy (SCP) acts as a guardrail. Sevdesk could deny the creation of resources such as clusters, Lambda functions, or databases when the owner condition was not met.
The AWS Resource Tagging Standard in Security Hub observed whether selected resources conformed without immediately blocking deployments.

The team initially tried to describe many resources and actions in SCPs. De Paolis reports encountering a 5,000-character SCP limit, limits on the number of SCPs attachable to an account or organizational unit, and inconsistent tagging support between AWS services, including differences between request tags and resource tags.

Rather than encode every possible service, the team used Steampipe to query AWS APIs with SQL and identify "heavy hitters": services responsible for the most cost and those used most often. Enforcement could concentrate there while monitoring covered a broader resource set. De Paolis notes that today he might also investigate Amazon Q and available MCP servers, but Steampipe was the tool used in this case.

Minimum Viable Governance

The old Confluence policy listed roughly 25-30 tags. Sevdesk reduced the active standard to five it considered crucial:

Owner.
Service.
User data.
Criticality.
Confidentiality.

This is de Paolis's idea of minimum viable governance: determine what matters to the company now rather than attempting every possible control with limited people and time.

His prioritization dimensions are urgency, importance, impact, and effort. Work on important and urgent issues, but also address important non-urgent issues before they become emergencies. High-impact, low-effort changes can build momentum, even though he dislikes the phrase "low-hanging fruit."

The talk uses a hypothetical scale problem: if Security Hub displays 12,000 vulnerabilities, the organization cannot address them all at once. The number illustrates the need to prioritize; de Paolis does not identify it as Sevdesk's actual backlog or provide a remediation result for it.

Measure Before Blocking

Before deciding whether to activate the SCP, the team enabled the tagging standard in Security Hub and let it collect findings for a day. The result was many more non-compliant resources than expected. A significant share belonged to the platform team itself: clusters, instances, roles, permissions, and security groups were missing the required tags.

The observation phase changed the rollout in three ways:

It revealed the likely blast radius before deployments were blocked.
It gave teams data with which to plan remediation.
It forced the platform team to fix its own resources and lead by example.

De Paolis argues against enforcing an arbitrary quarterly target when the data shows that, for example, half the resources remain non-compliant. Management can help teams prioritize, but enabling a control that predictably disrupts many releases is not made sensible merely because the platform roadmap named a date.

The Inform, Soft-Enforce, Enforce Sequence

The reusable process in the talk is:

Inform: explain the purpose, expose the current state, and let teams plan.
Soft-enforce: detect violations and send actionable feedback without breaking deployment.
Enforce: activate blocking guardrails after adoption and readiness data justify doing so.

Sevdesk designed two feedback paths during soft enforcement. The talk describes the SCP as the eventual enforcement mechanism, but it does not state that the team had activated the blocking policy by the time of the presentation.

Immediate Feedback for New Resources

AWS Config detected a resource creation, edit, or configuration change. If the owner tag was absent, an EventBridge event triggered a Lambda function. When the event did not identify the owner, the function inspected the CI/CD pipeline and the owning GitHub repository to infer the responsible team.

Events then passed through a queue to another Lambda for aggregation before being delivered through AWS Chatbot, since renamed Amazon Q Developer in chat applications, to Slack.

flowchart LR
    A[Resource created or changed] --> B[AWS Config]
    B --> C{Owner tag present?}
    C -->|Yes| D[No warning]
    C -->|No| E[EventBridge]
    E --> F[Lambda enriches event]
    F --> G[CI/CD and GitHub ownership lookup]
    G --> H[Queue]
    H --> I[Lambda aggregates events]
    I --> J[Chat integration]
    J --> K[Slack warning]

The queue was a developer-experience feature, not incidental plumbing. De Paolis's example deployment created a Lambda function, an API Gateway, a DynamoDB table, and an S3 bucket, plus supporting IAM roles. He said aggregation avoided six separate messages and the resulting Slack noise.

The ownership lookup was also necessary because creator attribution was not enough. De Paolis described an AWS-generated created by tag as being present on every resource, but AWS tag support varies by service, so that should be read as his account of their environment rather than a universal AWS guarantee. In his example, a direct deployment identified an individual rather than a team, while infrastructure as code deployed by GitHub Actions identified only the runner's assumed role. He also mentioned CloudTrail and CI/CD data as possible sources when tags could not establish ownership; the architecture shown used pipeline and GitHub repository ownership.

Trend Feedback for Existing Resources

A scheduled EventBridge rule triggered a weekly Lambda that read Security Hub findings. Missing ownership values were again enriched from GitHub. A report generator stored statistics in DynamoDB, compared them with the previous week, and sent each team a Slack update showing progress or remaining work.

The immediate path tried to prevent new debt; the weekly path made the legacy backlog and its trend visible. De Paolis presents this architecture and rollout pattern as reusable for other internal compliance initiatives, with scripts and checks adapted to each control.

Compliance Is a Collaboration Problem

Automation did not replace communication. Sevdesk also used Confluence, DevOps champions, recurring meetings, and a tour of duty or embedded expert model. A platform engineer joined product teams to explain changes, answer questions, and sometimes perform initial groundwork.

The boundary de Paolis draws is useful: product teams retain responsibility for their applications, while the platform team makes the change achievable and supports them through it. "You build it, you run it" should not mean "you are on your own."

He also emphasizes purpose. People are more likely to schedule governance work when they understand how it contributes to customers and company goals, rather than receiving a platform decree. Patience and empathy are required on both sides because organizational change takes longer than expected and priorities or team structures can interrupt momentum.

What the Talk Does Not Establish

Keeping the evidence boundary clear matters:

The presentation reports a rollout design and lessons from Sevdesk, but does not publish before-and-after compliance percentages, cost savings, developer satisfaction scores, or deployment-failure rates.
The statement that the process can work in a company of any size is de Paolis's generalization, not a multi-company comparative study.
The talk does not show that these internal controls satisfy a particular law, certification, or audit framework.
Backstage was evaluated but considered premature. Sevdesk had not selected it or built a custom equivalent at the time described.
The presentation supports staged enforcement, not indefinite non-enforcement. Mandatory external deadlines can require a different pace.

Synthesis: Engineering Lessons Beyond the Talk

The following are deductions from the case study, not claims or measured results reported by de Paolis.

Treat Enforcement as a Release

A blocking policy changes a shared production interface. It deserves the same release discipline as an API change: inventory consumers, estimate blast radius, provide a migration path, observe readiness, communicate a cutoff, and retain an escalation or exception process. An arbitrary roadmap date is not a readiness signal.

Optimize Feedback for Resolution, Not Detection

A finding is actionable only when it reaches a responsible team with enough context to fix it. Sevdesk's enrichment and aggregation imply a useful quality test for compliance automation: measure not only how many violations it detects, but also how many have an owner, arrive without duplicate noise, and can be resolved from the information supplied.

Ownership Metadata Is Foundational Infrastructure

The hardest part of the warning pipeline was not checking for a tag; it was identifying who should act when the tag was missing. Repository ownership, deployment identity, resource inventory, and team structure therefore need a maintained relationship. Without it, automated governance produces a central backlog rather than distributed action.

Monitor Broadly and Block Selectively

The SCP constraints and uneven AWS tagging semantics suggest two control planes: broad detective coverage for visibility and narrow preventive controls for the highest-value, best-supported cases. Expanding prevention should follow evidence that each service's creation paths and exceptions are understood.

Replacing self-managed components reduced the platform team's maintenance load, but product teams paid through pipeline changes and new cloud knowledge. The embedded-expert model is one way to rebalance that cost. Migration work should be included in the platform initiative's scope rather than externalized and then interpreted as user resistance.

Practical Checklist

State whether the initiative is internal governance or externally mandated compliance, and identify any fixed deadline.
Reduce the initial policy to controls with explicit business, security, or cost value.
Inventory current violations before enabling preventive controls.
Remediate the platform team's own resources first.
Identify which services and creation actions can be enforced reliably.
Map every finding to a team, not merely an individual or CI runner.
Send immediate, aggregated feedback for newly introduced violations.
Report the legacy backlog and trend on a predictable cadence.
Pair automation with champions, office hours, or embedded support.
Enable blocking controls based on readiness data and mandate, then repeat the process for the next prioritized rule.

The central lesson is not that compliance should be optional. It is that a platform team can choose whether compliance arrives as a surprise outage or as an observable, supported migration. Minimum viable governance narrows the work; soft enforcement creates a learning period; and data tells the organization when a stricter guardrail is likely to improve behavior rather than simply break delivery.

Canonical source: Davide de Paolis, "Road to Compliance: Will Your Internal Users Hate Your Platform Team?", InfoQ Dev Summit Munich 2025 presentation and transcript, published by InfoQ on July 13, 2026.