Roles & Permissions

Role Overview

Every user in SecureCodingHub is assigned one of three roles:

Permissions Matrix

The following table shows which permissions are available to each role:

Changing Roles

Org Admins can promote learners to Org Admin or demote org admins back to Learner within their organization. Role changes take effect immediately.

The Platform Admin role can only be assigned at the platform level and is not available through the organization admin panel.

Best Practices

Choosing roles for your org

Role design inside a training platform feels lower-stakes than role design inside production systems, and that is exactly why it tends to be done carelessly. The training platform holds data about who knows what, which teams are weakest on which topics, and which engineers have completed mandatory compliance training. That data is sensitive in its own right — both as competitive information and as evidence in audit conversations — and the role model should reflect that.

Org Admin versus delegating to team leads

The temptation in growing organizations is to make every engineering manager an Org Admin so they can manage their own teams without filing tickets. The cost of that pattern shows up later. Org Admins can view every team's data, not just their own, which means a manager can see how a peer's team is performing without that peer's knowledge. They can also reassign users between teams, change deadlines on assignments they did not create, and modify SSO configuration. For most organizations, two or three Org Admins is the right ceiling — typically the head of engineering or AppSec plus one or two designated administrators.

For day-to-day team-level operations, the better pattern is to keep team leads as Learners and give them the dashboard filter for their team. They get the visibility they need without the configuration power they do not. If a team lead needs to create an assignment for their team, the Org Admin can do it in a couple of minutes — far cheaper than the long-term cost of granting standing administrative access to a wider group than necessary.

Least privilege and audit logging

The principle of least privilege applies inside the training platform just as it does anywhere else. Every additional Org Admin is one more credential whose compromise lets an attacker read your training data, modify your SCIM configuration, or quietly grant their own external account admin access. Practical least privilege here means defaulting new hires to Learner, promoting only when the operational need is clear, and demoting promptly when someone changes role.

Role changes and significant administrative actions are recorded with timestamps and actor identity for the same reason that production systems log privileged actions. When something goes wrong — a user is removed who should not have been, an assignment is changed days before an audit, a team is deleted by mistake — the audit log is the artifact that lets you reconstruct what happened. Keep that in mind when granting admin rights, since the audit trail will eventually be read by someone, and a small admin roster makes the log readable. For details on managing the people inside these roles, see Managing Users.