Hierachy Definition
Helping you map your business structure to the Snyk hierarchy
~15mins estimatedThis lesson is designed to help you map your company’s business structure to the Snyk hierarchy. You will learn to define and strategically organize Tenants, Groups, and Organizations to ensure proper data isolation and streamlined management across different business units.
The Snyk Architecture
To build a scalable security program, you must first understand how Snyk organizes data. Snyk uses a four-tier hierarchy designed to mirror the structure of modern enterprise organizations.
- Tenant: The root of your Snyk environment. Typically, a customer has one tenant representing the entire company. This level provides global analytics via Snyk AppRisk
- Group: The primary administrative container. Groups hold your Organizations, global security policies, and default notification templates
- Organization (Org): The operational hub. This is where you control access, configure SCM integrations, and view project-level scan results
- Target & Project: A Target is a repository or image; a Project is a specific scannable file within that target (e.g., a package.json or a Dockerfile)
Your hierarchy dictates your governance. Before creating Orgs, consider these three "rules of engagement":
- Isolation (Groups): Most companies should use a single Group. Multiple Groups should only be used if business units require absolute data isolation, as Projects and Service Accounts cannot be shared across Groups.
- Access Control (Organizations): Access is governed at the Organization level. If a user needs the same permissions for a set of projects, those projects should live in the same Org.
- Performance & Scale: Snyk scales to thousands of Orgs, but to ensure high performance, we recommend limiting each Organization to 10,000 Projects.
There is no "one size fits all" for Organization structure. Choose the model that aligns with your internal ownership:
| Model | Best For... | Advantage |
|---|---|---|
| By Team/BU | Agile organizations with clear team ownership | Aligns directly with HR/Identity groups |
| By Application | Large monolithic apps or complex microservices | Reporting focuses on the security posture of the app |
| By SCM Structure | Centralized DevOps teams | Simplifies initial bulk-importing from GitHub/GitLab |
| By Environment | High-compliance environments (Prod vs. Dev) | Allows for stricter policies on production-facing code |
To ensure your tenant remains responsive as you scale, there are several best practices that you can follow:
- Consolidate where possible: Don't create an Org for every single repository; this makes managing user roles and integrations overly complex.
- Standardize Naming: Use a convention like [Business Unit] - [Application Name] to keep the UI searchable.
- Audit Regularly: Use the Asset Inventory discovered in Lesson 2 to ensure every repo is mapped to the correct governed Org.
What to learn next?
Using Snyk in an IDE
Administrating Snyk in an IDE