Replace Manual Checklists for Baseline Entitlements

The onboarding checklist is a lie. Here’s what to do about it.

Every IT team has The Spreadsheet.

Forty-seven tabs. Color-coded by department. Columns for every system, every group, every permission a new hire might need. Notes in the margins: “Check with Sarah first” and “Only for senior engineers” and “This might be outdated.”

Last modified: eight months ago. By someone who left the company six months ago.

This spreadsheet serves as the source of truth for what access new employees should get. It’s also wrong. Everyone knows it’s wrong. But fixing it is a project nobody has time for, and besides, it’s “close enough” most of the time.

That holds until the day it doesn’t.

The Baseline Entitlement Problem

In identity management, you may see the term “birthright entitlements” that refer to the access that all employees should get as an employee of a company of a member of a department. In other words, being a “citizen” of the organization entitles you to certain baseline access.

We use the term “baseline entitlements” instead, because “birthright” has connotations we want to avoid, and because what matters most is the baseline access associated with a role. You may also hear this as “role-based access,” but that term is overloaded in identity management circles.

Each of your organization profile attributes can be used to provide you baseline access to various systems. This is also referred to as Attribute-Based Access Control (ABAC).

If you’re in the Marketing department, you get the marketing Google Groups, the marketing Slack channels, the marketing shared drives. That’s your baseline as a member of the Marketing department.

The problem is how organizations track and provision baseline entitlements: manually curated checklists that are always incomplete and always outdated.

Here’s why this breaks down:

1. Systems evolve faster than documentation

   A team adopts a new tool and adds it to their mental checklist. Does anyone update The Spreadsheet? Sometimes. Eventually. Perhaps never.

2. Organizations restructure faster than processes can follow

   Sales splits into two regional teams. Product creates a new sub-group. Engineering adds a platform team. Each reorganization should trigger a checklist review. Each reorganization doesn’t.

3. Institutional knowledge walks out the door

   The person who knew why row 47 existed left last year. The person who maintained the “Engineering” tab got promoted and doesn’t have time anymore. Knowledge decays.

4. Checklists don't handle nuance well

   “Add to the engineering group” seems simple. But which engineering group? There are 12. Does this role need all of them? Some of them? The checklist says “engineering group” and someone has to figure out the rest.

The result: new hires show up, get provisioned according to a half-right checklist, and spend their first week discovering what’s missing. Each missing piece becomes an access request. Each access request consumes time from IT and the new hire. Frustration compounds.

Manual checklists create documentation that describes intent but not reality. When auditors ask for evidence of consistent provisioning, a checklist that’s “close enough” produces findings. The gap between documented process and actual practice is precisely what SOC 2 CC6.2 (system access review) is designed to catch.

The Hidden Cost of “Close Enough”

“Close enough” carries real costs that don’t appear on any dashboard:

1. Lost productivity compounds daily

   A new engineer can’t access the code repository on day one. They can’t complete onboarding tasks. They can’t contribute. A senior engineer billing at $150/hour who’s blocked for two days waiting for access represents $2,400 of lost productivity. Multiply that by every new hire, every year.

2. IT overhead scales with headcount

   Every missing checklist item becomes a ticket. Every ticket takes time to process. If the onboarding checklist is 80% accurate, dozens of tickets per new hire cover the missing 20%. That’s not exceptional workload—that’s predictable, preventable workload.

3. First impressions shape retention

   New hires form opinions about a company in their first week. When that first week is spent fighting for access to basic tools, the impression isn’t “this company has its act together.” It’s “I wonder what else is broken here.”

4. Security risk cuts both ways

   Missing access frustrates employees. Incorrect access—permissions granted that shouldn’t be—creates security exposure. When checklists are poorly maintained, both problems occur.

5. Compliance exposure accumulates

   Auditors want evidence that access is provisioned according to policy. When policy is a spreadsheet that doesn’t match reality, a compliance finding waits to happen.

Why “Just Update the Checklist” Fails

The obvious answer to checklist problems is “keep the checklist updated.” Create a process. Assign an owner. Review quarterly.

This works for about six weeks.

Then someone’s on vacation when a system change happens. Then a reorg creates three new teams and nobody remembers to update the tabs. Then the quarterly review gets pushed because everyone’s busy with end-of-quarter work. Then someone updates a row but doesn’t tell anyone. Then someone else reverts it because they didn’t know it changed.

Checklists fail because they require continuous human effort to maintain state that exists elsewhere in organizational systems. The information about what teams exist, what systems those teams use, and what access those systems require—that information already exists. It’s in the HRIS, the IdP, the application configurations.

A checklist is a manual copy of information that should be authoritative somewhere else. Manual copies always drift from the source.

From Checklists to Policies

What if, instead of maintaining a checklist of “what to provision,” organizations defined policies for “who should have access”?

The difference is subtle but powerful:

Checklist thinking: “When someone joins Marketing, add them to these 15 groups.”

Policy thinking: “The Marketing Google Group should contain everyone in the Marketing department.”

With checklist thinking, actions are scripted for humans to take. Every new hire triggers a manual process. Every change to what Marketing needs requires updating the script.

With policy thinking, desired state is defined. The system continuously ensures the policy is true. When someone joins Marketing, they’re automatically in the Marketing Google Group because the policy says Marketing members belong there.

This is what a Ruleset does. A Ruleset is a membership criteria policy—a definition of who should have access based on their attributes, not a list of actions to take.

Here’s how it works conceptually:

Ruleset: "Marketing Team Google Group"
Rule: Include users where department = "Marketing"
Result: All current Marketing employees are group members

When a new hire joins and their department is set to “Marketing” in the directory, they automatically match the rule. They’re added to the group. No checklist. No ticket. No delay.

When someone leaves Marketing for another department, they no longer match the rule. They’re removed from the group. No offboarding checklist item. No manual removal. No forgotten access.

The policy is the source of truth, not a spreadsheet that’s eight months out of date.

Policy-based provisioning transforms access control from procedural to declarative. Instead of “we follow this checklist” (which requires proving the checklist was followed), the evidence becomes “the system enforces this policy” (which is verifiable at any moment). This satisfies SOC 2 CC6.1 with system-generated evidence rather than manual attestation.

Handling Complexity with Multiple Rules

“But access isn’t that simple,” IT teams often think. “It’s not just department. It’s department AND role AND sometimes location AND occasionally exceptions exist.”

Rulesets handle this through multiple rules and conditions:

Multiple conditions (AND logic):

Rule: Include users where:
  - department = "Sales" AND
  - region = "EMEA"
Result: Only EMEA sales team members

Multiple rules (OR logic):

Ruleset: "Sales Leadership Slack Channel"
Rule 1: Include users where title contains "Sales Manager"
Rule 2: Include users where title contains "Sales Director"
Rule 3: Include users where title = "VP of Sales"
Result: All sales leadership regardless of exact title

Named user exceptions:

Ruleset: "Project Alpha Access"
Rule 1: Include users where team = "Platform Engineering"
Rule 2: Include specific user: [e-mail] (project consultant)
Result: Platform team plus specific exception

The flexibility of conditions and rules means complex access logic that would be impossible to maintain in a checklist becomes expressible. And because it’s rules-based, it stays accurate as the organization changes.

The Checklist That Updates Itself

Here’s the mental model shift: stop thinking of onboarding as “run through a checklist of actions” and start thinking of it as “ensure the user’s attributes trigger the right policies.”

When onboarding is policy-based:

1. HR enters the new hire in the HRIS with their department, team, title, manager, and location
2. That data syncs to the directory (Okta, Google Workspace, etc.)
3. The policy engine evaluates all Rulesets against the new user’s attributes
4. The user automatically matches every Ruleset their attributes qualify them for
5. Membership syncs to downstream systems (Google Groups, Slack, GitLab, etc.)
6. By the time they sign in on day one, access is already provisioned

No checklist to run through. No tickets to create. No clicking through admin consoles.

If access is missing, it’s because the policy is wrong—which is a one-time fix that benefits everyone in that role going forward. Fix the Ruleset once, and every future hire with those attributes gets the right access automatically.

This is the checklist that updates itself: policies that reflect organizational structure and automatically keep access in sync with reality.

Automated provisioning tied to HRIS data creates a complete audit trail from hire to access. When auditors ask “how do we know this person was provisioned correctly?”, the answer is traceable: HRIS record created, attributes synced, Rulesets matched, access granted. This chain of evidence satisfies ISO 27001 A.9.2.1 and SOC 2 CC6.3.

Migration: From Spreadsheet to Rulesets

Existing checklists don’t need to be thrown away. They can be migrated:

1. Audit the checklist

   For each row, identify: What group or resource? What criteria determines access? Is this still accurate?

2. Group by pattern

   Most checklist items fall into patterns: “everyone in department X,” “everyone with title Y,” “everyone reporting to manager Z.” Group similar items together.

3. Create Rulesets for patterns

   Instead of 47 checklist items that all say “add to Marketing groups,” create one Ruleset for Marketing team membership with appropriate conditions.

4. Handle exceptions explicitly

   Some checklist items are genuine exceptions—specific people who need access outside normal patterns. Add these as named user rules.

5. Validate before activating

   Use staged rules to preview who would get access. Compare against current group membership and the existing checklist. Identify discrepancies before going live.

6. Retire the spreadsheet

   Once policies are in place and validated, the spreadsheet becomes documentation of what was, not instructions for what to do.

The migration takes effort upfront. But it’s a one-time effort that eliminates ongoing checklist maintenance forever.

What Happens When the Checklist Is Gone

Teams that replace checklists with policies report consistent outcomes:

1. Onboarding time drops

   When access is pre-provisioned, new hires are productive on day one. No waiting for IT to work through a checklist. No discovering missing access throughout the first week.

2. Access request volume drops

   When baseline entitlements are automatic, the “I just joined the team and can’t access anything” requests disappear. IT can focus on actual exceptions.

3. Audit confidence increases

   “Show me who has access to X and why” becomes a database query instead of a forensic investigation across spreadsheets and ticket history.

4. Offboarding improves

   The same policies that provision access also deprovision it. When someone leaves a team, their access updates automatically.

The onboarding checklist isn’t serving anyone. It’s a maintenance burden that’s always slightly wrong, creating downstream problems that consume IT time and frustrate new hires.

There’s a better way. It starts with thinking about access as policy, not process.

Ready to replace checklists? See how Provisionr Rulesets work

---

In the next article, we’ll tackle an even harder problem: what happens when employees don’t leave—they just change roles. The “mover” problem creates compliance risks that most organizations don’t even realize they have.