Securing Data Platforms with DevSecOps: Why Communication Between Teams is Critical

Wednesday, 25 February 2026

Securing Data Platforms with DevSecOps: Why Communication Between Teams is Critical

Ryan HUNT

Data Engineering Practice Lead

Internet safety and protection concept with glowing digital lock

The Importance of Data & Infrastructure

Common Pitfalls

Scenario Comparisons

Final Thoughts

DevSecOps embeds security into every stage of the software and increasingly, data platform development lifecycle. Yet the value of this investment can be difficult to quantify. Security rarely delivers visible wins; instead, it prevents losses: the breach that didn’t occur, the fine that wasn’t issued, or the reputational damage that never materialised.

With regulatory pressure increasing and headlines dominated by data breaches and software supply‑chain vulnerabilities, many organisations feel they must simply accept higher levels of risk. The truth? With the right collaboration, they don’t have to.

This article explores how data engineering, analytics, and data science teams can partner effectively with infrastructure teams to apply DevSecOps principles. The foundation of all of this is clear, consistent communication.

The Importance of Data & Infrastructure

Collaboration In most large organisations, data and infrastructure teams operate separately - and for good reason. It is neither efficient nor realistic for a single group to manage operational data needs and security posture implementation. Roles such as Data Engineer, DevOps Engineer, and Network Engineer exist because their responsibilities intentionally differ.

One truth we’ve observed repeatedly: when data and infrastructure teams build strong relationships, cloud security outcomes improve dramatically. Key practices include:

Regular, high‑quality interaction: more than a ticket system
Shared roadmap planning: deploying the right infrastructure first time reduces drift
Clear communication of change: without visibility of what’s been modified, untracked resource updates can easily be overwritten or lost during the next deployment.

Two Common Pitfalls and How Communication Avoids Them

1: Over‑Scoping Permissions (Principle of Least Privilege)

Over‑scoped identities often arise when responsibilities between Infrastructure‑as‑Code (IaC) and downstream teams are unclear. This typically happens when downstream teams self‑configure resources, infrastructure teams grant all‑access identities due to pressure, or privileges are not reviewed.

For example, a CI/CD environment might be granted full control over a database or Databricks workspace. This enables delivery but also allows destructive or inappropriate actions - such as dropping databases or accessing sensitive catalogues.

To avoid this:

Define IaC boundaries clearly: agree who manages what
Set permission boundaries aligned to roles: and establish how privileged operations are governed
Design defensively: if a pipeline can drop a database, assume the risk must be mitigated

Over-scoping is especially risky when identities can grant or modify permissions themselves. Expanding access should be a deliberate governance decision—not an unintended side effect of enabling development. scoping is especially risky when identities can grant or modify permissions themselves. Expanding access should be a deliberate governance decision - not an unintended side effect of enabling development.

2: Limit Credential Proliferation

A related challenge is the creation of unnecessary credentials. Earlier, we discussed roles and identities, but when infrastructure and data teams lack shared context, access requests are often fulfilled in the least efficient way. This can lead to the creation of new service accounts or principals, assignment of additional RBAC roles, and distribution of new keys - all of which introduce avoidable operational and security risks.

Every new credential assumes that the recipient can store it securely, manage its lifecycle, and ensure timely rotation. In reality, these assumptions often fail.

In modern cloud architectures, this pattern is rarely needed. Most platforms support managed, system assigned identities, allowing resources to authenticate securely without manually created secrets. Using these built-in, nonperson identities reduce risk, eliminates credential sprawl, and provides more predictable governance.

Scenario Comparisons

Bad Example

A data engineer requests read access to an Azure SQL database via ticketing. Without context, a SQL login is created unnecessarily.

Transparent umbrella under rain against water drops splash background

Good Example

In a regular conversation, the data engineer explains the use case. The infrastructure colleague recommends granting the Azure Data Factory managed identity access - no secrets, no manual credentials.

Silhouette friends jump and birds fly on sunset sky at top of mountain abstract background.

Final Thoughts

Security is strengthened by teams who understand each other’s context. Clear communication ensures secure, efficient DevSecOps practices.

If your organisation is struggling to balance developer productivity with secure infrastructure, Talan Data & AI can help. We specialise in modernising data platforms, strengthening governance, and embedding DevSecOps best practices.

Book a consultation today to discuss how we can support your journey

Securing Data Platforms with DevSecOps: Why Communication Between Teams is Critical

The Importance of Data & Infrastructure

Two Common Pitfalls and How Communication Avoids Them

1: Over‑Scoping Permissions (Principle of Least Privilege)

2: Limit Credential Proliferation

Scenario Comparisons

Bad Example

Good Example

Final Thoughts

Contact Us