Personnel Security Training

PCI DSS 4.0.1 Requirement 12.6.3 requires you to run security awareness training for all personnel at hire and at least annually, use more than one communication method, and collect annual acknowledgments that people read and understand your information security policies and procedures (PCI DSS v4.0.1 Requirement 12.6.3). Operationalize it by defining scope, standardizing content, automating assignment/attestation, and retaining completion evidence.

Key takeaways:

• Training must happen upon hire and at least every 12 months, with tracked completion and exceptions (PCI DSS v4.0.1 Requirement 12.6.3).
• You must use multiple communication methods, not a single annual course (PCI DSS v4.0.1 Requirement 12.6.3).
• Annual acknowledgement of reading/understanding the information security policy and procedures is explicitly required (PCI DSS v4.0.1 Requirement 12.6.3).

“Personnel Security Training” is one of the fastest ways for a PCI assessor to test whether your security program is real or mostly paperwork. It is also one of the easiest requirements to fail through operational gaps: missed new hires, contractors not in HR systems, training that exists but can’t be proven, or “policy acknowledgment” that is informal and not retained.

PCI DSS 4.0.1 Requirement 12.6.3 is narrow but strict: it sets timing (upon hire and at least every 12 months), delivery expectations (multiple methods of communication), and a measurable output (acknowledgment at least annually that personnel have read and understood the information security policy and procedures) (PCI DSS v4.0.1 Requirement 12.6.3). This page translates that into an implementable program: who must be included, how to design the training and acknowledgment workflows, what evidence to retain, and what auditors ask when they want to see that it operates in day-to-day work.

If you already have annual training, focus on the two common misses: proving “upon hire” execution across all personnel populations, and demonstrating “multiple methods” beyond a single LMS module (PCI DSS v4.0.1 Requirement 12.6.3).

Regulatory text

PCI DSS 4.0.1 Requirement 12.6.3 (excerpt): “Personnel receive security awareness training as follows: upon hire and at least once every 12 months, and multiple methods of communication are used, and personnel acknowledge at least once every 12 months that they have read and understood the information security policy and procedures.” (PCI DSS v4.0.1 Requirement 12.6.3)

What the operator must do (in one view)

You need an operating process that:

1. assigns security awareness training at onboarding and reassigns it at least annually,
2. delivers awareness messages via more than one channel during the year, and
3. collects and retains annual attestation that personnel read and understood the information security policy and procedures (PCI DSS v4.0.1 Requirement 12.6.3).

Plain-English interpretation

Treat this requirement as a closed-loop system: assign, deliver, track, attest, and retain proof.

• “Upon hire” means new personnel must be trained as part of onboarding, not “whenever they get to it.” You should define what “hire” means for your environment (employee start date, contractor start date, access provisioning date) and then implement consistent triggers.
• “At least once every 12 months” means you must prevent training from drifting. Auditors look for lapses, not just averages.
• “Multiple methods of communication” means awareness cannot be only an annual CBT. You need at least one additional method (examples below) and you must be able to show it occurred.
• “Acknowledge … read and understood the information security policy and procedures” means an explicit annual attestation tied to the relevant policies and procedures, with evidence you can produce (PCI DSS v4.0.1 Requirement 12.6.3).

Who it applies to

Entities

Applies to organizations that store, process, or transmit payment account data, and to service providers whose people, processes, or systems can affect the security of the cardholder data environment (PCI DSS v4.0.1 Requirement 12.6.3).

Personnel populations (practical scoping)

Include any personnel who could affect the security of systems in scope for PCI, including:

• Employees (full-time/part-time/temporary)
• Contractors and consultants (including third-party staff with access)
• Interns
• Operations staff with logical access to PCI-scoped systems
• Engineers who deploy code or infrastructure that touches the cardholder data environment (CDE) or connected systems
• Support and customer service roles handling payment workflows

Common scoping hangup: “They don’t touch card data.” If they can administer, develop, or support systems that impact the CDE, they still matter under the requirement’s “personnel” framing (PCI DSS v4.0.1 Requirement 12.6.3).

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

1) Define ownership, scope, and training/attestation rules

Document, in one place:

• Control owner (typically Security/GRC; HR/People Ops as a key partner)
• In-scope personnel definition and sources of truth (HRIS, contractor management, IAM directory)
• Training timing rules: onboarding assignment trigger + annual retraining trigger (PCI DSS v4.0.1 Requirement 12.6.3)
• Acknowledgment requirement: annual attestation of reading/understanding the information security policy and procedures (PCI DSS v4.0.1 Requirement 12.6.3)
• Exception handling: leaves of absence, long-term contractors, mergers/acquisitions, off-cycle onboarding

2) Build an accurate personnel roster (the control fails without this)

Create a reconciled list of in-scope personnel. Minimum fields:

• Full name, email/unique ID
• Worker type (employee/contractor)
• Start date (or access start date)
• Department/role
• Manager
• Status (active/inactive)

Operational tip: assessors often sample from multiple sources. If HRIS shows 10 contractors but your LMS shows 7, you will spend the audit explaining the gap instead of passing.

3) Design training content that maps to your policy and procedures

Training must be “security awareness,” but the requirement explicitly ties you to your information security policy and procedures via acknowledgment (PCI DSS v4.0.1 Requirement 12.6.3). Make that linkage clean:

• Identify the policy/procedure documents covered by the annual acknowledgment
• Ensure training references the same topics and internal standards so “read and understood” is credible
• Maintain version control: what did someone acknowledge, and when?

Keep content modular:

• Core module (required for all personnel)
• Role-aware add-ons (engineering, support, finance) as needed for your risk profile

4) Implement two separate workflows: training completion and policy acknowledgment

Do not assume training completion equals policy acknowledgment. Build both.

Training workflow

• Assign at onboarding (automated)
• Set reminders and escalation
• Capture completion date, score (if used), and module version

Acknowledgment workflow

• Annual attestation in your LMS, GRC tool, or e-sign platform
• The attestation text should explicitly reference the information security policy and procedures and include “read and understood” language (PCI DSS v4.0.1 Requirement 12.6.3)
• Store the attestation record with user, timestamp, policy version/reference, and method

5) “Multiple methods of communication”: pick your mix and make it provable

You need more than one channel over the year (PCI DSS v4.0.1 Requirement 12.6.3). Choose methods that create evidence:

• LMS module (formal training)
• Security newsletters or targeted emails with tracked distribution
• Short internal posts in your intranet with view tracking
• Live security briefing sessions with attendance logs
• Phishing simulations with assignment and results records
• New-hire security orientation session with sign-in/attendance

Auditor-proofing rule: for each method, define what artifact proves delivery and what artifact proves receipt/participation (where applicable).

6) Run a monthly compliance check (lightweight, but consistent)

A monthly review reduces end-of-year scramble:

• Compare HRIS/IAM roster vs training/attestation completion list
• Identify new hires not assigned training
• Identify upcoming annual renewals and overdue personnel
• Log follow-ups and closures

7) Retain evidence in an auditor-friendly package

Do not bury proof across systems. Build an “audit binder” folder (or Daydream control record) with:

• Policy/procedure for personnel security training (owner, review cadence, approvals)
• Training content outline and current module links
• Report exports showing completion for onboarding and annual cycles
• Attestation exports showing “read and understood” acknowledgments
• Evidence of multiple communication methods (samples + distribution/attendance logs)
• Exception list and approvals

Daydream fit: if you already track controls in Daydream, create a single control record for this requirement with mapped evidence requests, automatic reminders for annual attestation, and a standing monthly roster reconciliation task. That keeps the control from degrading between assessments.

Required evidence and artifacts to retain

Use this as your minimum evidence checklist:

• Documented procedure for security awareness training and acknowledgment (PCI DSS v4.0.1 Requirement 12.6.3)
• Roster/scope definition of personnel required to complete training
• New-hire assignment proof (onboarding ticket, LMS assignment rule screenshot, or provisioning workflow evidence)
• Training completion report with dates and participant identifiers
• Annual acknowledgment report showing user, date/time, and the attestation language or policy reference (PCI DSS v4.0.1 Requirement 12.6.3)
• Multiple communication evidence (email campaign logs, phishing campaign dashboard exports, meeting attendance sheets, intranet post publication logs) (PCI DSS v4.0.1 Requirement 12.6.3)
• Version history and approvals for the training program documentation and relevant policies (PCI DSS v4.0.1 Requirement 12.6.3)

Common exam/audit questions and hangups

Expect these and prepare answers with artifacts:

1. “Show me the population.” How did you define all personnel in scope, including contractors?
2. “Prove training upon hire.” Pick a sample of recent hires. Show assignment date and completion.
3. “Prove annual cadence.” Show that no one exceeded the annual window without an approved exception (PCI DSS v4.0.1 Requirement 12.6.3).
4. “What are the multiple communication methods?” Show at least two methods and evidence of execution (PCI DSS v4.0.1 Requirement 12.6.3).
5. “Show acknowledgments.” Provide the attestation record and the policy/procedure documents referenced (PCI DSS v4.0.1 Requirement 12.6.3).
6. “What happens if someone doesn’t complete?” Show reminders, escalation, and access/HR consequences (if you have them).

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails	Fix
New hires complete training “sometime later”	“Upon hire” is not reliably met	Trigger training assignment from HRIS start date or access provisioning workflow (PCI DSS v4.0.1 Requirement 12.6.3)
One annual LMS course only	Doesn’t meet “multiple methods”	Add a second provable channel (phishing sim, newsletter, live session) and retain logs (PCI DSS v4.0.1 Requirement 12.6.3)
Policy acknowledgment is informal	No retained evidence	Use an attestation workflow with exports and audit-ready timestamps (PCI DSS v4.0.1 Requirement 12.6.3)
Contractors missing from the roster	Partial population means failure risk	Reconcile HRIS + procurement + IAM groups monthly
Training content drifts from policy	“Read and understood” looks hollow	Link training to policy sections and maintain version control
Evidence is scattered	Audit becomes a scavenger hunt	Centralize artifacts per requirement; Daydream can store evidence requests and recurring tasks

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement. Practically, the risk is assessment failure due to control operation gaps: you may have training content but can’t prove consistent assignment, completion, multi-channel awareness, and annual policy acknowledgment (PCI DSS v4.0.1 Requirement 12.6.3). That increases remediation workload and can delay attestation timelines with your acquirer or customers.

Practical 30/60/90-day execution plan

First 30 days (stabilize scope and mechanics)

• Name the control owner and document the training + acknowledgment procedure (PCI DSS v4.0.1 Requirement 12.6.3).
• Build the personnel roster and reconcile employees vs contractors.
• Confirm where training and attestation will live (LMS, GRC tool, e-sign).
• Draft the annual attestation text referencing your information security policy and procedures (PCI DSS v4.0.1 Requirement 12.6.3).
• Choose at least two communication methods and define evidence artifacts for each (PCI DSS v4.0.1 Requirement 12.6.3).

Days 31–60 (run the first operational cycle)

• Configure onboarding triggers for automatic training assignment.
• Launch annual training for current personnel and start collecting attestations.
• Run your second communication method (newsletter, phishing sim, live training) and store artifacts.
• Create a single audit binder (or Daydream record) with exports and screenshots.

Days 61–90 (make it durable)

• Implement monthly roster reconciliation and overdue follow-up workflow.
• Add escalation rules (manager notification, access gating, HR ticket) based on your internal governance.
• Review training content against the current information security policy/procedure set; update and re-approve if needed.
• Run a mock assessor sample test: pick personnel records and produce end-to-end evidence in one hour.

Frequently Asked Questions

Does “personnel” include contractors and third-party consultants?

Yes if they are part of your workforce and can affect the security of systems in scope for PCI. Treat contractors as in-scope unless you can justify exclusion based on access and role, and document that rationale (PCI DSS v4.0.1 Requirement 12.6.3).

What qualifies as “upon hire” in practice?

Define it as a consistent trigger you can prove, such as HR start date or first day of system access. Then automate assignment from that trigger so you can show the workflow operated for sampled new hires (PCI DSS v4.0.1 Requirement 12.6.3).

Can the annual policy acknowledgment be embedded inside the training module?

Yes if the attestation is explicit (read and understood), tied to the information security policy and procedures, and you can export evidence showing who attested and when. Many teams still separate it for clearer evidence and versioning (PCI DSS v4.0.1 Requirement 12.6.3).

What are acceptable “multiple methods of communication”?

Use at least two provable channels such as LMS training plus phishing simulations, newsletters with distribution logs, intranet postings with publication records, or live sessions with attendance. Pick methods that generate artifacts you can retain (PCI DSS v4.0.1 Requirement 12.6.3).

We have different policies for different business units. How do we handle acknowledgment?

Make the attestation conditional by role or business unit, and ensure each person acknowledges the correct policy/procedure set. Preserve the mapping (who saw what) alongside the attestation record (PCI DSS v4.0.1 Requirement 12.6.3).

What evidence should we hand an assessor without being asked?

Provide the procedure, the roster definition, completion and attestation exports, and one folder showing proof of each communication method. If you can produce those quickly from Daydream or your LMS, the assessment conversation usually stays focused (PCI DSS v4.0.1 Requirement 12.6.3).