This looks like a beginner question and is not. It is the decision that determines how painful everything else becomes, and the damage from getting it wrong takes about two years to become obvious and considerably longer to undo.
The distinction
- Organisational units carry settings and policy. A user sits in exactly one, and settings flow down the tree. This is how you say "contractors cannot install Marketplace apps" or "this department gets a shorter session length".
- Groups carry access and permissions. A user can sit in many. This is how you say "these people can open the finance shared drive".
The reason it matters: an organisational unit is a single-parent hierarchy, and access in a real company is not hierarchical. Someone in engineering may need access to a finance tool. If access lives in the tree, you cannot express that without either moving them, which changes their policy, or duplicating branches, which is where it starts to rot.
Designing the tree
Shape it by policy, not by the org chart. The temptation is to mirror departments because that is the diagram everybody has. Ask instead: what genuinely needs different settings. Often that is three or four groupings, such as standard staff, contractors, shared and service accounts, and admins, not the twenty branches the org chart suggests.
Keep it shallow. Every level is somewhere a setting can be overridden and then forgotten. Deep trees are how you end up debugging why one team has a policy nobody remembers setting.
Put access in groups from day one, and derive group membership from attributes such as department or location rather than maintaining lists by hand. Then a mover event recalculates membership automatically instead of relying on somebody to remember.
Separate service and shared accounts into their own unit. They need different rules, they routinely break blanket policies such as 2SV enforcement, and having them scattered across the tree is how the enforcement gap you did not know about gets found by somebody else.
Group settings are a security control
Groups are usually treated as mailing lists, which is how the interesting failures happen. Once a group grants access to anything, its own settings matter:
- Who can join group. Self-service join on an access-granting group is an open door.
- Who can post. A group accepting external mail is a phishing path straight into an internal distribution list.
- Allow members outside your organization. This decides whether company mail can leave through a membership nobody reviews.
- Who can view members. A reconnaissance question more than an access one.
Be accurate about the starting point, because "the defaults are wide open" is a claim that does not survive contact with the console. A newly created group is reasonable: joining is restricted to people in the organisation, and external members are not allowed. The problem is not the default, it is the drift. Somebody opens a group up for a legitimate reason on a Tuesday, the reason expires, the setting does not, and nobody looks again. So the discipline is not a one-off hardening pass. It is knowing which groups carry access, and putting exactly those back under review on a cycle.
Where it goes wrong
Using an organisational unit to grant access. The original sin. It works for the first case and then forces every subsequent exception into a structural change.
Mirroring the org chart. Reorganisations then become IT projects, because the tree has to be rebuilt every time the business moves a team.
Manually maintained group membership. It is correct on the day it is created and drifts from then on. Derive it or review it, but do not assume it.
Groups that quietly became access. A mailing list gets used to share a drive, and now a list anyone can join is a permission anyone can take. Audit which groups grant access and lock those down specifically.
The short version
Organisational units are policy and are hierarchical, groups are access and are not. Shape the tree by what needs different settings rather than by the org chart, keep it shallow, derive group membership from a source of truth, and treat any group that grants access as a security control with its own join and post settings.