How to Choose Software That Won't Break Your Access Model

In the first two posts of this series (post one, post two), we talked about why access control often fails inside a company. It's usually because of unclear rules, systems that don't talk to each other, and a lack of a person clearly responsible for the whole process.

But even if you get all that right, there's another big challenge: your software.

The tools you use might not be built to follow the access rules you’ve created. When that happens, keeping permissions in line becomes a slow, manual process. This leads to mistakes and bigger risks over time.

This post will show you what to look for when you choose new business software so it works with your access rules, not against them.

A Simple Model for Access Control

The best way to manage access isn't to think about tools; it's to think about your business. You can create a simple model by defining Roles, Objects, and Actions.

Let’s take a simple case with a sales team and a legal team.

In this simple table, we’ve just built a basic access model. This is an example of Role-Based Access Control (RBAC) in action, which tells exactly who should be able to do what. The Sales Manager can view customer contracts, which is all they need for their job. The Legal Team, however, has the full authority to work with those documents.

This model is your single source of truth and the business logic that should guide every access decision.

Expanding the Model with Scoping

As a business grows, the model needs to get more specific. What if the sales manager only needs to see contracts for their own customers? This is where scoping comes in.

We can add a new dimension to our model.

The model now says that a sales manager's permissions are limited not just by their role, but also by who they are working with. This is an example of Attribute-Based Access Control (ABAC) – making a decision based on a user's specific attributes, like "assigned customers."

You can see how this model easily applies to a shared drive like Dropbox or Google Drive. A well-structured drive might look like this:

With this structure, a sales manager could be granted permission to view all files in the sales-documents folder, but only for the customers they are assigned to. This is a very specific but powerful way to protect your data.

How This Model Connects to the Right Tool

Once you have a clear, written-down model, you can choose software that helps you enforce it. The best tools don't create your access rules, they simply follow them. The diagram below provides a visual summary of how the process works: your access model is the foundation, and your tools are an extension of those rules.

Here are the features that make that possible.

The Foundation: Your Identity Provider

Your Identity Provider (IdP) is the central hub for everyone in your company. It knows their name, email, job role, and team. When you have a solid access model, your IdP should be the single source of truth that your software listens to. This is the same Source of Truth you see in the diagram.

• Single Sign-On (SSO) makes sure everyone logs in through the IdP. This centralizes control: when someone leaves, you disable their account once and their access to every connected system disappears.
• Directory Sync (SCIM) connects your IdP to your software. When you change someone's role or team in your HR system, the software updates automatically. This reduces mistakes and keeps your tools in sync with reality.

Building on the Foundation: Your Tools

Once you have the core identity foundation in place, your tools should be able to handle the specific logic from your model. This means they must support:

• Role-Based Access Control (RBAC): This feature lets you assign permissions to the Roles you defined in your model (like "Sales Manager"), rather than to individual people. For example, a Salesforce license might have different permissions for a Sales Rep vs. a Sales Manager.
• Granular Access Scoping: This allows the software to apply those roles with precision, limiting access to a specific Object or Scope (e.g., only "customer-A" files), as defined in your model. In a tool like HubSpot, this might mean a Marketing Manager can only see campaigns for their specific region.‍
• Attribute-Based Access Control (ABAC): This builds on RBAC and scoping by making access decisions based on a person’s attributes (like location or project status). For example, it's what allows a sales manager in a CRM to automatically see only the customers they are assigned to.

Keeping It All in Check

Beyond the core access model, the right tools have features that help you manage and monitor everything. You should look for:

• Delegated Access Management: Permission changes shouldn’t be a bottleneck. With delegated management, team leads can grant or remove access for their group without needing global admin rights. This speeds up onboarding and project changes while still following the rules you’ve set.‍
• Audit Logging: Even with a good structure, you need visibility. Audit logs show who accessed what, when, and from where. They're like a security camera for your data, which is essential for reviews and proving you're following compliance rules like SOC 2 or ISO 27001.

A Real-World Problem: When the Tool’s Model Doesn’t Match Yours

Here’s a real example – imagine a company that uses a project management tool. The tool is set up so that every person has a "main" team and can also be part of several "secondary" teams.

Here's the problem: the software has a rule that says: If you are a member of a team, you can see all the content from that team.

Let's say a person from the Sales team is put on a secondary project team with someone from the Legal department. Because they're on that shared team, the salesperson can now see everything from the Legal team's main area – even highly confidential contracts and legal documents they should never see.

This problem wasn't caused by a user making a mistake; it was caused by the software itself. It didn't allow the company to restrict visibility to just the person's main team, forcing them to choose between a security risk and an inefficient workflow.

How It Could Have Been Different

If the platform had granular scoping, people could have been limited to seeing their main team’s content unless given permission for more. RBAC or ABAC could have set these rules clearly. Delegated management could have let the right people change ownership without strange workarounds. And directory sync would have kept the platform’s team data aligned with the real company structure.

With these features, the problems might not have disappeared completely – but they would have been rare and much easier to fix

How to Choose Tools That Fit Your Plan

When you choose a new system, it becomes a part of your company's access model. If that system can't follow your rules, you're forced to do the work yourself.

This is a big risk, especially for compliance. Security rules like SOC 2 and ISO 27001 require you to prove that your access policies are enforced consistently across all of your systems, including the ones you buy from other companies.

When you're looking at new software, ask the vendor how their access model works. Look for signs that the tool can adapt to your company, not the other way around. Good signs include

• A clear explanation of how roles and teams can connect to your identity provider.
• Automated syncing of user information, so new hires get access automatically and departing staff lose it immediately.
• Control over access by team, project, or region – not just per person.
• A clear, accessible audit trail for reviews and incident investigations.
• The ability for teamleads to manage access for their own teams without global admin rights.

You don’t need every feature from day one, but if a tool does not support all of these, it’s a red flag. The best tools let your company’s structure guide their access model – not the other way around. If you find yourself redesigning your roles just to make the software work, the mismatch will only grow as your company scales, making fixes harder and more expensive.

What's Next

In our final post of this series, we’ll go behind the scenes. We’ll show you how Truvity handles access internally, using the same principles we've discussed. We'll also explore how these ideas apply to new technology, like self-sovereign identity (SSI), and how that changes the way we think about access control.