How do I delegate task management without giving full admin access?

It's called custom roles. The beginner trap is thinking you only grant permissions. You must also explicitly block them from areas like user management or billing that your custom role doesn't need. The system often defaults to "no access" but you can't assume that.

Tags work for framework restriction, but create and lock them down before you build the role. Otherwise a user with that role could change the tags and expand their own access.

Test with a dummy account, but expect to iterate. You'll likely miss a dependency like "Evidence: View" on a control type and they'll get blocked. It's not intuitive.

Yes, custom roles are the intended mechanism, but as others have hinted, the beginner's trap is missing the dependencies. For your specific task of uploading evidence, you'll need to grant at least three interconnected permissions: the ability to view the relevant controls, create evidence items, and likely the permission to attach files. For a single framework, you'd scope this using tags.

My practical advice is to start by documenting the exact sequence of clicks the user needs to perform their task in the UI, then map each click to a required permission. You'll often find a necessary permission, like "Control: Read" on a specific framework, isn't obvious until the dummy user hits a blank screen.

You're right about the custom roles being the answer. What I find with Vanta's page, though, is that the permission categories aren't always named to match the user's mental model of the task.

For example, you might look for an "Upload Evidence" permission, but it's actually split between "Evidence: Create" and "File: Upload" under separate headings. That mismatch is what makes the initial setup confusing. Have you tried tracing the exact clicks needed for the upload task and then hunting for each corresponding permission? It's tedious but reveals those gaps.

Good question. I'm new to Vanta too, and I found that same gap in permissions.

I got stuck because there isn't just one "upload" permission. It's split up. You need "Evidence: Create" to make the item, and then something else for the actual file attachment. It's not obvious until you try to set it up.

Did you figure out which permission covers attaching the file? I couldn't find a clear list.

Yes, that tripped me up too. The file attachment permission is often called "File: Create" or "Artifact: Upload", hiding in a totally different part of the settings from "Evidence: Create".

It's one of those permission dependencies that only shows up when you try the action. My workaround is to keep a spreadsheet mapping UI actions to their required permissions for these common tasks. It saves so much time for the next role I need to build.

Have you found any other hidden splits like that?

That spreadsheet approach is practical, and I use something similar. The real challenge comes when permissions aren't just split across categories but have implicit hierarchical dependencies the UI doesn't surface. For instance, granting "Evidence: Create" on a specific control often silently requires "Control: Read" on the parent framework or policy group. Your dummy user won't get a clear error, just a confusing empty dropdown.

The other hidden split I've documented is around "Remediation Tasks." Creating one requires "Task: Create," but assigning it to another user often requires a separate "User: Read" permission on the team or group level, which feels completely unrelated to the task management function.

You've identified the exact pain point. The permission for file attachment is typically listed as "File: Upload" or "Artifact: Create" under a resource category like "Files" or "Artifacts," separate from the evidence permissions.

The deeper issue, as user777 noted, is the hidden dependency chain. Even with "Evidence: Create" and "File: Upload," the user might fail because they lack "Control: Read" on the specific framework or policy group their evidence links to. The error message won't tell you this, it will just present an empty selector or a generic failure.

Your best bet is to enable audit logging on your dummy test account and watch for the specific permission denial events when the upload action fails. That log entry is the only reliable map to the missing piece.

The audit log is the right tool, but I've found its timing can be misleading. It logs the final denial event, but often the root cause was a missing read permission earlier in the workflow that resulted in a silent failure, like an empty dropdown. The log shows the denied "create" action, but not the missing "read" that made the action impossible to attempt.

You really need to cross-reference the log with a step-by-step walkthrough of the UI flow to connect the dots. It's not enough to just check for the last error.