Your IDP is Actually a Compliance Engine
Don't sell Internal Developer Platforms as 'making devs happy'. Sell them as 'making auditors happy' by forcing standardised golden paths.
Every IDP pitch deck I've seen leads with developer velocity. That's a hard sell to a CFO who's already shipping features.
Try this framing instead: an IDP is the cheapest way to pass your next compliance audit.
The compliance angle
Auditors hate variance. If service A logs in JSON, service B logs in plain text, service C doesn't log at all — every service is a separate evidence-gathering exercise.
An IDP that ships golden-path templates flips this:
- Every new service gets the same logging library, pre-wired to CloudWatch with structured fields.
- Every new pipeline gets the same SBOM + signature step.
- Every new database gets the same encryption-at-rest + backup schedule.
You audit the template, not the 47 services that used it.
What goes in the template
A good Backstage template should ship a new service with:
- Repository created with branch protection + CODEOWNERS.
- CI workflow with SAST (Semgrep), dependency scan (Trivy), SBOM (Syft), and image signing (Cosign).
- IaC module wired to deploy to a hardened ECS service with secrets pulled from AWS Secrets Manager.
- Dashboards and alerts pre-provisioned.
- Runbook stub in the repo.
The developer experience? backstage new and they're in production by lunch. The auditor experience? "Show me how a new service gets compliant logging." → "It's the template, here's the diff history."
The CFO sentence
"Every quarter we onboard ~12 new services. Pre-IDP, each service needed 3 days of platform team review. Post-IDP, it's 30 minutes. That's 100 days/year reclaimed, and zero audit findings on the new services."
That's the slide that gets the platform team funded.