Open source LMS for PCI DSS security awareness: what requirement 12.6 asks of your training
A self-hosted LMS can run the PCI DSS 12.6 security awareness program, provided it records who completed which training, when they acknowledged the security policy, and when the program itself was reviewed. If your organization is a merchant, processor or service provider, your assessor will ask for those records, so the platform has to produce them on request. Requirement 12.6 is organized into five sub-requirements: 12.6.1 asks for a formal awareness program, 12.6.2 for a yearly review of that program, 12.6.3 for training with personnel acknowledgment at least once every 12 months, 12.6.3.1 for training on phishing and social engineering, and 12.6.3.2 for training on acceptable use. Sub-requirements 12.6.2, 12.6.3.1 and 12.6.3.2 were best practices until 31 March 2025 and are now assessed as required, so none of them can be treated as optional in your current assessment.
The PCI Security Standards Council owns the standard but does not validate compliance or impose penalties. Your Qualified Security Assessor or your validation process, and the payment brands that set the rules for your entity, decide whether your evidence meets the standard. Treat the LMS as the system of record for the program, not as the compliance decision. It can deliver the training, track completion against the policy version each person acknowledged, and hold the review records, but it does not make the organization compliant. The gaps usually sit in the content: confirm that your phishing and social engineering modules and acceptable use material are written for your own environment, and that the multiple communication methods 12.6.3 expects are documented in your program design.
Before you scope a build, confirm three things with your assessor: which sub-requirements apply to your entity type and validation path, which evidence format they accept, and how they expect acknowledgments to be captured, such as an electronic attestation tied to a policy version. Then check that your LMS can store completion dates, policy versions and reviewer sign-offs with a retention period your assessor agrees to, and that administrators cannot silently edit those records. An implementation partner should be able to map each sub-requirement to a course, report or procedure in writing before work begins.
Mapping requirement 12.6 to LMS functions and configuration
This table maps each part of PCI DSS requirement 12.6 to what the awareness function must do and how to configure a self-hosted LMS such as Moodle to produce the evidence. Read each row as a design input for course assignment, completion rules and reporting. Confirm the exact control wording against the official SAQ D or ROC for your assessment before you finalize the configuration.
| Requirement | What the function must do | How to configure the LMS |
|---|---|---|
| 12.6.1 Formal awareness program | Maintain a documented security awareness program that personnel receive when they join and on an ongoing basis. | Create a named program category with a course set, an owner, and a written program document. Enroll new hires through cohort or HR-driven enrollment so every person in scope gets the baseline course at onboarding. |
| 12.6.2 Yearly program review | Review the awareness content and program at least once every 12 months and update it for new threats and changes to the environment. | Store course versions, change history and review sign-off in a dated record. Use a yearly review task or calendar item that is tied to the program category, and keep the review minutes with the course set. |
| 12.6.3 Training and policy acknowledgment | Deliver training through multiple communication methods and obtain each person's acknowledgment, at least every 12 months, that they have read and understood the security policy. | Assign the annual course with a 12-month recurrence and a completion rule that requires a policy acknowledgment activity, such as a quiz or signed policy activity. Set reminders before the due date and an escalation to managers for overdue users. |
| 12.6.3.1 Phishing and social engineering | Train personnel to recognize phishing and social engineering attempts and to report them. | Build a module with scenario content, knowledge checks and a reporting procedure. Add role-based variants for staff who handle payments, customer support and refunds, and record completion with the module version. |
| 12.6.3.2 Acceptable use | Train personnel on the acceptable use of end-user technologies as defined by the organization's policies. | Publish an acceptable use course tied to the current policy version. Require acknowledgment through a signed activity, and reassign the course when the policy version changes. |
How the LMS runs the 12-month awareness cycle
The annual cycle starts with a complete and current roster. Every person in scope for PCI DSS, including staff, contractors and administrators with access to the cardholder data environment, needs an account and an enrollment before the first course opens. Under Requirement 12.6.3, the acknowledgment that personnel have read and understood the security policy must recur at least once every 12 months, so the platform has to show, for each person, when the last acknowledgment happened and when the next one falls due. Moodle core ships manual accounts, email self-registration, external database, LDAP, LTI, OAuth 2 and Shibboleth authentication, so the implementer can tie accounts to the HR system of record through LDAP, OAuth 2 or Shibboleth. Then joiners and leavers are handled by the directory, not by manual lists. Confirm with the HR and identity owners which attribute marks a person as in scope before the first enrollment run.
Recurrence is the part that is rarely ready out of the box. In Moodle, enrollment methods, completion conditions and activity restrictions can be combined to release a course again after a set period, but a yearly re-enrollment cycle usually needs a configured scheduled process or a plugin, and the implementer should test how completion records behave when a course is reset. Open edX offers a similar pattern through course runs, certificates and enrollment settings, while third-party authentication covers OAuth2 providers, SAML 2.0, Shibboleth and LTI. Whichever platform is chosen, the reader should ask the partner to demonstrate a full cycle in a test environment: a learner is enrolled, completes modules, acknowledges the policy, and is re-enrolled before the 12-month window closes, with the earlier record still retrievable.
Delivery should mix methods, as Requirement 12.6.3 expects multiple forms of communication. The core course covers the policy and acceptable use, short modules cover phishing and social engineering, and reminders are sent through the LMS messaging or email. Phishing simulations can run through content on the LMS or through an integrated tool connected by LTI, but the simulation results must be linked back to the person's training record. Decide early who owns the policy text shown at acknowledgment, how versions are tracked so that a revised policy triggers a new acknowledgment, and how the acknowledgment is stored. The reader should confirm these decisions with the security and compliance owners before build, because they determine what the completion report can prove to an assessor.
Which open source LMS fits a PCI DSS awareness program
Requirement 12.6 asks for a formal awareness program that reaches personnel at least once every 12 months, with policy acknowledgment and training on phishing and acceptable use. The three open source LMS options below can each host that program, but they differ in release model, operating effort and fit with the rest of your identity and HR stack.
Moodle for most awareness programs
Moodle is licensed under GPL-3.0 and fits teams that want native enrollment, completion reporting and a large plugin catalog. Moodle 5.3 is the designated next long-term support release, with security fixes until 1 October 2029, which gives a long window for planning yearly review cycles. Moodle 5.3 requires 64-bit PHP 8.3 or later and PostgreSQL 17, MySQL 8.4 or MariaDB 11.4, and sites must run Moodle 4.4 or later to upgrade. Confirm phishing simulation support with the plugin vendor before you commit, because it is not a core feature to assume.
Open edX for engineering-led teams
Open edX is licensed under AGPL-3.0 and suits organizations with a strong engineering function that can run a Python, Django and Docker-based stack. Only the latest named release is supported, so you must plan for upgrades to Willow in December 2026 and Xylon in June 2027 on a regular cadence. Tutor is the common production path, and the maintainers note that bare-metal installation is complex. Check the reporting and phishing content options with your partner, since awareness completion reports are not the platform's primary use case.
Canvas LMS where Canvas already runs
Canvas LMS by Instructure is licensed under AGPL-3.0. It is the logical choice when your organization already operates Canvas for other training, because course structure, completion tracking and support processes are already established. Adding a separate self-hosted Canvas instance only for PCI DSS awareness usually duplicates effort, so weigh that cost against reusing an existing deployment. Confirm the self-hosting and support terms directly with the vendor or your hosting partner before sizing the work.
Let identity and HR decide
The right platform often depends less on course features than on how learners are identified and assigned. Check whether your directory supports SAML 2.0, OAuth 2, LDAP or LTI, and whether HR feeds role changes that should trigger new assignments. Moodle core covers LDAP, OAuth 2, Shibboleth and LTI, and Open edX supports SAML 2.0, Shibboleth and LTI through third-party authentication. Map every payment-relevant role, such as call center staff and developers with production access, to a course and an acknowledgment record before choosing the platform.
What assessors ask to see and which component produces it
This table maps the evidence an assessor typically requests for the security awareness program to the Moodle component that produces it and what to export and retain. Read it as a checklist to set up reports before the assessment, not after. Retention periods and export formats must be confirmed with your QSA or assessor, since they depend on the organization and the assessment scope.
| Evidence item | Which LMS component produces it | What to export and retain |
|---|---|---|
| Training completion records per person, with dates | Course completion reports and activity completion logs in Moodle | Named completion report per course with completion timestamps, exported on a fixed schedule and stored outside the LMS |
| Signed or recorded policy acknowledgments within the last 12 months | Acknowledgment activity or quiz with timestamped submission, or a plugin that records electronic acceptance | Acknowledgment text version, learner ID, date and time, and proof the acknowledgment is within the 12-month window |
| Training content and version history | Course backups, content revision history and the course content version in use at each completion date | Course backup files per release, change log of modules, and the exact content each learner completed |
| Phishing and social engineering module records | Quiz or SCORM/xAPI results for the phishing module, plus any simulation plugin results if used | Module version, scores, completion dates, and records of the scenarios covered; confirm with your assessor whether simulations count as evidence |
| Acceptable use training records | Dedicated course or activity with completion logs, linked to the acceptable use policy version | Policy version identifier, completion records, and mapping to the 12.6.3.2 topic |
| Yearly program review record | Not produced by the LMS; supported by exported reports, training metrics and change records kept by the security team | Review minutes, approvals, updates made to courses and policies, and dated sign-off by responsible management |
| Enrollment rosters matched to in-scope personnel | Cohort or enrollment lists synced from the HR or identity source, with course assignment history | Roster exports with dates of enrollment and removal, reconciled against the in-scope personnel list from HR or access records |
What the LMS alone does not satisfy
An LMS can deliver the training and keep the acknowledgment records for Requirement 12.6, but several parts of the program depend on documents, people and assessment decisions outside the platform. The cards below set out what remains with the organization and its assessor, and what to confirm before the program is scoped.
The written security policy and its content
Requirement 12.6.3 asks personnel to acknowledge that they have read and understood the security policy, but the LMS only records that acknowledgment. The policy itself must exist, be current and cover the topics the standard expects, including acceptable use. Check who owns the policy, how revisions are approved, and whether the course text matches the approved version so the acknowledgment refers to the right document.
The yearly program review
Requirement 12.6.1 expects a formal awareness program that is reviewed at least once every 12 months. That review is a governance decision: someone must assess incidents, phishing results, completion gaps and changes in the business, then record what changed. The LMS can supply completion and quiz data as inputs, but it cannot decide whether the program is still fit for purpose or sign off on changes.
Phishing simulation content and tooling
Requirement 12.6.3.1 expects training on phishing and social engineering, and many teams run simulated campaigns to test it. Moodle can host lessons and quizzes on these topics, but sending realistic simulated emails, tracking clicks and maintaining a content library are usually handled by a separate tool that the organization selects. Confirm which simulation product or content source will be used, where its data is stored, and whether it touches cardholder data systems.
Customized approach evidence
If the organization meets a requirement through the customized approach instead of the defined approach, the burden shifts to documentation. It must state the security objective, show how the alternative meets it, and retain evidence that assessors can review. An LMS feature list is not that evidence. Ask the assessor early whether the training design qualifies, and agree on what records, risk analysis and test results will be kept.
Scope of the LMS and the cardholder data environment
Whether the LMS sits inside the cardholder data environment determines which controls apply to it. An LMS that stores learner names with employee IDs, connects to HR systems or runs on servers shared with payment systems may be in scope, while a fully separated instance may not. Document the network path, identity source, data flows and administrator access, and confirm the scoping decision with the assessor before the platform is built.
Who decides, validates and completes the assessment
The PCI SSC publishes the standard but does not enforce compliance or impose penalties. The individual payment brands decide which entities must validate and run any enforcement programs, so the organization should confirm its obligations with its acquirer or brand contacts. The SAQ or Report on Compliance, with its Attestation of Compliance, is completed by the organization or a Qualified Security Assessor. DeployOpen prepares the systems and evidence but does not issue these documents.
How a 12.6 LMS rollout runs
The sequence moves from agreeing scope with the assessor to a first completed annual cycle and a documented yearly program review, so each phase produces evidence the assessor can test. Effort depends on the number of personnel, how much training content already exists and how complex the identity integration is.
Confirm scope with the assessor
Before any build work, agree with your Qualified Security Assessor or internal assessor which personnel, systems and locations sit inside the cardholder data environment and which assessment template applies, such as a Report on Compliance or a Self-Assessment Questionnaire. The partner documents the requirement mapping for 12.6.1 through 12.6.3.2 against that scope. Done means a signed scope note that names the awareness population and the evidence the assessor expects to see.
Map in-scope personnel from HR
Your HR system of record or identity directory becomes the source for who must be trained. Your team, with the partner, defines role groups such as call center staff, developers with production access and payment operations staff, and agrees how joiners, movers and leavers flow into the LMS. Done means a reconciled roster and a documented rule for automatic enrollment, with an owner for exceptions such as contractors.
Build the platform and integrate identity
The partner installs the chosen LMS (Moodle, Open edX or Canvas) in your own cloud account or data center, applies hardening and backup, and connects single sign-on to your identity provider so learners authenticate with corporate accounts. Enrollment and completion reporting are configured for each role group. Done means a tested build in a non-production environment with login, enrollment and report export verified by your security team.
Build policy acknowledgment and phishing content
Your security and compliance leads write or adapt the acceptable use and security policy acknowledgment, the phishing and social engineering modules and any role-specific material. Content is delivered through more than one method, such as short modules, reminders and simulated phishing exercises, so it meets the multiple-methods expectation of 12.6.3. Done means approved content, a version-controlled policy text and an acknowledgment step that records the learner, the policy version and the date.
Run a controlled pilot
A small, representative group completes every course, acknowledgment and reminder as a real learner would, and administrators test completion reports, overdue lists and exception handling. The partner records defects and the assessor reviews a sample of the evidence. Done means a pilot sign-off listing fixed issues, accepted report formats and the evidence pack template.
Enroll production and run the first annual cycle
The full in-scope population is enrolled from the agreed roster, and the first 12-month cycle begins. Your team tracks completion, acknowledgment dates and overdue learners, and the partner supports learner access issues and reminder schedules. Done means every in-scope person has a dated acknowledgment and training record, with exceptions documented and owned.
Complete the first yearly program review
Leadership reviews the awareness program against 12.6.2, covering incident trends, phishing results, changes to the policy, changes to personnel and the platform's upgrade status. The review updates content and the roster and sets the next cycle's plan. Done means a dated, signed review record filed with the evidence pack, ready for the assessor.
Questions buyers ask about PCI DSS awareness on an open source LMS
What does a self-hosted LMS for PCI DSS awareness cost, and what drives it?
The software itself carries no license fee for Moodle or Open edX, so the cost is the work and infrastructure around it. Expect recurring hosting in your own cloud account or data center, plus one-time setup, theming, and integration with your identity provider. Content authoring, phishing simulation content, upgrades and support are the other main line items. Cost rises with the number of people in scope, the number of distinct roles needing different courses, how many systems must integrate, and how much custom content you build. Ask any partner for a quote that separates one-time setup from recurring hosting, upgrades and support, and names who pays for each component.
Can our internal team run PCI DSS awareness training on an LMS alone?
Often yes for the training itself, but the platform work usually needs skills your team may not have in-house. Administering courses, assigning training by role, and pulling completion reports are routine tasks for an LMS administrator. Standing up the platform, keeping it patched, moving it to each new major release on schedule, and integrating it with identity and HR systems require server administration, database, and web hosting skills. Assess your team against those tasks before deciding. A fixed-scope partner engagement can cover setup and handover while your staff keep the program running.
How long does it take to get a PCI DSS awareness program running on an LMS?
Timing depends on the scope agreed in writing, not on a standard duration. The main drivers are the hosting environment you already have, how many identity and HR integrations are needed, how much existing content must be converted or written, and how many approval rounds your security and HR teams require. Phishing and social engineering content adds review time because it must reflect your own threats and policies. Ask a partner to show the phases, the dependencies on your teams, and the milestone where the first training cycle goes live.
What do HR, security and the QSA need from us for the LMS work?
HR must supply the accurate roster of personnel who need training, along with role and department data and leaver events so access and assignments stay current. Security must own the policy text employees acknowledge, the phishing and social engineering scenarios, and the acceptable use content, and must approve them. The Qualified Security Assessor or internal assessor needs access to the evidence, including the policy acknowledgment records, completion dates, and the yearly program review record. Agree early on the format of each evidence item, because assessors usually ask for the same records every cycle.
Does an LMS make us PCI DSS compliant?
No. An LMS is a tool that helps you run and record the security awareness program that Requirement 12.6 expects, but compliance depends on your whole environment and on an assessment. Only a Qualified Security Assessor completing a Report on Compliance, or a Self-Assessment Questionnaire with its Attestation of Compliance, can document validation, and the payment brands decide which entities must validate. DeployOpen prepares systems, controls and evidence for compliance assessments but does not issue audit reports, attestations or certifications.
Is Moodle or Open edX the better choice for PCI DSS awareness?
For most security awareness programs, Moodle is the more common fit because it offers straightforward course authoring, broad plugin coverage, and standard authentication options such as LDAP, OAuth 2, and SAML2 through a plugin. Open edX suits organizations that want a modular platform and already have engineering capacity, but it is generally deployed through a service provider or Tutor, and it supports only its latest named release. PCI DSS does not prescribe a platform. Choose based on your administrators' skills, your identity setup, and how you will keep the platform current.
How do we keep the LMS upgraded given the supported release windows?
Plan upgrades around the vendor's support windows, not around your audit date. Moodle publishes long-term support releases with security fixes for a defined period, and Moodle 5.3 is designated the next LTS with security support until 1 October 2029, per the Moodle releases page. Each major upgrade also raises PHP, database and web server requirements, and the web document root changed in Moodle 5.1, so test on a copy first. Open edX supports only its latest named release. Ask any partner how upgrades, backups and regression testing are scheduled and whether they are covered by a retainer.
What to confirm with your assessor and LMS partner before you start
Before you build anything, ask your Qualified Security Assessor or your acquirer which validation path applies to you. The choice between a Self-Assessment Questionnaire and a Report on Compliance determines how much evidence the assessor will expect and in what form. Confirm whether the LMS sits inside the cardholder data environment or connects to it, because a learning platform that holds staff identities, HR feeds or access to systems that touch card data can pull into scope. Also confirm whether the policy acknowledgment must be a signed record or whether a recorded electronic click-through is accepted, how long the acknowledgment and completion records must be kept, and whether you intend to use the customized approach for any part of requirement 12.6. A customized approach needs a documented objective and evidence that the alternative meets it, so agree that position with the assessor before you design the course flow, not after.
Ask your LMS partner how completion evidence is exported. You want to know which reports exist out of the box, which fields they carry (learner identity, course version, date of acknowledgment, policy version and score), whether exports can be produced on demand for an assessor, and whether the export format can be retained outside the platform for the full retention period. Ask in writing how the 12-month cycle is enforced: whether the platform automatically reassigns the policy acknowledgment and training when a year lapses, how leavers and new starters are handled, and who is alerted when a learner is overdue. Ask for a demonstration using a test account, and confirm that course and policy versions are preserved when content changes so that a past acknowledgment can still be tied to the text that was in force on that date.
How DeployOpen scopes, builds and supports a PCI awareness LMS
DeployOpen plans, implements, customizes, hardens, documents and supports self-hosted open-source LMS platforms inside your own infrastructure, so training records for PCI DSS requirement 12.6 stay under your control. Engagements start with a written scope that defines the courses, records, integrations and evidence before any build work begins.
How we scope
- Map the 12.6 sub-requirements to specific courses, assessments and acknowledgment steps in the written scope
- Confirm which staff roles, payment systems and cardholder data environment touchpoints need training and records
- Agree the target platform, hosting location and identity source in writing before work starts, with fixed scope and deliverables
How we build
- Configure the chosen LMS for annual policy acknowledgment, role-based enrollment and completion reporting
- Build phishing and social engineering modules and acceptable use content, tested with a sample of learners before launch
- Harden the server, database, backups and plugin set, and document each configuration decision for your assessor
How we hand over
- Deliver architecture, configuration, runbook and evidence-collection procedures as written documentation
- Walk your compliance and IT teams through completion report exports and how to answer an assessor's sample requests
- Provide a yearly program review checklist so your team can run the 12.6.2 review on a repeatable basis
How we support
- Offer ongoing support, upgrades and testing as a retainer, scoped separately from the initial build
- Plan upgrades around the platform's published support windows and test each release before it reaches production
- Confirm with your assessor which evidence they expect, since DeployOpen prepares evidence but does not issue assessment reports
