13 Education, Training and Awareness: HITRUST requirements

What HITRUST domain 13 requires for education, training and awareness

If you are preparing for an e1, i1 or r2 and need the training domain to score well, start with this: domain 13, Education, Training & Awareness, is counted in every HITRUST certification score, and it covers everyone with access to the environment in scope, not only the security team. In plain terms, the domain asks whether people who touch the in-scope systems know what is expected of them, have been trained for their role, and are kept up to date as threats and systems change. That population usually includes employees, contractors, developers, system administrators, and support staff who can reach production data or administrative consoles.

Training is a common scoring gap because it is easy to treat as an annual slideshow. Assessors look for more than completion records. They expect a defined audience for each training type, role-based content for developers and administrators, a way to show who was trained and when, and a process for people who miss the training or change roles. Start by building a list of everyone with in-scope access, sorted by role, and compare it with your training records. Gaps between that list and the records are the first thing to close. Confirm with your assessor how they expect sampling to work for your population, since the handbook sets the rules for evidence and sampling.

Plan for the domain to grow if your scope includes AI systems. HITRUST's AI Security Assessment help page places AI security requirement statements in this domain, so an e1, i1 or r2 with the AI security certification adds requirements here. Decide early whether your staff who build, operate or use AI tools need separate training content, and record who completed it. Your training platform should be able to show completion by person, course and date. Open-source learning management systems such as Moodle can track activity completion, though you should verify that the completion conditions you configure produce evidence your assessor will accept before relying on them.

Who must be trained for the HITRUST training domain

Domain 13 covers everyone whose work touches the in-scope environment, and the population is set by your scope statement, not by your org chart. The cards below separate the groups that most often get missed, and they flag the one responsibility that stays with you even when a provider supplies course material.

Workforce members with in-scope access

Start with every employee who can log in to, administer, or handle data from the systems named in your HITRUST scope. Build the list from identity provider group memberships and data access grants, not from department headcount, because access often reaches beyond the team that owns the system. Check the list against leavers and movers each quarter so that new access triggers training before it is used. Confirm with your assessor how they expect you to evidence the population, since the sample they pull will come from it.

Developers building the scoped applications

Engineers who write, review or deploy code for in-scope applications need role-based secure development training, not only general awareness. Map the topics to the stack you actually run, such as authentication flaws, input handling and secrets management in your repositories and pipelines. Include contractors who commit code to scoped repositories. Ask your assessor whether AI-assisted coding tools and the people who configure them fall within this group in your scope.

System administrators and privileged operators

Administrators who change configurations, manage backups, or hold privileged credentials carry risks that general staff do not. Their training should cover privileged account handling, change control on production systems, and the procedures they must follow during incidents. Record the privileged roles separately from ordinary users so that a reviewer can see that the people with the most power received the most targeted instruction. Keep their training records tied to the access reviews in your access control program.

Contractors and temporary staff

Contractors, consultants and temporary workers who use your systems are inside the training population for as long as they hold access. Their onboarding should require the same core awareness content as employees, and their access should end when the engagement ends. Many organizations miss this group because contractors sit outside HR systems. Agree in writing who delivers and records their training, whether you or the agency, and confirm that the agency's records can be produced on request.

Third-party staff who touch the environment

Vendor personnel who remotely support, maintain or monitor systems in scope are part of your workforce for training purposes. Your contract should require them to complete training equivalent to yours, or you should provide it, and you should keep evidence that they did. Domain 13 training does not transfer to a provider simply because the provider holds its own certification. Coordinate this with the third-party assurance domain so that vendor access, training and reviews are tracked together.

Ownership of the training program

Even when a provider supplies course content, the training program remains yours to run, and HITRUST's inheritance guidance treats this domain as one that a provider cannot inherit on your behalf. Your responsibilities include deciding the audience, approving the content, tracking completion, and following up on people who fall behind. Ask any provider for documentation of the material, but keep the completion records and the enforcement process in your own systems. Before you hire outside help, confirm with your assessor which parts they expect you to own.

How an assessor tests domain 13 training evidence

This table compares what an assessor examines for each training element in domain 13, what evidence they ask for, and where organizations usually fall short. Read it as a preparation checklist: each row is a question the assessor will try to answer with records, not with policy statements.

Test area	What the assessor checks	Evidence usually requested	Common finding
Training policy and scope	Whether a documented policy defines who must be trained, on what topics and how often, and whether it covers staff, contractors and administrators	Approved training policy, scope statement, version history and management approval	Policy exists but does not name contractors or administrators with access to the in-scope environment
Role-based curricula	Whether developers, system administrators and privileged users receive content tied to their duties, not only general awareness	Curriculum by role, mapping of roles to modules, and course content with dates	One generic course is assigned to every role, including engineers who deploy production changes
Awareness content	Whether topics such as phishing, handling of in-scope data and incident reporting are current and reflect the organization's own environment	Course materials, release dates, and records of content updates after relevant incidents or system changes	Materials are years old and describe systems that have since been retired
Completion tracking	Whether the organization can show who completed which training, when, and whether gaps are followed up	Learning management system exports, completion reports with timestamps, and overdue lists with escalation records	Completion is recorded as viewing a page rather than passing an assessment or confirming understanding
Coverage of privileged users	Whether administrators and others with elevated access completed training before or shortly after access was granted	Access grant records alongside training dates for the same individuals	Privileged users are untrained or trained only after their access was already active
Contractors and third-party staff	Whether people who reach in-scope systems through contracts receive equivalent training or evidence of it from their employer	Contractor roster, contract clauses, training attestations or records held by the provider	No records exist for contractors, even though they operate production systems
AI security training (where applicable)	If the AI security certification is in scope, whether staff who build, operate or use AI components received training on the requirements added for AI systems	AI-specific course content, role assignments and completion records for AI-related staff	AI training is planned but not delivered to the teams that deploy models or agents

How to build a training program that passes domain 13

This sequence turns training from a general awareness course into a documented program that covers everyone with access to the in-scope environment. Each step produces an artifact an assessor can sample, from the list of people in scope to the records that show they were trained and tested.

Identify roles with environment access
Start by listing every role that can reach systems, data or administrative functions inside the assessed scope. Include employees, contractors, developers, system administrators, support staff and anyone with privileged access, and cross-check the list against identity and access records so nothing is missed. The output is a role inventory that names each role, the systems it touches and the person accountable for it. Confirm the list with HR, IT operations and the people who own the assessed environment before moving on.
Define role-based curricula
Write a curriculum for each role group so that the content matches the risks that role creates. General staff typically need awareness on phishing, credential handling and reporting, while developers need secure coding and secrets handling, and administrators need privileged access practices and secure configuration. The output is a short curriculum document per role with learning objectives, the policies it references and the owner who approves it. Ask your assessor early whether they expect AI security content for roles that build or use AI systems in scope, because that content sits in this domain.
Deploy awareness and role training
Deliver the curricula through a learning platform that can assign courses by role, host the material and report on who has completed it. Self-hosted open-source learning management systems such as Moodle can do this inside your own environment, which keeps training records under your control. The output is a live course set mapped to role groups, with enrollment rules that assign the right course to each new joiner and each role change. Confirm that the platform's enrollment and reporting features meet your needs before you commit to a design.
Track completion against the role inventory
Compare training completion with the role inventory on a regular schedule, not only at audit time. Completion tracking in Moodle, for example, can mark an activity complete when a learner views it, receives a grade or ticks it manually, depending on the conditions set for the activity. Choose the completion condition that reflects real learning for each course, since a page view alone may not show understanding. The output is a completion report that lists each person in scope, their assigned courses and their status, with overdue items escalated to the role owner.
Test understanding and remediate gaps
Add knowledge checks, such as graded quizzes or scenario questions, so that completion reflects understanding. Review results by role group to find topics where many people fail, then update the curriculum or the course content and retrain the affected group. Simulated phishing exercises can add evidence of behavior, though their design and reporting need to be agreed in advance. The output is a set of assessment results and a record of the corrective changes made, which shows that training is measured and improved rather than simply delivered.
Retain records and prepare evidence
Keep the role inventory, curricula, enrollment rules, completion reports, assessment results and remediation records together, with dates and version numbers. Store them in a location that the assessor can access and that you can preserve for the period the assessment covers. The output is an evidence folder organized by domain 13, where each training requirement can be traced to a course, a population and a completion record. Ask your independent assessor what sampling approach they will use and what format they expect, since the evidence needs to hold up when they select individuals to test.

Choosing how training is delivered and recorded

A commercial learning management system is licensed from a vendor and usually hosted by that vendor, although some offer deployment inside your own tenancy. Completion records sit in the vendor's system, and subscription and content licensing fees recur as long as the platform is used. The assessor will want to see who was assigned each course, when each person completed it, and whether those records can be produced for the full review period. Your organization still owns the training program, even when the vendor hosts it.

Completion trigger: Confirm whether the platform records completion when a module is opened, when a quiz is passed or when an attestation is signed, and document which trigger your policy relies on.
Export and retention: Confirm you can export user-level completion history with dates and course versions for the whole period under review.
Vendor scope: If the platform stores workforce identities or training records, it handles in-scope data and belongs in your Third-party Assurance review.
Identity linkage: Check that learner accounts map to directory identities, so records match the people who hold access to the environment.
Recurring cost: Seat or user licenses scale with headcount and usually renew on a fixed cycle, so ask for them as a separate recurring line in any quote.

Before committing, pull a sample completion report and confirm it produces the names, dates and course versions an assessor would sample.

Evidence that satisfies domain 13 and how to keep it current

Assessors test domain 13 by asking for proof that the right people were trained, when they were trained and what they were trained on. The cards below cover the artifacts that carry that proof and the routines that keep them accurate between validated assessments.

Training curricula by role

Keep one curriculum per audience: general staff, developers, administrators and anyone with privileged access to the in-scope environment. Each curriculum should name its learning objectives, its delivery method and its version date, so an assessor can see what content applied when. Review the curriculum whenever the CSF version, a policy or a tooling change alters the expected behavior. Ask whether your AI security content, if you pursue that add-on, appears in the developer and administrator tracks.

Role-to-training matrix

A role matrix maps each job function to the training modules it must complete and the frequency at which it must repeat them. It is the document that lets an assessor confirm that a new administrator did not skip the privileged-access module. Tie each role to the access groups in your identity system, so that a change in role triggers a change in required training. Gaps usually appear where contractors and shared service accounts are not listed.

Completion records with dates

Completion records show who finished which module and on what date, exported from the learning system with timestamps intact. Open-source learning platforms such as Moodle can record activity completion when a learner views an activity, receives a grade or ticks it manually, depending on how each activity is configured. Confirm which trigger your configuration uses, because a page view and a passed quiz are different evidence. Store exports outside the learning system so they survive platform changes.

Quiz results and attestations

Quiz scores and signed attestations show that learners understood the material or accepted responsibility for it. Keep the question bank versioned so you can show which questions each learner answered, and retain the passing threshold used at the time. For policies that must be acknowledged, record the attestation text, the version of the policy and the timestamp. An assessor will look for failed attempts and retakes, so do not discard them when a learner later passes.

Awareness campaign materials

Campaign materials include phishing simulations, posters, newsletters and short briefings, along with the schedule that shows when each ran. Record the audience, the message and the results, such as click rates or reporting rates, and what the team changed in response. Materials prove the program is active between formal training cycles. Keep a dated archive so that a campaign from a past period can be shown as it appeared at the time.

Contractor and access list linkage

Contractors and temporary staff with access to the in-scope environment need the same training evidence as employees. Reconcile your training records against the access list at least each time access is reviewed, so that any account without a completion record is flagged before an assessor finds it. Record the contractor's sponsoring manager, the date access was granted and the date training was completed. Confirm with your assessor how they expect contractor training to be evidenced, since responsibility for it may sit with the contracting organization.

What the AI security certification adds to domain 13

HITRUST's AI Security Assessment places AI security requirement statements in the Education, Training and Awareness domain, so an organization pursuing the AI security certification alongside an e1, i1 or r2 must show that people who build, operate or administer in-scope AI systems have received training that fits their role. The domain you already prepare for does not stop at general security awareness once AI is in scope. It also has to reach the engineers, data scientists, prompt and agent developers, and platform administrators who touch those systems.

Start by listing who in your environment falls into those roles. For each group, separate the general awareness content every employee receives from the role-based content that addresses how AI components fail or get abused, such as handling sensitive data in training or retrieval pipelines, reviewing model outputs, and securing tool access granted to agents. Keep records that show who completed which module, when, and with what result, because an assessor will sample those records against the people who actually have access to the AI environment. Confirm with your assessor and in MyCSF exactly which AI security requirement statements land in domain 13 for your assessment type and CSF version, since the wording and the count can change between CSF releases.

Plan for this work early, because training content for AI roles is often new and needs owners, review cycles and evidence that is current when the assessor arrives. Ask your assessor how they expect you to show that content reflects the AI systems you actually run, and whether any AI-related modules will be tested as a sample. Your internal training owner and the technical leads for each AI system should agree on the curriculum before fieldwork begins, so that the training records and the system inventory tell the same story.

What meeting domain 13 costs in money and effort

This table breaks down the cost components of meeting domain 13 in the HITRUST CSF, showing who is paid for each, whether it is one-time or recurring, and what moves it up or down. Use it to build a quote request and to decide which parts to buy, build or outsource. No fixed prices are shown because none were supplied for this domain.

Cost component	Who is paid or who carries it	One-time or recurring	What drives it up or down
Training content or course licenses	Commercial e-learning vendor, or internal staff if content is written in-house	Licenses usually recur per seat or per year; content build is one-time	Number of role tracks, languages and whether content is custom or off the shelf
Open-source LMS hosting	Your cloud account or data center team, or a DeployOpen engagement if scoped in writing	Hosting recurs; initial setup is one-time	Learner count, backup and retention needs, and whether the LMS sits inside the assessed scope
Engineering to link completions to access	Internal engineers or an implementation partner under a fixed-scope agreement	One-time integration, with recurring upkeep when identity systems change	Number of systems that gate access on training, and how many identity sources feed them
Role-based training for developers and admins	Internal security leads or external trainers	Recurring, usually at least annually and after role changes	Size of privileged and developer population, and depth of secure coding or AI security content
Internal instructor and reviewer time	Internal staff, paid through payroll rather than invoices	Recurring	Frequency of refresher cycles, quiz review and exception handling for late completions
Completion evidence upkeep	Compliance or security staff who sample records each cycle	Recurring	Whether completion data is exported automatically or collected by hand from several tools
External review of content and records	Independent consultant or readiness reviewer, if engaged	Usually one-time before fieldwork, then as needed	Scope of pre-assessment review and how mature the records already are
Assessor fieldwork	Authorized HITRUST External Assessor, paid by the organization	Recurs with each validated assessment cycle	Sampling of training records and the number of in-scope staff whose records are tested

Where organizations fall short on training and how to close it

Training gaps rarely come from missing courses. They come from records that do not match who actually touches the in-scope environment, training that is not linked to access, and content nobody has reviewed. Each card below names one gap an assessor is likely to find and the action that closes it.

Contractors missing from training records

Contractors, temporary staff and outsourced administrators often receive access to in-scope systems without entering the employee training system. An assessor who samples people with access and asks for their training record will find the gap quickly. Reconcile the access list from your identity provider against the training roster each quarter, and include contractors, managed service staff and vendor accounts. Confirm with your assessor which population they will sample before the fieldwork window opens.

Privileged administrators without role training

Administrators who change firewall rules, manage identity directories or restore backups often hold the most sensitive access and the least formal training. A general awareness course does not show that they understand privileged handling, break-glass procedures or change approval. Assign role-based modules to each administrative role, record completion against the named role, and require it before privileged access is granted or renewed.

Training not tied to access

Many organizations track training as an annual event that runs alongside access provisioning rather than as a condition of it. The result is staff with live access whose training is overdue, or new joiners who work for weeks before completing their first course. Make training completion a gate in the joiner and mover workflow, and have the access review report flag any account whose holder is out of date.

Completion recorded without evidence of learning

A course marked complete in the learning system does not prove that the learner viewed the content or passed an assessment. Moodle, for example, can mark an activity complete on viewing, on receiving a grade or on a manual tick, depending on how the activity is configured. Choose the completion condition that matches the control, such as a graded quiz for role-based content, and keep the configuration as part of your evidence.

Stale content and no refresh cycle

Training material that describes last year's phishing patterns, retired tools or an old incident process is a common finding. Assessors look for evidence that content is reviewed on a set schedule and after material changes such as a new CSF version, a new platform or a new AI tool in scope. Record who reviews each module, the review date and the change log, and retire content that no longer matches the environment.

AI security training missing from scope

When an AI security certification is in scope, requirement statements in this domain add expectations for people who build, deploy or operate AI systems. Teams that use AI tools in the assessed environment often receive generic awareness training only. Confirm with your assessor which AI requirements apply, then add role content for developers and operators covering the risks of the systems they run, and keep records that show it was delivered.

Who owns domain 13, who helps and where the assessor stops

Your organization owns domain 13 in full. Education, training and awareness is one of the 19 assessment domains that HITRUST uses to group requirement statements and score certification, and it is not inheritable in HITRUST's own OCI inheritance example. A cloud provider can supply documentation about its own staff training, but it does not train your workforce, so your people, contractors and administrators need training that you design, deliver and record.

Program ownership: Name an accountable owner for the awareness and role-based training program and document who approves its content.
Audience definition: List every group with access to the in-scope environment, including staff, developers, administrators and contractors.
Delivery and records: Run the training, track completion and keep dated records for each person.
Role-based content: Give developers, administrators and staff different material that matches their access and duties.
AI security content: If you pursue the AI security certification, plan additional requirement statements that also sit in this domain.

Check that each training record ties to a named person, a dated course and a defined audience, because the assessor will sample against those fields.

Questions buyers ask about HITRUST training requirements

How much effort does domain 13 training take to get ready for a HITRUST assessment?

Domain 13, Education, Training & Awareness, usually takes less effort to build than technical domains, but the effort is spread across the whole workforce. The work has three parts: writing a training program that covers general security awareness, adding role-based training for staff, developers and administrators with access to the in-scope environment, and keeping proof that each person completed it. The largest recurring cost is time: every new hire, role change and contractor needs training records, and every refresher cycle has to be run and documented. Ask any provider to scope these three parts separately so you can see which one drives the hours.

How long does preparing the training domain take before a validated assessment?

The time depends on how much training already exists and how many roles touch the in-scope environment. Organizations with a documented awareness program and a learning platform that records completions usually need to confirm coverage, fill role-based gaps and collect a consistent sample of records. Organizations that start from informal onboarding often need to write the program first. The validated assessment fieldwork window is at most 90 days for e1, i1 and r2 under the HITRUST Assessment Handbook, but preparation happens before that window opens. Confirm your readiness timeline with your assessor and your implementation partner in writing.

Can our internal team handle HITRUST training controls without outside help?

Yes, many internal teams can build and operate the training program themselves, since domain 13 depends mostly on policy, content and records rather than specialized tooling. Outside help is most useful for mapping role-based training to the requirement statements, setting up completion evidence on your learning platform and running a readiness review before the assessor arrives. Only an Authorized HITRUST External Assessor can perform the validated assessment submitted for certification, and HITRUST performs central quality assurance before issuing reports, so the assessment itself cannot be done by your team or an implementation partner.

Can training requirements be inherited from a cloud provider?

Generally no. HITRUST's Oracle Cloud Infrastructure inheritance example classes Education, Training & Awareness as not inheritable: a provider can supply documentation, but it does not train your workforce. Your staff, developers and administrators who reach the in-scope environment need their own training records. Provider training may still help with the provider-side portion of your shared responsibility matrix, so ask your provider exactly which statements they document and which remain yours before you plan the work.

What does the AI security add-on change for training?

The AI security add-on adds requirement statements to domain 13. HITRUST's AI Security Assessment help page places AI security requirements in this domain, so an e1, i1 or r2 that includes the AI security certification expands the training content and the people it must reach. Expect training to cover how staff and developers handle AI systems in scope, including the risks of the tools they use. Confirm the exact statements that apply to your scope in the current MyCSF requirement set, since the add-on changes with CSF versions.

How does domain 13 affect whether we pass the assessment?

Domain 13 is scored like every other domain, so weak training evidence can pull down the result. For e1 and i1 certifications, the core requirement statements in each domain must average at least 83, while an r2 requires each domain to average at least 62 across all its requirement statements. Gaps usually come from incomplete completion records, missing role-based content for administrators or training that exists only as a policy. Ask your assessor which statements count as core for your chosen assessment before you start collecting evidence.

Can open-source learning tools produce training evidence?

Yes, a self-hosted learning platform can record evidence, but it has to be configured for it. Moodle, which is GPL-3.0-or-later, has activity completion that marks an activity complete when a learner views it, receives a grade from it, or ticks it manually, depending on the conditions set for the activity. Choose the completion condition that matches your policy, since a view-only completion may not prove understanding. Confirm with your assessor that the records and retention meet the requirement statements in your scope.

How DeployOpen prepares training evidence for domain 13

DeployOpen's part in domain 13 is to make the training program provable before the assessor arrives. The first step is scoping the workforce: working with the client to list every person who can reach the in-scope environment, including staff, developers, administrators and, where relevant, contractors, then grouping them by role. Role-based training only makes sense once that population is fixed, so the roster, the role mapping and the training requirement for each role are written down as the starting evidence. The client decides which roles need which courses and who approves them. DeployOpen documents the decisions and flags gaps, such as administrators with privileged access who have no role-specific module.

If the client chooses a learning platform, DeployOpen can deploy an open-source option such as Moodle inside the client's own cloud account, data center or air-gapped network, so training records stay in the environment being assessed. Configuration covers enrollment, course content, quizzes and the completion conditions. In Moodle, activity completion can be set to mark an activity complete when a learner views it, receives a grade, or ticks it manually, so the team should choose the condition that matches what the organization can prove. DeployOpen then configures reporting exports that show who completed what and when, and tests that those reports reproduce correctly. Confirm with the client whether the platform's vendor offers any support or hardening terms that matter to their own third-party review.

DeployOpen prepares the evidence package the assessor will sample: role mappings, course records, completion exports, policy acknowledgments and the records of any awareness campaigns. DeployOpen does not issue reports or certifications. Only an authorized HITRUST External Assessor performs the validated assessment, and the organization owns its training program and its answers to the assessor. Engagements are fixed-scope, so the roles covered, the platform work, the evidence deliverables and the timeline are agreed in a written quote before work starts. Ask any preparation partner, DeployOpen included, to show exactly which records they will produce and who will keep them current after handover.

13 Education, Training and Awareness