Choose an account structure with purpose
Separate by environment, business ownership and risk. Place security logging and recovery capabilities where workload administrators cannot alter them. Avoid an explosion of accounts without automation and ownership.
Use naming, tags and mandatory metadata to connect resources to a service, owner, data class and lifecycle. Inventory without ownership is only a list.
- Production and non-production separation
- Dedicated security and log archive boundary
- Shared network or platform services with clear owners
- Automated account vending
Create preventive guardrails
Federate identities and require strong authentication for privileged work. Apply organisation-level policies to block public storage, unmanaged regions, disabled logging and other unacceptable states.
Guardrails should be transparent. Show teams which rule blocked a deployment, why it exists and the approved exception path. Silent policy engines create workarounds.
- No long-lived human access keys
- Restricted public exposure
- Baseline encryption and key policy
- Approved regions and services
Provide shared visibility
Collect control-plane, identity, network and key events into a protected account. Normalise ownership data so findings reach the team that can act.
Expose a simple posture view to product teams. Security should not be the only group able to see misconfiguration. Good platform feedback shortens correction time.
- Central log archive
- Configuration history
- Security finding routing
- Cost and resource anomaly signals
Operate exceptions and change
Every exception needs an owner, reason, compensating control and expiry. Review common exceptions as product feedback: the guardrail may need better documentation or a safer supported pattern.
Test landing-zone changes in representative accounts and communicate breaking changes. The foundation is production infrastructure for every team using it.
- Time-bound exception process
- Versioned policy changes
- Platform reliability measures
- Quarterly architecture review
A practical 30-day field plan
Week one — Organise. Accounts, folders, subscriptions and ownership. Put one accountable owner in the room, agree which business service or decision is in scope, and record the assumptions the team is making. Resist the urge to begin with a technology purchase; the first deliverable is a shared view of the problem and the authority to change it.
Week two — Guard. Identity, policy, network and encryption defaults. Walk through the current process with the people who operate it. Compare the written design with real access paths, data flows, exceptions and on-call practice. Mark every point where an owner is missing or where the team cannot produce evidence that a control works.
Week three — Observe. Inventory, logs, findings and cost signals. Choose a narrow pilot that can be observed safely. Define the expected result, the rollback path and the person who may accept a trade-off. Capture operational friction as product feedback; controls that are difficult to use will eventually be bypassed.
Week four — Evolve. Exceptions, upgrades and developer feedback. Review the pilot with engineering, operations, security and the service owner. Close urgent gaps, assign longer work to a funded backlog and set the next evidence review. The month should end with a repeatable operating rhythm, not a one-time presentation.
Evidence worth keeping
Good evidence is understandable outside the team that created it. Keep a concise record that connects the decision, owner, technical implementation and observed result. Screenshots can support evidence, but configuration, logs, test output and approved records are stronger because another person can reproduce or challenge them.
- Production and non-production separation — owner, current state, last validation and any open exception
- No long-lived human access keys — owner, current state, last validation and any open exception
- Central log archive — owner, current state, last validation and any open exception
- Time-bound exception process — owner, current state, last validation and any open exception
- Decision log showing who approved residual risk and when it will be reviewed
- Test or exercise result with the actual outcome, not only a pass label
Questions for the leadership review
Use these questions to keep the discussion connected to operating risk rather than tool activity. A useful answer names a person, a service and evidence.
- Who is accountable for the cloud foundation outcome when teams disagree about delivery and risk?
- Which critical service or customer promise would be affected by a failure in this area?
- What evidence would tell us the design is working in production today?
- Which exception creates the largest concentration of access, dependency or recovery risk?
- What would the team contain first, and how would it restore a trustworthy service?
- Which improvement can be completed in the next 30 days without waiting for a large programme?
Common questions
Should every workload have its own cloud account?
Often it is useful, but the right boundary depends on scale, automation, ownership and risk. Separate production and high-impact workloads at minimum.
Who owns the landing zone?
A cloud platform team should operate it with security architecture and governance input; responsibilities must be explicit.