7.1 Access restriction processes and roles: evidence guide

What PCI DSS 7.1 asks for and why assessors start with paperwork

Requirement 7.1 has two sub-requirements. Requirement 7.1.1 expects the security policies and operational procedures for Requirement 7 to be documented, kept up to date, in use and known to everyone they affect. Requirement 7.1.2 expects the roles and responsibilities for Requirement 7 activities to be documented, assigned and understood. For both, the assessor's self-assessment testing is to examine the documents and interview the people who run the process, so an audit or self-assessment that is coming will start with the paperwork and then check whether staff describe the same process. Before the assessment, confirm which version of the questionnaire or template your assessor uses, since the Requirement 7 wording is shared across the PCI DSS v4.0.1 templates.

Access rarely gets too broad on purpose. It accumulates when people change teams, when temporary grants are never removed and when a new system is onboarded with its own administrators. Requirement 7.1 is the foundation the rest of Requirement 7 depends on. The access model and approved privileges in 7.2 and the technical enforcement in 7.3 only mean something if there is a written rule for who may grant access, who reviews it and who revokes it. Without that rule, a six-monthly review has no agreed standard to test against, and an enforced permission has no documented owner to approve changes to it.

Three things make 7.1 harder than it looks. First, policies go stale: a document written for last year's environment may name systems, job titles or tools that no longer exist, and assessors notice. Second, procedures exist on paper but nobody follows them, for example an access request workflow that staff bypass by email. Third, ownership is unclear between IT operations, security and business teams, so each assumes another group grants or reviews access. A practical first step is to list every access activity in Requirement 7, name one accountable owner and one supporting party for each, and check that the policy and the RACI-style record describe the same people and steps.

Which policies, teams and third parties 7.1 reaches

Requirement 7.1 applies wherever Requirement 7 applies, so its reach depends on which systems sit in the cardholder data environment (CDE) and which connected systems can affect it. The cards below cover the scoping decisions, the teams that touch access, and the third parties whose administrators need to appear in your documents.

Cardholder data environment boundary

The documented access policy and roles must cover every system in the CDE, including systems that store, process or transmit cardholder data and those that could affect its security. Start from your current scope definition and data-flow diagrams, not from an older network map. Check whether jump hosts, administration consoles and backup systems are listed, because they often sit outside the application layer teams usually document. Confirm that the boundary in your access documents matches the boundary your assessor will test.

Connected systems and shared services

Systems that connect to the CDE, such as identity providers, directory services, logging platforms and deployment pipelines, can grant access to cardholder data even when they hold none themselves. Your access procedures should say who may change their access paths and how those changes are approved. Ask whether each shared service has a named owner in your roles record, and whether its administrators are covered by the same need-to-know rules as CDE administrators.

Service desk and IT operations

Service desk staff and IT operations usually perform the day-to-day grants, changes and revocations, so their steps are the procedures an assessor will ask to see in use. Document who may submit a request, who approves it, who executes it and how the request is closed. Confirm that emergency or out-of-hours access follows the same record-keeping path, and that staff know which steps apply to them.

Application owners and line managers

Application owners define which job functions need which privileges, and line managers confirm that a person still needs them. Your roles record should name the owner for each in-scope application and state who approves access for each role. Check that managers are responsible for requesting removal when someone changes teams or leaves, because access that outlives a role change is one of the most common gaps assessors find.

HR and offboarding triggers

HR events such as hiring, transfers and terminations should start access changes automatically or through a defined handoff. Document which HR events trigger a review, who receives the notice, and how quickly access must be changed in your own procedure. Ask whether contractors and temporary staff, who may not appear in HR records, have an equivalent trigger tied to their sponsor's contract end date.

Third parties and managed service providers

Managed service providers and vendor support staff who administer CDE systems hold access your organization does not directly control, so they must appear in your policies and responsibility records. Document which vendor accounts exist, who at your organization authorizes them, and how they are removed when a contract ends. Ask each provider to confirm that its own personnel follow need-to-know rules for your environment, and keep that confirmation with your access records.

How an assessor tests 7.1.1 and 7.1.2

This table compares how an assessor examines the access restriction policy and the roles record under 7.1.1 and 7.1.2, what evidence to have ready, and where organizations usually fall short. Read each row as a test the assessor runs, then check whether your own documents would pass it.

Test element	What the assessor does	Evidence to prepare	Common findings
7.1.1 policies and procedures	Examines the written policy and operational procedures for Requirement 7 and checks they are current and in use	Access control policy with version history, review dates and owner, plus procedures for granting, changing and revoking access	Policy has no date or review record, or procedures describe a process that staff do not follow
7.1.1 awareness	Interviews staff who grant or review access to confirm they know the documents exist and apply them	Acknowledgment records or training attendance for the people who run access processes	Documents sit in a shared drive that the access team has never opened
7.1.2 roles and responsibilities	Examines the record that assigns Requirement 7 activities to roles and checks every activity has an owner	RACI matrix or equivalent covering granting, reviewing and revoking access, with role descriptions	Roles are documented but not assigned to named people, or a role has no current holder
7.1.2 understanding	Interviews the people holding each role and asks them to describe their duties and approval limits	Role holder list, delegation records and handover notes for staff changes	Role holders describe duties that differ from the matrix, or nobody knows who covers for absent approvers
Consistency between documents and practice	Compares a sample of recent access grants and removals against the written procedure and roles	Access request tickets showing approver, business justification and completion date	Tickets approved by someone outside the defined role, or access granted with no recorded approval
Change control over the documents	Checks how policies and role records are updated and approved when systems or staffing change	Revision history showing who changed each document, when, and who approved it	Changes made in place with no record of what changed or why

How to build the 7.1 policy and role set in order

This sequence turns Requirement 7.1 into a documented policy, a set of operational procedures and a roles record that assessors can examine and staff can actually follow. Each step names the output that the next step depends on.

Confirm the scope of Requirement 7
Start by confirming which systems, people, third parties and data stores fall inside the cardholder data environment and which business functions touch them. Record the list of system components and the functions that need access, such as payment operations, customer support, development and infrastructure. The output is a scoped access inventory that the policy and procedures will reference. Confirm the list with your QSA or internal assessor before drafting, because a missed system here carries forward into every later document.
Draft the access restriction policy
Write the policy around the business need to know principle: people and accounts receive only the access their job requires for a stated purpose. State who owns the policy, which systems and data it covers, how exceptions are approved and how often the policy is reviewed. Keep the wording specific enough that an assessor can test it against practice. The output is a versioned policy document with an owner, an approval field and a revision history.
Write the operational procedures for granting, reviewing and revoking access
Turn the policy into procedures for each lifecycle event: how a request is made, who approves it, how the access is provisioned, how periodic reviews are run and how access is removed when a role changes or a person leaves. Describe the evidence each step produces, such as the request ticket, the approval record, the review sign-off and the removal log. The output is a procedure set that operators can follow without interpretation. Test one procedure with a real request before you approve the set.
Build the roles and responsibilities record
Map each Requirement 7 activity to a named role and an accountable owner. A RACI matrix is a common format: it shows who is responsible for doing the work, who is accountable for the result, who must be consulted and who is informed. Include granting, reviewing, revoking, maintaining the access control system and handling exceptions. The output is a roles record that matches the people in your organization chart and the people named in the procedures.
Obtain documented approval
Route the policy, procedures and roles record to the executive or governance body that owns the security program, and record the approval with name, role and date. Check that the approved versions match the drafts, and that the procedures reference the same role names as the roles record. The output is an approved document set with traceable sign-off. Keep the approval record with the documents so an assessor can see who authorized them.
Communicate the documents to affected parties
Distribute the approved policy and the procedures that apply to each group, including administrators, approvers, reviewers, service desk staff and relevant third parties. Confirm that each recipient understands their role, and keep a record of who received the material and how acknowledgement was captured. The standard expects the documents to be known to all affected parties, so the output is a distribution and acknowledgement record. Interviews are a common assessor step here, so brief the people who will answer questions.
Set the review date and maintenance cycle
Schedule the next review of the policy, procedures and roles record, and assign an owner for keeping them current when systems, staff or payment flows change. Define the triggers that force an earlier update, such as a new system in the CDE or a reorganization. The output is a maintenance schedule and change log that show the documents stay in use after approval. Confirm the review interval with your assessor, since the expectation is that documents remain current, not that they follow a fixed period.

Evidence that passes 7.1 and how to keep it current

An assessor testing 7.1 reads the documents and then asks staff what they do with them, so the written policy, procedures, roles record and acknowledgments must agree with each other and with real access activity. The cards below cover the evidence set and the routines that keep it accurate between assessments.

Written access control policy

The policy states who may access cardholder data and system components, on what business need, and who approves exceptions. It should name the systems in scope and be specific enough that a reviewer can test a request against it. Check that it covers all Requirement 7 activities, not only user onboarding. An assessor will compare the policy against your access reviews and tickets, so any rule it states must be something your team actually does.

Operational procedures for granting and revoking

Procedures turn the policy into steps: how a request is raised, who checks business need, how access is provisioned, and how it is removed when someone changes role or leaves. Write them as numbered steps with the system or ticket queue named at each step. Ask whether a second person can follow them without the author present, since that is the test a reviewer applies.

Roles and responsibilities record

A RACI matrix or equivalent table shows who is responsible, accountable, consulted and informed for each Requirement 7 activity, such as approving access, performing reviews and removing accounts. Each named role should map to a real person or team and to a backup. Confirm that the record matches the approval rights configured in your access control systems, because mismatches are a common finding.

Approval and version history

Every document needs an owner, an approval date, and a record of what changed and who approved each change. A wiki or document system with built-in version control can show this history without manual copying. Ask the assessor's likely question before the audit: can you show the version in force on a given date, and who signed it off?

Staff acknowledgment records

Policies and procedures only count as in use if the people who depend on them have read and accepted them. Keep signed or electronically recorded acknowledgments for each version, and track new joiners and role changers who need to confirm the current version. Look for gaps: staff who joined after the last version was published, and contractors who never received it.

Scheduled review and change control

Set a review cycle for each document and a trigger for unscheduled review, such as a new system entering scope, an organizational change or an audit finding. Route every change through the same approval step and record it. Keep a dated log of reviews even when no change was needed, because a clean review record shows the documents were kept current between audits.

Documents linked to real access

The strongest evidence ties each documented rule to output from the systems: an approval ticket, an access review result, or a certification campaign that records keep, change or revoke decisions. Tools such as midPoint support designated reviewers who decide within a set timeframe, which produces a traceable record. Test the link by picking a recent access grant and tracing it back to the policy that authorized it.

What meeting 7.1 costs in money and effort

This table breaks down the cost components of meeting Requirement 7.1, showing who is paid for each item, whether it is one-time or recurring, and what pushes it up or down. Use it to build a quote request and to decide which items your own team should carry. No figures are given because none were supplied for this requirement, so ask each provider for effort estimates against your written scope.

Cost component	Who carries it	One-time or recurring	What drives it
Writing the access restriction policy and operational procedures	Internal policy owner, with optional implementation partner support	One-time, then recurring on review	Number of existing documents to reuse and how many procedures must be written from scratch
Maintaining policy and procedures in use and up to date	Internal control owner and process owners	Recurring	How often systems, teams and access processes change
Document version control and publishing tooling	Internal IT, or a partner for self-hosted setup	One-time setup, recurring hosting and administration	Whether a document platform is already licensed, and whether it is self-hosted or subscription-based
Defining and agreeing roles across teams	Security, IT operations, application owners and HR	One-time, with periodic updates	Number of teams and systems that grant, review or revoke access
Building the roles and responsibilities record such as a RACI matrix	Internal governance lead, with partner facilitation if needed	One-time, then recurring on change	Number of role changes, handoffs and third parties involved in access work
Periodic review of policies, procedures and role records	Internal control owner and management sign-off	Recurring	Frequency set in your own governance calendar and volume of changes since the last review
Assessor examination and interviews of responsible personnel	Qualified Security Assessor or internal assessor time, paid by the entity	Recurring at each assessment cycle	Number of teams interviewed, readiness of documents, and how quickly staff can explain their roles

Which open-source tools keep 7.1 evidence current

XWiki suits the written access control policy and the operational procedures that sit beneath it, because those documents change over time and an assessor needs to see that the version in force is current and was known to the people it affects. XWiki is licensed under LGPL-2.1-or-later, which you should have your legal team review against how you plan to deploy and modify it. Its version control is the feature most relevant to 7.1.1, since it keeps a history of every change to a page.

Change history: Every edit is kept under version control, recording what changed, when and by whom.
Comparison: Reviewers can compare any two versions to show exactly what an access review or policy update altered.
Rollback: Earlier versions can be restored, which helps when an unapproved edit must be reversed.
Evidence trail: Version history gives an assessor a dated record that the procedure was maintained over the assessment period.
Limits: The version history proves edits happened. It does not prove that staff read the document, so pair it with acknowledgment records.

Confirm with your platform team how XWiki will be hosted, backed up and access-restricted inside your environment before you treat its history as an official record.

Where 7.1 usually fails and how to close each gap

Requirement 7.1 fails less often on missing documents than on documents that do not describe how the organization actually works. The gaps below share one cause: the policy, roles and procedures exist on paper but are not kept current, owned or used. Each card names a gap an assessor is likely to find and the fix that makes the evidence hold up.

Templated policies that do not match practice

A policy downloaded from a template often names tools, approval steps or queues the team never uses. An assessor who interviews staff and compares the written procedure with the access tickets will see the mismatch quickly. Walk each procedure through a real access request, grant and revocation, then rewrite the policy to describe exactly those steps. Keep the policy short enough that the people who run it can recite its key points.

Policies with no review date

A policy with no owner, version or review date gives an assessor no way to tell whether it reflects current systems. Record the approval date, the next review date and the change history on every document. Store the documents in a system that keeps version history, so you can show which version was in force on a given date. Confirm your own review cycle with your QSA, since the standard does not fix one in the wording you need to quote.

Roles that exist only in a diagram

A RACI chart that names people who have left, or shows a role nobody has been formally assigned, fails the test for documented and understood roles. Assign each Requirement 7 activity to a named role, then confirm that the person in the role knows they hold it. Check the matrix against the current org chart and the access tooling at each review, not only when an audit is coming.

Procedures held by one person

When only one administrator knows how access is granted or revoked, the process fails the moment that person is on leave or leaves the company. Write the procedure as a step list that a second person could follow, and name a backup for each role. Test the backup by having them run one access change under observation. Keep the procedure in a shared, access-controlled location rather than in one person's files.

Access reviews with no reviewer decisions

Role-based access that is documented but never examined allows privileges to build up as people change jobs. Assign each access item to a designated reviewer who decides to keep, change or revoke it within a set timeframe, and record each decision with the reviewer's name and date. Campaign-style tooling can produce this record, but the review rules and the timeframe are decisions your organization must set and document.

No proof that staff know the documents

An assessor will ask the people who grant and review access what the policy says, and a blank look counts against you. Require the people in each role to acknowledge the current procedure, keep those acknowledgments with dates, and repeat them after each material change. Ask a few staff outside the security team to explain the procedure in their own words, and record what they say so you can show the check was done.

Questions buyers ask about 7.1 before hiring help

How much effort does PCI DSS 7.1 take for a small team?

The effort is mostly writing and agreeing documents, not building technology. Requirement 7.1 asks for a documented access control policy with operational procedures, and for documented roles covering who grants, reviews and revokes access. A small team has fewer roles to define, so the work is shorter, but each document still has to be accurate about how access is really handled. The main drivers are how many systems hold cardholder data, how many people currently approve access informally, and whether procedures already exist in a wiki or ticket workflow that can be turned into formal documents. Teams that already keep access tickets and approvals in one system usually need less rewriting. Ask any provider to break its estimate into policy drafting, procedure writing, staff interviews and review cycles so you can see where the time goes.

Can a small team complete PCI DSS 7.1 without outside help?

Yes, a capable internal team can write and maintain the 7.1 documents, provided it has an owner with authority to enforce them and time to keep them current. The standard asks that the policy and procedures be in use and known to all affected parties, so the harder part is getting managers and administrators to follow them and to confirm they understand their role. Outside help tends to be useful for reviewing whether the written process matches actual practice, or for explaining what an assessor will examine. Your own team can also prepare the evidence, such as the policy, procedure and roles record, and then ask your QSA whether it meets the expected testing. Confirm with your assessor which evidence they will accept before you invest heavily in any format.

What does a PCI DSS implementation partner do and not do for 7.1?

A partner can help draft the access control policy and procedures, map the roles for granting, reviewing and revoking access, configure the documentation and workflow tools that hold the records, and prepare the evidence your assessor will examine. DeployOpen plans, implements and documents self-hosted open-source platforms in your own infrastructure, and can deliver that work under a fixed scope agreed in writing. A partner does not own your controls, decide whether your access model is acceptable, or sign off on compliance. DeployOpen does not issue reports or attestations. Only a Qualified Security Assessor or the appropriate assessor issues a Report on Compliance, and your organization signs the Attestation of Compliance. Ask any provider to state these boundaries in writing before work starts.

How long does it take to finalize the 7.1 documents?

The timing depends on scope, and no duration is given here. The main factors are how many payment systems and business units are included, how many approval paths exist today, how many people must review drafts, and whether the organization already has a current access control policy. Each review round, interview with responsible staff and correction after testing adds time. Ask a provider for a written schedule tied to a defined scope, with milestones for draft, review, approval and staff acknowledgment. Also ask your assessor when they need the final documents so the schedule works backward from your assessment date.

Is a RACI matrix required to meet PCI DSS 7.1?

The standard does not name a RACI matrix. Requirement 7.1.2 asks for roles and responsibilities for Requirement 7 activities to be documented, assigned and understood. A RACI matrix is a common and convenient way to show who is responsible, accountable, consulted and informed for each access activity, and assessors often accept it as the roles record. Any format that clearly assigns each activity to a named role, and that staff can confirm they understand, can work. Confirm the expected format with your QSA, because the assessment procedures ask the assessor to examine documentation and interview people, so the matrix must match what staff actually do.

How do requirements 7.1, 7.2 and 7.3 relate to each other?

Requirement 7.1 sets the governance layer: the policy, the procedures and the named roles that everything else depends on. Requirement 7.2 defines and assigns access itself, including the access control model, approved privileges and periodic user access reviews. Requirement 7.3 requires technical access control systems that enforce those decisions across system components, typically with a deny-all default. In practice, the 7.1 documents define who may approve a privilege, the 7.2 records show what was approved and reviewed, and the 7.3 configuration proves the system enforces it. Assessors often test these together, so a gap in one area, such as a policy that does not reflect the actual access model, will surface in the others. Plan the three together to avoid rewriting documents later.

How DeployOpen prepares 7.1 documents and evidence

DeployOpen prepares the access control policy, operational procedures and roles records that Requirement 7.1 asks for, inside your own environment. The organization owns its policies and role assignments, and an independent QSA or assessor decides whether the evidence meets the standard.

How we scope

Confirm which systems, tools and teams fall under Requirement 7 in your cardholder data environment.
Agree in writing which policy, procedure and roles documents DeployOpen will draft, review or update.
Identify the people who grant, review and revoke access and who must know the procedures.
Engagements are fixed-scope, with deliverables and timelines agreed before work starts.

How we build

Draft the 7.1.1 access restriction policy and operational procedures, aligned to your actual provisioning workflow.
Build a roles and responsibilities record for 7.1.2, such as a RACI matrix, with named owners for each activity.
Configure version-controlled documentation so every policy change records what changed, when and by whom.

How we hand over

Deliver the policy, procedures and roles record in formats your assessor can examine directly.
Walk responsible personnel through the documents so they can explain their roles during interviews.
Provide an evidence index mapping each document to the 7.1.1 and 7.1.2 testing your assessor will perform.

How we support

Offer ongoing support as a retainer to keep policies current after staffing or process changes.
Review documents at your review cadence and update roles when responsibilities move between teams.
Confirm with your QSA or assessor which evidence format and sampling they expect before final handover.