Access

The Access module is the governance oversight layer for access across your organization. It is not the system that grants, revokes, or enforces access; those are your identity provider, your cloud IAM, your application RBAC, your network access systems. Access governance is the layer above those systems that tracks who should have what, who approved it, what the providers say currently exists, when it was last reviewed, and where the gaps are.

This distinction matters. A regulator asking “show me your access governance” doesn’t want to see your IAM admin console; they want to see your governed register of access entitlements, the review campaigns that periodically recertify them, the privileged-access records with their authorization trail, and the separation-of-duties detection that catches conflicts.

When you would reach for this

You set up access governance when:

A regulator or framework expects periodic access reviews (“recertification campaigns”) with documented outcomes.
Privileged accounts need to be inventoried separately with stricter oversight (admin accounts, service accounts, emergency access).
Service accounts, process accounts, third-party accounts, and external-identity accounts need governance distinct from human users.
Separation-of-duties rules need to be defined and conflicts need to be detected.
Access provider snapshots (from IAM, cloud accounts, source systems) need to be imported and compared against approved posture.
Access-related findings, violations, or risk signals need to be linked into your governance program.

You don’t reach for this for actual access enforcement (that’s the source systems and Novantra’s own RBAC, membership, and resource-access). Access governance is the oversight, not the enforcement.

What lives in access governance

A composite set of record types:

Access entitlement is the inventory item: “Alice has admin role on the customer-data system.” Entitlements are imported from provider snapshots (the source system’s IAM exports its current state) and represent approved posture (this entitlement exists because it was requested and approved).

Access request is the governed request: someone proposes new access, an approver signs off, the actual grant is then made in the source system. The governed record is the audit trail of the request and decision.

Access review campaign is a periodic recertification cycle. Each campaign picks a set of entitlements and routes each one to a reviewer to confirm “yes, this should still exist” or “no, revoke it.”

Access review item is one entitlement-reviewer pairing inside a campaign. Each item has a status (pending, confirmed, revoke-requested, escalated) and the reviewer’s decision rationale.

Privileged access record captures privileged accounts (admin, root, break-glass) with stricter oversight: who has it, why, when it expires, what the emergency-use audit trail looks like.

Access provider snapshot captures what the source system says exists at a point in time. The snapshot is compared against approved entitlements to detect drift.

Separation-of-duties rule defines a constraint (“no one should be able to both create and approve their own purchase requisitions”) and the system surfaces detected conflicts.

A worked example: a public-utility operator governs access across operational technology and corporate IT

A public-utility operator runs both operational technology systems (controlling generation and distribution) and corporate IT systems (customer billing, employee data, supplier portal). Access to OT systems is strictly governed for safety and regulatory reasons; access to corporate IT systems has its own SOX-style controls. Their access governance lead, Camilo, sets up Access like this.

Step 1: ingest provider snapshots. Camilo’s team configures imports from each significant access provider:

The OT system’s IAM (nightly snapshot of all named accounts and roles).
The corporate IdP (daily snapshot of user-to-group membership).
The cloud account’s IAM (daily snapshot of cloud roles and policy bindings).
The supplier portal’s access list.

Each provider snapshot lands as a record in Access; entitlements are derived from the snapshot.

Step 2: privileged access records. Camilo lists every account that has privileged access (OT-system admin, cloud account-owner role, root accounts, emergency break-glass accounts). Each gets a privileged-access record with:

The account identity.
The provider (which system it’s on).
The justification.
The reviewer cadence.
The emergency-use SOP if applicable.

Privileged accounts get tighter review (monthly) than standard accounts (annual).

Step 3: separation-of-duties rules. Camilo defines rules like:

“No one should be able to both initiate and approve an OT-system change request.”
“No one should be able to both create and approve their own purchase requisition.”
“Read-only audit access cannot also hold administrative access on the same system.”

The system runs these rules against the imported entitlements and surfaces detected conflicts as findings.

Step 4: quarterly access review campaigns. Each quarter, Camilo launches campaigns. A campaign picks a slice of the entitlement universe (e.g., “all corporate IT privileged accounts”) and routes each entitlement to its named reviewer. Reviewers receive their queue, work through each item, and decide confirm or revoke. Revoke decisions create findings that route to the IAM team for action in the source system.

Step 5: drift detection. Between campaigns, when a provider snapshot shows an entitlement that was never approved (an account added directly in the source system without governance), the system surfaces it as a finding. The IAM team either retroactively governs it (request + approve flow) or removes it.

Step 6: incidents and break-glass. When an emergency requires use of a break-glass account, the operator records the use through the privileged-access record with timestamp, rationale, and any incident reference. The record creates a finding that requires review within a defined SLA.

After a year:

The access register is a governed inventory across every important access provider.
The campaign history shows every entitlement was reviewed in the last cycle.
Privileged access usage has an audit-grade trail.
SoD conflicts are surfaced and tracked through findings.
The regulator sees not just current state but the discipline behind it.

What you’ll see in the product

Access lives under Governance → Access in the workspace.

Multiple top-level tabs: Entitlements, Requests, Review Campaigns, Privileged, Provider Snapshots, SoD Rules.

The Entitlements list is the inventory: filter by provider, account type, current posture, last review.

The Requests list shows pending and historical access requests with approver state.

Review Campaigns is where you launch and manage recertification cycles. Inside a campaign, you see every item, its reviewer, its current decision state, and the campaign’s overall progress.

Privileged shows the privileged-access register with use logs.

Provider Snapshots shows the import history per provider and the deltas detected against governed posture.

SoD Rules is the rule list and the active conflicts currently flagged.

Every change is captured in the workspace Audit Log.

What this module does not do

Be clear about boundaries:

It does not grant or revoke access in source systems. That action happens in the source system; the governance record captures the request, approval, and the eventual confirmation when the source system reports the change.
It does not replace Novantra’s own RBAC, membership, or resource-access. Those are runtime authorization systems for the Novantra application itself; access governance is the oversight layer above them, just as it sits above external IAM systems.
It does not ingest raw provider logs. Snapshots are point-in-time state, not event streams. Event-driven detection (e.g., real-time anomaly detection) lives elsewhere.

Common workflows

Standing up access governance

Identify the access providers you want to govern (start with the most regulator-sensitive).
Configure snapshot imports per provider.
Inventory privileged accounts and create privileged-access records.
Define separation-of-duties rules that matter for your business.
Schedule the first review campaigns.

Running a quarterly recertification campaign

Access → Review Campaigns → New campaign. Pick the entitlement scope and the reviewer assignment.
Launch; reviewers receive their queues.
As reviewers decide, the campaign’s overall progress updates.
Revoke decisions create findings; those route to the IAM team to action in the source system.
Close the campaign when all items have decisions.
Export the campaign record for the audit committee.

Handling drift between snapshots

A new provider snapshot detects an entitlement that wasn’t in the governed register.
The drift is surfaced as a finding.
The team either retroactively requests/approves the entitlement (formalizing it) or removes it from the source system.
The finding closes when the gap is reconciled.

Recording break-glass use

From the relevant privileged-access record, record the emergency use.
Capture timestamp, rationale, incident reference.
The finding that’s automatically created walks the standard review flow.

Findings - access drift and SoD conflicts create findings.
Risks - access misuse can become a risk.
Evidence - review campaign outcomes are evidence.
Assessments - access-related controls are assessed.
Workspace administration → Members & Invitations - Novantra’s own member access lives separately from this oversight module.