Access Based on Job Classification

PCI DSS v4.0.1 Requirement 7.2.2 requires you to grant access (including privileged access) based on a person’s job classification and job function, and to limit that access to the least privileges needed to perform assigned responsibilities (PCI DSS v4.0.1 Requirement 7.2.2). Operationalize it by defining role-based access profiles, mapping every user (and service account) to an approved role, and enforcing approvals, reviews, and monitoring against those role definitions.

Key takeaways:

• Define job-based roles first, then map systems and permissions to each role (PCI DSS v4.0.1 Requirement 7.2.2).
• Prove least privilege with documented access profiles, tickets/approvals, and periodic access reviews.
• Include privileged users, admins, and third-party access in the same job-based model.

“Access based on job classification” is a practical access control requirement disguised as a short sentence. PCI DSS assessors expect to see that your organization can explain (a) which job roles exist, (b) what those roles need to access in the cardholder data environment (CDE) and connected systems, and (c) how you prevent role creep and excess permissions over time. The requirement is not satisfied by having an IAM tool alone. It is satisfied when access decisions consistently trace back to a defined job function, and the granted permissions match the minimum needed for that function (PCI DSS v4.0.1 Requirement 7.2.2).

For a CCO, compliance officer, or GRC lead, the fastest path is to treat this as a governance-and-evidence problem: define role/entitlement standards, require approvals against those standards, and maintain artifacts that make it easy for an assessor to test samples. The operational friction shows up in edge cases: admins with broad rights, shared or orphaned accounts, third parties needing emergency access, and “temporary” permissions that never expire. This page gives requirement-level guidance you can hand to IAM, IT, and security operations to implement quickly, then defend in a PCI DSS assessment.

Regulatory text

PCI DSS v4.0.1 Requirement 7.2.2: “Access is assigned to users, including privileged users, based on job classification and function, and the least privileges necessary to perform job responsibilities.” (PCI DSS v4.0.1 Requirement 7.2.2)

Operator interpretation (what you must do):

• Create and maintain job-based access rules (job classification/function → approved access set).
• Assign access by mapping people to those rules, rather than granting ad hoc permissions.
• Demonstrate least privilege by showing the role grants only what is necessary, and by preventing accumulation of excess rights over time.
• Include privileged users explicitly, not as an exception category (PCI DSS v4.0.1 Requirement 7.2.2).

Plain-English requirement interpretation

You must be able to answer this assessor question with evidence: “Why does this user have this access?” The acceptable answer is: “Because they are in job role X, and job role X is approved to have permissions A/B/C for these tasks.” If the real answer is “Because someone asked for it” or “Because they’re trusted,” you will struggle to satisfy the requirement (PCI DSS v4.0.1 Requirement 7.2.2).

Least privilege is not a one-time design choice. It is an operating state you maintain through:

• standard role definitions,
• controlled provisioning and change approvals,
• periodic validation that users still match their roles,
• rapid removal of access when job function changes.

Who it applies to (entity and operational context)

Entities: Merchants, service providers, and payment processors in scope for PCI DSS assessments (PCI DSS v4.0.1 Requirement 7.2.2).

Operational scope (where it shows up):

• Systems in the CDE, plus systems that can impact the security of the CDE (for example, identity providers, admin consoles, jump hosts, and endpoints used for CDE administration).
• All user types: employees, contractors, and third parties with access to in-scope systems.
• Privileged users: system administrators, database administrators, security administrators, cloud administrators, and any role that can change security settings or access sensitive data.
• Service and application accounts: if they have access, you need a job-function equivalent owner and a least-privilege rationale.

What you actually need to do (step-by-step)

1) Build a job classification/function role catalog

Create a role catalog that reflects how work is done, not how org charts look.

Minimum fields to include for each role:

• Role name and description (job function)
• In-scope systems covered (CDE and connected systems)
• Approved entitlements (groups, roles, permissions)
• Data and actions permitted (read, write, admin, export)
• Privileged status (yes/no) and extra controls required
• Role owner (business owner) and technical owner (system owner)
• Approval workflow required for assignment

Practical tip: start with a “thin slice” of roles for the teams that touch payment systems (support, operations, engineering, security, finance). Expand after you can pass sampling.

2) Map systems and entitlements to each role (least privilege design)

For each in-scope system:

• Inventory the permission model (local accounts, LDAP groups, cloud IAM roles, database roles, application roles).
• Define “standard access profiles” per role (for example: Support Tier 1 = view-only in ticketing + limited application console; DBA = database admin but no OS admin).
• Eliminate “everyone gets admin” patterns. If a role needs admin only for rare tasks, split into a base role plus a separate, time-bound elevation path.

Deliverable: a permissions matrix that ties job function → system → entitlement.

3) Enforce controlled provisioning (no ad hoc grants)

Your provisioning process must ensure access is assigned because of role membership:

• Request must specify role assignment (not a list of permissions).
• Approver must be the role owner or designated delegate plus system owner where needed.
• Access is provisioned through groups/roles tied to the role catalog.
• Exceptions require explicit documentation: why the role model doesn’t cover it, which extra permissions are granted, who approved, and when it expires.

If you’re implementing quickly, use your ITSM tool to standardize request forms and ensure every access request captures job function, role, and business justification.

4) Handle privileged access as a defined job function (not a shortcut)

The requirement explicitly includes privileged users (PCI DSS v4.0.1 Requirement 7.2.2). Treat privileged access as its own set of job functions and enforce separation where feasible:

• Admin roles should be distinct from standard user roles.
• Require separate admin accounts where your environment supports it.
• Restrict privileged role assignment to named individuals with documented duties.

5) Run access reviews tied to job function changes

Least privilege fails over time due to transfers, promotions, temporary projects, and emergency grants. Operationalize:

• Joiner/mover/leaver triggers from HRIS or identity governance to update role assignments.
• Periodic user access reviews for in-scope systems focusing on “does this person still match this job function?”
• Targeted reviews for privileged access and third-party access.

You don’t need to review every entitlement individually if your role definitions are well-controlled. Many teams review at the role assignment level, then spot-check sensitive entitlements.

6) Monitor and correct “role drift”

Set up detective controls to find:

• users with direct permissions not granted via roles/groups,
• users in privileged groups without documented job function,
• dormant accounts with access,
• service accounts without an owner.

Feed findings into a remediation workflow with due dates and documented closure.

7) Prepare assessor-ready sampling packages

Assessors will sample users and privileged users. Pre-build a “user access evidence pack” template:

• user identity and job title/department,
• assigned roles/groups,
• ticket/approval showing role-based assignment,
• role definition showing least-privilege scope,
• last access review evidence showing the assignment is still valid.

Required evidence and artifacts to retain

Keep artifacts that let you show “job function → access granted” without reconstructing history.

Core artifacts

• Role catalog / role definitions with owners and approved entitlements
• Systems-to-roles entitlement matrix for in-scope systems
• Access request and approval records tied to role assignment
• Provisioning logs or IAM change records showing role/group assignment
• Access review results (including privileged reviews) and remediation tracking
• Exception register for non-standard access with expiration and approvals

Supporting artifacts (high value in audits)

• HR job classification list mapped to access roles
• Third-party access inventory and role mapping
• Evidence of removal on termination or job change (tickets or IAM logs)

Common exam/audit questions and hangups

Assessors commonly test requirement 7.2.2 by sampling and asking for traceability.

Expect questions like:

• “Show me how you determine the least privileges for this role.” (PCI DSS v4.0.1 Requirement 7.2.2)
• “Why does this user have admin rights? Where is that documented?”
• “How do you ensure role changes occur when someone changes jobs?”
• “How do you handle third-party admin access?”
• “Show me that access was approved based on job function, not convenience.”

Hangups that cause findings:

• Roles exist on paper but provisioning is still manual and inconsistent.
• Privileged users are excluded from the role model.
• Exceptions don’t expire and become the real access model.
• Shared accounts prevent user-to-job-function traceability.

Frequent implementation mistakes and how to avoid them

1. Mistake: Using job titles as roles without entitlement detail.
   Fix: define role access profiles at the permission/group level per system.

2. Mistake: “Everyone in IT” gets broad access.
   Fix: split IT into job functions (helpdesk, sysadmin, network admin, security admin) and narrow entitlements per function (PCI DSS v4.0.1 Requirement 7.2.2).

3. Mistake: Exceptions become permanent.
   Fix: require an expiration date and periodic recertification for all exceptions.

4. Mistake: Privileged access granted because a person is trusted.
   Fix: require a job-function justification and an approved privileged role with assigned duties.

5. Mistake: Third-party access handled outside governance.
   Fix: require third parties to be mapped to the same job-function roles and reviewed the same way.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, but assessors treat it as a core access control expectation because excessive permissions are a common root cause of payment environment compromise. The practical risk is straightforward: users with unnecessary access can expose account data, change security settings, or create persistence paths. For service providers, weak role governance also creates multi-tenant impact if admins can cross boundaries.

A practical 30/60/90-day execution plan

First 30 days: establish the role model and stop the bleeding

• Identify in-scope systems for access control design (CDE and connected systems).
• Draft a role catalog for the teams with CDE access, including privileged roles (PCI DSS v4.0.1 Requirement 7.2.2).
• Freeze ad hoc privilege grants unless documented as exceptions with an owner and expiry.
• Standardize access request forms to require role selection and approvals.

By 60 days: implement role-based provisioning and initial reviews

• Map entitlements to roles for each in-scope system and implement groups/roles accordingly.
• Migrate existing users into role-based groups; eliminate direct permissions where possible.
• Perform an initial privileged access review to remove obvious excess access.
• Create your evidence pack template and run a mock sample test internally.

By 90 days: operationalize ongoing least privilege

• Implement joiner/mover/leaver triggers so role assignment tracks job function changes.
• Run a formal access review cycle for in-scope systems and record results.
• Stand up monitoring for role drift (direct grants, privileged group changes, orphan accounts).
• Tighten exception handling (approvals, expiry, recertification).

Where Daydream helps: teams often lose time stitching evidence across HR, ITSM, IAM, and system consoles. Daydream can centralize role definitions, map them to control requirements, and generate audit-ready evidence requests and sample packages so your access governance is defensible without spreadsheet sprawl.

Frequently Asked Questions

Do we need a full RBAC program to meet the access based on job classification requirement?

You need a role-based access model for in-scope systems that ties access to job function and least privilege (PCI DSS v4.0.1 Requirement 7.2.2). It can start small, but it must be real: defined roles, controlled assignment, and evidence.

How do we handle users who legitimately need access across multiple job functions?

Assign multiple approved roles only if each role is justified by current responsibilities, and document who approved each assignment. Avoid “combo roles” that accumulate permissions without review; they make least privilege hard to prove.

Does this apply to privileged users like sysadmins and security admins?

Yes. The requirement explicitly includes privileged users, so privileged access must also be assigned based on job classification/function and limited to least privilege (PCI DSS v4.0.1 Requirement 7.2.2).

Are service accounts covered?

If an account has access to in-scope systems or data, treat it as needing least privilege and a documented “job function” via an accountable owner. Keep an inventory, intended use, and the minimum permissions required.

What’s the minimum evidence an assessor will expect to see?

Role definitions (job function to entitlements), proof of approved role assignment for sampled users, and evidence you review and remove access when it no longer matches job responsibilities. Privileged access samples typically get extra scrutiny (PCI DSS v4.0.1 Requirement 7.2.2).

We can’t technically enforce all access through groups. Is that an automatic failure?

Not automatically, but you must show that access assignment is still controlled by job function and that direct grants are governed, approved, reviewed, and minimized. Track direct entitlements as exceptions and work toward reducing them.