Acceptable Use Training

PCI DSS requires your security awareness training to explicitly cover acceptable use of end-user technologies, aligned to your acceptable use policies (PCI DSS v4.0.1 Requirement 12.6.3.2). Operationalize it by defining “end-user technologies” in scope, mapping training content to your acceptable use policy, assigning completion requirements by role, and retaining completion and content evidence for assessor testing.

Key takeaways:

• Training must teach acceptable use of end-user technologies and align to your acceptable use policy (PCI DSS v4.0.1 Requirement 12.6.3.2).
• Assessors will test both content coverage and operating effectiveness (who took it, when, and what it contained).
• The fastest path to compliance is a tight policy-to-training mapping plus clean evidence: roster, modules, attestations, exceptions, and follow-up.

“Acceptable use training” under PCI DSS is not a generic security awareness module. Requirement 12.6.3.2 ties your training content directly to the acceptable use expectations you documented under Requirement 12.2.1, and it expects that people who touch your environment understand what they can and cannot do with end-user technologies (PCI DSS v4.0.1 Requirement 12.6.3.2). For a Compliance Officer or GRC lead, the practical challenge is rarely writing a policy; it’s proving the policy is translated into training that is assigned, completed, and repeatable, with evidence that survives assessor scrutiny.

This page is written to help you implement the requirement with minimal ambiguity: who must be trained, what topics must be covered, how to structure assignments by role, and what artifacts you should retain. The goal is a training control that works during steady-state operations, not a one-time scramble at assessment time. Where helpful, it also flags the examiner and QSA “hangups” that commonly cause a requirement to be marked as not met, even when a training program exists.

Regulatory text

PCI DSS states: “Security awareness training includes awareness of acceptable use of end-user technologies in accordance with Requirement 12.2.1.” (PCI DSS v4.0.1 Requirement 12.6.3.2)

What that means for an operator

• You must have security awareness training content that covers acceptable use of end-user technologies.
• The training must be consistent with, and traceable to, your acceptable use policies (the acceptable use expectations you maintain under Requirement 12.2.1).
• During assessment, you should expect content testing (what the training says) and population testing (who took it, when, and whether exceptions are controlled).

Plain-English interpretation (requirement intent)

You need to teach your workforce (and others in scope) the rules for using company-approved devices, systems, and services in a way that protects payment data and the environments that process it. The training has to match your written acceptable use rules. If your policy prohibits storing cardholder data on endpoints, your training must say that plainly. If your policy requires locking screens, patching, or bans unapproved software, the training must cover those expectations in language a non-security employee can follow.

Who it applies to (entity and operational context)

This requirement applies to organizations in scope for PCI DSS, including merchants and service providers, and to the people whose actions can affect the security of the cardholder data environment (CDE) (PCI DSS v4.0.1).

In-scope audiences typically include

• Employees and contractors with access to CDE systems, CDE-connected networks, or administrative tooling that can change security posture.
• Operations staff (IT, SRE, helpdesk) who provision endpoints, manage identity, or support remote access.
• Developers who use end-user technologies that could introduce malware or data exposure pathways (workstations, source control access, collaboration tools).
• Third-party personnel with logical access (support engineers, managed service providers), if their access can impact the CDE (PCI DSS v4.0.1).

Operational contexts that raise the bar

• Remote workforce and BYOD patterns (even if BYOD is “not allowed,” you need training that reinforces the rule and the exception process).
• High endpoint privilege populations (local admin, developer workstations, IT admins).
• Environments where collaboration tools, file sync, screenshots, or screen recording are common, because those can conflict with acceptable use and data handling expectations.

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

1) Define “end-user technologies” for your environment

Create a short, explicit list you will use consistently across policy, training, and evidence. Common examples:

• Laptops/desktops, mobile devices, tablets
• Email, collaboration tools, browsers
• Password managers, MFA apps
• Remote access tooling
• Removable media and peripherals
• Printing and scanning workflows

Keep the list aligned with how your acceptable use policy is written under Requirement 12.2.1, because assessors will compare them (PCI DSS v4.0.1 Requirement 12.6.3.2).

2) Map policy statements to training learning objectives

Build a one-page mapping table. This becomes your assessor “bridge” artifact.

Example mapping format (you can copy/paste):

Acceptable use policy statement (Req 12.2.1)	Training module/slide	Learner action expected	Evidence produced
“Only approved devices may access corporate systems.”	Acceptable Use: Devices	Use managed endpoint; request exception via ticket	LMS completion + policy attestation
“No storage of cardholder data on endpoints.”	Data Handling + Acceptable Use	Use approved payment systems only	LMS quiz question + acknowledgment
“Lock screen when unattended.”	Endpoint Hygiene	Enable auto-lock; lock manually	Quiz + endpoint baseline reference

Your training does not need to quote the policy verbatim, but it must clearly cover the same rules (PCI DSS v4.0.1 Requirement 12.6.3.2).

3) Set role-based assignment rules

Create assignment logic that matches real risk:

• Baseline acceptable use training for all workforce members with corporate endpoints or corporate accounts.
• Enhanced track for privileged users (IT admins, security, developers with elevated access), focusing on risky tools: scripting, remote admin, logging into production, handling secrets on endpoints.

Make the assignment rule deterministic: tied to HR role, identity group, or access profile. Avoid manual spreadsheet targeting unless you can prove completeness.

4) Deliver training and require an acknowledgment

Minimum operating components:

• Training module(s) that include acceptable use topics aligned to your acceptable use policy (PCI DSS v4.0.1 Requirement 12.6.3.2).
• Acknowledgment/attestation that the learner understands and will follow acceptable use rules.
• A quiz or knowledge check is not explicitly stated in the excerpt, but it is a practical way to demonstrate understanding if an assessor challenges training effectiveness.

5) Operationalize joiner/mover/leaver (JML) triggers

Most “we do training” programs fail on new hires and transfers. Implement triggers:

• Joiners: training assigned automatically on onboarding, before access to sensitive systems where feasible.
• Movers: assignment changes when privileges or role changes.
• Leavers: access removed; training records retained per your retention practices.

6) Control exceptions and document compensating behavior

You will have exceptions (temporary contractors, urgent access, incomplete training). Treat them as controlled deviations:

• Track exceptions in tickets with an owner, rationale, and remediation due date.
• Apply interim safeguards (restricted access, increased monitoring, supervised sessions) based on your risk tolerance.
• Close the loop with completion evidence.

7) Build an assessor-ready evidence pack (repeatable)

Create a single folder (or GRC object) that you refresh before assessment:

• Current acceptable use policy version
• Training content export (slides, module outline, screenshots)
• Role-to-training assignment logic
• Completion reports and sampling-ready rosters
• Exception tickets and resolutions

If you use Daydream to manage controls and evidence requests, set this requirement up as a recurring evidence task with a standardized checklist, so the “policy-to-training mapping” and “completion population report” are collected consistently year to year.

Required evidence and artifacts to retain

Keep artifacts that prove content, coverage, and operation:

Content evidence

• Acceptable use policy (and revision history) that the training aligns to (PCI DSS v4.0.1 Requirement 12.6.3.2).
• Training module content (LMS export, PDFs, screenshots, or versioned SCORM package).
• Policy-to-training mapping table (the fastest way to answer assessor questions).

Coverage and completion evidence

• Training assignment rules by role/group (documented logic, not tribal knowledge).
• Completion reports from the LMS for in-scope personnel.
• Attestations/acknowledgments captured per user.

Operational evidence

• JML procedure showing how training is assigned at onboarding and role changes.
• Exception records: tickets, approvals, follow-up, closure evidence.

Common exam/audit questions and hangups

Expect these, and pre-answer them in your evidence pack:

1. “Show me where acceptable use of end-user technologies is covered.” Provide the mapping table and training export (PCI DSS v4.0.1 Requirement 12.6.3.2).
2. “Who is required to take it?” Provide the in-scope roster definition and role-based assignment logic (PCI DSS v4.0.1).
3. “Prove completion for a sample.” Provide LMS completion records, plus attestations.
4. “How do you handle new hires and transfers?” Show onboarding workflow and automated assignment triggers.
5. “What about contractors/third parties with access?” Show that third-party identities are included in training assignments or covered by equivalent contractual/training mechanisms consistent with your program scope (PCI DSS v4.0.1).

Frequent implementation mistakes (and how to avoid them)

Mistake 1: Acceptable use policy exists, but training is generic

Fix: Add an “Acceptable Use” module section that directly covers your policy’s do/don’t list and maps to Requirement 12.2.1 content (PCI DSS v4.0.1 Requirement 12.6.3.2).

Mistake 2: Training is assigned, but population is incomplete

Fix: Tie training assignment to your identity provider groups or HRIS job codes. Periodically reconcile the LMS roster against active accounts with corporate email or endpoint enrollment.

Mistake 3: No version control for training content

Fix: Version training like a policy. Keep “what was live when” artifacts. Assessors may sample past completion and ask what content the learner saw.

Mistake 4: Exceptions are informal (“we remind them later”)

Fix: Create an exception workflow with approvals, time limits, and closure evidence. Treat it like any other compliance exception.

Mistake 5: Third-party access is ignored

Fix: If third-party users have logical access that can impact the CDE, include them in training or document an equivalent training/attestation requirement contractually and retain proof (PCI DSS v4.0.1).

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement. Practically, the risk is still concrete: weak acceptable use training increases the likelihood of endpoint-driven incidents (malware, credential theft, unsafe remote access behaviors) and creates an evidence gap during PCI DSS assessments. If you cannot prove training aligns to your acceptable use policy and was completed by in-scope personnel, assessors can mark the control as not met (PCI DSS v4.0.1 Requirement 12.6.3.2).

Practical 30/60/90-day execution plan

First 30 days (stabilize scope and content)

• Confirm your acceptable use policy statements that relate to end-user technologies (Requirement 12.2.1 dependency) (PCI DSS v4.0.1 Requirement 12.6.3.2).
• Define “end-user technologies” list for your environment and scope.
• Draft the policy-to-training mapping table.
• Update or create the acceptable use training module content and acknowledgment.

By 60 days (make it operational)

• Implement role-based training assignments in your LMS.
• Implement onboarding and role-change triggers so assignments are automatic.
• Run a completion campaign for the current population; track exceptions in tickets.
• Build the assessor-ready evidence pack and store it in a single system of record (a GRC tool like Daydream, a controlled repository, or both).

By 90 days (prove control effectiveness)

• Perform an internal sample test: pick a cross-section of roles (including privileged users and third-party accounts) and verify training completion and content version evidence.
• Fix gaps found in roster completeness and exception handling.
• Schedule recurring reviews: policy changes trigger training updates; training updates trigger evidence refresh for the next assessment cycle.

Frequently Asked Questions

Does PCI DSS require a standalone “acceptable use” training course?

The requirement is that security awareness training includes acceptable use of end-user technologies aligned to your acceptable use policy (PCI DSS v4.0.1 Requirement 12.6.3.2). That can be a standalone module or a clearly labeled section within a broader security awareness course.

Who counts as “end-user technologies” users for training assignment?

Define this based on your environment, then apply it consistently across policy, training, and scoping. In practice, anyone with a managed endpoint, corporate identity, or access that can affect the CDE should be evaluated for inclusion (PCI DSS v4.0.1).

How do we handle third-party support engineers who access our systems?

If their access can affect the security of the CDE, include them in your training assignments or require equivalent training/attestation and retain proof. Your assessor will want to see how you ensured coverage for that population (PCI DSS v4.0.1).

What evidence is most likely to satisfy a QSA quickly?

A policy-to-training mapping table plus an export of the training content and an LMS completion report for the sampled users. Add exception tickets if any sampled users were overdue (PCI DSS v4.0.1 Requirement 12.6.3.2).

Our acceptable use policy changed. Do we need to retrain everyone immediately?

Update the training content to match the new policy and document when the updated module went live. Whether you require immediate retraining depends on your change significance and risk posture, but you should be able to show alignment from that point forward (PCI DSS v4.0.1 Requirement 12.6.3.2).

We use multiple LMS platforms across subsidiaries. Can we still meet the requirement?

Yes, if you can demonstrate consistent content coverage and produce completion evidence across all in-scope populations. Standardize the mapping table and evidence pack format so assessment sampling does not become a data chase (PCI DSS v4.0.1 Requirement 12.6.3.2).