Org-wide security tooling has trusted access enabled — Scrivas has begun centralizing security. on track
No delegated administrator is set despite trusted access being enabled for GuardDuty, Security Hub and Inspector. These services are therefore administered directly from the management account. Best practice is to delegate them to a dedicated security/audit account and keep the management account minimal. headline gap
Organization resource policy: none set. Of 44 IAM roles in the management account, all but three are AWS service / service-linked roles. Notable external & federated trusts:
Lazka member account (6 roles): only default service-linked roles + OrganizationAccountAccessRole — no GuardDuty/SecurityHub/Inspector roles, so org security services are not deployed into the member account.
| Severity | Observation | Why it matters |
|---|---|---|
| High | No delegated administrators despite trusted access | Security ops run from the mgmt account; violates multi-account best practice |
| High | Workloads in the management account — EKS, EC2, RDS, VPC flow logs | Blast-radius & separation-of-duties risk; mgmt account should be minimal |
| Medium | Member account not monitored — Lazka lacks security SLRs | Coverage gap; trusted access enabled but not delivered to members |
| Medium | Flat org, no OUs — SCPs enabled but unused for targeting | No policy boundaries; governance won't scale as accounts are added |
| Signal | Compliance stack present — Intruder, Secureframe, Macie, Config, Access Analyzer | Client is actively pursuing compliance — receptive to a landing-zone engagement |