8.1 Identification and authentication processes and roles

What PCI DSS 8.1 asks for and why assessors start here

When an assessor begins testing Requirement 8, 8.1 is usually the first place they look, because it asks whether the organization has written down how people are identified and how their access is authenticated, and whether those written rules are actually followed. Requirement 8.1 contains two sub-requirements. Sub-requirement 8.1.1 expects the security policies and operational procedures for Requirement 8 to be documented, kept current, in use, and known to everyone they affect. Sub-requirement 8.1.2 expects the roles and responsibilities for Requirement 8 activities to be documented, formally assigned, and understood by the people who hold them. In the self-assessment questionnaire for service providers, the expected testing is to examine the documents and interview the responsible staff, so the assessor will ask for the policy and procedures and then ask a sample of people whether they know what those documents require.

The underlying risk is unmanaged identity. If nobody owns the process for creating, changing, and removing accounts, or nobody can say who is allowed to approve an authentication exception, the technical controls in 8.2 through 8.6 tend to drift. Accounts accumulate, shared logins appear, and authentication settings are changed by whoever is available that day. A written procedure with a named owner is what keeps those controls consistent over time. Before the assessment, the compliance lead should confirm which systems and teams fall under Requirement 8, identify the person accountable for each step of identification and authentication, and check that the policy is dated, approved, and reviewed on a schedule the organization can show.

Requirement 8.1 is hard for a different reason: it is a people and documentation requirement rather than a technical one. Engineers can configure a directory in an afternoon, but producing a policy that matches what the platform really does, a RACI matrix that names the same people the access records name, and evidence that staff were told about the procedure takes sustained coordination across security, operations, HR, and application owners. Gaps usually appear where the paperwork describes one process and the system runs another. A useful first step is to trace one real account from request to approval to provisioning to removal, and confirm that each step matches a written procedure and a named role. Where outside help is involved, the organization still owns the policy and the role assignments, and the QSA is the party who tests them.

Which systems, teams and third parties 8.1 reaches

Requirement 8.1 applies to every identity system, team and provider that touches Requirement 8 activities, so scope is set by where authentication decisions are made and carried out. The cards below cover the scoping decisions that most often change how much documentation, role assignment and evidence an assessor will expect.

Identity systems inside the CDE

Directories, identity providers and access platforms that authenticate users into the cardholder data environment are in scope for the policies and procedures 8.1.1 requires. An identity provider that issues tokens for a payment application makes the policy cover that provider's configuration, not only the application. Inventory each system that can grant or deny access to the CDE, then confirm which ones your written procedures describe by name.

Identity systems that only touch the CDE

Some systems sit outside the CDE but can still change who gets in, such as a corporate directory that feeds group membership into CDE access tools. Assessors look at whether these systems affect Requirement 8 outcomes, which is a judgment you should document in the scope rationale rather than assume. Ask your QSA early which connected systems they will treat as in scope, because that decision decides how many procedures need named owners.

Directory services for Linux and UNIX

Where Linux or UNIX hosts in the CDE rely on centralized single sign-on, the directory and its Kerberos realm become part of the authentication process being documented. Changes to that realm are administrative changes with their own owners. Confirm whether administrators sign in through this directory, local accounts or both, since each path needs its own procedure and role assignment.

Teams that own identity decisions

8.1.2 requires the roles and responsibilities for Requirement 8 activities to be documented, assigned and understood. In most organizations, identity decisions are split between security, infrastructure, application owners and the help desk, and each team that approves account creation, MFA enrollment or credential resets needs a named role. Map who approves, who executes and who verifies, then confirm each team can describe its part when interviewed.

Managed service providers and outsourced help desks

Third parties that reset passwords, enroll MFA devices or administer identity platforms perform Requirement 8 activities on your behalf, so they must appear in the roles record. The record should state what each provider does, which of your roles approves it and where its actions are logged. Ask each provider for its own responsibility matrix and confirm that your documentation matches it, since a gap between the two is a common finding.

Identity platform vendors and documentation repositories

Identity platform vendors and the wiki or document system that holds your policies both affect 8.1 evidence. The policy is only meaningful if it is current and accessible to affected staff, so document ownership and version history matter. A wiki that records each change with its author and date gives assessors a clear trail, and an identity vendor's support access should be listed as a third party with its own approval path.

How an assessor tests 8.1.1 and 8.1.2

This table sets out what an assessor examines and asks for under each sub-requirement of 8.1, the evidence that usually satisfies it, and the findings that appear most often. Read it as a checklist of what to have ready before the assessment starts, since the assessor will test the documents and the people together.

Test step	8.1.1 policies and procedures	8.1.2 roles and responsibilities
What is examined	Written identification and authentication policy and the operational procedures under it	Roles and responsibilities record for every Requirement 8 activity
Currency and approval	Document shows an owner, an approval date and a review cycle that has actually been followed	Roles record is dated and approved by someone with authority over the program
Distribution	Evidence that affected staff received or can access the current version	Named owners are told of their assignment and have accepted it
Interview focus	Administrators and help desk staff explain the steps they follow in practice	Named owners describe their duties, handoffs and escalation paths in their own words
Evidence to prepare	Policy set, version history, distribution or acknowledgement records	RACI or equivalent matrix, assignment records, change history of the matrix
Common finding: stale policy	Policy exists but references retired systems, old tools or a superseded process	Matrix lists owners who have left or changed teams without an update
Common finding: unclear duties	Procedures are written but staff perform the task differently	Interviewee cannot explain their part or assumes another team owns it
Question to confirm early	Who approves each change to the policy and where the approved copy is kept	Who maintains the matrix and how often it is reviewed against HR changes

How to build the 8.1 policy set and roles record step by step

This sequence turns Requirement 8.1 into a documented, approved and communicated set of identification and authentication policies, backed by a roles record that assessors can examine and staff can explain. Each step ends with a named output that a QSA or internal assessor can check during testing.

Inventory identity and authentication processes in scope
Start by listing every process that identifies users or authenticates access to systems in the cardholder data environment and the systems that connect to it. This covers employee and administrator accounts, customer or partner access, remote access, and the identity providers, directories and single sign-on services that carry those decisions. Confirm the list against your current network and data-flow diagrams so that nothing in the CDE is missing. The output is a scope inventory that names each process, the systems it covers, and the team that operates it. You know the step is done when the inventory reconciles with the CDE system list and an owner is recorded for each entry.
Draft or revise the Requirement 8 policy and procedures
Using the inventory, write or update the identification and authentication policy and the operational procedures that carry it out. Map each procedure to the Requirement 8 sub-requirements it supports so that the document reads as a working method rather than a statement of intent. Ask your QSA or internal assessor which format they expect, and confirm whether your existing policy set already covers any of these topics. The output is a draft policy and a set of procedures with version numbers and a change history. The step is complete when every process in the inventory points to a procedure that describes how it is performed.
Assign owners and document roles and responsibilities
Name a responsible owner for each procedure and each Requirement 8 activity, such as account provisioning, MFA enrollment, access reviews and authentication configuration changes. Record who is responsible, who approves, who is consulted and who is informed, usually in a RACI matrix. Confirm that each named person accepts the role and understands what it involves, because assessors interview these people and test whether they know their part. The output is a documented roles and responsibilities record. The step is done when every activity has exactly one accountable owner and the record is signed off by the security leader.
Obtain formal approval of the policy versions
Route the policy, procedures and roles record through the approval path your organization uses for security documents, typically the security lead and an executive sponsor. Record the approver, the approval date and the version number on each document so that the approved version can be distinguished from drafts. Keep the approved copies in the controlled repository where the document owners maintain them. The output is a set of approved policy versions with an approval record. You know the step is complete when every document in the set carries an approved version and no unapproved draft is circulating as current.
Distribute the documents and record acknowledgement
Make the approved policies and procedures available to every affected party, including internal staff, administrators, and any service providers or contractors who perform Requirement 8 activities. Ask each recipient to acknowledge that they have read and understood the documents, and capture the acknowledgement with a name, a date and the version acknowledged. Follow up with anyone who has not responded and escalate through their manager. The output is an acknowledgement log tied to specific document versions. The step is done when the log covers every affected party listed in the roles record, with no gaps for people who hold Requirement 8 duties.
Set a review cycle and triggers for updates
Define how often the policies, procedures and roles record are reviewed and what events force an earlier review, such as a change to the identity provider, a new remote access method, a staff change in a named role, or a revision of the standard. PCI DSS v4.0.1 is the only active version, and the PCI SSC has announced no release date for a next version, so record which version your documents reference. Keep the version history in the repository so that an assessor can see what changed and when. The output is a review schedule with named owners and recorded trigger conditions. The step is complete when the schedule is stored with the policy set and the next review date is recorded on each document.

Which evidence passes 8.1 and how to keep it current between audits

Requirement 8.1 is judged on documents and on whether people know and follow them, so the evidence is a set of linked artifacts rather than a single policy. The cards below cover what an assessor asks to see and how to keep each artifact accurate between assessments.

Written identification and authentication policy

This is the policy that sets out how users are identified, how their access is authenticated, and which rules apply to passwords, factors and account handling across the cardholder data environment. For 8.1.1, the assessor compares it with what the systems actually do, so every rule in it should match a configuration you can show. Check that it names the systems in scope and that its review date is recent. Confirm the current version with your assessor, since the expected form of the policy depends on how your environment is scoped.

Operational procedures for identity tasks

Procedures describe the steps staff follow for everyday identity work: creating and changing user IDs, granting and removing authentication factors, resetting credentials, and reviewing lockouts. Each step should name the system used and the record left behind, such as a ticket or an approval entry. Assessors interview the people who run these tasks and compare their answers with the written steps. Procedures that describe a tool no longer in use are a common finding, so review them whenever the identity platform changes.

Roles and responsibilities record

Requirement 8.1.2 expects roles for Requirement 8 activities to be documented, assigned and understood. A RACI matrix is a practical format: it shows who is responsible, accountable, consulted and informed for each identity activity, such as approving access, administering the identity provider and reviewing authentication settings. Name people by role and keep a current list of the individuals holding those roles. Confirm that the matrix matches the actual handover of duties, because the assessor will ask the people named in it what they do.

Version history and change records

Version history shows what changed in a document, when, and by whom. A wiki or document system with built-in revision tracking, such as XWiki, keeps every change under version control and lets reviewers compare any two versions or roll back to an earlier one. This matters because assessors check that the policy in force during the assessment period is the one that was used. Keep the history intact rather than replacing pages, and record the reason for each material change in the page comment.

Approval and acknowledgement records

A policy becomes effective when someone with authority approves it, and staff must know it applies to them. Keep the signed or logged approval for each version, with the approver's role and the date. Distribution and acknowledgement records show who received the policy and procedures and confirmed they read them, which addresses the requirement that the documents be known to all affected parties. Use role-based permissions in the documentation platform so only approvers can publish, and check that acknowledgements cover contractors with access too.

Identity platform configuration exports

Exports from the identity provider show how authentication is set up in practice, which supports the written procedures without replacing them. For example, an authentik or FreeIPA configuration export can show which providers and sign-in sources are enabled, while the procedure explains who approves a change. Store exports under version control with dates, and confirm which settings each platform can export and in what format before you rely on them. Both platforms are open source under licenses you should review with counsel, and they are supporting tools, not evidence on their own.

What meeting 8.1 costs in money and effort

This table breaks down the cost components of meeting Requirement 8.1, who is paid for each one, whether it is one-time or recurring, and what drives it up. No prices or durations are supplied for this requirement, so use the rows to structure your internal estimate and your quote requests. The main takeaway is that the recurring review and acknowledgement work usually outlasts the initial drafting.

Cost component	Who is paid or who bears it	One-time or recurring	What drives it up
Drafting the identification and authentication policy and procedures	Your security or compliance staff, and any outside writer you engage	One-time, then recurring when revised	Number of identity systems and access paths covered by the procedures
Roles and responsibilities workshops	Internal owners from IT, security, HR and application teams	One-time, then recurring when roles change	Number of teams and third parties that touch user identity or authentication
Documentation and version control tooling	Licensing or hosting cost if commercial, or internal hosting time if self-hosted open source	Recurring (hosting and upkeep), with a one-time setup	Number of editors, required approval steps, and whether you run the platform yourself
Identity platform configuration that the procedures describe	Identity engineering staff or an implementation partner preparing the systems	One-time build, with recurring changes	Number of identity providers, directories and applications that must match the written procedures
Recurring review and staff acknowledgement	Policy owners and every affected party who must confirm they know the procedures	Recurring, usually on a set review cycle	Staff turnover, frequency of identity changes, and the number of affected parties
External review or assessor time	Your QSA or assessor, billed under the terms of the engagement	Recurring at each assessment cycle	Quality of the documents at first review and how many interviews the assessor must hold
Evidence collection for the assessor	Internal staff preparing exports, RACI records and version history	Recurring at each assessment cycle	Scattered records across tools without a single source of truth

What your team, a partner and the assessor each own for 8.1

Your organization owns Requirement 8.1 in full. The policy decisions about how users are identified and how access is authenticated belong to you, as do the roles that carry those activities and the proof that the people affected know what the rules are. A partner can propose wording, but a policy that no one with authority has approved will not hold up when an assessor asks who signed it and when it was last reviewed.

Policy decisions: Set the identification and authentication rules for your environment, including who may hold accounts and how strong authentication must be.
Role assignments: Name the people accountable for Requirement 8 activities and confirm they accept those responsibilities.
Staff acknowledgement: Collect evidence that affected personnel have read and understood the procedures, and repeat this when the documents change.
Review cadence: Decide who reviews the documents, how often, and what triggers an earlier update.
Approval records: Keep signed or otherwise attributable approvals for each version.

Check that every policy and role named in your documents has a real owner who can answer questions about it in an interview.

Where organizations fall short on 8.1 and how to close each gap

Requirement 8.1 is less about technology than about whether the paperwork describes how identity and authentication work today. The gaps below recur across assessments, and each one usually surfaces when an assessor compares a document with what staff actually do. Check each item against your own environment before the assessor does.

Policies written for a previous environment

An identification and authentication policy that describes an on-premises directory, a retired VPN or a password rule set that no longer applies tells the assessor the document was never maintained. Under 8.1.1, the policies and operational procedures must be kept up to date and in use. Fix this by mapping each statement in the policy to a system you can point to today, such as the current identity provider, the current MFA method and the current account review process. Remove or rewrite any statement you cannot tie to a live control.

Roles that name people who have left

A roles and responsibilities record that lists a former administrator or a departed security lead shows that 8.1.2 is not being maintained. Assessors look for roles that are assigned and understood, so a name that no longer works in the organization raises the question of who actually performs the activity. Fix this by assigning each Requirement 8 activity to a role rather than a person, then attaching the current holder of that role. Set a review trigger for staff changes so the record is updated when people move.

No record that staff read the procedures

Documentation that exists but has no acknowledgment trail is hard to defend, because the standard expects the procedures to be known to all affected parties. An assessor will usually interview a sample of staff who perform identity tasks, such as account administrators and help desk agents, and ask what the procedure says. Fix this by requiring a recorded acknowledgment for each affected role when a procedure is published or changed, and keep the list of who was notified. Confirm the acknowledgment method with your assessor before you rely on it.

Documents stored in personal drives

Policies kept in personal folders or email attachments have no change history, so no one can show which version was in force on a given date. Assessors need to see that documentation is current and controlled, which is difficult to prove without versioning. Move the policy and procedures into a wiki or document system that records each change, who made it and when, and that allows rollback. Restrict edit rights to the owners of the document and keep an approved copy of each version for the assessment period.

Roles record that does not match actual approvers

A RACI matrix that names one approver while the change system shows another is a common finding. The gap means the documented role and the operating role have drifted apart, and the assessor will test both. Compare the roles record with the approval settings in your ticketing, identity and change tools, then correct whichever source is wrong. Check the approval chain for identity changes such as new privileged accounts, since that is where mismatches usually hide.

Split identity duties with no shared record

When an outsourced provider runs directory administration or MFA enrollment while the internal team owns policy, responsibility can fall between the two. Each party may assume the other is performing a check, and neither keeps a record. Fix this with a single responsibility record that names who performs each identity activity, who approves it and where the evidence sits, and that both parties sign off on. Contracts with providers should reference that record. Ask the provider to confirm which activities it controls and which it only supports.

Questions buyers ask about 8.1 cost, effort and outside help

How much effort does requirement 8.1 take compared with the technical Requirement 8 controls?

Requirement 8.1 is mostly documentation and coordination work, so it usually takes less engineering time than the controls in 8.2 through 8.6, but it touches more people. The two sub-requirements ask for a current identification and authentication policy, operational procedures that are in use and known to affected staff, and documented roles and responsibilities. Engineering effort rises when the existing procedures do not match how accounts are actually created, changed and removed. Ask any partner to estimate effort from a written scope that lists the systems, teams and existing documents involved, and ask how that estimate changes if the procedures must be rewritten rather than updated.

Can an internal team complete 8.1 without an outside partner?

Yes, an internal team can write and maintain the policy, procedures and roles record without a partner, provided it has the authority to make the documents binding and access to the people who run identity operations. The harder parts are proving the documents are in use and known to affected staff, which requires interviews and records of how work is actually done. Teams without a recent PCI DSS assessment often underestimate that step. A partner can prepare the documents and evidence, but the organization owns the policy and the assessor tests it independently.

What does the work need from the compliance and identity teams?

The compliance team owns the policy framework, the approval path and the link to the assessment, while the identity team supplies the actual procedures for provisioning, changing and deprovisioning accounts and for authentication. Both teams should agree who signs each document and who answers assessor interview questions. In practice this means a named owner for the policy, a named operator for each procedure and a reviewer who checks that the written steps match the systems. Confirm these owners in writing before drafting begins, because unclear ownership is the most common reason documents stall.

How long does it take to get the 8.1 documents approved and distributed?

The duration depends on how many approval layers the organization has, how many teams must sign off and how quickly the identity and operations staff can review drafts. PCI DSS does not set a calendar for approval, so the schedule is an internal decision that the assessor will test against the documents in force on the assessment date. Ask a partner for a timeline built from your approval steps, and confirm how distribution and acknowledgment are tracked, since the procedures must be known to affected parties. Any duration quoted without knowing your approval chain should be treated as a starting point only.

Can a partner write the policy and still stay independent of the assessor?

A partner can help write the policy and procedures, but it cannot also issue the assessment result. Only the Qualified Security Assessor completing the Report on Compliance or the assessor performing the validation can judge whether requirement 8.1 is met. Ask the partner to confirm in writing that it will not perform the assessment, and ask the assessor how it will treat documents the partner prepared. Keeping the roles separate protects the organization's credibility with the assessor and avoids conflicts about who tested what.

What should a RACI matrix for requirement 8 contain?

A RACI matrix maps each Requirement 8 activity to who is Responsible, Accountable, Consulted and Informed. For 8.1 it should list activities such as maintaining the identification and authentication policy, approving account procedures, provisioning and deprovisioning users, reviewing MFA configuration and handling exceptions. Each row should name a role rather than only a person, carry an owner and a review date, and match the actual procedures. Assessors typically check that the matrix exists, is current and that the people interviewed understand their assigned roles.

What should a quote for 8.1 work include?

A quote should state the scope in writing, including which systems, business units and documents are covered, and which deliverables you will receive. Ask for the following:

Each document to be drafted or updated, with its owner and approval step
The evidence set the work will produce, such as the policy, procedures and roles record
Who performs staff interviews and how records of acknowledgment are kept
Assumptions about existing documents and access to identity staff
What the work excludes, including assessment, certification and ongoing reviews
Whether any recurring support is included or offered as a separate retainer

DeployOpen plans and documents engagements against a written scope before work starts, and it prepares evidence for an assessment but does not issue validation.

How DeployOpen prepares 8.1 evidence for your assessment

DeployOpen helps organizations prepare the written policies, procedures and roles records that Requirement 8.1 expects, and the open-source systems that keep them current. The organization owns its policies and its assessment outcome, while only a QSA or the applicable validation process issues the report or attestation.

How we scope

Engagements are fixed-scope, with the 8.1 deliverables and documents agreed in writing before work starts.
We confirm which systems, teams and third parties touch the cardholder data environment for Requirement 8.
We map which documents already exist, which are outdated and which have no owner today.

How we build

We draft identification and authentication procedures for 8.1.1 for your review and approval by your own policy owners.
We set up version-controlled documentation so each policy change records what changed, when and by whom.
We configure role-based permissions in the documentation platform so only assigned owners can approve changes.

How we hand over

We deliver the 8.1 policy set, procedures and a roles and responsibilities record, such as a RACI matrix, for your assessor to examine.
We document the team interviews needed to show staff understand their assigned Requirement 8 responsibilities.
We provide a handover session that walks your staff through where each record lives and who maintains it.

How we support

Ongoing support, upgrades and reviews of the 8.1 documentation are available as a retainer.
We can review policies at the cadence your assessment plan sets, so records stay current between assessments.
Ask your QSA which evidence format they accept before we finalize the document set.