Business units
A business unit is a slice of your organization, for the people responsible for part of it.
Its job is ownership. A finding scoped to a business unit reaches the team that can fix it; a report scoped to one says something that team can act on. Without them, every list is the whole estate and everyone filters past it.
What they change
| With business units | Without | |
|---|---|---|
| Findings | A team sees its own | Everyone sees everything |
| Access | Can be restricted per unit | Organization-wide |
| Reporting | Per-unit, actionable | One number nobody owns |
| SLA policy | Can be overridden per unit | One policy for all |
That last row is the one people miss. A unit with a stricter regulatory obligation can carry tighter remediation deadlines than the rest of the organization without forcing everyone to the same standard. See Remediation SLA policy.
Modelling them
Model responsibility, not network topology. "Payments Engineering" is a business unit. "10.4.0.0/16" is not - that is a zone, and the two answer different questions.
The test: if a finding appeared on this asset, who would fix it? That team is the business unit. If the answer is "depends what kind of finding", the unit is probably too broad.
Common shapes that work:
- By product or service - the team that owns the thing
- By subsidiary or region - where ownership genuinely divides that way
- By client - for service providers who are not using separate organizations
Shapes that tend not to:
- By environment (production, staging) - that is a tag, not an owner
- By technology (all the Linux boxes) - nobody owns "Linux"
Assigning assets
Assets carry a business unit. Set it as assets are discovered, or in bulk over an existing inventory.
Where an asset's owner follows from something already recorded - a cloud account, a naming convention, a tag - assign by that rather than by hand, so new assets inherit it instead of arriving unowned.
When to introduce them
Not immediately. Business units only pay off once more than one team is acting on findings; before that they add a filtering step with nothing behind it.
Adding them later is straightforward - assets are reassigned, not recreated - so there is no cost to waiting until the need is real.
Business units and roles
A role says what someone can do. A business unit says what they can do it to.
The two combine: an engineer scoped to a unit sees findings on that unit's assets and
not the rest. See
Roles and permissions.
API
The endpoints behind this section are in the API reference.
Next
- Organizations, business units, and zones - how the three scoping layers differ
- Remediation SLA policy - per-unit deadlines
- Reports - per-unit reporting