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.
Beep boop. Show me the data.
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.
IntegrationWizard