EYE AWS Governance

The Governance Challenge

EYE is a cybersecurity firm that had grown rapidly. As the organisation expanded, so did its AWS footprint: multiple accounts, multiple tenants, and an increasingly tangled web of permissions that no single person could fully map or explain.

The problem was not that access was uncontrolled -- it was that the controls had been applied reactively, account by account, without a unifying governance framework. Managing and tracking permissions across multiple accounts and tenants had become a daunting challenge. Each new account meant a new set of ad-hoc IAM policies. Each new team member meant manual permission assignments that were difficult to audit.

For a cybersecurity company, this gap between operational reality and security best practice was not just an inconvenience. It was a credibility risk. EYE needed a robust solution to enhance their permissions management framework before the complexity became unmanageable.

"When your business is cybersecurity, your own cloud governance needs to be exemplary. We could not afford to have permission sprawl in our own infrastructure."

-- EYE Engineering Leadership

Our Approach: AWS Organizations as the Foundation

EYE selected Out.Cloud due to our superior support, insights and resources in public, private, and hybrid cloud services, and our track record of reducing costs by 97% per release and accelerating delivery times by 82% for other clients.

Rather than patching the existing permission model, we recommended rebuilding governance from the ground up using AWS Organizations. This was not about adding more policies on top of existing ones. It was about creating a structural foundation that would make the correct governance posture the default, not the exception.

Our approach focused on four building blocks that together form a complete governance framework:

• Organizational Units (OUs) -- logical groupings that mirror EYE's operational structure
• Service Control Policies (SCPs) -- guardrails applied at the OU level to enforce boundaries
• Permission Sets -- standardised access profiles attached to groups and users
• Account structure -- new accounts placed within OUs for immediate governance inheritance

Permission Architecture

The first phase of the project focused on designing Permission Sets that reflected how EYE's teams actually needed to work. Instead of per-account IAM policies that varied unpredictably, we created a library of standardised Permission Sets:

• AdminAccess -- full administrative capabilities, restricted to platform leads
• ReadOnlyAccess -- audit and review access for compliance and security teams
• SecurityAudit -- elevated read access to CloudTrail, Config and security services
• DeveloperAccess -- scoped write access for engineering teams, limited by service and region

Each Permission Set was attached to groups rather than individual users. This meant that onboarding a new team member required a single group assignment rather than manual policy creation across multiple accounts. The result was faster provisioning, consistent access levels, and a clear audit trail.

SCP Strategy

Service Control Policies are the outermost boundary of what any principal in an account can do. They do not grant access -- they limit the maximum possible access. This distinction is critical, and it is where many governance implementations go wrong.

We designed EYE's SCP strategy around three principles:

• Deny by default at the boundary -- SCPs restricted root account usage, prevented disabling of CloudTrail, and enforced encryption on all data services
• Region locking -- sandbox and development accounts were restricted to approved AWS regions, preventing accidental resource creation in non-compliant jurisdictions
• Progressive trust -- production OUs had the strictest SCPs, while sandbox OUs allowed more flexibility for experimentation within defined limits

The key insight was that SCPs should encode what must never happen rather than trying to enumerate what should happen. This negative permission model is more resilient to change and easier to audit than attempting to whitelist every allowed action.

Organizational Design

The OU structure we designed for EYE reflected both their current operational reality and their anticipated growth trajectory. The hierarchy was deliberate:

Root Organization

At the top level, the AWS Organization acts as the management boundary. The management account holds no workloads -- it exists solely for governance, billing consolidation, and Organization-level administration.

Security OU

This OU contains the Log Archive and Audit accounts. These accounts are locked down with the strictest SCPs: no root access, mandatory CloudTrail, and no ability to modify security baselines. Only the security team has any Permission Sets attached here, and those sets are read-heavy.

Workloads OU

Production and staging environments sit under this OU. SCPs enforce encryption, prevent public S3 bucket creation, and require tagging. Permission Sets here are role-based: developers get scoped write access, operations teams get deployment capabilities, and security teams get audit access.

Sandbox OU

Development and experimentation accounts are placed here. SCPs are more permissive but still enforce region restrictions and spending limits. The SCP LimitRegions ensures no resources are accidentally created in non-approved regions, while a budget alarm prevents runaway costs.

Outcomes

The structured approach delivered measurable improvements across three dimensions:

Best Practices

EYE gained a clearer understanding of best practices for managing accounts and groups within AWS Organizations. The governance model was not just implemented -- it was documented and understood by the team, making it sustainable beyond the engagement.

Improved Security

Security was significantly enhanced by utilizing Permission Sets and SCPs. Root access was denied by policy. Encryption was enforced at the OU level. Every account inherited a baseline security posture from its parent OU, eliminating the inconsistency that comes from per-account configuration.

Faster Management

Creating new accounts and attaching them to newly created OUs allowed more efficient permissions management. What previously required manual IAM policy creation across multiple accounts now happened automatically through OU inheritance. New accounts came pre-configured with the correct SCPs and could be immediately assigned the appropriate Permission Sets.

• New account provisioning: days to minutes (pre-configured via OU inheritance)
• Permission consistency: 100% of accounts now under centralized governance
• Audit readiness: complete visibility into who has access to what, across all accounts
• Security posture: SCPs enforce baseline controls that cannot be overridden by account-level administrators

"The governance model Out.Cloud designed means we no longer have to think about whether a new account is secure. The structure guarantees it. That changes how fast we can grow."

-- EYE Platform Team

What This Means for Your Organisation

The lesson from EYE's project is that cloud governance is not a restriction on speed -- it is a prerequisite for sustainable speed. Without a clear OU structure, SCP strategy, and Permission Set library, every new account and every new team member increases your governance debt.

AWS Organizations is not just a billing feature. When used correctly, it is the foundation of your entire cloud operating model. The OUs define your trust boundaries. The SCPs encode your non-negotiable security controls. The Permission Sets standardize how humans interact with your infrastructure.

EYE now has a governance framework that makes growth safer instead of messier. New accounts inherit the correct posture. New team members get the right access through group membership. And the security team can audit the entire estate through a single, coherent model rather than account-by-account discovery.

That is what cloud governance looks like when it is treated as a platform concern rather than an administrative afterthought.