Organizations, business units, and zones
Three things scope data in the CyberOptix CTEM Platform, and they are easy to confuse because all three sound like ways of grouping assets. They are not interchangeable - each answers a different question:
| Layer | Answers | Determines |
|---|---|---|
| Organization | Whose data is this? | Isolation |
| Business unit | Who is responsible for it? | Access and reporting |
| Zone | Where is it, and who scans it? | Scanning |
Get these right early. They are the difference between a findings queue people act on and one they filter past.
Organization
The outermost boundary. Assets, findings, users, integrations, and settings all belong to exactly one organization, and nothing crosses between them.
If you are a service provider, you have one per client. If you are a single business, you almost certainly want exactly one - resist the urge to model departments as separate organizations, because that is what business units are for and separate organizations cannot report together.
Switching organizations changes everything on screen. Until you have selected one, most pages have nothing to show.
Business unit
A business unit is a slice of one 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 actually fix it, and a report scoped to one says something that team can act on rather than burying them in the whole estate.
Business units are how you get:
- Access control. A user can be restricted to their own business unit's assets and findings.
- Reporting that means something. Per-unit reports and SLA tracking, rather than one organization-wide number nobody owns.
- A queue people trust. The fastest way to make a findings list ignored is to show everyone everything.
Model them on responsibility, not on network topology. "Payments Engineering" is a business unit; "10.4.0.0/16" is not - that is a zone.
See Business units for setting them up.
Zone
A zone is a scanning scope. It holds the subnets and URLs to test, the scanner group that will do the testing, and the schedule it runs on.
A zone answers a question business units cannot: what can reach this, and from where? Two assets owned by the same team can sit in completely different network positions, and a scanner in the DMZ cannot test an internal subnet no matter who owns it.
A zone carries:
| Component | Purpose |
|---|---|
| Subnets | Network ranges to scan, in CIDR |
| URLs | Web applications to test |
| Scanner group | Which scanners do the work |
| Scan schedules | How often each scan type runs |
| Nmap parameters | How aggressively to probe |
| Blackout windows | When not to scan |
The scanner group is assigned to the zone, not to the assets. That indirection is what lets you replace a scanner without touching scope, and lets one scanner group serve several zones.
See Zones, subnets, URLs, and tags for configuration, and Scanner groups and tasks for the scanning side.
How they combine
They are independent axes, not a hierarchy. One asset has one organization, may belong to a business unit, and may sit in one or more zones.
That independence is the useful part. "Critical findings, in Payments Engineering, on internet-facing assets" crosses all three - severity, business unit, zone - and none of them alone would have answered it.
Zones are required to scan anything, so you will build them first regardless.
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.
Tags
Where the three layers are structural, tags are free-form. Use them for anything
that cuts across: production, pci-scope, owner:platform-team, decommission-q3.
Tags are the right tool when you catch yourself wanting a business unit that is not really about ownership, or a zone that is not really about network position.
Next
- Assets - what these layers scope
- Findings, severity, and risk - why scope matters more than severity alone
- Zones, subnets, URLs, and tags - configuring scope