Why these three roles
Most M365 operating-model failures trace to one of two patterns: every decision goes to a central IT team that's too far from the business, or every decision goes to business users who lack the platform context to make consistent choices. The three-role model splits the work into the right slices and gives each role explicit accountability.
| Role | What they own | Where they sit |
|---|---|---|
| Broker | Approving workspace and library requests for their portfolio. Translating business needs into IM-aligned outcomes. | Decision: see below. |
| Site Owner | Day-to-day site management — content organization, navigation, libraries, permissions inside the policy envelope. | Decision: see below. |
| Information Manager | Tenant-wide information model — taxonomy, content types, retention policy, library catalog. Stewardship of the platform. | Almost always centralized. |
Information Manager — the stable role
The Information Manager role is almost always centralized, for one reason: a tenant has one term store, one set of enterprise content types, one retention label catalog, and one library template catalog. Distributing that work creates immediate inconsistency. The Information Manager team maintains the platform's information backbone, so every site that uses standard templates gets the same backbone.
Typical responsibilities:
-
Maintain the enterprise term store and taxonomies.
-
Define and evolve enterprise content types.
-
Curate the library catalog (the set of standardized library templates).
-
Define retention label policy and disposition rules.
-
Approve new templates and major information-model changes.
-
Train and support Brokers and Site Owners on information-management practices.
-
Drive Phase 2 maturity (introducing taxonomy, content types, document sets where they add value).
Site Owner — central or distributed?
Site Owners manage individual sites day-to-day: content organization, navigation, library creation, permissions inside the established policy envelope. Whether they sit in central IT or in business lines is one of the most consequential decisions in an M365 operating model.
| Central IT site owners | Business-line site owners | |
|---|---|---|
| Pros | Stable, consistent, low risk early. Central team has platform expertise. No training required for business users. Easier to enforce standards. | Business knows their content best. Many hands make light work — IT doesn't bottleneck site changes. Empowers departments. Aligns with Microsoft's recommended model. Faster local change. |
| Cons | Creates a bottleneck — every navigation tweak goes through IT. IT lacks business context. Doesn't scale beyond ~50 sites without growing the central team. | Untrained owners create unmanaged sprawl. Governance debt accumulates fast. Inconsistent standards. Drift goes unnoticed without an audit cadence. |
| Best for | Early rollout phases. Highly regulated environments. Organizations with limited business-side capacity for platform work. | Mature deployments. Organizations with engaged business champions. Departments with content-heavy operations and dedicated IM-aware staff. |
| Mitigations | Plan to evolve toward distributed ownership as the platform matures. Build a site-owner training pipeline. | Mandatory training before assignment. Quarterly audit cadence to catch drift. Clear escalation to Information Manager. Limited scope — owners manage content and navigation, not policy. |
Start with central site ownership during initial rollout, especially if business-side capacity for platform work is limited or the organization is new to M365.
Plan to evolve toward distributed ownership within 12–18 months, with a defined training requirement before delegation. Selected business areas — those with engaged champions and content-heavy operations — go first.
Information Manager remains accountable for standards even when site ownership is distributed. The IM team audits site-owner work quarterly and catches drift before it compounds.
Broker — central or distributed?
The Broker role approves new workspace, library, and template requests for a defined portfolio of business areas. The Broker is the gate between 'someone wants a site' and 'a site gets provisioned.' Where this role sits matters because the Broker's job is to apply judgment — to ensure the request fits the broader IA, the business area's content strategy, and the platform policy envelope. Centralized brokers can apply consistency. Distributed brokers can apply context.
| Central brokers (IT/governance team) | Distributed brokers (per business area) | |
|---|---|---|
| Pros | Consistent decision-making across the tenant. Easy to train and onboard. Smaller team to staff. Low coordination cost. | Business-area context informs decisions. Faster turnaround for the business. Brokers know whether 'we need a new site' is genuinely new or a duplicate. Business accountability for the platform. |
| Cons | Lacks business-area context. Can become a bottleneck. Decisions are quick but sometimes wrong because the central team can't tell whether a request makes sense. | Variance in decision quality across business areas. Requires more brokers to train and support. Requires escalation paths when brokers disagree. |
| Best for | Smaller tenants. Organizations early in their M365 journey. Highly regulated environments where consistency matters more than context. | Mature operating models. Larger organizations with distinct business areas. Environments where business areas have engaged information-management capacity. |
| Mitigations | Maintain close link between central brokers and Information Managers. Quarterly broker review of request patterns to catch context gaps. | Onboard brokers with structured training. Maintain a shared decision log so brokers see each other's calls. Regular broker community of practice. |
If the organization is early in its M365 journey, start with central brokers and one or two distributed brokers in pilot business areas to test the model.
If the organization has mature business-area engagement, distributed brokers tend to scale better. The right number is roughly one broker per directorate or major business area, with central brokers as a backstop for areas that haven't designated one yet.
Either way, brokers operate inside a defined policy envelope set by Information Managers. The broker's discretion is in approving requests that fit the envelope, not in changing the envelope.
Day-to-day responsibilities by role
| Activity | Broker | Site Owner | Information Manager |
|---|---|---|---|
| Approve workspace request | ✓ (in their portfolio) | — | Escalation only |
| Approve library request | ✓ (in their portfolio) | — | Escalation only |
| Add a library to an existing site | — | ✓ (from catalog) | — |
| Customize site navigation | — | ✓ | — |
| Manage site permissions (within envelope) | — | ✓ | Audit |
| Define a new content type | — | — | ✓ |
| Approve new library template | Consulted | — | ✓ |
| Drive content cleanup in their site | — | ✓ | Support |
| Decommission a site | ✓ (with IM) | Initiates | Approves |
| Set retention policy | — | — | ✓ (with forum) |
Training requirements
Each role requires structured onboarding before assignment. Training is the lever that makes distributed roles work — without it, distributed ownership becomes governance debt.
-
Broker. Half-day onboarding covering: the IA model, the request flow, what makes a request valid, when to escalate, the decision log.
-
Site Owner. Half-day onboarding covering: site management, permissions inside the envelope, library creation from the catalog, navigation maintenance, when to escalate to the Broker.
-
Information Manager. Multi-day deep-dive on the information model — taxonomy, content types, retention, library catalog. Plus shadowing existing Information Managers.
Kybera Impact provides role-specific tooling: the Broker Portal for request approvals, the IM Portal for information-model management, and the standard SharePoint experience plus the Workspace Requests app for Site Owners. Each role's training material lives in the corresponding folder under training/ — brokers/, information-managers/, and the standup playbooks built for each role.
Stock M365 supports the same operating model — request approvals can run through Power Apps and Power Automate, site ownership is a SharePoint construct, and Information Managers can manage taxonomy through SharePoint Term Store. The work is real: building the request flow, training Brokers on the approval criteria, maintaining a shared decision log. Kybera Impact productizes that work; without it, plan to build and maintain it.
Escalation paths
-
Site Owner question about content placement → Broker.
-
Site Owner question about a permission policy or sensitive content → Information Manager.
-
Broker request that falls outside policy envelope → Information Manager.
-
Information Manager decision affecting platform policy → Governance Forum.
-
Anyone, on a security incident → Security team (out-of-band, not via the operating model).
Discussion Questions
• Are we ready to delegate site ownership to business lines today, or do we need to start central?
• What training does a Site Owner need before they get the keys to a site?
• Where would distributed brokers sit — by directorate, by major business area, by region?
• Is there enough business-side capacity to absorb the Broker role, or do we start with central brokers?
• How many Information Managers do we need? Is there one centralized team, or do we have specialists per content domain?
• What's our audit cadence to catch drift in distributed roles?
• What's the escalation path when a Site Owner and a Broker disagree?
• How do we transition from central ownership to distributed without losing standards?