Most cloud breaches are not the result of an exotic zero-day. They start with an over-permissioned role, a forgotten access key, or a service account nobody owns. As Australian enterprises push more workloads into AWS and Azure — often both at once — identity has quietly become the real security perimeter. Getting cloud IAM best practices right is now the single highest-leverage thing most organisations can do to reduce risk without slowing delivery.

This guide walks through the practices that matter most for AWS and Azure, with an Australian regulatory lens (APRA CPS 234, the ACSC Essential Eight) and the operational reality of running identity at scale across multiple clouds.

Why cloud IAM is different from on-premises identity

On-premises identity grew up around a network boundary: get inside the firewall and Active Directory largely decided what you could reach. In the cloud that boundary is gone. Every API call to AWS or Azure is authenticated and authorised individually, and a single misconfigured policy can expose storage, compute, or an entire management plane to the public internet.

Two consequences follow. First, the blast radius of a bad permission is larger and faster to exploit. Second, identity is now programmable — which cuts both ways. The same APIs that let an attacker escalate privileges let you codify, review, and continuously test access. The enterprises that win treat IAM as code, not as a console clicking exercise.

Core cloud IAM best practices for AWS and Azure

1. Enforce least privilege — then keep proving it

Least privilege is easy to say and hard to sustain. Permissions accrete: someone needs write access for a migration, it never gets removed, and six months later that role is a liability. The practical discipline is to grant narrowly and review continuously.

• AWS: Use IAM Access Analyzer to generate policies from actual CloudTrail activity, and to flag resources shared outside your account. Prefer permission boundaries and Service Control Policies (SCPs) at the AWS Organizations level to cap what any account can do, regardless of local policy.
• Azure: Lean on built-in Azure RBAC roles before writing custom ones, scope assignments to the narrowest resource group or resource, and use Azure AD (Entra ID) access reviews to expire standing access that is no longer justified.

The goal is not a one-off cleanup but a repeatable loop: grant, monitor real usage, right-size, and re-review on a schedule.

2. Eliminate long-lived credentials

Static access keys are the credential most likely to end up in a public code repository, a laptop, or a CI log. Wherever possible, replace them with short-lived, federated credentials.

• For human access, federate through your identity provider with SSO rather than issuing IAM users. In AWS, IAM Identity Center (formerly AWS SSO) is the default; in Azure, Entra ID already is your directory.
• For workloads, use IAM roles for service accounts, workload identity federation, and Azure managed identities so machines authenticate without a stored secret at all.
• For CI/CD pipelines, use OpenID Connect federation (for example, GitHub Actions to AWS or Azure) instead of storing keys in the pipeline.

3. Make MFA and phishing-resistant auth non-negotiable

Multi-factor authentication on every human identity — especially privileged and break-glass accounts — is the baseline the Essential Eight explicitly calls for. Push beyond SMS and app codes toward phishing-resistant methods (FIDO2 security keys, passkeys) for administrators. In Azure, enforce this with Conditional Access; in AWS, require MFA in your identity provider and through IAM policy conditions for sensitive actions.

4. Separate privileged access from everyday access

Administrators should not carry standing high-privilege rights. Just-in-time elevation limits the window an attacker can abuse. Azure AD Privileged Identity Management (PIM) lets you grant time-bound, approval-gated activation of privileged roles; on AWS, achieve the equivalent with temporary role assumption, session policies, and approval workflows. This is where cloud IAM and dedicated privileged access controls meet — a topic we cover in depth in our guide to privileged access management.

5. Centralise identity across both clouds

Running AWS and Azure with two disconnected identity stores doubles the places a joiner-mover-leaver process can fail. Federate both to a single authoritative identity provider so that deprovisioning one account removes access everywhere. This is also the foundation for consistent logging, consistent policy, and a single access review rather than several.

6. Log everything and actually watch it

Enable AWS CloudTrail across all regions and accounts, and Azure AD sign-in and audit logs, then ship them to a central store you monitor. The signal that matters most: unusual privilege escalation, new access key creation, disabled logging, and sign-ins from unexpected locations. Detection is not optional — CPS 234 expects APRA-regulated entities to detect and respond to information security incidents in a timely way, and identity logs are where the earliest signals appear.

Governance: the practice that ties it together

Tooling gets you started; governance keeps you safe. Every access grant should trace back to a role or a request, every privileged account should have a named owner, and every quarter you should be able to answer “who can touch production, and why?” without a fire drill. This is the domain of identity governance — automated joiner-mover-leaver, periodic certification, and segregation-of-duties enforcement. For regulated Australian organisations, we explore this further in identity governance and administration for regulated industries.

Cloud IAM done well is not a product you buy once. It is an operating model: least privilege enforced as code, credentials that expire by default, privileged access granted just in time, and a governance layer that continuously proves the whole thing is still true.

Meeting Australian regulatory expectations

For AU enterprises, two frameworks anchor the conversation. APRA CPS 234 requires regulated entities to maintain information security capability proportionate to threats, to clearly define information security roles and responsibilities, and to test controls — identity controls very much included. The ACSC Essential Eight calls out MFA and restricting administrative privileges as core mitigations. Mature cloud IAM is, in practice, how you satisfy large parts of both. Building the evidence trail as you go — access reviews, logs, policy-as-code history — turns your next audit from a scramble into an export.

Where to start

If you are early in the journey, sequence it: federate identity to a single provider, enforce MFA everywhere, kill long-lived keys, then layer on least-privilege tuning and just-in-time privileged access. If you are further along, the highest-value move is usually continuous verification — turning point-in-time cleanups into automated reviews and policy-as-code guardrails.

Delivery Centric helps Australian and APAC enterprises design and operate cloud IAM across AWS and Azure — from identity federation and least-privilege architecture to privileged access and governance that stands up to APRA scrutiny. If you are scaling identity across multiple clouds and want it done once, properly, talk to our team. We are also growing our identity and cloud practice if you would rather build this from the inside.

Build vs Buy: A Practical Guide to Adopting Agentic AI in Your Enterprise

Almost every enterprise leader has now seen what agentic AI can do — software agents that plan a sequence of steps, call the systems they need, and carry a piece of work to completion with a human in the loop where it matters. The harder question isn’t whether to adopt it, but how. The enterprise AI build vs buy decision — build an agentic capability in-house, buy a packaged product, or partner to deliver something in between — will shape your cost, your speed to value, and how much control you keep over a technology that touches your core processes.

This guide breaks the decision down the way we approach it with clients across Australia and APAC: not as a religious debate, but as a set of trade-offs you can reason about against a specific business problem.

Start with the problem, not the platform

The most expensive agentic AI programmes are the ones that start with a tool and go looking for a use case. Before you weigh build against buy, get specific about the problem you’re solving and what “good” looks like:

• What manual or slow process is costing you? Claims handling, invoice matching, customer onboarding, IT support triage, procurement approvals — name the workflow and roughly what it costs in hours or delay.
• Which systems does the work touch? An agent is only as useful as the systems it can act on. A workflow that spans a legacy core, a CRM and three spreadsheets is a very different build than one that lives inside a single SaaS product.
• What’s the tolerance for error? A drafting assistant that a human always reviews carries far less risk than an agent that moves money or updates a system of record autonomously.

Once the problem is concrete, the build-versus-buy trade-offs become much easier to see, because you’re comparing options against a real target rather than a demo.

The enterprise AI build vs buy trade-offs

Buy: packaged and embedded agents

“Buy” usually means one of two things: a standalone agentic product, or agentic features embedded in software you already run (your ERP, service desk, CRM or contact-centre platform). The appeal is obvious — speed and a lower barrier to entry. You get a supported product, a roadmap someone else funds, and you avoid standing up AI and platform engineering talent you may not have.

Buying works best when the problem is common and well understood — summarising documents, drafting responses, answering questions over a knowledge base, or automating a workflow that sits neatly inside one vendor’s ecosystem. The limits show up when your process is differentiated, spans multiple systems the vendor doesn’t reach, or when your data and IP are the very things that make the capability valuable. You also inherit the vendor’s pace, pricing model and guardrails, and switching later can be difficult if you want to move.

Build: a bespoke agentic capability

“Build” means assembling your own solution on foundation models and an orchestration framework, integrated with your systems and governed by your own controls. It costs more up front and demands real engineering discipline — but it’s the right call when the workflow is a competitive differentiator, when agents must reach across systems no single product covers, or when data residency, sovereignty and control are non-negotiable.

The mistake teams make is assuming “build” means building the model. It almost never does. You’re building the orchestration, the integrations, the evaluation harness and the guardrails around commercially available models. That’s a systems-integration and software-engineering problem far more than a data-science one — which is good news, because it’s a discipline most enterprises can resource or partner for.

Partner: the pragmatic middle

In practice, most enterprises land in the middle: buy the commodity layers (foundation models, vector stores, cloud infrastructure) and build the thin, high-value layer that’s specific to your business — the orchestration logic, the integrations and the guardrails. A delivery partner can stand this up quickly, transfer the capability to your team, and avoid the two classic failure modes: a shelfware product that never fits, or an over-engineered in-house platform that takes a year to reach production. Our Agentic AI practice is built around exactly this pattern — accelerating the build where it matters while reusing everything that’s already a commodity.

A decision framework you can actually use

When we help clients make the call, five factors do most of the work:

1. Differentiation. Is this workflow a source of competitive advantage, or just table stakes? Differentiators lean build; commodities lean buy.
2. Integration depth. The more systems an agent must read from and act on — especially legacy ones — the more a packaged product will struggle, and the more a bespoke build earns its cost.
3. Data sensitivity and sovereignty. Regulated data, strict residency requirements, or IP you can’t hand to a third party push you toward build or a tightly controlled private deployment.
4. Time to value. If you need a result this quarter and the problem is common, buy or embed. If the payoff is large and durable, a build pays back.
5. Total cost over three years. Compare per-seat or per-transaction licensing at scale against a one-off build plus run costs. Buy is cheaper to start and can get expensive at volume; build is the reverse.

No single factor decides it. But scoring a specific workflow against all five turns a vague “should we build or buy?” into a defensible recommendation — and often reveals that different parts of the same programme want different answers.

What good adoption looks like, whichever way you go

The build-versus-buy choice matters less than the discipline you bring to it. The enterprises getting real value from agentic AI tend to do the same handful of things:

• Start narrow and prove it. One workflow, a clear baseline, and a measurable outcome beats a broad “AI transformation” every time.
• Keep a human in the loop where it counts. Match the level of autonomy to the cost of a mistake, and earn more autonomy as evidence accumulates.
• Instrument everything. Log what agents do, evaluate quality continuously, and make it easy to intervene. Governance and guardrails aren’t a bolt-on — they’re what makes production adoption safe.
• Plan for the run, not just the launch. Models change, data drifts and processes evolve. Someone has to own the capability after go-live.

Cloud foundations matter here too: agentic workloads need scalable, well-governed infrastructure to run reliably and cost-effectively, which is why adoption and cloud strategy tend to move together.

Making the call

There’s no universal answer to enterprise AI build vs buy — only the right answer for a specific problem, weighed against differentiation, integration depth, data sensitivity, time to value and cost at scale. Buy the commodity, build the difference, and bring engineering discipline to whichever path you take. For Australian and APAC enterprises in particular, keeping data control and integration with legacy systems front of mind often tilts the balance toward a bespoke or hybrid build — done pragmatically, not from scratch.

If you’re weighing the options for a specific workflow, Delivery Centric can help you score it and stand up a working pilot quickly. Explore our Agentic AI capabilities, read how these ideas play out in a regulated setting in Agentic AI in Banking, or join the team building it.

Identity Governance and Administration (IGA) in Regulated Industries

Identity governance has moved from a back-office housekeeping task to a board-level obligation for Australian enterprises in banking, insurance, health and government. Regulators now expect organisations to prove — not just assert — that the right people have the right access to the right systems, and that every entitlement can be traced, justified and revoked. For regulated industries, a mature identity governance and administration (IGA) programme is the difference between passing an audit cleanly and scrambling to explain why a departed contractor still had access to a production database six months later.

This guide explains what IGA actually delivers, why regulated sectors in Australia and across APAC face particular pressure, and how to build a programme that satisfies auditors without grinding the business to a halt.

What identity governance and administration actually covers

IGA is the discipline of managing digital identities and their access rights across their entire lifecycle — from the day someone joins to the day they leave, and every role change in between. It sits above the day-to-day mechanics of authentication and single sign-on, answering a harder set of questions:

• Who has access to what, and can you produce that answer on demand?
• Should they still have it? Access granted for a project two years ago rarely gets cleaned up on its own.
• Who approved it, and is that approval recorded in a way an auditor will accept?
• Are risky combinations blocked? Separation-of-duties conflicts — such as one person both raising and approving a payment — need to be detected before they become a fraud finding.

A working IGA capability typically combines automated joiner-mover-leaver provisioning, periodic access certifications (or “recertifications”), role-based access models, segregation-of-duties controls, and a complete audit trail. Done well, it reduces the standing access that attackers exploit and shrinks the manual review burden that quietly consumes IT and risk teams.

IGA vs IAM vs PAM — where the lines sit

These acronyms overlap and get used loosely. Identity and access management (IAM) is the broad umbrella covering authentication and access. Privileged access management (PAM) focuses specifically on high-risk administrative accounts. IGA is the governance layer that decides and evidences who should have access in the first place. Most regulated enterprises need all three working together. If you’re untangling the first two, our explainer on IAM vs PAM is a useful companion read.

Why regulated industries in Australia feel the pressure

Regulated sectors carry obligations that make weak identity governance genuinely expensive. In Australian financial services, APRA’s CPS 234 requires regulated entities to maintain information security capabilities commensurate with the threats they face — and access management is a recurring theme in the control expectations and in post-incident reviews. Health and government bodies handling sensitive personal information sit under the Privacy Act and, increasingly, sector-specific data-handling rules. Across APAC, comparable regimes apply: Singapore’s MAS Technology Risk Management guidelines and New Zealand’s evolving privacy expectations push in the same direction.

The common thread is evidence. It is no longer enough to have a policy that says access is reviewed. Auditors want to see the review happened, on a defined cadence, with named approvers and documented outcomes. Organisations that manage certifications in spreadsheets typically discover — usually mid-audit — that the evidence is incomplete, stale, or impossible to reconcile against the live directory.

The cost of “access sprawl”

In large enterprises, entitlements accumulate faster than anyone removes them. People change roles and keep old access “just in case”. Contractors onboard quickly and offboard slowly. Service accounts multiply. The result is access sprawl: a growing population of standing privileges that expands the attack surface and makes every certification cycle more painful. Regulated industries feel this acutely because the systems in question — core banking, policy administration, patient records — are exactly the ones regulators scrutinise.

Building an IGA programme that auditors trust

A durable identity governance capability in a regulated Australian enterprise usually comes together in stages rather than a single big-bang rollout.

1. Establish an authoritative source of identity

Governance is only as good as the data underneath it. The HR system (for employees) and a contractor register (for non-employees) should drive identity lifecycle events. When a leaver is marked terminated in HR, downstream access should be revoked automatically — not left to a manual ticket that may never be raised.

2. Automate joiner-mover-leaver provisioning

Automated provisioning removes the two biggest sources of audit findings: access that is granted too broadly on day one, and access that lingers after departure or role change. Birthright access tied to role, with everything beyond that requested and approved, gives you both speed and control.

3. Model access with roles — but stay pragmatic

Role-based access control makes certifications tractable, because reviewers approve a coherent role rather than hundreds of individual entitlements. The trap is over-engineering the role model until it becomes unmaintainable. Start with high-value, high-population roles, and accept that some access will always be handled as exceptions.

4. Run risk-based access certifications

Certifying everything on the same cycle wastes reviewer attention on low-risk access and rushes the review of dangerous access. Prioritise privileged accounts, access to regulated data, and separation-of-duties-sensitive entitlements for more frequent, more careful review. Rubber-stamping is the enemy — a certification that approves 100% of access in seconds is a finding waiting to happen.

5. Capture the evidence automatically

Every grant, approval, certification decision and revocation should be logged in a form you can hand to an auditor without a week of preparation. This is where a purpose-built IGA platform earns its keep over manual processes.

Common pitfalls to avoid

• Treating IGA as a tooling project. The technology is the easy part. The hard part is defining roles, owners and approval workflows with the business — which is where most programmes stall.
• Boiling the ocean. Attempting to onboard every application at once usually collapses under its own weight. Sequence by risk and regulatory exposure.
• Ignoring non-human identities. Service accounts, API keys and automation credentials often outnumber human users and are frequently the least governed.
• Certification fatigue. If reviewers are drowning, they rubber-stamp. Reduce the volume with better role models and risk-based scoping so the reviews that matter get real attention.

Where Delivery Centric fits

Delivery Centric helps Australian and APAC enterprises design and deliver identity governance programmes that stand up to regulatory scrutiny — from establishing authoritative identity sources and automating the joiner-mover-leaver lifecycle, to building role models and risk-based certification processes that satisfy APRA, MAS and privacy obligations without exhausting the business. Our consultants work across banking, insurance, health and government, and pair governance design with the wider identity and cyber security services that regulated organisations depend on. For teams weighing regulatory readiness specifically, our APRA CPS 234 compliance checklist is a practical starting point.

If you’re scaling an identity practice and want to work on this kind of engagement, we’re hiring — see our careers page.

Ready to strengthen your identity governance? Talk to Delivery Centric about an IGA assessment tailored to your regulatory environment — we’ll map where your access risk really sits and give you a sequenced roadmap to close it. Get in touch to start the conversation.