Access privileges should be assigned based on which factors?

Access privileges should be assigned based on which factors?

• A. The individual's job classification and function
• B. Senior staff tenure
• C. Team size
• D. Time of year

Answer: (A)

Access privileges should be tied to what a person actually needs to do their job. Granting permissions based on their role—job classification and function—embodies the principle of least privilege and need-to-know. When access is defined by role, you ensure each user gets only the data and systems required for their responsibilities, making it much easier to enforce consistent controls, perform role-based reviews, and revoke access promptly when roles change. This alignment also helps balance security with productivity, because permissions reflect concrete job needs rather than subjective or arbitrary factors. Tenure, team size, or the time of year don’t indicate what access a person truly requires. Years on the job don’t automatically justify broader rights, team size doesn’t determine an individual’s tasks, and calendar timing shouldn’t drive who can access sensitive systems. If access needs to be temporary or project-based, it should be managed within the same role-based framework with timely revocation, not used as a basis for permanent privileges. This approach supports PCI DSS practice by ensuring access to cardholder data is granted only to those whose roles require it and is reviewed regularly to prevent privilege creep.

Access privileges should be tied to what a person actually needs to do their job. Granting permissions based on their role—job classification and function—embodies the principle of least privilege and need-to-know. When access is defined by role, you ensure each user gets only the data and systems required for their responsibilities, making it much easier to enforce consistent controls, perform role-based reviews, and revoke access promptly when roles change. This alignment also helps balance security with productivity, because permissions reflect concrete job needs rather than subjective or arbitrary factors.

Tenure, team size, or the time of year don’t indicate what access a person truly requires. Years on the job don’t automatically justify broader rights, team size doesn’t determine an individual’s tasks, and calendar timing shouldn’t drive who can access sensitive systems. If access needs to be temporary or project-based, it should be managed within the same role-based framework with timely revocation, not used as a basis for permanent privileges.

This approach supports PCI DSS practice by ensuring access to cardholder data is granted only to those whose roles require it and is reviewed regularly to prevent privilege creep.