I’ve lost count of the number of times I’ve heard some version of this: “I know exactly what I want to build. I just can’t get access to the services I need to build it.”
It’s one of the most common friction points in cloud adoption. On one side, you have engineers and architects who are ready to move quickly and understand the platform well enough to deliver real value. On the other, you have an information security team carrying policies that were shaped by a decade of on-premises thinking, trying to apply them to an environment those policies were never designed for. The result is usually one of two things: access so locked down that teams spend weeks raising service requests and waiting for approvals, or frustrated teams finding workarounds and the governance picture quietly getting worse. Both outcomes are failures — one of agility, one of governance — and both are avoidable.
What’s missing is a framework that connects access to demonstrated capability. Not job title, not seniority, and not a request-and-approval queue — but a meaningful, verifiable signal that someone understands what they’re doing in the cloud and the responsibilities that come with it.
That’s the idea behind what I call a Cloud Operator’s Licence.
Pedal Boats, Yachts, and Cruise Ships
I’m a keen sailor, and the maritime world has a tiered approach to licensing that maps remarkably well to cloud access. Bear with me.
The pedal boat. You’ve almost certainly been on one. No licence required, no meaningful training, and the risk is minimal — you’re typically confined to a small lake, the vessel has a top speed of about three knots, and the worst that can happen is a sunburned afternoon. Anyone can operate one, and that’s entirely appropriate given what it is.
The sailing yacht. A different proposition entirely. A yacht skipper needs a qualification and practical experience to back it up. The vessel can cover serious distances, carries a crew depending on the skipper’s judgement, and operates in conditions that change fast. The skipper must know their limits, understand when conditions are safe, and take genuine responsibility for the decisions they make on the water. Experience earns the keys.
The cruise ship captain. Years of training, multiple qualifications, and a track record built across progressively larger vessels. The responsibility is enormous — thousands of passengers, a complex engineering operation, a global range of operating conditions. Nobody hands a cruise ship captain the bridge on the strength of enthusiasm alone.
So why am I telling you this?
Because the same logic applies to cloud access — and it gives us a practical, principled framework for governance that doesn’t feel like a bureaucratic obstacle course.
Here’s what the maritime world gets right that cloud governance so often doesn’t: the requirements are completely transparent. If you want to drive a truck, the licence categories are written down and publicly available. If you want to skipper a yacht, the qualification syllabus is published — you know precisely what you need to study, what experience you need to log, and what the examination will cover. There’s no mystery. There’s no gatekeeping for its own sake. You either have the qualification or you don’t, and if you don’t, you know exactly how to get it.
Most cloud governance models work in exactly the opposite way. Access is controlled, but the criteria are opaque. Engineers raise requests and receive decisions without a clear explanation of what would change the outcome. The information security team becomes, in the eyes of the people it’s trying to protect, a dark tower of ‘no’. That adversarial dynamic makes everyone’s job harder — including the security team’s. A Cloud Operator’s Licence flips it: governance becomes a published standard that people can actively work towards, rather than an invisible barrier they bounce off.
Applying the Model to Cloud
The principle is straightforward: link the level of cloud access someone holds to the level of certification they can demonstrate.
At practitioner level — your pedal boat tier — everyone across the technology function and relevant business partners (finance, governance, procurement) should receive awareness training and ideally achieve practitioner-level certification on your primary cloud platform. This isn’t exclusively for engineers; understanding what the cloud is, how it’s governed, and what responsible use looks like is foundational for anyone involved in decisions around it. Access at this tier might include read-only permissions, sandboxed environments, or a limited set of lower-risk services.
At associate level — your yacht — access expands meaningfully. An engineer holding associate-level certification has demonstrated a real understanding of architecture, security, and the well-architected principles that underpin sound cloud design. They know why you don’t leave a storage bucket publicly accessible, why least-privilege identity management matters, and why cost governance isn’t somebody else’s problem. They’ve earned broader access, and the certification is the signal that they’ve earned it.
At professional or speciality level — your cruise ship captain — you’re talking about administrator roles, production environment access, and the ability to make architectural decisions that affect the entire platform. The people operating at this level should have the deepest training, the broadest experience, and a genuine understanding of both the organisation’s governance frameworks and the platform they’re operating. Earning this level of trust should take time, and it should require evidence.
The number of people certified to professional level in most organisations will naturally be smaller than those at practitioner level. That’s expected and correct. What this model does is create a clear, incentivised pathway — and, crucially, one that everyone can see.
Making It Work in Practice
The concept is straightforward. The implementation requires a little more thought, and the right level of complexity will depend on where you are in your cloud journey.
At its most sophisticated, you can integrate certification verification directly into your service catalogue. I’ve built this using a set of Lambda functions connected to a service management platform — in one case ServiceNow — where an identity and a required certification level are passed in, and a true or false response comes back, calculated against completions recorded in an internal or external LMS, whether that’s a cloud skills assessment, a training course, or a vendor certification. That response directly gates the vending of specific catalogue items. Want an administrator role in a non-production account? The system checks your certification. Want to provision a sandbox environment? It first confirms you’ve completed the relevant awareness training.
This takes the governance decision out of a human approval queue and makes it systematic. It doesn’t replace human judgement — the policies still need to be defined thoughtfully — but it scales in a way that manual approvals never can.
One implementation I’m particularly proud of took this a step further. Rather than relying solely on vendor exam results, I built a cloud skills assessment tool that gave the organisation the ability to run their own contextualised assessments — scored against their specific platform, architecture standards, and governance requirements. That meant the true or false response wasn’t just “did they pass the AWS exam” but “do they understand how we do things here.” For organisations with strong internal standards or bespoke architecture patterns, that distinction matters enormously.
If that level of automation isn’t the right starting point for your organisation, simpler approaches work too. Even a lightweight review process that requires evidence of certification before access is granted is a material improvement on a blanket lockdown. The principle matters more than the tooling at the outset.
What This Actually Achieves
Beyond the governance mechanics, three outcomes from this approach are worth naming.
The first — and the one most often overlooked — is transparency. When the requirements for each access tier are clearly defined and published, people stop guessing and start working towards something concrete. The question shifts from “how do I get access?” — which is often unanswerable in a request-based system — to “here’s what I need to do to earn it.” That’s a fundamentally different relationship between your teams and your governance framework. It turns the information security function from a gatekeeper into something far more useful: a set of standards that motivated people can actively work towards.
The second is that you’re investing in your people in a way that’s visible and meaningful. Many engineers and architects in technology teams haven’t had targeted, relevant cloud training in a long time — if ever. Framing certification as a requirement for expanded access reframes it as a genuine development pathway, not a box-ticking exercise. People respond to that. It builds trust, and trust is currency in any transformation programme.
The third is that you’re creating a shared vocabulary across your teams. When people hold certifications on the same platform and have worked through the same well-architected principles, they’re operating from a common understanding of what “good” looks like — security baselines, architecture patterns, cost discipline. That shared understanding is the foundation of effective governance. It’s significantly harder to build without it, and nearly impossible to maintain at scale without something like it.
Cloud governance doesn’t have to be the thing that slows everyone down. Done well, it’s what gives teams the confidence to move quickly, because the guardrails are understood rather than resented. A Cloud Operator’s Licence is one way to get there — and it’s a model that scales as your people and your platform grow together.
What does your organisation’s approach to cloud access and certification look like? I’d be genuinely curious what’s working, and where the friction still is.
Leave a Reply