When Cloud Becomes the Business, Transparency Becomes the Security Control

Cloud security failures rarely start with a missing tool. More often, they begin with a missing conversation.

That belief sits at the centre of how Dave Osment, a technology leader at Devoteam UK, thinks about cloud leadership, governance, and risk. As cloud platforms become the operational backbone of modern enterprises, Osment argues that security maturity depends less on technology choice and more on how organizations behave when things go wrong.

Osment has spent nearly half his life working in IT, starting with mainframes and green screens and moving through on-premise infrastructure to large-scale cloud platforms built on Amazon Web Services. Across those shifts, one reality has remained constant.

"Things will go wrong. Things are always going to go wrong. You will make mistakes. You will make some quite spectacular mistakes," he says. "Other people will make mistakes. And between you all, you'll break things."

For Osment, the differentiator is not avoiding failure, but how quickly and openly teams respond when it happens.

No-Blame Culture as a Security Control

Osment is direct about the role a company's culture should play in cloud security. In complex environments where configuration errors and automation missteps can have an immediate impact, he sees transparency as a practical safeguard, not a soft leadership ideal.

He summarizes it bluntly. "If you break something and tell someone, I consider it a useful learning exercise. If you break it and tell nobody, I consider you a liability."

The reasoning is operational. Early admission allows rapid remediation and shared learning. Concealment, by contrast, compounds risk. Osment says he has consistently applied this approach with customers, even when it involves public accountability.

"I will quite happily sit in front of a client and say I got it wrong. But this is why they got it wrong and this is how they fixed it," he says. "I've never had an issue where we've lost a client relationship as a result of that."

In his experience, transparency builds trust, particularly with security and risk leaders who understand that zero-failure environments are unrealistic.

Cloud Made IT Visible, and Visibility Changed Accountability

Osment contrasts today's expectations with earlier stages of his career, when IT departments were often physically isolated and culturally opaque. As cloud now underpins everything from identity management to customer-facing services, technology failures translate directly into business disruption.

"IT is a critical component of every business," he says, noting that when systems work well, they fade into the background, but when they fail, the impact is immediate and visible.

That shift has changed how accountability works. Cloud teams must operate in lockstep with the wider business, using metrics that reflect real delivery quality and risk posture. Osment recalls boards demanding KPIs that looked reassuring but bore little resemblance to operational reality.

His response has been to push for measures that show velocity, resilience, and security maturity rather than reporting convenience. For him, governance only works when it reflects how systems actually behave.

Where Organizations Underestimate Cloud Risk

Osment sees two recurring blind spots in cloud risk management.

The first is skills mismatch. Teams strong in traditional on-premise security often underestimate the unique risks introduced by cloud platforms. Even when issues are identified, uncertainty can block action.

"I've noticed this risk here, but because I don't have a firm understanding of the wider ecosystem, I don't want to fix it in case I break something," he says.

The second is risk saturation. Cloud environments generate so many findings that teams struggle to prioritize. "There's so many risks, I don't know where to start. So I won't start anywhere."

His remedy is shared ownership. Developers must be empowered to address vulnerabilities, infrastructure teams need time to fix configuration issues, and the business must accept that security work competes with feature delivery. Without that alignment, risk accumulates quietly.

He points to a simple but telling example. "A customer I worked with a couple of years ago was using a 20-year-old version of a logging package because none of them had thought it was their problem to fix it."

Getting AWS Right Means Starting with Intent

Osment's focus is not on pushing a single cloud blueprint. What works depends on industry, regulation, and business maturity.

"Ultimately, IT needs to be subservient to business, not vice versa," he says. That framing forces conscious trade-offs, because cloud rarely optimizes for cost, performance, scalability, and compliance simultaneously.

One of his earliest questions to customers is why they want to migrate. Trend-driven answers are immediate warning signs. "We want to migrate to save money. Sorry to break it to you folks you're not going to," he says. "Any business that says I want to migrate to the cloud because it's going to save me money is a red flag."

He sees similar risk in AI initiatives driven by board pressure rather than clear outcomes. "I need to implement AI in my product because my board says so."

Automation and Agentic AI Demand Blast-Radius Thinking

Osment supports automation and agentic AI when applied with discipline. His starting point is always impactful.

"When you're looking to automate something, I always take the mindset of what's the worst case scenario if this thing went wrong?" he says.

That question forces leaders to weigh effort, time saved, and business risk together. Low-impact automation can free skilled engineers to focus on higher-value work. High-impact automation without safeguards can amplify failure.

He applies the same logic to agentic AI. Used well, it can remove friction from internal workflows and customer support. Used poorly, it introduces financial, operational, and reputational risk. He also highlights costs that are often ignored.

"There's two elements to cost, There's raw financial cost and there's environmental cost," he says, pointing to the energy and resource footprint of large-scale AI infrastructure.

For customer-facing AI, his advice is pragmatic. "Remember that sometimes your customers do want to speak to a real person." Any AI interface, he contends, should preserve a clear path to human support.

A Quieter Definition of Cloud Maturity

Looking ahead, Osment wants organizations to continue breaking down the "us and them" mindset that once defined IT. Cloud, AI, and automation remain cost centers unless they are aligned with business outcomes and governed realistically.

For security leaders, his message is understated but firm. Mature cloud security is not defined by how many tools are deployed, but by how clearly risk is owned, how quickly issues surface, and how honestly trade-offs are made.

In a cloud-first world, transparency, not opacity, becomes the most reliable control.