Some users like to start by diving straight into importing data, but performing some initial structuring can pay dividends.

Every organization's architecture is different, and there is no single correct way to structure your DefectDojo hierarchy. The approach that works for a 10-person startup with two services is likely not the approach that works for a large enterprise with dozens of teams and hundreds of repos. The goal of this post is to give you a framework for thinking, not a rigid blueprint.

Understanding the DefectDojo Data Model

Before any AI tool can help you, it is important to understand what DefectDojo's hierarchy actually represents.

DefectDojo Asset Hierarchy is organized into four main tiers:

• Organizations: Top-level groupings. Think of these as business divisions, application portfolios, or departments. In DefectDojo Pro, these are called "Organizations."
• Assets: Represent individual projects, applications, services, or repositories being tested. In DefectDojo Pro, these are called "Assets," and they gain the ability to have parent/child relationships.
• Engagements: Represent specific testing activities or time windows within a Product/Asset. These can be either interactive (manual pentests, one-off assessments) or CI/CD-driven (automated pipeline scans).
• Tests: Individual scanning events or testing activities nested within an Engagement. Tests are where your actual scan output lives.
• Locations: a new asset-modelling tool in DefectDojo Pro. This gives DefectDojo a single, polymorphic way to describe where a Finding lives. This can be a URL, a software dependency from an SBOM, a cloud resource ID, container image, or code repository.

Engagements and Tests are the operational layer of the hierarchy, they track when and how testing happened. Findings are what flow out of Tests.

This hierarchy isn't arbitrary. Most deduplication in DefectDojo operates within the scope of a single Asset, so how you draw those boundaries has direct implications for how your tool handles repeated findings across scans, tools, SBOMs via locations.

What DefectDojo Pro Adds: Asset Hierarchy

If you're on DefectDojo Pro, the data model gains significant flexibility. The Assets and Organizations feature introduces parent/child relationships between Assets, enabling you to model nested environments which is something that wasn't possible with the flat Product model.

This is particularly valuable if you have:

• Microservices architectures where individual services are sub-components of a larger platform
• Monorepos with multiple independently testable modules
• Dev/staging/production environments that should be tracked separately but reported on together
• Shared infrastructure that underlies multiple applications

For example, a nested Asset tree might look like this:

1. Core Application [Organization]

2. webapp-frontend [Parent Asset]

3. webapp-frontend/prod

3. webapp-frontend/dev

4. webapp-frontend/dev/feature-a

4. webapp-frontend/dev/feature-b

There is no limit to the number of parent/child relationships you can create. Theoretically, you could map an entire repository's directory structure if your workflow called for it, though in practice, you want to be deliberate about how granular you go, since finer granularity adds management overhead.

RBAC: Structure Has Consequences

Your hierarchy isn't just an organizational preference, it's a security boundary. DefectDojo's RBAC model grants or restricts access at the Asset and Organization level.

A few things to keep in mind as you design your structure:

• Giving a user access to an Organization grants them access to all Assets within it.
• Giving a user access to a single Asset does not grant access to its parent or sibling Assets.
• An Asset-level Role supersedes an Organization P Role for that specific Asset, but cannot reduce permissions already granted at a higher level, roles only add, never subtract.

This means that if you have a use case like "allow third-party pen testers to upload results without seeing internal findings," you should model that as a dedicated child Asset rather than giving testers access to your primary Asset. The Pro permissions documentation describes how to configure this through the Pro UI.

For large teams, User Groups allow you to assign consistent permissions across many users at once, which becomes essential once you're managing dozens of team members.

Where AI Tools Actually Help

While planning a hierarchy can be relatively straightforward, you may need to weigh certain tradeoffs between:

• Reporting granularity vs. management overhead
• Deduplication scope vs. isolation of environments
• RBAC simplicity vs. access precision
• Future-proofing vs. over-engineering

This is where using LLM’s like Claude or ChatGPT can be helpful.

By using a prompt like the following example, you can output a basic tree structure. Getting this right upfront is significantly cheaper than reorganizing after you've imported thousands of findings.

Using Claude to Draft Your Hierarchy

Below is a prompt you can copy directly into Claude.ai to get a structured draft of your DefectDojo hierarchy. Customize the sections in brackets with your actual environment details.

Prompt: DefectDojo Hierarchy Planner

I'm setting up DefectDojo Pro for my organization and need help planning my asset hierarchy before I start importing scan data.

Here's a description of my environment: [Describe your application portfolio, services, repos, or infrastructure. For example: "We have a monolithic e-commerce platform, three internal microservices, a mobile app (iOS and Android), and a shared infrastructure layer running on AWS. We also have a data analytics pipeline."]

Here's how my security team is structured: [Describe your teams. For example: "We have a centralized AppSec team of 5, plus a DevOps team that handles infrastructure scanning, and we occasionally engage a third-party pen test firm."]

Here are my current scanning tools: [List the tools you use. For example: "Semgrep for SAST, Trivy for container scanning, Burp Suite for DAST, Terraform scanning via Checkov, and manual pen test reports in PDF form."]

Here are my key reporting requirements: [Describe how you report on security posture. For example: "We need per-application executive reports monthly, and we track SLA compliance separately for production vs. dev environments."]

Based on this, please generate a proposed DefectDojo Pro hierarchy using the following structure:

- Organizations (top-level groupings, formerly "Product Types")

- Assets (individual testable units, formerly "Products"), including any parent/child nesting that makes sense

- Suggested Engagement types per Asset (CI/CD vs. interactive)

- Any RBAC access control suggestions based on my team structure

Format the hierarchy as an indented tree, then explain the rationale behind any key decisions. Flag any trade-offs I should consider, and remind me that my architecture may require adjustments once I start working in DefectDojo.

When you review the output, validate it against a few questions:

• Does deduplication scope make sense? Findings only deduplicate within a single Asset, so Assets that share a codebase might need to be structured carefully.
• Is the RBAC model reflected? If certain teams shouldn't see certain Assets, does the tree enforce that?
• Is reporting served? Can you generate the reports your stakeholders need from this structure, or does it need adjustment?
• Is it maintainable? A hierarchy that's accurate but requires constant manual maintenance is worse than a slightly less accurate one that runs cleanly.

Your actual environment has nuances that a language model can't fully anticipate and there are tradeoffs that only your team can make.

Common Hierarchy Patterns (and When to Use Them)

To give you some concrete reference points, here are three patterns that tend to work well — though again, your situation may call for a different approach entirely.

Pattern 1: Team-Based Organizations Create one Organization per security team or business unit, with Assets reflecting the applications or services that team owns. Works well when teams have distinct ownership and need independent reporting.

Pattern 2: Technology-Domain Organizations Create Organizations around technology domains ("Web Applications," "Infrastructure," "Mobile," "Data Platform"), with Assets reflecting individual services or repos within each domain. Works well when you're scanning across teams with the same tools and want to aggregate findings by technology type.

Pattern 3: Environment-Aware Asset Nesting (Pro) Use parent Assets to represent logical applications, with child Assets for each environment (prod, staging, dev). Works well when SLA enforcement and risk tolerance differ by environment and you need isolated deduplication per branch.

None of these patterns are mutually exclusive, and many real-world DefectDojo instances end up as a hybrid.

Next Steps

Once you've drafted and validated your hierarchy, you're ready to start building in DefectDojo Pro. A few things to set up in the right order:

1. Create your Organizations first
2. Create parent Assets, then child Assets
3. Assign RBAC - User Groups before individual users, so permissions are consistent
4. Create Engagements before importing scan data
5. Set up CI/CD Engagements for automated imports

The Asset Hierarchy overview is worth a second read once you've done this planning exercise; a lot of the design decisions will click once you've thought through your own environment.

If you're migrating from an existing DefectDojo Open Source instance, reach out to DefectDojo Support to enable the Asset Hierarchy beta and the optional label changes. Existing automation will continue to function since the underlying API endpoints are unchanged.

Have questions about structuring your DefectDojo Pro hierarchy? Join the DefectDojo community’s help channel and check out the doc’s reference material for both Pro and Open Source users.