A police evidence vault AWS account must deny broad access from outside a dedicated security organizational unit. Which Organizations design supports that containment?

A police evidence vault AWS account should sit in a dedicated security organizational unit with Service Control Policies that deny unwanted access paths and privilege escalation. The OU placement signals that the account is high sensitivity; SCPs can block leaving the organization, disable creation of open resource policies where inappropriate, deny use of root access keys, restrict which principals may be trusted for AssumeRole, and prevent disabling of security services. That locked-wing design keeps sandbox developers and general workload admins from casually reaching evidence objects.

Leaving the vault in a general sandbox OU with no SCPs invites experimentation controls that are too weak for evidence. Placing the vault in the management account and granting all OUs AdministratorAccess centralizes crown jewels next to org-wide power and widens access. Deleting Organizations and relying on public bucket policies for evidence objects is the opposite of containment.

Exam caveat: management account should not host workloads; use a delegated security/audit account for tooling. SCPs are preventive maximums—they do not replace KMS policies, Object Lock, or tightly scoped IAM on the vault bucket. Operational check: confirm the account is under the security OU; attempt a denied action (for example disable GuardDuty or attach AdministratorAccess) from a vault admin and expect SCP denial; verify cross-OU roles into the vault are minimal and MFA-conditioned; ensure evidence buckets are private with Object Lock where legally required.