Perimeters
A perimeter is an optional scope refinement inside a domain. Where a domain decides who can see the work and how numbers roll up, a perimeter says what exactly is being assessed — a product, a system, a business process, a contract. Audits and risk assessments can be attached to one, so a single domain can run several distinct assessment scopes side by side without spinning up extra access-control machinery.
Where to find it
Section titled “Where to find it”Organization → Perimeters in the sidebar.
Key concepts
Section titled “Key concepts”Optional everywhere
Section titled “Optional everywhere”Perimeters are never mandatory. An audit or risk assessment created without one is simply scoped to its domain. Reach for a perimeter when either of these is true:
- You need to assess the same framework several times inside one domain against genuinely different scopes.
- You want to report by scope — “how compliant is the payments platform” — rather than by business unit.
Fields
Section titled “Fields”| Field | What it does |
|---|---|
| Reference ID | Your own identifier, shown as the first column and searchable |
| Name | What the scope is called |
| Description | What is in and out of scope — worth filling in properly |
| Domain | The domain this perimeter belongs to; it cannot float free |
| Status | Where the perimeter sits in its lifecycle |
| Default assignee | Who work created inside this perimeter falls to by default |
Status
Section titled “Status”The lifecycle Status is a planning signal rather than a permission: Undefined, Design, Development, Production, EndOfLife and Dropped. New perimeters start at Design. Keeping it current is what lets you filter the list down to what is actually live, and it tells reviewers whether an assessment covers a system in production or one still being built.
Default assignee
Section titled “Default assignee”Setting a Default assignee on a perimeter saves repetitive work later: the named actor becomes the presumed owner for work raised inside that scope, so a product team’s perimeter routes to that team without anyone remembering to set it each time.
Working with perimeters
Section titled “Working with perimeters”Use Add perimeter to create one. Give it a reference ID and a name, pick the Domain it sits under, and write a description that states the boundary explicitly — a perimeter whose scope is ambiguous produces audits nobody trusts.
The list supports search across name and domain, plus filters by domain and status. The optional columns add Status, Created at and Updated at when you need to see how stale a scope has become.
Opening a perimeter shows what has accumulated inside it — the audits and risk assessments pointing at it, and the compliance picture they produce.
How many perimeters?
Section titled “How many perimeters?”The common mistake is creating a perimeter for everything. Each one splits your assessments, and splitting too finely means a lot of near-identical audits and no single number anyone can quote. A workable rule:
- One perimeter per system or product that is certified, audited or contracted separately.
- No perimeter at all when the whole domain is the scope.
- A new perimeter instead of a new domain whenever everyone who sees one scope should also see the other.
Related
Section titled “Related”- Domains — the access-control boundary a perimeter lives inside.
- Audits — the main consumer of perimeters.
- Risk assessments — scoped the same way.