An SCA tool for a large organization needs scoped roles: a small central admin group, delegated admins for each business unit, team members who triage their own findings, and read only auditors. Test that a unit admin cannot see or change another unit's data, and that every change is logged.
Why scoping matters
Dependency findings reveal what software you run and where it is weak. A unit that handles regulated data may not want other units browsing its findings. At the same time, central security needs a global view. One flat admin role cannot do both, so delegation is a core feature, not a nice extra.
The roles most programs need
| Role | Can do | Cannot do |
|---|---|---|
| Org admin | Set org policy, manage units, view all | Nothing blocked, but actions logged |
| Unit admin | Manage teams and repos in a unit, tighten policy | See other units, loosen org policy |
| Team member | Triage and comment on own findings, request exceptions | Change policy, approve own exception |
| Auditor | Read findings, policies and logs | Change anything |
| Service identity | Run scans from CI with a narrow token | Read unrelated projects |
Separation of duties is the detail people forget. The person who requests an exception should not be the one who approves it.
Scenario tests
- Create two units. Log in as an admin of unit A and try to open a repo in unit B.
- As unit admin, try to lower a severity threshold below the org baseline.
- As a team member, approve your own exception request.
- As an auditor, try to edit a policy.
- Generate a CI token for one project and try it on another.
- Remove a person and check that their access and API tokens end together.
Every one of these should fail cleanly with a clear message. Record the result for your evaluation notes.
Identity integration questions
- Does it support single sign on and group based role mapping, so a reorg in your identity provider flows through?
- Can access be revoked from the identity provider alone?
- Are API tokens scoped per project or unit, and do they expire?
- Is there a list of who holds tokens?
Audit trail
Ask for an audit log that records policy changes, exception approvals, role changes and token creation, with actor and time. Check that it can be exported. When an auditor asks who approved a risk acceptance, you should answer from the log in minutes. Related: access review evidence and what auditors look for.
Data boundaries
Some organizations separate units by legal entity or region. Ask where scan results are stored, whether a unit can be placed in its own tenant or region, and how deployment options map to your data handling rules. Keep claims about hosting and residency tied to the vendor's written documentation, not a sales call.
Keep delegation reviewable
Delegation grows messy over time. Schedule a quarterly review of unit admins and service tokens, and remove anyone who has changed roles.
Safeguard includes agent identity and compliance and evidence automation, which help show who did what and when. A free scan at gold.safeguard.sh/scan shows how results are presented before you set up any roles.
Quick check
Do we need a separate tenant per business unit?
Not always. Scoped roles inside one tenant often work. Use separate tenants when legal, regional or contractual boundaries demand it.
Who should approve exceptions?
Someone other than the requester, usually a unit security lead, with the approval and expiry logged.
Last reviewed: 19 October 2026.
