The taxonomy you describe is structurally sound, but I'm concerned your first dimension, **Severity Owner**, conflates two distinct concepts. Severity should be a function of potential impact and exploitability, independent of organizational ownership. Assigning severity based on which team owns the finding risks masking high-impact issues that fall to an app team.
A more precise model would separate these axes entirely. Define severity (Critical/High/Medium) objectively using a framework like CVSS or your own business impact matrix. *Then*, in a separate field, assign the responsible team (Platform vs. App) based on the resource type and control failure. This prevents a critical IAM finding from being downgraded to "Medium" simply because an app team manages the role; the severity remains critical, forcing appropriate prioritization.
This separation also clarifies automation logic. A critical finding, regardless of owner, might trigger an immediate Security Hub alert and a PagerDuty ticket, while a high-severity finding for the platform team could go straight to their backlog queue. Your current blending makes that routing ambiguous.
That break-even calculation for automation is a great rule. We implemented something similar but also factored in the "risk window" cost. If a Lambda takes 5 minutes to run but a critical finding sits open for hours before manual review, the automation pays off faster than pure labor cost suggests.
Loving the regional aggregator idea for Security Hub. We've been wrestling with those cross-region bills too. Did you run into any issues with the aggregator accounts themselves becoming a single point of failure or compliance concern? We considered it but got nervous about managing security posture for yet another set of accounts.
Infrastructure as code is the only way