Self-service tools - Percona: Making compliance & data management self-service
This is a guest post written by Briana Swifft, director of solutions marketing at Percona.
Swift writes in full as follows…
Developers build software to meet specific needs or goals, often by creating new functionality or integrating with existing applications.
Alongside these technical requirements sit additional responsibilities like how the application handles, stores and governs its data.
Security, sovereignty and compliance obligations increasingly impact developers in day-to-day decisions, especially as organisations spread workloads across services.
Not in my wheelhouse
For many developers, this level of operational responsibility sits far outside their comfort zone.
They signed up to write software, not to manage data or design compliance frameworks. But as organisations deploy more containerised and cloud-based architectures, decisions made during development can directly affect how data is secured and governed.
The result is that this compliance and security overhead lands more and more often into developer workflows, even though the responsibility may be better owned by teams with expertise around platform engineering, security, and data.
Compliance-as-code
In response, developers can translate security compliance requirements into machine-readable rule sets that can be version tested and deployed like any other code.
Agile and DevOps practices pushed automation deeper into software delivery, while CI/CD pipelines standardised how code is built and released, turning deployments into a fast, repeatable process instead of a series of manual steps. The same logic applies to compliance: once the rules are encoded and automated, teams stop fixing the same issues over and over again.
Using Infrastructure-as-Code to manage containers has set an industry pattern for Security as Code (SaC) and Policy as Code (PaC). These approaches translate security and compliance requirements into machine-readable rulesets that can be versioned, tested and deployed like any other code.
Those rules can be copied and automated, reducing configuration drift through consistent guardrails across environments.
Self-service data compliance
Where does this leave developers? Looking at this as a continuous process, just like deployment, can take some of the pain out of this. Compliance rules don’t tend to change often. Where they do change, the standard templates can be updated and differences in the infrastructure highlighted. More importantly, the consistent, auditable foundation for making changes can be automated, based on getting the underlying approach right from the start.
Percona’s Swift: Continuous compliance aims to standardise how systems are checked against security and data-handling rules.
Continuous compliance aims to standardise how systems are checked against security and data-handling rules. Automated audits can flag drift early, and updates can be applied consistently across environments. This improves reliability and gives organisations clearer visibility and control over how sensitive data is handled.
Building compliance into infrastructure by default reduces the need for developers to constantly revisit the same security or data-management tasks. Rather than responding to constant calls for support around compliance actions or security fixes, developers can get to the root cause of potential issues and fix them once when images are built.
Control across clusters
When base images and platform components enforce encryption, role-based access control (RBAC), backup retention, and audit logging automatically, developers fix an issue once rather than repeatedly. Kubernetes Operators extend this model to stateful systems like databases, providing consistent deployment, failover and governance controls across clusters without custom scripts or per-team variations.
Embedding this mindset into your team, whether you follow DevOps or a more full-scale Platform Engineering mindset, is about putting your team in charge of the requirements, rather than being reactive to them.
Databases, in particular, require non-negotiable rules around access control, data creation, encryption, and backup. Embedding those rules into infrastructure makes compliance the default outcome. The challenge for most organisations is not whether developers should own this work, but rather which team is best positioned for defining and maintaining those guardrails.
Secure-by-design
For developers, adopting that secure-by-design approach doesn’t require them to become compliance experts. Instead, it requires collaboration across security, legal, platform engineering, and architecture teams to define consumable rules that are appropriate for the organisation’s policies.
With these defined, developers get true self-service, and the ability to move quickly with minimal business risk. The result is an organisation that ships faster, stays secure, and maintains consistent governance across all environments.