We’re experiencing a critical permission issue after our recent user role restructuring. System administrators who previously had full access to the risk management module can no longer edit risk categories in the risk matrix interface.
The problem appeared immediately after we updated our role-based access control settings last week. Admins can view the risk matrix and see all categories, but when they try to modify category definitions or thresholds, they get a “Permission Denied” error. This is blocking our quarterly risk assessment updates.
I’ve verified the admin role still has “Risk Management - Full Access” enabled in the permissions panel. The backend audit logs show the save attempts are being rejected at the system level, but I can’t identify which specific permission flag is missing. Other modules like CAPA and Document Control work fine with the same admin accounts.
Has anyone encountered similar permission inheritance issues with risk matrix configurations? The delay is impacting our compliance timeline.
Adding to Rachel’s point - if you need to bypass this temporarily for urgent updates, there’s usually an “Emergency Override” permission in the Change Control settings that allows designated super admins to make critical system changes without workflow approval. Use cautiously and document in your quality system, but it might help you meet your compliance deadline while you properly configure the workflow rules.
James, that workflow_approval_required flag is the smoking gun. Check your Change Control module settings. In qual-2022.2, there’s a feature where you can require change approval workflows for system configuration modifications, including risk matrix structural changes. Go to Change Control > Configuration > System Change Rules and see if “Risk Matrix Structure Changes” is listed as requiring approval workflow. If it is, your admins would need to initiate a change request first, even with full permissions. This was added for 21 CFR Part 11 compliance environments where all system config changes need documented approval.
I’ve seen this exact behavior before. Check if the “Risk Matrix Configuration” permission is enabled separately from the general “Risk Management - Full Access” setting. In qual-2022.2, they split the matrix editing permissions into a distinct flag that doesn’t automatically inherit from the module-level permission. Navigate to Admin Console > User Roles > [Your Admin Role] > Risk Management section and look for a checkbox specifically labeled “Edit Risk Matrix Structure” or similar. It’s easy to miss during role updates.
Thanks both. I checked the granular permissions and found “Edit Risk Matrix Structure” was indeed unchecked. However, even after enabling it and forcing a session refresh, the issue persists. Marcus, I pulled the access audit logs and found something interesting: the rejection happens at “risk_category_definition_update” level, and the log mentions “workflow_approval_required” flag. Could this be related to a change approval workflow that got inadvertently linked to risk matrix changes?
Sarah’s on the right track. Also worth checking the audit trail for your admin users specifically. Go to System Logs > Access Audit and filter by username and “risk_matrix” actions. You might find the logs show which exact permission check is failing. In our environment, we discovered the issue was actually related to organizational unit restrictions that were inadvertently applied during a bulk role update. The admins had module access but not OU-level access to modify certain risk categories that were tied to specific departments.
I want to expand on this systematically since it touches on all three core aspects of your permission architecture.
Role-Based Access Control Analysis:
Your issue stems from the layered permission model in qual-2022.2. The “Risk Management - Full Access” module permission is necessary but not sufficient. You need three permission levels active: (1) Module-level access to Risk Management, (2) Feature-level “Edit Risk Matrix Structure” permission, and (3) Action-level permissions for risk category modifications. Review Admin Console > User Roles > Permissions Matrix and ensure all three layers show green checkmarks for your admin role.
Risk Matrix UI Permissions Deep Dive:
The UI permission denial you’re seeing is actually a backend validation failure that manifests in the interface. The risk matrix editing interface performs a pre-flight permission check before allowing any modifications. When Rachel mentioned the workflow_approval_required flag, that’s triggering a fourth permission layer you weren’t aware of. Navigate to Risk Management > Settings > Matrix Configuration Governance and check the “Governance Mode” setting. If it’s set to “Controlled” or “Validated”, all structural changes require change control workflow completion. Set it to “Standard” for direct admin editing, or configure your admins with “Change Initiator” and “Change Approver” roles if you want to maintain the governance controls.
Admin Backend Audit Resolution:
Your audit logs showing “risk_category_definition_update” rejections are valuable forensic data. Export the full audit trail for the past two weeks (System Logs > Access Audit > Export) and filter for event_type=“permission_denied”. Cross-reference the denied_permission field values against your current admin role configuration. You’ll likely find 2-3 specific permission flags that are missing. The most common culprits in this scenario are: “risk.matrix.structure.modify”, “risk.category.definition.update”, and “system.config.change.execute”. Add these explicitly to your admin role definition.
Immediate Fix:
Go to Admin Console > User Roles > System Administrator > Risk Management section. Enable these specific permissions: “Edit Risk Matrix Structure”, “Modify Risk Categories”, “Update Category Definitions”. Then go to Change Control > Configuration > System Change Rules and either disable “Require approval for risk matrix changes” or add your admins to the “Emergency Change Executors” group. Finally, have your admins log out completely and log back in to refresh their permission cache. This should restore full editing capability while maintaining your audit trail compliance.
Test with a non-production risk category first to verify the permissions are properly resolved before proceeding with your quarterly assessment updates.