Role-Based Everything: Aligning Access Control, Policies, and Training
Your new hire’s first day looks something like this: they sit through two hours of generic security training about phishing and password hygiene, they click through a 47-page acceptable use policy that covers everything from clean desk requirements to data retention, and then they get added to whatever Slack channels and tools their manager remembers to request. Three months later, they’re blocked on something, so they ping their manager who pings their manager, and suddenly they have production access. The security policies they acknowledged on day one? Nobody’s looked at those since.
This is broken. We have three systems (RBAC, security policies, and security training) that don’t talk to each other. Policies gather dust in Confluence. Training is a checkbox exercise everyone resents. And RBAC becomes a tangled mess of individual exceptions and Okta group rules hanging off job titles that hiring managers invented on the spot. There’s a better way. What if we stopped pretending these are separate problems?
If someone has access to production, they have specific security responsibilities. Those responsibilities should be written as policies. Those policies should be their training.
Roles describe responsibilities, not just access
With great power comes great responsibility. If someone has elevated access, they have specific security obligations. Those obligations should be documented as role-specific security policies.
Security policies, properly defined, are rules that guide how people do their work securely. They’re not just documents for the security team. They’re objectives the security team has for everyone else - telling engineers how to handle secrets, telling support how to verify customer requests, telling finance how to process vendor payments securely.
These role-specific policies should form the basis of role-specific training. Training is just teaching people how to meet the objectives you’ve set for them. It all fits together.
What this looks like in practice
Let’s say you create a “Product Engineer” role. This role gets you everything you need to contribute code to the main product: GitHub access to the relevant repos, your CI/CD pipeline, your observability stack, your cloud environments. All the things an engineer needs to do their job.
Because this role has access to production systems and customer data, it also comes with a “Product Engineering Security Policy”. Not generic copy about password complexity requirements or physical document shredding that was written in 2015 and hasn’t been updated since. Specific policies about things like: can you use AI coding assistants (and if so, with what guardrails), how do you handle customer data in development, what’s the process for emergency production access, how do we think about secrets management.
For this system to work, your policies need to actually be good. I’ve written about better security policies in software engineering environments before. The core principle: write policies for the people who need to follow them, not for auditors. When policies drive training and connect to access control, that principle becomes critical.
With role-specific policies, you can build role-specific training. Your onboarding training for Product Engineers walks through these policies. You don’t need expensive learning management systems to make this work. Use your existing knowledge management software (Notion, Confluence, whatever) to host the content and track who’s viewed it. Add a Google Form at the end for attestation. Write some light scripts against your identity system to check completion, send reminder emails or Slack messages to people who haven’t finished, and generate the compliance reports your auditors want.
Then there’s annual refresher training. Many compliance frameworks require it, and the spirit of the requirement is sound: security knowledge needs reinforcement and updating. But forcing people to take the exact same training again feels like a waste of time. It is a waste of time. The only people who benefit from unchanged annual training are security teams who don’t have to think creatively about how to fulfill the requirement.
Instead, use refreshers to do two things: briefly review your role-specific policies and highlight any recent changes or additions, then dive into substantive content that’s temporally relevant. If you have policies around secure coding standards for Product Engineers, your annual refresher should walk through the bugs from your bug bounty program over the past year. Show how they were introduced and how to prevent them. The best predictor of the next bug is the last bug. This is infinitely more valuable than generic OWASP content nobody remembers, and it directly reinforces the policies you’ve already established.
Here’s where it gets interesting: let’s say you have a product manager who wants to learn to code and contribute to the product. Great! They can get the Product Engineer role. But they also need to understand the policies that now apply to them, and they need to go through the training. Access and responsibility travel together.
Details that make it work
Start with your highest-risk roles. Identify the 2-3 roles with the most elevated access (Product Engineer, Support, Infrastructure). If you have a data classification, use that to think through who has access to your most sensitive data. Check with your auditors early that the evidence you’ll collect for security policies and training controls works for them. Document the policies for these roles, build the training, and get people through it. Once you have the pattern working, the next roles get easier.
Keep the granularity manageable. Think 10 to 20 roles maximum, at the job family level. If you need more than you can count on your fingers and toes, you’ve gone too far. These are the big blocks, not the fine-grained technical permissions you’d configure in AWS or Salesforce.
Integrate with hiring. This is where most RBAC systems go off the rails. Job descriptions get created by hiring managers, titles get invented, and then later someone tries to figure out what access these people need. Flip it around. When a new job description is created, security should be involved. What role does this map to? What access does this role need? Don’t retrofit access patterns onto org structures that were designed without any thought to security.
Handle exceptions gracefully. You won’t be able to say that every product manager needs the Product Engineer role. You need a system that’s flexible enough to handle exceptions. But at a high level, at a structural big block level, the roles should do most of the heavy lifting.
Layer your policies. You can have a baseline employee security policy that applies to everyone. But then layer on role-specific policies for people with elevated access. Support engineers who have broad access to customer data and can perform administrative actions on behalf of customers? They get specific policies about customer privacy and how to verify requests. Infrastructure engineers with cloud admin permissions? They get specific policies about root account usage and infrastructure changes.
This is hard work for the security team. You can’t just copy and paste policies from a SOC 2 in a box product. You can’t buy generic security awareness web video training and call it done. You actually need to own the underlying content, make sure it communicates what’s important, and build deep empathy with the people in your organization and the work they do. But when you align RBAC, policies, and training, you get better outcomes: people understand what matters to them specifically instead of drowning in generic noise, you spend less on overpriced compliance theater while actually reducing risk, and the system scales naturally as people move into new roles. This isn’t about finding a shortcut. It’s about doing the work that actually matters, respecting people’s intelligence enough to give them exactly what they need to know for the access they have.