Appearance
Requirements Register
Where to find it: Regulatory Compliance, then Requirements (/requirements).
The Requirements register is the working surface of the compliance function. It flattens every requirement across every framework in your library into one list, so a compliance officer can see the whole obligation estate at once.
What the register contains
One row per requirement, across every framework. The columns are:
| Column | Contents |
|---|---|
| Ref | The framework clause reference |
| Requirement | Title and framework |
| Owner | The governed owner, and their acceptance state |
| Status | Where the obligation is in its demonstration workflow |
| Compliance | The current compliance display, with its source |
| Flags | Health factors needing attention |
| Actions | Open the workspace, assign an owner, edit metadata |
Columns can be resized by dragging the separators, and your layout persists between sessions. Reset columns restores the default.
Tabs
| Tab | Shows |
|---|---|
| All | Every requirement |
| Unassigned | Requirements with no accepted or offered owner |
| Needs attention | Requirements carrying health flags |
| With obligations | Requirements that have decomposed obligation activities |
Tabs are applied on the server, so the counts reflect the whole estate rather than the current page.
Ownership
Ownership in OrviQ is an offer and acceptance handshake, not an assignment you can impose silently.
| Owner state | Display | Meaning |
|---|---|---|
| Accepted | The owner's name | The person has accepted accountability |
| Offered | Amber, "awaiting acceptance" | An offer is outstanding |
| Unassigned | Muted | Nobody has been offered ownership |
Use Assign owner to make an offer. The offeree accepts or declines through their Workbench. Requires users.assign_owner or work.assign; accepting requires ownership.accept.
Why the handshake matters
An owner who never agreed to own something is not an owner in any sense a regulator would accept. The acceptance step turns an administrative field into an accountability record with a timestamp.
Status: the demonstration workflow
The Status column shows where the requirement sits in its compliance demonstration lifecycle.
| Status | Meaning |
|---|---|
| Not started | No demonstration work has begun |
| In progress | The owner is assembling the compliance position |
| Submitted | Submitted for first-line review |
| L1 approved | First-line review passed |
| Compliance review | With the compliance function for validation |
| Approved | The demonstration has been approved |
This is a workflow status. It describes the progress of the work, not the compliance outcome. A requirement can be Approved in workflow terms and Partially Complied in compliance terms — that combination means the organisation has completed and signed off an honest assessment that identifies a gap.
Compliance display
The Compliance column shows the current compliance position and, alongside it, where that position came from.
| Value | Meaning |
|---|---|
| Complied | The obligation is met |
| Partially Complied | Genuine but incomplete compliance |
| Not Complied | The obligation is not met |
| Accepted Risk | A governed acceptance or exception covers the deviation |
| Awaiting Evidence | Waiting for supporting evidence |
| Awaiting Review | Evidence present, awaiting human review |
| In Progress | Assessment underway |
| Invalidated | A previous position has been invalidated |
| Not Applicable | Governed out of scope |
| Not Started | No assessment begun |
| Not assessed | Shown where no determination exists at all |
Each value carries its source:
| Source | Meaning |
|---|---|
| Final | A final governed determination |
| Human review | A human reviewer's recorded position |
| AI recommendation | An advisory AI suggestion, not authoritative |
| Derived | Computed by the assurance engine from evidence and controls |
An AI recommendation is not a determination
Where the source reads AI recommendation, the value is advisory. It has not been adopted by a person and carries no governance authority. Treat it as a prompt to review, never as a position you can report.
For the underlying five-dimension model that produces derived positions, see Compliance Determination.
Flags
Flags surface health factors on a requirement — evidence gaps, overdue activities, ownership problems, staleness. The Needs attention tab filters to rows carrying them.
Flags are diagnostic. They are not a compliance verdict and never change one.
Working the register
Search filters across reference and title.
Sort by clicking a column header. Sorting is applied on the server across the whole estate, not just the visible page — so sorting by owner or status gives you the true top of the list, not the top of page one.
Paginate at 10, 25, 50 or 100 rows. The register loads only the page you are looking at.
Why there is no "All" page size
Loading twenty thousand requirements into a browser to look at the first fifteen is slow for you and expensive for everyone else on the tenant. Use search, tabs and sorting to bring what you need to the top instead.
Common tasks
Open a requirement workspace
Select the requirement. The workspace shows the source text, mapped controls, evidence, obligations, assurance posture, history and comments in one place.
Assign an owner
Use Assign owner on the row, choose the person or team, and send the offer. The offeree sees it in their Workbench.
Review a requirement's assurance posture
Open the workspace and go to assurance, or use Requirement Assurance for the multi-framework cockpit view.
Find everything unowned
Use the Unassigned tab. This is the first thing to run after adopting a new framework.
Edit requirement metadata
Use the edit action. Note that ownership is deliberately not edited here — it goes through the offer-and-accept flow.
Permissions
| Action | Permission |
|---|---|
| View requirements | obligations.read |
| Update obligation responses | obligations.update |
| Assign owners | obligations.assign or work.assign |
| Accept an ownership offer | ownership.accept |
| Review submitted obligations | obligations.review |
| Validate compliance | compliance.validate |
| Final compliance approval | compliance.mark_complied |
Example
A bank adopts a national cyber assurance framework containing 264 requirements.
Immediately after adoption the register shows: 264 requirements, all Not started, all Unassigned, all Not assessed. That is the correct and honest starting picture — adoption created obligations, not compliance.
Over the first quarter the Compliance Manager works the Unassigned tab down to zero by making ownership offers by department. Owners accept, and status begins moving to In progress.
By quarter end the register shows a mixed and truthful picture: 91 Approved with Complied, 44 Compliance review, 78 In progress, 51 still Not started — and 12 Partially Complied with flags identifying specific evidence coverage gaps.
No number in that picture was inferred. Each came from a person doing work that is on the record.
Troubleshooting
"Every requirement shows Unassigned." No ownership offers have been made, or offers were made but not accepted. Check the Owner column for amber "offered" states.
"Compliance shows Not assessed everywhere." There are no determinations yet. Requirements need mapped controls and evaluated evidence, or direct evidence assertions, before a position can be derived. See Compliance Determination.
"Sorting seems to change which rows I see." That is correct — sorting reorders the whole estate on the server, so page one changes. It is not filtering anything out.
"A requirement shows Approved but Not Complied." Those are different axes. The demonstration workflow is complete and approved; the compliance outcome it approved is a gap. This is a legitimate and common state.
"Requirements is not visible." Requires the compliance core entitlement.