Risk Management secured record access framework

Redwood Platform

Use the updated security framework to control who can view and work with secured Risk Management records.

  • Risk Administrators can create records for IT business processes and have Can Assign and Edit eligibility and authorization for existing records. They also receive Security Checkup notifications.
  • Risk Power Users can create records and have Can Assign and Edit eligibility for all record types.
  • Risk Users have Can Assign and Edit eligibility for all record types but can't create records.

Use the Stakeholders section on supported record pages to view authorized people and participant groups, review assigned authorizations, and share access. Authorized users can invite, remove, replace, or update stakeholders for one or more records. Updates affecting multiple records run as a mass security modification job, and you can review the outcome.

The seeded All Employees participant group provides default list-page visibility for Oracle Managed Content records. Eligible users can view record names and short descriptions, then request access when they need to work with a record. Stakeholders with Assign and Edit authorization can remove this group when default visibility is not appropriate.

Request additional access from supported record pages. Requests are sent to stakeholders with Assign and Edit authorization for review. For the complete request, analysis, review, approval, and status-tracking workflow, see the Submit and manage Advanced Access Requests feature in this What's New.

Business benefit

Manage record visibility, collaboration, and access governance consistently across Risk Management while retaining auditability and clear ownership of security decisions.

Steps to enable and configure

  1. Assign the Risk Administrator role directly, or inherit it through the IT Security Manager job role.
  2. Assign the Risk Power User role to users who create and manage records.
  3. Assign the Risk User role to users who work with records but do not create them.

Tips and considerations

  • Use the delivered Risk Management job roles. Custom roles can prevent Risk Management from working as intended.
  • Each secured record must have at least one eligible stakeholder with Assign and Edit authorization.
  • Users with only view access can share a record only as View Only.
  • To ensure users can view related record information across Risk Management, include All Employees as a stakeholder on all object type records.
  • The All Employees group is not editable or displayed in the Participant Groups list; it is available when adding a participant group as a stakeholder.
  • Mass sharing and stakeholder updates for more than one record run as background jobs. Review the job outcome for completed and unsuccessful updates.

Access requirements

Security access is granted through the Risk Administrator, Risk Power User, and Risk User roles, together with stakeholder authorizations assigned during implementation.

Job Role Name Job Technical Name
Risk Administrator ORA_GTG_RISK_ADMINISTRATOR_JOB
Risk Power User ORA_GTG_RISK_POWER_USER_JOB
Risk User ORA_GTG_RISK_USER_JOB

Risk Administrator role is also inherited through the IT Security Manager job role (ORA_FND_IT_SECURITY_MANAGER_JOB).