Internal Developer Platforms have become the dominant approach for managing developer productivity at scale in large engineering organisations. The core premise is sound: standardise the path from code to production, abstract away infrastructure complexity, and let product engineers focus on product problems rather than platform problems. In a regulated enterprise, the IDP premise has an additional requirement that most IDP implementations do not address: the golden path must make the compliant path the easy path, not an optional detour.
The Compliance Blind Spot in Standard IDPs
A standard IDP provides: self-service infrastructure provisioning (spin up a Kubernetes namespace, an RDS instance, an S3 bucket), CI/CD pipeline templates, service scaffolding generators, and an internal service catalog. None of these standard components inherently produce compliant systems. A developer who provisions a PostgreSQL RDS instance through the IDP gets a database — but does it have encryption at rest enabled? Is it in a VPC with private subnets only? Are access logs enabled? Is the backup retention period set to meet the organisation's RPO requirement? Unless the IDP template enforces all of these, the answer depends on whatever the developer configures, which means the answer varies and some configurations will fail compliance review.
The golden path in a regulated enterprise must include: pre-approved cloud service configurations (templates that already have encryption, logging, and access controls correctly configured), compliance-as-code policies that run in the CI/CD pipeline and block non-compliant configurations from deploying, mandatory secret management integration (no hardcoded credentials — all secrets from Vault or the cloud provider's secrets manager), and evidence-generating pipelines that produce audit artefacts as a byproduct of normal development workflow, not as a separate compliance exercise.
Pre-Approved Cloud Configurations
Every cloud service available through the IDP should be available only in pre-approved configurations. For S3: encryption enabled, public access blocked, access logging enabled, versioning enabled for buckets that store regulated data. For RDS: encryption at rest enabled, deletion protection enabled, automated backups with a defined retention period, enhanced monitoring enabled. For EC2: SSM agent installed for patch management, CloudWatch agent installed for log shipping, security groups restricted to necessary ports. These configurations should be the only configurations available through the IDP — a developer who needs a non-standard configuration must go through a review process.
Pre-approved configurations are most effectively enforced through infrastructure-as-code modules: a Terraform module for an S3 bucket that accepts only the parameters the organisation has approved. The module enforces the configuration baseline at the point of provisioning. Cloud provider policy frameworks (AWS Service Control Policies, Azure Policy, GCP Organization Policy) enforce the same constraints at the cloud API level, providing a second layer of enforcement that catches configurations created outside the IDP.
Evidence-Generating Pipelines
Compliance audits require evidence that controls are implemented and operating effectively. In a traditional compliance model, evidence collection is a manual exercise that happens in the weeks before an audit. In a well-designed IDP, evidence is generated continuously as a byproduct of normal development workflow. Every deployment generates a change management record. Every infrastructure provisioning operation generates a configuration baseline record. Every pipeline run generates test execution evidence. The IDP's audit trail is the compliance evidence record — if the IDP is configured correctly, the compliance team's audit preparation effort reduces from weeks to days.
- Audit the current IDP against compliance requirements before declaring it production-ready for regulated workloads — standard IDPs are not compliant by default
- Replace the current infrastructure templates with compliance-enforcing modules that make non-compliant configurations unavailable, not just discouraged
- Integrate compliance-as-code policy checks (OPA, Checkov, or cloud-native policy frameworks) as blocking gates in the CI/CD pipeline
- Make secret management integration mandatory at the scaffold level — services generated by the IDP should include secrets manager integration, not environment variable handling
- Build evidence generation into the pipeline: structured logs, change records, and configuration snapshots should be produced automatically, not collected manually before audits
- Define a compliance review process for developers who need non-standard configurations — the review process is the safety valve, not the default path
The engineering behind this article is available as a service.
We have done this work — not advised on it, not reviewed documentation about it. If the problem in this article is your problem, the first call is with a senior engineer who has solved it.