Continuous access governance
across cloud and SaaS.
Qwalora Governance compares the access your organization approved with the access that actually exists in your identity, cloud and SaaS systems, turns the differences into prioritized findings, and routes every change through approval with evidence recorded along the way.
Built for the teams who answer for access.
IT operations
Administrators running Microsoft Entra ID, Microsoft 365, Okta and cloud subscriptions who need to find access that outlived its purpose, without writing scripts for every review.
Security
Security teams who need to see privileged, orphaned and stale access in one place, and who want remediation to follow a controlled, approved path.
Compliance and audit
Compliance owners who need records of what was found, who approved the response and what changed, produced as the work happens rather than reconstructed later.
Actual access drifts away from approved access.
Access is granted for a reason and rarely removed when the reason ends. People change roles, contractors finish, groups are reused, licenses are assigned and forgotten, and administrative roles accumulate. Each change is small. Together they leave a gap between what was approved and what is actually in place.
Periodic reviews find some of it, months later, in spreadsheets. Qwalora Governance treats the gap as something to measure continuously and close through a governed process.
From discovery to evidence, in one governed loop.
Connectors read identities, group memberships, role assignments and licenses from connected systems.
Observed access is compared with the access your policies and approvals say should exist.
Differences become findings, ranked so the riskiest access is reviewed first.
Remediation plans go to a named approver and run only once approved.
Approvals, actions and results are written to the audit trail and evidence packages.
See what exists, next to what was approved.
Qwalora Governance collects access data through connectors that use each provider's own administrative APIs, then evaluates it against policy. Coverage differs by system and by capability, so we publish it per connector rather than as a single claim.
- Users, groups, role assignments and license assignments, where the connector supports them
- Stale, orphaned and expiring access identified against defined policy
- Per-connector coverage published on the integrations page
A short list of what matters first.
Each difference between approved and actual access becomes a finding with an owner, a severity and a history. Findings stay open until they are resolved through the workflow, accepted with a recorded reason, or shown to be resolved by a later observation.
Changes happen only after someone approves them.
Remediation plans are proposed, reviewed and approved before they run. Approvers can approve, reject, delegate or ask for more information, and a person cannot approve their own plan.
- Every change to a connected system needs an approval for that exact change
- Approvals come from someone other than the requester, expire, and can be used once
- Which connectors support approved changes is stated per connector on the integrations page
Records produced as the work happens.
Requests, approvals and actions are recorded in an audit trail and assembled into evidence packages. Packages are signed with a key held by the service and can be checked for alteration inside the product. Automated re-checks of the target system after a change are in development.
A signature or hash shows whether a stored record has changed since it was produced. It does not by itself prevent deletion, and a signature made with a service-held key cannot be checked independently by a third party, so we describe these limits on the security page.
Clear about where it runs and what it reaches.
Qwalora Governance is a hosted application. Cloud and SaaS connectors call provider APIs from the Qwalora Governance service using credentials you grant and can revoke. For systems that cannot be reached from the internet, a Linux edge agent runs inside your network.
- Edge agents initiate all connections outbound over TLS; no inbound firewall rules are required
- Runs on Linux with Node.js 18 or later and performs read-only collection: host inventory and evidence; it does not make changes
- Restricted networks with outbound access are supported; fully disconnected operation is not offered at this time
How an evaluation works.
We start with your systems, not a slide deck. Before anything connects, we confirm in writing which connectors and capabilities apply to your environment.
We review the systems you want governed and the questions you need answered.
You receive the connectors, capabilities and permissions the evaluation will use.
Read-only discovery first. Any write action requires your approver and a test target.
We walk through the findings and evidence with your team and agree next steps.