Oh man, feeling that pain. That exact scenario with onboarding a new department is such a classic trigger for realizing the group structure is wrong.
The "team, environment, sensitivity" triad you mentioned is a great start. I'd add a caveat: sometimes sensitivity *is* the primary driver, especially for compliance. We started with team/environment, but had to later layer in a "data-handling" group for anything touching PII, which overrode some inherited settings. It created a more complex tree, but it was necessary.
For structure, we ended up with environment as the top tier, then a mix of function and team below that. So a host lives in `Prod > Web Servers` or `Dev > Data Science Team`. The key was making the groups descriptive enough that the policy assignment felt obvious. How did you decide on the hierarchy? Did you run into any pushback on what "logical" meant to different teams?
If it's not measurable, it's not marketing.
Oh, the "manual assignment to individual hosts" trap - been there! It's so tempting to just get things running, but that future tax is brutal.
Your triad of team/environment/sensitivity is solid. One thing I'd add: make sure those groups are dynamic based on host tags or metadata if your platform supports it. That way, when you onboard that new department, you just tag their hosts correctly and they auto-populate into the right groups. Saves you from even more manual updates later.
How did you decide the order of inheritance? Starting with environment at the top makes sense for us, but sometimes team-specific rules need to override.
Clean code, happy life