For years, the conversation around automation and modern data platforms has followed a familiar pattern: as tooling becomes more capable, the need for hands-on database administration (DBA) declines. For straightforward workloads, this assumption often holds. Provisioning is faster, maintenance is abstracted, and many operational tasks are handled by the platform itself – or by scripts and managed services.
In regulated environments - such as financial institutions and payment systems - the picture is more nuanced. Here, the role of the DBA has not diminished, but evolved in response to growing expectations around accountability, control, and resilience.
Where automation is in place - in the cloud or in a modernized on-premise estate - it has reduced the manual effort associated with infrastructure management. Tasks like patching, scaling, and provisioning are increasingly handled by tooling. But whether that effort is automated or still carried by hand, responsibility for data integrity, recoverability, and compliance has not decreased.
What has changed is the focus of the role - from maintaining systems to ensuring they are reliable, auditable, and prepared for failure.
From operations to accountability
Wherever the database runs, the real challenge moves beyond keeping systems running. It centers on whether those systems can be trusted under real conditions.
In practice, most environments, cloud and on-premise alike, follow a similar pattern. Infrastructure is well-configured, but assurance is uneven. Backups exist, yet are rarely tested end-to-end. Disaster recovery plans are defined, but not executed under pressure. Data moves between environments without consistent control or traceability. This is where responsibility concentrates.
Configuration sets the baseline - but it does not ensure outcomes. Systems may be operational, yet still fall short when recovery, auditability, or compliance are required. The role around the database evolves accordingly - from executing tasks to validating that critical processes actually work.
The assurance gap
There is a consistent gap between enabling capabilities and being ready to rely on them.
Features such as replication, standby databases, and automated backups create a sense of completeness. But their presence does not ensure successful recovery or regulatory alignment. A standby database does not guarantee failover. A backup policy does not ensure recoverability. Environment refreshes without masking introduce immediate compliance risk. In financial systems, this is not theoretical. This is where risk accumulates.
Closing this gap requires more than configuration. It depends on continuous validation, clear ownership, and the ability to demonstrate that systems behave as expected under stress - not just in normal operation.
Regulation at the core
Frameworks such as DORA, NIS2, PCI-DSS, and GDPR have brought the database layer into scope. Organizations must not only operate securely, but continuously demonstrate control. Recovery must be tested, access must be traceable, data handling must be consistent.
The division of responsibility is explicit. In the cloud, infrastructure is managed by the provider; on-premise, the organization owns the full stack. Either way, data, access, and recoverability remain the organization’s responsibility.
The go-live reality
The difference between configuration and readiness often becomes visible at go-live. From a delivery perspective, systems appear complete. Databases are running, backups are configured, and services are live. But operational readiness depends on what has been verified - not what has been set up.
We see this consistently. Backups have not been restored in realistic scenarios. Disaster recovery exists as documentation rather than practice. Ownership of controls is unclear or inconsistently applied across environments. At this stage, stability depends on assumption. That is where exposure begins.
Ensuring readiness means validating recovery paths, enforcing controls, and confirming that systems can operate under failure conditions - not just during normal operation.
Sirma’s perspective
Sirma operates in the layer between what is configured and what is proven – across cloud, on-premise, and hybrid estates.
Our approach is built around making control demonstrable. We validate backup and recovery processes through regular, scenario-based testing. We implement and enforce access controls with full audit trails, ensuring that every action is traceable. Data movement between environments is governed, with masking and policy enforcement aligned to GDPR requirements. This is not treated as a one-time setup. It is an ongoing operational model.
We work with organizations to define clear ownership, establish repeatable processes, and ensure that critical scenarios - such as failover and recovery - are tested under realistic conditions. Operational practices are aligned with frameworks like DORA, NIS2, and PCI-DSS, so that compliance is embedded in how systems run.
The result is an environment where systems are not only operational, but controlled, validated, and auditable. In this context, the database role evolves into a control function - one that determines whether systems are truly reliable under pressure.
Conclusion
Modern platforms - in the cloud and on-premise alike - have simplified how databases are run, but they have not simplified what organizations are accountable for. The focus has shifted, from maintaining systems to proving that those systems can withstand failure, meet regulatory expectations, and remain under control at all times. This is where the real value now sits. The question is no longer whether a database is running. It is whether recovery has been proven, access is fully traceable, and data handling is consistently governed across environments. Because in regulated systems, reliability is not defined by uptime alone. It is defined by evidence. And the role behind the database is no longer operational support. It is the function that ensures control is proven - before it is questioned.
