Groups

Groups are the building blocks of our identity and access model. Every group follows the prv-{team}-{type}-{qualifier} naming pattern and falls into one of several categories based on its purpose.

Group Categories

Category	Purpose	Grants Access?
People rosters	Track who is in a lifecycle state (active, offboarded, etc.)	No
Identity rosters	Track non-human accounts (service accounts, bots)	No
Departments	Durable organizational units that own budget and policy	Indirectly (via nesting)
Teams	Day-to-day collaboration units where individuals belong	Indirectly (via nesting)
Roles	Grant specific permissions to specific systems	Yes
Automation accounts	Bot and service account identifiers	No (helper groups)

The Access Model

Understanding the group hierarchy is critical:

1. People are placed in People rosters based on their lifecycle state (OU placement).
2. People join Teams based on their function.
3. Teams nest into exactly one Department.
4. Roles grant access to systems and are assigned to individuals (not teams or departments).

People rosters   →  "who exists and in what state"
Teams            →  "who works together day-to-day"
Departments      →  "who shares budget/policy scope"
Roles            →  "who can do what in which system"

Key rule: Privileges flow only through Role groups. Teams and Departments organize people — they don’t directly grant system access.

Security vs Non-Security Groups

Every group is labeled as either Security or Non-security:

• Security ON: Groups that are used on ACLs, drive permissions, or system access grants. This includes Departments, Teams, and Roles.
• Security OFF: Groups used for communication, routing, or roster tracking. This includes People rosters, Identity rosters, Mail, Intake, Alerts, and Infra pipes.

Warning: The Security label is irreversible in Google Workspace. If you enable it and later need it off, you must recreate the group.

Ownership Rules

Every group must have at least two owners from durable admin cohorts. Typical owners:

• prv-plt-team-wks (Platform — Workspace team)
• prv-sec-team-grc (Security — GRC team)

Single-owner groups are a compliance risk. Automation should flag any group with fewer than two owners.

Display Name Format

All groups use name-first with en dash format:

PRV – {Type} – {Department} – {Specifics}

Examples:

• PRV – Department – Engineering
• PRV – Team – Platform Engineering – Workspace
• PRV – Role – PLT – AWS – IDC – PRD – Admin

Description Format

Descriptions start with the exact display name, followed by a colon, then structured metadata:

{Name}: {purpose} | {audience} | {usage notes} | {trailer}

The trailer is mandatory and must be one of:

• Security group ({concise purpose})
• Non-security group ({concise purpose})
• Optionally add: Locked group ({reason})

Pages in This Section

• People & Identity — Dynamic rosters by lifecycle state
• Departments — Durable organizational units
• Teams — Day-to-day collaboration groups
• Roles & Permissions — System access grants
• Automation Accounts — Bots, jobs, and integrations