Requirement 7 of PCI DSS asks you to give people access to card data, and to the systems around it, only when their job needs it and only at the level their job needs. This is called need to know and least privilege. Everything else is denied by default. You define access by job role, get each assignment approved, set your systems to enforce it, and review every account at least once every six months.
What do need to know and least privilege mean?
Need to know means a person only sees the data their job requires. Least privilege means they only get the permissions their job requires, and nothing extra. A support agent may need to see the last four digits of a card to answer a question, but not the full number. A bookkeeper may need to issue refunds in your payment gateway, but not change its settings or add users. A web developer may need admin access to a test site, but not to the live database. Requirement 7.2.1 asks you to define an access control model that grants access this way, based on each job's duties.
How do I set up role-based access?
Start with job roles, not people. List the roles in your business, such as owner, store manager, cashier, support agent, bookkeeper, and outside IT provider. For each role, write down which systems and data it needs and what it needs to do there. Then put people into roles. Requirement 7.2.2 says access, including privileged access, is assigned by job classification and function, with the least privileges needed. Requirement 7.2.3 says the privileges must be approved by authorized personnel, so keep a record of who approved each assignment. When someone changes jobs, move them to the new role rather than adding new rights on top of the old ones. That is how access quietly piles up over the years.
How often do access rights need to be reviewed?
At least once every six months. Requirement 7.2.4 says all user accounts and their access rights must be reviewed on that schedule, including accounts for third parties and vendors. Any access that isn't appropriate must be fixed, and management must confirm that the access left in place is still right. This became mandatory on 31 March 2025. Vendor accounts are where reviews tend to find the most. The developer who built your site three years ago, a former IT contractor, or a login set up for a one-time fix are all common examples of accounts nobody remembered were still active.
Do system and application accounts count?
Yes. Requirement 7.2.5, also mandatory since 31 March 2025, covers the accounts that software uses rather than people, such as the account your online store uses to connect to its database, or a service account that runs backups. Each one must have only the privileges it needs, and be usable only by the systems and processes that need it. A web application connecting to its database as the database root user is a common example of what this is meant to stop. Requirement 7.2.5.1 adds a periodic review of these accounts, at a frequency you set through a targeted risk analysis under Requirement 12.3.1.
Who can query stored card data directly?
Very few people. Requirement 7.2.6 says users should reach stored card data through applications or other programmatic methods, with what they can see and do based on their role. Only the responsible administrators may query the data store directly. A support agent looking up an order through your admin screens is fine. The same agent running queries against the production database is not. If you don't store card numbers at all, because your payment provider holds them for you, this part has much less to cover.
How do my systems enforce it?
Requirement 7.3 asks for an access control system that enforces all of this, rather than relying on people to follow a policy. Requirement 7.3.1 says it must restrict access based on need to know and cover every system component. Requirement 7.3.2 says it must enforce the privileges assigned to people, applications, and systems. Requirement 7.3.3 says it must be set to deny all by default, so a new account gets nothing until someone grants it. In a small business, the access control system is usually the built-in user and role settings in your operating systems, payment gateway, online store platform, and cloud accounts.
How is Requirement 7 different from Requirement 8?
Requirement 7 decides what each person is allowed to do. Requirement 8 proves that the person logging in is who they say they are, with unique user IDs, strong passwords, and multi-factor authentication. You need both. An outside scan can't see who has access inside your systems, but it can see the outside version of the same problem: an admin panel, remote desktop service, or database port that the whole internet can reach. ServerScan is a PCI Approved Scanning Vendor, and our quarterly ASV scans under Requirement 11.3.2 report exposed services like these. The pricing page shows what a plan includes.
Go on to Requirement 8 - Access Control.
Go back to Requirement 6 - System Security.