Skip to main content

Sub-Organizations

Sub-organizations allow parent organizations to create isolated groups within their account — useful for managing multiple teams, clients, or business units under a single subscription.

Availability

Sub-organizations are available on Tier 3 plans only.

Overview​

  • Sub-organizations share the parent organization's scan quota and LOC limits
  • Each sub-org can have its own members, repository submissions, BYOK key, and branding logo
  • Vendor-review policy follows the parent by default, while parent administrators can delegate a custom bundle to the child or retain parent-only control of child-specific settings
  • Parent org admins have full visibility and control over all sub-orgs
  • Members of the parent organization can see repositories submitted for all sub-organizations
  • Sub-org-only members can only see repositories and data belonging to their sub-org

Operational Capabilities and Roles​

A sub-organization operates as its own organization for vendor reviews and software analyses. Its parent manages the shared account, subscription, billing, quotas, and governance controls.

Your role is evaluated in the organization that owns each resource, using the same permissions as a standalone organization:

RoleSoftware and vendor review workSettings
AdminCreate, edit, review, and make decisionsView and manage authorized settings and members
MemberCreate, edit, review, and make decisionsNo access
Read-only AdminView onlyView authorized settings only
Read-only MemberView onlyNo access

Vendor work includes creating vendors, starting and retrying reviews, editing questions, recording responses, updating findings, and public research. Settings access is enforced by the API as well as the navigation menu. Branding and operational quota/readiness information remain available to ordinary users so they can use the platform.

A local role in one child does not grant access to the parent or another child; parent admins retain oversight of all children. Child admins can manage peer members and admins, API keys, and BYOK keys for their own scope.

Regular MSP accounts retain access to their managed clients. Platform-admin MSP accounts must use explicit Support Access impersonation to access client repositories, vendors, or child organizations; impersonating one child does not grant access to its siblings or parent.

Vendor-review settings remain read-only for child admins when the parent chooses Follow parent organization or Parent manages child-specific settings. With Child admins manage settings, local admins can edit the child bundle. These settings modes do not prevent admins or members from operating their own vendors and reviews.

Child API Keys​

On Tier 3, child admins can open Settings → API Access to create and revoke keys for children they administer. The scope selector only offers administered organizations; child admins cannot issue parent-wide keys or revoke another child's keys. Read-only admins can view the keys for their scope. Parent admins can revoke child-issued keys too.

Keys remain limited to their assigned scope and supported API operations. They cannot administer users or credentials. BYOK and branding still require the applicable plan and the parent's branding toggle.

Creating a Sub-Organization​

Only parent org admins can create sub-organizations.

  1. Go to Settings in the top navigation bar
  2. Scroll to the Sub-Organizations section
  3. Click Create Sub-Organization
  4. Enter a unique name for the sub-org
  5. Click Create

The new sub-org will appear in the list immediately.

The Settings list refreshes each sub-org's current permissions when it loads. Newly created sub-orgs remain visible after members are added, and local role changes are reflected when the list is refreshed. Parent admins and read-only admins retain visibility of every active child organization.

Managing Members​

In the parent's Team Members table, child-only users have a separate, labeled role selector for each active child membership. Selecting Admin here makes them an admin of that child without granting parent membership or changing their role in another child. You can also edit roles in the child's Members panel.

Viewing Members​

Click on a sub-org row in the Settings page to expand its management panel, then select the Members tab.

Sub-org admins and read-only admins can open Settings from the navigation bar even when they are ordinary members at the parent-account level. Their management panels are limited to the sub-orgs where they hold an admin role. Read-only admins can view members and enabled branding, but cannot change them. Admin access to one sub-org does not grant admin access to another.

Adding Members​

Parent org admins and sub-org admins can add members:

  1. Open the sub-org management panel in Settings → Sub-Organizations
  2. Click Add Member
  3. Select an existing organization user or enter an email to invite a new member
  4. Click Add
note

Members must belong to the same parent organization. Cross-tenant additions are not allowed.

Removing Members​

  1. Open the sub-org management panel
  2. Click Remove next to the member you want to remove

Sub-org admins can remove or change the role of peer admins as well as regular members. Child-initiated changes must leave at least one local admin.

Parent org admins can remove or demote the last sub-org admin, and can remove the last member from a sub-org. The parent org retains control of an empty sub-org or one with no local admin. The parent organization's own last-admin protection still applies.

If a parent admin removes a sub-org-only user's final sub-org membership, that user loses the access granted by that membership, including dashboard filters for that sub-org. Their account and any separately granted repository shares are retained, and they do not gain parent-org access or permission to submit analyses for the parent. Sub-org admins must still leave such a user with another active sub-org membership or ask a parent admin to complete the removal.

Submitting Repositories for a Sub-Organization​

When submitting a repository, you can assign it to a specific sub-org:

  1. Go to Submit Repository (or Submit Extension / NPM Package)
  2. In the Submit for dropdown, select the desired sub-organization (or leave as the default parent org)
  3. Complete the rest of the submission form and click Start Analysis

The repository will be associated with the selected sub-org and will count toward the parent organization's quota.

Filtering the Dashboard by Sub-Organization​

The dashboard supports filtering repositories by sub-org:

  1. From the Dashboard, use the Organization filter dropdown above the repository list
  2. Select:
    • All Organizations — shows all repositories you have access to
    • Parent Org — shows only repositories not assigned to any sub-org
    • A specific sub-org name — shows only that sub-org's repositories

Each repository card displays a sub-org badge when it belongs to a sub-org.

BYOK (Bring Your Own Key) per Sub-Organization​

Parent org admins and the sub-org's own admins can assign a dedicated Anthropic API key to that sub-org. When set, scans for that sub-org will use the sub-org's key instead of the parent org's key.

Key resolution waterfall: sub-org key → parent org key → MSP key → platform key

Setting a Sub-Org BYOK Key​

  1. Go to Settings → Sub-Organizations
  2. Expand the sub-org management panel
  3. Open the BYOK tab (visible to parent administrators and local child administrators)
  4. Enter your Anthropic API key and click Save

Removing a Sub-Org BYOK Key​

In the same BYOK tab, click Remove Key to revert to the parent org's key.

note

BYOK per sub-org is only available on plans that support BYOK.

Branding per Sub-Organization​

Sub-organizations can have their own logo displayed in reports and shared links, if the parent org admin enables this feature.

The logo also appears in the navigation bar when a signed-in sub-org-only user belongs to one active sub-org. If that sub-org has no logo or sub-org branding is disabled, the parent or MSP logo is used. Users assigned to multiple active sub-orgs see parent branding because there is no single sub-org context; their shared reports continue to use the report's sub-org branding.

Enabling Sub-Org Branding​

Parent org admins can enable sub-org branding:

  1. Go to Settings → Sub-Organizations
  2. Toggle Allow Sub-Org Branding to on

Once sub-org branding is enabled, sub-org admins can upload a logo:

  1. Open the sub-org management panel
  2. Open the Branding tab
  3. Upload a logo image (PNG, JPG, or GIF, max 5 MB)
  4. Click Save

Branding resolution: sub-org logo → parent org logo → MSP logo

Vendor Settings per Sub-Organization​

Vendor security requirements, AI instructions, review mode, and document retention are governed as one bundle. Children follow the parent bundle by default. A parent administrator can use the Vendor Settings Scope card in Settings to:

  • Keep a child dynamically synchronized with the parent
  • Let child administrators manage a separate child bundle
  • Maintain a separate child bundle that only parent administrators can change

When a separate bundle is created for the first time, the parent chooses whether it begins as a copy of the current parent settings or from RepoRisk platform defaults. See Vendor Settings Across Parent and Child Organizations for the full behavior and permission model.

Archiving a Sub-Organization​

Archived sub-orgs are hidden from the dashboard and no longer accept new submissions.

  1. Go to Settings → Sub-Organizations
  2. Click Archive next to the sub-org
  3. Confirm the action
note

Archiving is a soft delete — existing repositories and data are preserved. Only parent org admins can archive sub-orgs.

Troubleshooting​

"Sub-organizations" section not visible in Settings

  • This feature is only available on Tier 3 plans. Contact support to upgrade.

"Cannot add member" error

  • The user must already be a member of the parent organization, or you need to invite them by email.
  • Cross-organization member additions are not permitted.

"Cannot submit to sub-org" error

  • The sub-org may be archived. Unarchive it before submitting.
  • Confirm your plan tier supports multi-tenancy.

For additional help, see Contact Support.