Captioning cybersecurity training video: MITRE ATT&CK, CVE identifiers, NIST framework vocabulary, and why security content has the highest proper-noun ASR failure rate in corporate L&D

Why security training vocabulary breaks ASR: the identifier class problem

The vocabulary in corporate L&D training content that breaks ASR falls into three categories, each with a distinct failure mechanism. The first category is domain jargon — technical terms that are real words in a general dictionary but used with specialised meaning (buffer overflow, privilege escalation, threat model). ASR handles these well because the underlying words are represented in the training corpus, and the phonetic pattern is well-conditioned. The second category is invented proper nouns — company names, product names, tool names — which fail when the phonetic pattern does not match any prior training signal. The third category, unique to cybersecurity and a few adjacent verticals, is identifier-class vocabulary: structured alphanumeric codes that name things within a taxonomy (CVE-2024-21762, T1059.001, AC-1, DE.CM-7). This third category is where cybersecurity training captioning fails most severely, and the failure mechanism is fundamentally different from the failure mechanisms in the other two categories.

Identifier-class vocabulary fails because ASR is trained to transcribe speech — to convert acoustic signals to natural language text. A MITRE ATT&CK technique ID like T1059 is not natural language text. When a security trainer says "T-1059" aloud, they are producing a sequence of sounds that a general-purpose ASR model has never seen mapped to the token "T1059." The ASR encounters a letter ("T"), spoken slowly or with emphasis, followed by four digits spoken individually or as a number. Its training corpus shows this pattern most often in contexts like sports scores, phone numbers, or date references — so the output reflects those prior probabilities. The result is something like "T 10 59" (decomposed to two numbers) or "tee ten fifty-nine" (fully phonetised), neither of which preserves the identifier's taxonomic meaning.

The Whisper accuracy benchmarks by vertical show that cybersecurity content ranks second in overall proper-noun error rate, behind clinical pharmacology but ahead of legal, engineering, and financial services content. The breakdown by error type reveals why: cybersecurity content has the highest identifier-class error rate of any vertical tested, while its invented-proper-noun error rate (for vendor and tool names) is comparable to engineering content but higher than healthcare content. The overall error rate figure understates the severity of the identifier-class problem because identifiers are binary — a CVE reference is either correct or it is wrong, and a wrong CVE reference is completely non-functional. A mildly incorrect drug name in a training caption is a quality issue; a wrong CVE identifier in a patch management training module is an accuracy catastrophe that renders the caption useless for learners who need to act on the information.

The failure modes in cybersecurity content also interact in ways that amplify total error rate. A sentence like "In the incident report, the adversary leveraged CVE-2021-44228 to establish a beachhead using T1190, then used T1059.001 to execute the PowerShell payload" contains three identifier-class tokens, two technique IDs, a CVE reference, and mixed natural-language context. ASR with no domain conditioning transcribes the natural-language elements correctly, which makes the garbled identifiers more disorienting — the surrounding text is perfect but the specific identifiers, the only part a learner needs to be able to copy or reference, are wrong. This phenomenon — technically called the reference failure in captioning quality contexts — means that even caption tracks that pass simple word-error-rate metrics may contain systematic failures on the most operationally important vocabulary in the content.

The proper-noun failure mode taxonomy identifies six classes of proper-noun captioning failure; cybersecurity training content exhibits at least five of the six simultaneously: invented-word splitting (CrowdStrike → "crowd strike"), phonetic substitution (Vectra → "vector"), decomposition failure (T1059.001 → "T 10 59.001"), numeral parsing failure (CVE-2024-21762 → "CVE twenty twenty-four twenty-one seven six two"), and abbreviation expansion failure (SIEM → "seem"). The one class it exhibits less often is homophone confusion, because most cybersecurity vocabulary does not have natural-language homophones. The combination of multiple simultaneous failure modes is what makes cybersecurity content the most challenging L&D vertical for captioning quality without domain-specific glossary intervention.

MITRE ATT&CK captions: technique IDs, tactic names, and the taxonomy that defeats standard ASR

The MITRE ATT&CK framework is the most widely referenced adversarial behaviour taxonomy in corporate cybersecurity training. Published by MITRE Corporation and updated multiple times annually, ATT&CK (Adversarial Tactics, Techniques, and Common Knowledge) currently contains 14 tactics, more than 200 techniques, and hundreds of sub-techniques, each assigned a structured identifier. The framework is foundational vocabulary in threat intelligence training, SOC analyst certification prep, purple team exercises, and security operations onboarding — any organisation running security operations training is producing or purchasing content that references ATT&CK identifiers regularly.

The ATT&CK identifier system uses a predictable format that is systematically hostile to standard ASR. Technique IDs follow the pattern TNNNN (four digits after the letter T), and sub-technique IDs follow TNNNN.NNN (three additional digits after a period separator). Tactic IDs follow TANNNN (the prefix "TA" before four digits). When spoken aloud, these identifiers produce acoustic patterns that the ASR model must map to text without any prior conditioning on the TNNNN token format. The consistent failure pattern across Whisper, Google STT, and Azure Speech Services is decomposition: the letter prefix is preserved as a letter, and the numeric suffix is parsed as a spoken number. T1059 becomes "T 10 59" or "tee ten fifty-nine"; T1059.001 becomes "T 10 59.001" or "T 10 59 point zero zero one"; TA0001 becomes "TA zero zero zero one" or "T A zero zero zero one."

The technique name itself — the natural-language description that accompanies the ID — transcribes much better because it uses natural English words. "Command and Scripting Interpreter" (the name for T1059) is a four-word phrase in the ASR training corpus and is usually transcribed correctly. "Exploit Public-Facing Application" (T1190) is similarly natural language. The problem arises when trainers use technique IDs and names together (the most common usage in advanced security content: "T1059, Command and Scripting Interpreter") or when they use IDs alone as shorthand. In the latter case, the ID appears in the caption as a garbled number sequence with no accompanying technique name to provide context.

Sub-techniques add a second decomposition problem beyond the base technique ID. T1059 has nine sub-techniques, from T1059.001 (PowerShell) through T1059.009 (Cloud API). The period separator in the sub-technique ID is not reliably transcribed — it becomes a spoken "point" or "dot" or is dropped entirely. T1059.001 in security training might appear in a caption as "T 10 59.001," "T 10 59 point zero zero one," "T 10 59 dot zero zero one," or "T 10 59 zero zero one" depending on the speaker's pronunciation and the ASR engine. None of these are the correct token, and none can be looked up in the ATT&CK knowledge base. The sub-technique that corresponds to the learner's current study topic is invisible in the caption.

The glossary approach for ATT&CK identifiers requires registering the full technique name as the canonical output token, with the ID as the triggering surface form. The customer glossary architecture for ATT&CK content uses the technique name as the primary glossary entry — "PowerShell" for T1059.001, "DCShadow" for T1207, "Mimikatz" for references to the tool — rather than attempting to condition ASR on the identifier format directly. This works because the technique names are natural language and the ATT&CK knowledge base provides the canonical name for every ID. The ID appears correctly in the transcript when the trainer says the ID followed immediately by the technique name, because the natural-language name triggers the correct glossary entry and the reviewer corrects the preceding ID in the post-processing QA pass.

The ATT&CK tactic names — Initial Access, Execution, Persistence, Privilege Escalation, Defense Evasion, Credential Access, Discovery, Lateral Movement, Collection, Exfiltration, Command and Control, Impact, Reconnaissance, Resource Development — are all natural-language phrases that ASR transcribes correctly in most conditions. When a trainer uses tactic names without IDs, caption quality on the structural elements is high. The failure appears at the technique and sub-technique level where the ID is the primary reference. Training content that consistently uses technique names rather than IDs produces better caption output — not because the quality of the training has changed, but because natural language transcribes better than identifier-class tokens. This observation is useful for organisations reviewing their security training content for captioning risk before a large batch submission.

The iterative glossary improvement feedback loop that compounds accuracy over time has a structural advantage for ATT&CK vocabulary: MITRE publishes the complete ATT&CK knowledge base as a machine-readable STIX 2.1 JSON file (available at attack.mitre.org/resources/working-with-attack/). The technique ID and technique name for every entry in the framework can be extracted programmatically and used to seed an ATT&CK glossary section in the captioning system. Rather than manually building ATT&CK vocabulary from individual training videos, an organisation can ingest the full ATT&CK knowledge base as a glossary seed and immediately condition the ASR output on all current technique names. When the ATT&CK framework is updated (new sub-techniques added, technique names revised, technique IDs deprecated), the same JSON feed provides the update. This is the only L&D vertical where a complete, authoritative, machine-readable glossary source is publicly available at no cost.

CVE identifiers: the numeral parsing failure and how to prevent it

Common Vulnerabilities and Exposures (CVE) identifiers are the primary reference system for software vulnerabilities in corporate security training. Every security awareness module that discusses a real-world breach references CVE identifiers; every patch management training module tells employees which CVEs are being addressed by the patches they are asked to install; every incident response training walkthrough that uses a historical case study references the CVE or CVEs associated with the exploited vulnerability. The National Vulnerability Database (NVD), maintained by NIST, publishes approximately 25,000–30,000 new CVE identifiers annually, and high-profile CVEs generate training content that may remain in active circulation for two to five years after the initial disclosure.

The CVE identifier format follows a fixed pattern: the prefix "CVE," a hyphen, a four-digit year, a hyphen, and a variable-length integer (typically five to seven digits for recent high-profile vulnerabilities). The full token "CVE-2021-44228" has three components: the prefix (correctly transcribed by most modern ASR as "CVE" because the abbreviation is common in technical speech), a year (usually transcribed correctly as a four-digit year), and a numeric suffix (the problem component). The suffix "44228" is parsed by ASR as a spoken number sequence, not as a fixed identifier. Spoken number parsing produces outputs like "forty-four two twenty-eight," "forty-four thousand two hundred and twenty-eight," or "four four two two eight" depending on the speaker's phonetic pattern and the ASR engine's number normalisation behaviour. The correct transcription is the raw digit sequence in the CVE format: "44228" as part of the token "CVE-2021-44228."

The most commonly referenced CVEs in security training content include a set of high-profile vulnerability disclosures that have acquired common names alongside their CVE identifiers:

CVEs with common names create a two-part reference pattern in training content that partially mitigates the identifier failure. A trainer who says "Log4Shell, which is CVE-2021-44228" gives the learner the common name first — and "Log4Shell" is a natural-language token that ASR transcribes correctly — followed by the formal CVE identifier. In this pattern, a learner who sees the common name transcribed correctly can recover the CVE reference even if the numeric suffix is garbled. The problem arises in two scenarios: content that references the CVE identifier without the common name (more common in advanced security operations training that assumes familiarity with vulnerability nomenclature), and content that references a CVE that does not have a widely-used common name (the majority of the 25,000+ CVEs published annually).

The analogy to drug identifier captioning in healthcare is instructive. The medical training video captioning post covers how drug name identifiers — NDC codes, RxNorm codes — fail in clinical training content with the same decomposition failure pattern as CVE identifiers. The parallel extends to the glossary approach: just as the medical glossary registers the drug name as the primary output token and the identifier code as a triggering surface form, the cybersecurity glossary registers the CVE common name (where one exists) and the correct CVE format string as conditioning inputs. For CVEs without common names, the glossary must include the full CVE-YYYY-NNNNN token with its correct format as the canonical output, and the QA pass must explicitly verify CVE format preservation.

The chemical identifier parallel from the HazCom captioning guide is equally relevant: CAS registry numbers (7439-97-6 for mercury, 67-64-1 for acetone) follow the same format — a prefix, hyphens, and a numeric identifier — and fail with the same numeral parsing decomposition. The captioning community has more experience with CAS numbers in EHS training content than with CVE identifiers, but the fix is the same: register the identifier as a glossary token, verify format preservation in QA, and use human review for all identifier-dense segments.

The CVE glossary update problem is more severe than the ATT&CK glossary update problem because CVEs are published continuously rather than on a quarterly update schedule. An organisation that produces security training content about a newly disclosed vulnerability within days of the CVE publication — a common scenario for security operations teams who use training as part of their incident response communication — will have a CVE reference in their training content before the glossary has been updated. The workflow implication: for any security training module that references a specific CVE, the CVE identifier must be added to the glossary before the captioning submission, not after. A post-production glossary update fixes the glossary for future submissions but does not correct the already-submitted batch. The LMS caption audit methodology covers the retrospective audit workflow for content where the glossary was not current at submission time.

NIST framework vocabulary: CSF functions, categories, subcategories, and SP 800-53 control codes

NIST publishes two primary framework documents that appear extensively in corporate cybersecurity training content: the Cybersecurity Framework (CSF) and Special Publication 800-53. The CSF provides a risk management structure built around five functions (Identify, Protect, Detect, Respond, Recover) organised into categories and subcategories identified by structured codes. SP 800-53 provides a security control catalogue used by federal agencies and widely adopted in private sector compliance frameworks, with controls identified by two-to-four character family codes followed by a numeric sequence. Both documents use identifier-class vocabulary that fails in ASR with the same decomposition mechanism as MITRE ATT&CK identifiers, but with a different character-class composition that produces different failure patterns.

The CSF 1.1 identifier structure uses dot-separated function and category codes followed by hyphen-separated subcategory numbers. The Detect function (DE) with the Continuous Monitoring category (CM) and subcategory 7 produces the code DE.CM-7. Spoken aloud, this is "D-E dot C-M dash 7" or "Detect dot Continuous Monitoring dash 7" depending on the trainer's convention. The former produces "D E C M 7" in ASR output — each letter spoken individually with the separators dropped. The latter is more problematic because "Detect dot Continuous Monitoring dash 7" suggests to ASR that the structure is natural-language prose with a numeral at the end, producing correct transcription of the English words but missing the compact code format. NIST released CSF 2.0 in February 2024, adding a sixth function — Govern (GV) — and revising the category and subcategory structure, which means training content produced before and after the release uses different code vocabularies that must both be in the glossary.

NIST SP 800-53 control identifiers use a different format: a two-letter control family code (AC for Access Control, AT for Awareness and Training, AU for Audit and Accountability, CA for Assessment, CM for Configuration Management, CP for Contingency Planning, IA for Identification and Authentication, IR for Incident Response, MA for Maintenance, PE for Physical and Environmental, RA for Risk Assessment, SC for System and Communications, SI for System and Information Integrity, SR for Supply Chain Risk Management) followed by a hyphen and a numeric sequence. Control AC-1 is the Access Control Policy control; control SI-2 is the Flaw Remediation control; control AU-6 is the Audit Log Review control. These two-character codes are shorter and often spoken as letter pairs rather than spelled out individually — "A-C dash 1" is spoken more naturally than "A C 1 individually" — but the ASR output is inconsistent between "AC-1," "A C 1," and "A C dash one" depending on the speaker's natural speech pattern.

The SP 800-53 control catalogue contains more than 1,000 individual controls and enhancements across the 20 control families. Not all of these appear in any given training programme, but the subset that appears in compliance training for regulated industries is substantial: AT controls (AT-1 through AT-6) are almost universally referenced in security awareness training content because they define the training requirements; AC controls appear in access management training; IR controls appear in incident response training. The glossary for SP 800-53 content cannot be seeded from a single-source feed the way ATT&CK identifiers can, but NIST publishes SP 800-53 in machine-readable OSCAL (Open Security Controls Assessment Language) XML format, which can be parsed to extract all control IDs and names for glossary seeding. The Section 508 caption requirement applies specifically to content produced for federal agencies, and federal security training content is precisely the context where SP 800-53 control IDs appear most densely.

The compliance training programmes that most extensively reference both CSF and SP 800-53 are those prepared for FedRAMP authorisation (which requires demonstrating alignment to SP 800-53 across all 20 control families), StateRAMP (the state government equivalent), and DoD CMMC assessments. Security training for organisations seeking FedRAMP authorisation must demonstrate that personnel have received documented training on the specific controls applicable to their role — and that training content must be accessible. The intersection of high identifier-code vocabulary density and strong caption compliance requirements (Section 508 applies to federal contractors and grant recipients) makes FedRAMP-related security training one of the highest-stakes captioning contexts in the corporate L&D environment. The WCAG 2.1 AA caption accuracy requirement of 99% is not achievable for SP 800-53 control code references without glossary injection — the decomposition failure rate for control IDs in unassisted ASR is consistently above 80%.

Security vendor product name failures: the industry's invented-word vocabulary problem

The cybersecurity industry has a naming convention pathology from a captioning perspective: security products are consistently named with invented words, portmanteau constructions, or word combinations that have no prior phonetic conditioning in ASR training data. This is not a coincidence — security product names are designed to be memorable, distinctive, and domain-specific, qualities that produce exactly the phonetic composition that ASR handles worst. The result is that the ASR failure rate for security vendor product names is the highest of any technology vertical, exceeding even software development tooling (which has a high invented-word rate from open-source project naming conventions).

The failure patterns divide into four types. Word splitting occurs when a compound word is correctly parsed as two separate words: CrowdStrike → "crowd strike," SentinelOne → "sentinel one," Lacework → "lace work," ThreatLocker → "threat locker." These failures are semantically recoverable — a learner who sees "crowd strike" recognises it as CrowdStrike — but they introduce inconsistency in the transcript (the vendor name appears differently from the way it appears in product documentation, which is a quality failure that matters for compliance training) and they prevent programmatic processing (search, index, glossary matching) from working correctly on the transcript. Phonetic substitution occurs when the ASR engine maps an unfamiliar word to a familiar phonetically-similar word: Vectra → "vector" (very common, as the phonetic similarity is high), Snyk → "snick" or "snack" (the word has no prior occurrence in English), Tenable → "tachable" (occasional). Partial recognition occurs when a multi-word product name is partially correct: "Palo Alto Networks Panorama" is usually correct for the first three words but "Panorama" may become "panorama" (lowercase, incorrect brand capitalisation) or "pan-o-rama" (hyphenated incorrectly). Abbreviation expansion is rare for security vendor names but occurs with acronym-style names like SIEM ("seem" is a common Whisper output).

The security vendor glossary is the highest-turnover component of the cybersecurity training glossary, for two reasons. First, the security industry has a high M&A rate and frequent product rebranding: companies are acquired and renamed (Mandiant became part of Google Security Operations), products are rebranded (Demisto became Cortex XSOAR, then Cortex Cloud), and new product lines are launched at the major security conferences three or four times per year. A glossary that accurately reflects the vendor landscape at the beginning of a year may have 15–20% outdated entries by year-end due to rebranding alone. Second, new security tools — both commercial products and open-source tools popular in training content — enter the vocabulary with each RSA and Black Hat conference cycle, when vendors release new products and the security research community releases new open-source tools that immediately appear in training content. The feedback loop for glossary improvement must be tuned for a high-turnover vocabulary environment: reviewing captioned outputs for new, uncaptured vendor names is a mandatory step before each batch submission in security training contexts.

The comparison to the chemical vocabulary in EHS training content from the HazCom captioning guide is useful here. Chemical names (PFAS, toluene diisocyanate, methylisocyanate) are invented or Latin-derived terms that fail in ASR with the same phonetic decomposition pattern as security product names. The HazCom glossary solution — registering the full IUPAC name and common name as paired entries — applies directly to security vendor names: register both the full legal entity name (CrowdStrike Holdings, Inc.) and the brand name (CrowdStrike) and the primary product name (Falcon) as separate entries that all resolve to the correct brand format. For security tools, register both the project name (BloodHound) and any common abbreviations (BH, which in security context is understood to mean BloodHound) as entries.

Certification prep vocabulary: CompTIA, CISSP, CEH, GIAC, and offensive security terminology

Security certification preparation content represents a large fraction of the corporate security training catalogue. Organisations fund certification prep for their security operations staff — CompTIA Security+, (ISC)² CISSP, EC-Council CEH, ISACA CISM, ISACA CISA, GIAC certifications — and the resulting study modules are complex, vocabulary-dense, and frequently reference both the certification body's specific terminology and the underlying technical content at the same time. The vocabulary failure points in certification prep content are layered: the certification acronyms themselves, the certification body names, the domain-specific terminology defined by each certification's body of knowledge, and the technical identifier vocabulary (CVEs, NIST controls, ATT&CK techniques) that appears throughout.

The certification acronyms divide into two groups by ASR behaviour. Acronyms that map to common English words are the most problematic: CISA (Certified Information Systems Auditor) → "sigh-zah" or correct as an acronym but conflated with the US government Cybersecurity and Infrastructure Security Agency (also CISA); SOAR (Security Orchestration, Automation, and Response) → "soar" (the verb); SIEM (Security Information and Event Management) → "seem" (Whisper's most common output for this acronym). Acronyms that do not map to common words — CISSP, CEH, OSCP, CISM, GIAC — are generally transcribed letter-by-letter with a space between each letter, or merged into a single token. "GIAC" (the Global Information Assurance Certification body) is often transcribed as "JACK" or "jac" by Whisper because the phoneme cluster /dʒɪæk/ is more common in English than the /dʒiˈæk/ cluster that "GIAC" implies. "OSCP" (Offensive Security Certified Professional) is usually transcribed correctly as the four letters. "CEH" (Certified Ethical Hacker) is usually transcribed correctly. "CISSP" is usually transcribed correctly.

The certification body names introduce additional failure points. "(ISC)²" is spoken as "I S C squared" — the exponent notation and abbreviation combination produces failures like "I S C two" (digit substitution), "ISC two" (merged), or "I S C to" (homophone). EC-Council (the organisation behind CEH) is usually transcribed correctly. ISACA (the organisation behind CISM and CISA) is usually transcribed correctly. CompTIA — the Computing Technology Industry Association — is transcribed as "comp T I A" (letter-by-letter) or "comp-tee-ah" (phonetic) or "comptia" (merged), but rarely in the correct form "CompTIA" with the compound capitalisation. GIAC certifications have additional complexity: the individual certification acronyms include GPEN (GIAC Penetration Tester), GWAPT (GIAC Web Application Penetration Tester), GREM (GIAC Reverse Engineering Malware), GCIH (GIAC Certified Incident Handler) — each of which fails in different ways depending on its phoneme pattern.

The domain-specific terminology from each certification's body of knowledge introduces vocabulary failures that are specific to the certification context. CISSP's eight domains include terms like "non-repudiation" (usually correct), "cryptanalysis" (usually correct), "Kerberos" (usually correct), "Diffie-Hellman" (hyphenated name — "Diffie hellman" or "Diffie-Hellman," the hyphen handling is inconsistent), "RSA encryption" (correct), "elliptic curve cryptography" (usually correct), and "zero-knowledge proof" (usually correct). The CISSP domain vocabulary is relatively well-represented in ASR training data because cryptography terminology has a long history in technical writing and documentation. The CEH body of knowledge includes a higher density of tool names and attack technique names that fail at the rates described in the vendor names and tools sections. CompTIA Security+ vocabulary is more accessible for ASR — the certification is designed for entry-level practitioners and uses relatively standard technical vocabulary — but it includes the same set of common acronyms (SIEM, SOAR, EDR, XDR, UEBA) that require glossary conditioning.

Security protocol and tool vocabulary: red team tools, attack technique names, and blue team platform acronyms

Beyond the formal framework vocabulary (ATT&CK IDs, CVE identifiers, NIST codes), cybersecurity training content references a large vocabulary of attack tool names, protocol-level attack technique names, and blue team platform acronyms that each have distinct ASR failure patterns. This vocabulary appears in training content across the spectrum from security awareness (explaining to non-technical employees what a phishing simulation is and what it can detect) to advanced red team certification prep (covering specific tool capabilities and usage in penetration testing engagements). The density of this vocabulary in advanced security operations training is high enough that it significantly affects overall caption accuracy even after framework identifier errors are addressed by glossary injection.

Red team and offensive security tool names fail at high rates because the security research community that produces these tools deliberately uses invented or unusual names. The most frequently referenced tools in training content include: Mimikatz (credential dumping tool) → "mimi cats" or "mimi katz" (Whisper's most consistent failure for this vocabulary item; the "katz" ending has no English prior conditioning); BloodHound (Active Directory recon tool) → "bloodhound" (correct lexically, but lowercase — the capitalisation matters for tool references in training transcripts); Rubeus (Kerberos exploitation tool) → "rube us" or "roobius" (the Latin origin has no English phoneme conditioning); Empire (post-exploitation framework) → "empire" (usually correct); PowerView (PowerShell AD enumeration tool) → "power view" (splitting, low severity); PowerSploit (PowerShell offensive toolset) → "power splooit" or "power sploit" (the "splooit" ending is a deliberate security community spelling); Cobalt Strike → "cobalt strike" (correct, the product name uses natural English words); Metasploit → "meta splooit" or "meta sploit" (the "splooit" suffix fails consistently for the same reason as PowerSploit); SharpHound (BloodHound's data collection tool) → "sharp hound" (splitting, low severity); Responder (LLMNR poisoning tool) → "responder" (usually correct).

Protocol-level attack technique names fail in ways that reflect their linguistic origins. Kerberoasting — the technique of requesting service tickets for service accounts and cracking them offline — combines the proper noun "Kerberos" (usually correct) with the English word "roasting" (correct) in a compound that Whisper may render as "Kerberos roasting" (split, low severity) or "Kerberoasting" (correct). Pass-the-Hash — an authentication attack using NTLM hash values — is usually transcribed correctly as "pass-the-hash" because the three English words are natural and the hyphens reflect a spoken pause. Pass-the-Ticket (Kerberos ticket attack) is similarly well-handled. DCShadow and DCSync — Active Directory domain controller attacks — fail more often because the "DC" prefix is rendered as "D C" (two letters) rather than the merged "DC" convention. Golden Ticket and Silver Ticket attacks (Kerberos forgery techniques) are correctly transcribed. LLMNR (Link-Local Multicast Name Resolution) poisoning — the protocol acronym "LLMNR" is consistently rendered as individual letters rather than as the compound abbreviation, which is correct but produces "L L M N R" with spaces rather than "LLMNR" as a single token.

Blue team platform acronyms create a specific failure mode: they are commonly used abbreviations that map to either English words or other common acronyms. SIEM (Security Information and Event Management) → "seem" (Whisper maps to the verb); SOAR (Security Orchestration, Automation, and Response) → "soar" (maps to the verb); EDR (Endpoint Detection and Response) → usually "E D R" (spelled out correctly); XDR (Extended Detection and Response) → usually "X D R" (correct); UEBA (User and Entity Behaviour Analytics) → "U E B A" or "yuba" (phonetic misrouting); CSPM (Cloud Security Posture Management) → "C S P M" (usually spelled correctly); CIEM (Cloud Infrastructure Entitlement Management) → "seem" or "C I E M" (inconsistent); WAF (Web Application Firewall) → "waff" or "W A F" (phonetic rendering of the abbreviation is ambiguous). The SIEM → "seem" failure is particularly significant because SIEM is one of the most commonly referenced platform categories in security operations training, and "seem" appearing mid-sentence where "SIEM" was intended creates a grammatically correct but semantically wrong caption that automated quality checks do not flag.

The caption QA methodology must include a specific check for acronym-to-common-word substitutions in the cybersecurity vertical. The standard DCMP spot-check protocol identifies errors where the caption differs from the audio; it is less effective at identifying errors where the caption is grammatically correct but substitutes a common word for a technical acronym. A reviewer scanning for "obvious" errors will not catch "the analyst ingested the logs into the seem platform" because "seem" is a grammatically valid word in that context. The check requires recognising that "seem" is unlikely to appear in security operations training content and querying whether the audio source said "SIEM." The same check applies for SOAR/soar, CISA/sigh-zah, and other acronym-to-homophone substitutions specific to the cybersecurity vertical.

The glossary-biased decoding approach handles most of these failures by increasing the probability of the correct security-vocabulary output token relative to the common-word alternative. The SIEM/seem disambiguation works by registering "SIEM" as a high-probability output when the preceding and following context involves security operations vocabulary. The Mimikatz/mimi-cats disambiguation works by registering "Mimikatz" as a glossary entry with the exact capitalisation and spelling required, making the correct spelling the dominant output when the phoneme cluster /mɪmɪkæts/ is detected. For red team tool names specifically, the glossary must include both the commonly spelled name (Mimikatz) and the less common variations (mimikatz, MIMIKATZ) because tool names in training content are referenced with variable capitalisation depending on the trainer's documentation source.

The mandatory training compliance overlay: NERC CIP, CMMC, FINRA, and HIPAA Security Rule

Cybersecurity training occupies a unique position in the compliance training landscape because the training itself is subject to a dual compliance obligation: the training must be delivered in a WCAG-compliant, accessible format (the captioning compliance), and the training must be delivered to satisfy a separate cybersecurity regulatory requirement (the security training compliance). When these two obligations intersect — when mandatory cybersecurity regulatory training is delivered in an inaccessible format — the organisation faces compound regulatory exposure. The caption compliance matrix across Section 508, ADA, and WCAG covers the captioning obligation side of this intersection; this section covers the mandatory security training obligations that create the underlying training requirement.

NERC CIP (Critical Infrastructure Protection) standard CIP-004 requires organisations subject to NERC oversight (bulk electric system operators, transmission owners, generator operators) to provide cybersecurity awareness training and personnel risk assessment training to all personnel with authorised access to bulk electric system cyber assets. The training must be documented, must include specific content areas defined in CIP-004-7 (cybersecurity awareness, physical security, access controls, incident response), and must be repeated annually. NERC CIP training content has two characteristics that compound the captioning challenge: it references the CIP standard identifiers themselves (CIP-004, CIP-007, CIP-010, CIP-011) in the same identifier format as NIST control codes, and it covers technical operational content specific to industrial control systems (ICS) and operational technology (OT) that has a distinct vocabulary not represented in standard ASR training data. The ICS/OT vocabulary includes SCADA (usually correct), HMI (human-machine interface, usually correctly spelled out), PLC (programmable logic controller, usually correct), historian server (correct), and vendor-specific product names for ICS platforms (Siemens SIMATIC, Honeywell DCS, GE iFIX, OSIsoft PI) that fail at the same rates as security vendor product names.

CMMC (Cybersecurity Maturity Model Certification) preparation training for Department of Defense contractors is one of the most vocabulary-dense cybersecurity training contexts in the corporate L&D environment. CMMC 2.0 maps to NIST SP 800-171 controls (which have their own identifier format: 3.1.1, 3.5.3, 3.13.16 — numeric dot-notation identifiers that ASR renders inconsistently) and references the DoD Assessment Methodology, DFARS clauses (252.204-7012, 252.204-7019, 252.204-7021 — all identifier-format strings), FedRAMP equivalents, and CUI (Controlled Unclassified Information) handling procedures. CMMC training content produced by third-party compliance firms (Coalfire, A-LIGN, Schellman, Tevora) typically has high identifier-code density and is frequently delivered in SCORM format via platforms like Cornerstone or Docebo — creating the same SCORM caption workflow challenge covered in the eLearning authoring tool captioning post.

FINRA Rule 4370 requires FINRA-member firms to implement business continuity planning that includes cybersecurity considerations, and FINRA's cybersecurity guidance (FINRA Report on Cybersecurity Practices) is frequently incorporated into mandatory continuing education content for registered representatives. The FINRA-specific vocabulary — "FINRA" (usually correct), "broker-dealer" (correct), "registered representative" (correct), "Form BD" (letter-number identifier, variable ASR output) — is relatively accessible for ASR, but the technical cybersecurity content within FINRA-mandated training modules references the same framework vocabulary (NIST CSF, SP 800-53, MITRE ATT&CK in more advanced content) as any other security training. The primary compliance risk from a FINRA perspective is that inadequate captioning of mandatory continuing education content could be characterised as a failure to maintain the training records required under FINRA Rule 4511 (General Requirements for Records), since a caption track with systematic identifier errors produces a training record that does not accurately reflect the training content delivered.

HIPAA Security Rule (45 CFR Part 164, Subpart C) requires covered entities and business associates to implement a security awareness and training programme for all members of its workforce. The Security Rule training obligation has no specific vocabulary requirement — the content is largely at the discretion of the covered entity — but in practice, HIPAA Security Rule training content references PHI (Protected Health Information, correctly transcribed), ePHI (electronically protected health information, usually "E P H I" correctly), audit controls (audit log review, correctly transcribed), and technical safeguard controls that mirror the NIST SP 800-53 control language. HIPAA compliance training content produced for healthcare organisations also references the full vocabulary of clinical cybersecurity — EHR platform names (Epic, Cerner, Meditech — all usually correct), medical IoT (mIoT) security terminology, and HITECH Act references — at the intersection of the healthcare vocabulary failures covered in the medical training video captioning post and the general cybersecurity vocabulary failures covered in this post.

The practical workflow implication of the dual compliance obligation is that cybersecurity regulatory training content requires caption QA that is more rigorous than standard compliance training content. The employer cannot delegate the caption quality assessment to the content provider — if the NERC CIP training vendor provides auto-captions that render CIP standard identifiers incorrectly, the employer's audited record shows incorrect training documentation. The employer's NERC CIP compliance audit is at risk not because the training content was wrong but because the accessible delivery of the training content was inadequate. Building a caption quality check into the procurement of mandatory cybersecurity regulatory training modules — as a contract requirement, not a post-purchase review — is the only way to prevent this compound compliance exposure. The vendor SLA review checklist and the caption compliance programme build guide both cover the procurement-side requirements for external training content.

Purchased security awareness content: KnowBe4, SANS, Proofpoint, and the third-party obligation

Security awareness training is the highest-volume purchased training content category in the corporate L&D market. Organisations outsource security awareness content production to specialised providers because the content requires both security domain expertise and high production quality, and because purchased platforms provide the simulation capabilities (phishing simulation, vishing campaigns) that are integral to awareness programme outcomes. The major platforms — KnowBe4, Proofpoint Security Awareness Training (formerly Wombat), SANS Institute Security Awareness, Infosec IQ (now Infosec Institute), Mimecast, Cofense, Terranova — each provide libraries of short training videos and interactive modules covering phishing recognition, password security, physical security, data handling, and social engineering awareness. The captioning obligation for this content follows the employer: the organisation that assigns the training to its employees bears the WCAG compliance risk if the training is not delivered in an accessible format.

KnowBe4 is the market-share leader in security awareness training platforms. The KnowBe4 ModStore contains thousands of video modules across dozens of content categories. KnowBe4 has invested in accessibility over recent years and many newer modules include caption files, but coverage is not universal — older content, localised content, and content from acquired libraries (KnowBe4 has made multiple acquisitions including Popcorn Training, CLTRe, SecurityIQ) may have inconsistent caption quality. The vocabulary-specific risk with KnowBe4 content is that it references the threat actor techniques it is designed to defend against — a module on ransomware response may reference CVE identifiers, ATT&CK technique IDs, or tool names associated with specific ransomware groups. When the auto-generated captions on this content fail on these identifiers, the employer must either correct the captions (which requires the KnowBe4 agreement to allow SRT download and reupload, or the use of the caption upload functionality in the KnowBe4 admin portal) or request corrected captions from KnowBe4's accessibility team.

SANS Institute security awareness training and certification prep content has a vocabulary density and technical depth significantly higher than general awareness training. SANS produces content for security professionals, not just for general-employee awareness — the SEC401 (Security Essentials), SEC504 (Hacker Tools, Techniques, and Incident Handling), and SEC542 (Web App Penetration Testing) courses are training content for security practitioners with high identifier vocabulary density. SANS content is typically delivered through the SANS LMS or via employer SCORM deployment; in either case, the employer who assigns it as mandatory training bears the caption quality obligation. The third-party caption obligation is discussed at length in the third-party compliance training captioning post; the specific application to SANS content is that SANS course transcripts (when available) provide a valuable source for generating a content-specific glossary that pre-seeds the captioning system with the specific identifiers that appear in the course. SANS often provides course workbooks that contain all references to CVE identifiers, ATT&CK technique IDs, and tool names — these workbooks can be parsed to extract identifier vocabulary for the glossary.

Proofpoint Security Awareness Training (formerly Wombat Security) and Infosec IQ both provide SCORM-deployable modules that can be uploaded to the employer's primary LMS. When deployed via SCORM, the caption challenge is the same as for any SCORM-packaged eLearning content: the captions are embedded in the package at the content provider's publish time, and the employer cannot add a post-hoc SRT sidecar file. If the embedded captions fail on security vocabulary identifiers, the only remediation path is to request corrected modules from the provider or to reconstruct the module with corrected captions. This is the SCORM post-hoc captioning limitation documented in the eLearning authoring tool captioning post — the employer's ability to correct third-party SCORM content is constrained by whether the content provider will provide updated SCORM packages with corrected captions.

The procurement workflow implication for purchased security awareness content is that caption quality should be a contract requirement, not a post-purchase discovery. Before signing with a security awareness training platform, an L&D or security team should: (1) request a representative sample of 5–10 modules with caption files and evaluate the caption quality on a 50-sample spot-check using the DCMP protocol; (2) specifically test caption quality on any module that references CVE identifiers, ATT&CK technique IDs, or vendor/tool names; (3) review the accessibility statement in the vendor's agreement and confirm whether the vendor's WCAG compliance claim covers caption accuracy or only the presence of caption tracks; (4) confirm whether the agreement allows the employer to upload corrected SRT files to replace auto-generated captions on their platform deployment; (5) confirm the vendor's process for producing updated modules when captions fail a quality review. These five steps apply to all purchased compliance training content as covered in the procurement checklist framework, but the specific check on identifier vocabulary (step 2) is unique to security awareness and cybersecurity training content.

Building the cybersecurity glossary: term sourcing, structure, and the high-cadence update process

The cybersecurity training glossary requires a different construction approach from the glossary for other L&D verticals, for two reasons. First, a significant portion of the required vocabulary is available from authoritative machine-readable sources that can be ingested programmatically rather than assembled manually: the MITRE ATT&CK STIX JSON, the NVD CVE API, and the NIST OSCAL-format SP 800-53 catalogue collectively cover the three most important identifier-class vocabulary categories. Second, the update cadence required is significantly faster than for other verticals — quarterly for ATT&CK, continuous for CVEs, and annual for SP 800-53 — which means the glossary maintenance process must be systematised rather than treated as an ad hoc review task. The customer glossary architecture covers the general structure; this section covers the cybersecurity-specific sourcing and maintenance workflow.

The MITRE ATT&CK STIX 2.1 JSON file is the authoritative source for ATT&CK vocabulary. The file is available at attack.mitre.org/resources/working-with-attack/ and is updated with each ATT&CK framework release (typically quarterly). A Python or JavaScript parser can extract the full set of technique IDs and technique names, tactic IDs and tactic names, and group/software names and aliases. The extracted data seeds the ATT&CK section of the glossary: each technique name becomes a glossary entry with the canonical capitalisation and spelling as defined in the ATT&CK knowledge base. Sub-technique names (T1059.001 → PowerShell; T1059.003 → Windows Command Shell) are registered as entries under the sub-technique ID. Group names (APT28, Lazarus Group, Scattered Spider) and software names (Mimikatz, BloodHound, Cobalt Strike as classified by MITRE) are extracted from the "intrusion-set" and "malware" STIX objects respectively. When the ATT&CK framework is updated, the parser reruns against the new STIX file and the diff is applied to the glossary — new entries added, deprecated entries flagged for removal, renamed entries updated. This programmatic update process is the only practical approach given the quarterly release cadence and the scale of the vocabulary (300+ technique and sub-technique entries plus hundreds of group and software entries).

The NVD CVE API (available at services.nvd.nist.gov/rest/json/cves/) provides the full CVE database with associated metadata. For the purpose of glossary seeding, the relevant fields are the CVE ID (CVE-YYYY-NNNNN format), any Common Vulnerability Scoring System (CVSS) identifiers, and the description. The glossary entry for a CVE reference should include: the CVE ID in its canonical format, the common name if one exists (Log4Shell for CVE-2021-44228, Heartbleed for CVE-2014-0160), and the affected product name as a contextual signal for ASR disambiguation. For organisations that produce training content about specific recent vulnerabilities, the workflow is: when a CVE is referenced in new training content, add the CVE ID to the glossary before the first captioning submission. For organisations that manage a large library of existing security training content that references CVEs, a retrospective audit to identify all CVE references in the content library — searchable by scanning transcript corrections or by parsing existing transcript files for CVE-format strings — followed by a batch glossary update, is the most efficient approach.

The glossary structure for cybersecurity training content benefits from categorisation by vocabulary class, which supports targeted QA and targeted review. A glossary structure with four sections — (1) Framework Identifiers (ATT&CK IDs, NIST CSF codes, SP 800-53 controls, CVE identifiers), (2) Product and Vendor Names (commercial security products, platform names), (3) Tool Names (offensive tools, red team software, open-source security tools), (4) Certification and Body-of-Knowledge Terms (certification acronyms, domain-specific terminology) — allows the QA reviewer to apply category-specific review criteria to each section. The Framework Identifier section is verified by format correctness (does CVE-2021-44228 appear in the correct format in the caption?); the Vendor Name section is verified by brand-style correctness (is "CrowdStrike" capitalised correctly, not "crowd strike"?); the Tool Name section is verified by both spelling and capitalisation (is "Mimikatz" spelled with a capital M?); the Certification section is verified by abbreviation consistency (is "CISSP" consistently the same token throughout the transcript?).

The update cadence for the cybersecurity glossary should be driven by three trigger events. The first is the ATT&CK framework release: MITRE typically publishes ATT&CK updates in January, April/May, July/August, and October, with each release adding new techniques, revising existing technique names, and occasionally deprecating identifiers. The glossary's ATT&CK section should be updated within one week of each ATT&CK release. The second trigger is major security conference season: RSA Conference (typically May/June), Black Hat USA (typically August), and DEF CON (typically August) are the primary venues for new security product launches and new open-source tool releases. Content produced in the four to eight weeks following these conferences will reference newly-released products and tools; a glossary review against each conference's announced releases is a practical way to pre-empt glossary gaps. The third trigger is major CVE disclosures: when a critical vulnerability (CVSS score 9.0+) is disclosed, training content is typically produced within days. The CVE ID must be in the glossary before the first training video about that vulnerability is submitted for captioning. The feedback loop for identifying glossary gaps — reviewing captioned outputs for repeated correction patterns — provides the backstop: if a term is being corrected repeatedly across multiple submissions, it should be added to the glossary proactively rather than corrected retroactively in each batch.

QA methodology for security content: adapting the standard protocol for identifier-class vocabulary

The standard caption QA protocol for training video — the DCMP spot-check methodology that samples 10% of each caption file and measures word error rate against a manual transcript reference — is insufficient for cybersecurity training content on two dimensions. First, the standard word error rate metric does not weight identifier errors appropriately: a single garbled CVE identifier ("CVE twenty twenty-one forty-four two twenty-eight" instead of "CVE-2021-44228") counts as five word errors against a metric that is averaged across the full file, which may be 5,000+ words. The CVE error contributes less than 0.1% to the total word error rate — well within the 1% WCAG budget — but the error is a total functional failure for the specific token. A transcript with 99.5% word-level accuracy that has a garbled CVE reference has failed its functional purpose for every learner who needed to copy that CVE into a patch management system or vulnerability tracker. Second, the standard 10% random sampling may not capture the identifier-dense segments of a security training video. Security training content is often structured with a conceptual introduction (no identifiers, high natural-language accuracy) followed by technical deep-dives (high identifier density, low accuracy without glossary) — a random sample may oversample the introductory sections and undersample the high-identifier segments.

The adapted QA protocol for cybersecurity training content modifies the standard in three ways. The first modification is targeted sampling rather than random sampling: the QA review identifies segments by transcript search for ATT&CK technique ID patterns (T\d{4}), CVE identifier patterns (CVE-\d{4}-\d+), NIST control code patterns ([A-Z]{2}-\d+), and known vendor/tool names from the glossary list. These segments are reviewed at 100% rather than sampled — every identifier reference is verified. The remaining non-identifier segments can use the standard 10% random sampling rate. This approach concentrates review effort on the vocabulary where failures have the highest functional impact.

The second modification is binary identifier scoring rather than word-error-rate scoring. Identifier-class tokens are binary: a CVE reference is either correct (CVE-2021-44228) or it is wrong (in any other form). There is no "close enough" for identifier vocabulary — a learner who sees "CVE twenty-twenty-one forty-four two twenty-eight" cannot reliably reconstruct "CVE-2021-44228" without already knowing the CVE ID. The QA scoring for identifier segments uses a pass/fail criterion: does every identifier in the reviewed segment match its canonical form exactly? A file that passes the identifier QA check and meets the standard WCAG word error threshold on the non-identifier segments passes the full QA review. A file that fails the identifier check fails the QA review regardless of its overall word error rate. The 99% WCAG accuracy threshold is a necessary but not sufficient condition for cybersecurity training captions — identifier format correctness is an additional, independent quality criterion.

The third modification is functional context testing for acronym-to-common-word substitutions. The SIEM→"seem," SOAR→"soar," CISA→"sigh-zah" failure class is not caught by word error rate scoring (the substituted word is a valid English word) and is not caught by identifier pattern matching (the substituted output does not match a NIST or ATT&CK identifier format). Functional context testing requires the QA reviewer to read each sentence containing a potential acronym-to-word substitution and assess whether the output is semantically coherent in a security context. A sentence like "the organisation deployed a seem platform to centralise log collection" is grammatically correct but semantically wrong — it should read "the organisation deployed a SIEM platform." These errors require human review; automated quality checks do not reliably identify them. The review pass for acronym substitutions should cover at minimum the 15–20 most common security acronyms that map to common English words or other common acronyms.

The overall QA workflow for a cybersecurity training batch submission involves four sequential steps: (1) automated identifier extraction (scan the transcript for identifier-pattern strings and flag any that appear in a non-canonical format); (2) targeted manual identifier review (review each flagged segment and verify the identifier against the authoritative source — ATT&CK knowledge base for technique IDs, NVD for CVE identifiers, NIST documentation for framework codes); (3) acronym substitution review (read all sentences containing SIEM, SOAR, CISA, GIAC, UEBA, CIEM, and other high-risk acronyms and verify semantic coherence); (4) standard DCMP sampling on non-identifier segments. The caption QA methodology post covers the full DCMP protocol and how to implement it as a team process; the cybersecurity-specific adaptation in steps 1–3 should be documented as a supplementary procedure for security content batches.

Platform delivery: how security-specific LMS environments handle captions

Cybersecurity training content is delivered through a wider variety of platform types than most other L&D content categories. The primary delivery channels include: the organisation's general-purpose LMS (Cornerstone, Workday Learning, Docebo, TalentLMS, Absorb) for mainstream security awareness and compliance training; specialised security training platforms (Cybrary, Offensive Security's training platform, SANS OnDemand, Coursera Business for security certifications) for advanced practitioner content; and SCORM or xAPI deployments of third-party content (KnowBe4 modules, Proofpoint content, SANS Security Awareness content) within the organisation's primary LMS. Each delivery channel has distinct caption format and workflow requirements.

For security training delivered through the general-purpose LMS, the caption workflow is the same as for any other video-based training content. The Cornerstone OnDemand caption workflow requires SRT upload per video in the Content Manager; the TalentLMS caption workflow supports SRT sidecar upload in the Course Settings; the Workday Learning caption workflow supports VTT upload at the Learning Resource level. The vocabulary challenges for security training content are handled at the captioning vendor stage — the caption file delivered to the LMS upload should already have glossary-assisted accuracy applied. The LMS itself has no role in vocabulary handling; it receives the SRT or VTT file and delivers it alongside the video.

Specialised security training platforms present different challenges. Cybrary — one of the largest security practitioner training platforms — delivers content on its own hosted platform and does not support LMS-side SRT upload for employer-assigned content in the same way a general-purpose LMS does. When an organisation purchases Cybrary access for its employees and assigns specific courses as mandatory training, the caption quality is determined by Cybrary's own production process, not by the employer's captioning workflow. The employer's only lever is to request WCAG-compliant captions from Cybrary's accessibility team or to seek an accommodation for specific affected employees. Offensive Security (creators of the OSCP certification) delivers learning paths on a platform that similarly does not support employer-side caption upload; the caption quality is Offensive Security's responsibility for the content they produce, and an employer assigning OSCP preparation as mandatory training has limited post-purchase correction capability for caption errors.

The SCORM deployment of third-party security awareness content creates the caption correction challenge described in the third-party section: caption errors in a SCORM package cannot be fixed with a sidecar file upload. For KnowBe4 and Proofpoint content deployed as SCORM within the employer's LMS, the correction path requires either requesting an updated SCORM package from the vendor (which is the vendor's responsibility if the employer has raised an accessibility concern) or replacing the SCORM deployment with a platform-native delivery method if the vendor supports it. Some security awareness platforms support caption upload or correction through their admin portal without requiring a SCORM repackage — reviewing the admin interface capabilities at procurement time avoids discovering this constraint after deployment. The broader SCORM caption correction challenge is covered in detail in the eLearning authoring tool captioning post; the principle is the same for third-party SCORM content as for internally-produced Storyline or Rise content.

For organisations with security training content distributed across multiple LMS platforms after acquisitions or due to separate security-specific LMS deployments, the LMS migration caption checklist is relevant even outside of a formal migration context: the multi-platform inventory, cross-system caption status audit, and caption format compatibility checks apply to any situation where security training content lives in more than one system. The specific vocabulary-related audit consideration in a multi-platform environment is verifying that the same glossary version was applied consistently across all platforms — if security training content was captioned before and after a major glossary update (a major ATT&CK framework release, for example), the older content may have systematic identifier errors that the newer content does not, requiring a targeted re-captioning pass of the older segments.

Eight failure modes specific to cybersecurity training captioning

1. Glossary not updated before the ATT&CK framework release cycle

The organisation's cybersecurity training programme produces new content quarterly, aligned to the ATT&CK framework update cycle. The captioning glossary is updated annually during the accessibility programme review, not quarterly. A batch submission for a security operations training module produced in Q3 references three techniques added in the Q2 ATT&CK release that are not in the glossary. The transcript shows the technique names correctly (natural language) but the technique IDs as garbled number sequences — the missing glossary entries mean that the identifier format injection did not fire. The error is not caught until the next periodic quality audit. The fix requires identifying all submissions made in the gap window between the ATT&CK release and the glossary update, re-captioning those modules with the updated glossary, and re-uploading the corrected SRT files. The process is operationally similar to the batch re-captioning workflow documented in the feedback loop post but triggered by a glossary gap rather than a vendor accuracy issue.

2. CVE reference added to training content after glossary submission

An incident response team produces a training module about a recent ransomware incident within 72 hours of the incident. The module includes repeated references to the CVE identifier associated with the exploited vulnerability. The glossary submission for the captioning batch was prepared before the CVE was added to the content. The CVE identifier appears in every caption reviewer's corrected output but is not in the glossary for the next batch. If the content goes through a captioning vendor with an asynchronous glossary update process (where glossary changes do not take effect until the next submission cycle), the next module that references the same CVE will have the same error. The workflow fix is a synchronous glossary update trigger: before any captioning submission for a module that references a new CVE, the CVE ID must be added to the glossary and the update confirmed active. Time-sensitive security content (incident response modules, breach notification training) needs a fast-path glossary update process that does not wait for the next scheduled update cycle.

3. SIEM/SOAR acronym appears in captions as a common English word

A security operations training module about SOC workflow references "SIEM" forty-seven times over 35 minutes. The automated caption output renders "seem" in all forty-seven instances. The standard QA sample checks 3–4 minutes of the module and happens to sample segments without SIEM references. The file passes QA and is uploaded to the LMS. Learners see "the analyst ingested events into the seem platform" forty-seven times. The error is not caught until an employee with a hearing disability emails the L&D team to report that the training content appears to be missing a key platform name that colleagues have mentioned in conversation. The fix requires a full re-review of the module, re-captioning with an updated glossary that treats "SIEM" as a high-probability output ahead of "seem," and re-upload. The prevention is acronym-to-common-word substitution review on every cybersecurity caption file before QA sign-off — a step that must be explicit in the QA checklist, not assumed to be covered by the standard DCMP word error rate check.

4. Purchased KnowBe4 module deployed with auto-captions that fail on ATT&CK technique IDs

An organisation's security team assigns a KnowBe4 advanced threat hunting module to its SOC staff as mandatory training. The module includes sections on ATT&CK-mapped adversary behaviour and references technique IDs throughout. The module was produced by KnowBe4 with auto-generated captions that have not been reviewed for identifier accuracy. A SOC analyst with a hearing disability submits an accommodation request because the captions are unintelligible in the technique-ID-dense sections. The L&D team discovers that the KnowBe4 agreement does not include an SRT download/upload capability for employer-assigned content. The accommodation must be addressed through the KnowBe4 accessibility team — a process that may take weeks. The prevention is a caption quality review of modules at the point of purchase, specifically testing any module with "advanced" or "threat intelligence" content for identifier vocabulary, and confirming the caption correction workflow before assignment to employees with accommodation needs.

5. Red team tool name appears incorrectly throughout a security certification prep module

An organisation funds CompTIA Security+ preparation training for five security analysts. The training content, delivered as a 40-hour SCORM course from a third-party provider, includes extensive coverage of penetration testing tools and techniques. "Mimikatz" appears as "mimi cats" throughout all sessions covering credential dumping. "BloodHound" appears as "blood hound" (two words) rather than the tool's one-word name. The analysts who are hearing-impaired study from the captions and form incorrect mental models of tool names that later create confusion when tool documentation, reports, and discussion use the correct spelling. The prevention requires the third-party content provider to use a security-domain glossary that includes red team tool names, or to provide corrected captions as part of the accessibility assurance for purchased course content. The vendor SLA checklist should include an accessibility section that specifies caption accuracy standards for tool name vocabulary.

6. NERC CIP standard identifiers rendered incorrectly in regulatory training documentation

A bulk electric system operator delivers annual NERC CIP-004 training to all personnel with access to bulk electric system cyber assets. The training content references CIP standard identifiers (CIP-004-7, CIP-007-6, CIP-010-4) as part of the training record requirement. The auto-generated captions for the training videos render "CIP-004-7" as "chip zero zero four seven" or "C I P 004 seven" — neither of which preserves the standard identifier format. When NERC auditors request training documentation as part of a CIP compliance audit, the submitted training records include caption tracks that render the mandatory training content incorrectly. The auditor notes the caption inconsistency as a documentation quality concern. The prevention requires CIP standard identifier codes to be included in the training captioning glossary and caption QA to verify standard identifier format correctness before training records are finalised for audit use.

7. DevSecOps onboarding content produced without security vocabulary in the captioning workflow

An engineering organisation expands its DevSecOps programme and produces a 10-module onboarding series for engineering teams joining the security practice. The content is produced by the security team and submitted to the standard L&D captioning workflow — the same workflow used for product training and HR compliance content. That workflow uses a glossary built for engineering vocabulary (SDK names, API terms, product identifiers) but not for security vocabulary. The DevSecOps content references ATT&CK technique IDs, CVE identifiers for common web application vulnerabilities (OWASP top 10 CVEs), and security tool names at high density. The engineering vocabulary glossary provides no lift for security vocabulary failures. The resulting captions are significantly below threshold on identifier vocabulary. The prevention requires onboarding the security content type into the captioning workflow with a security-domain glossary as a required parameter — not treating it as general technical content and applying the engineering glossary by default.

8. Security training content not included in the annual LMS caption audit

An organisation's LMS caption audit covers all training content in the primary LMS but excludes content delivered through the separate security awareness platform (KnowBe4) on the grounds that it is not managed by the L&D team. The security awareness platform has never been included in a WCAG compliance assessment. Over three years, several thousand modules from the KnowBe4 library have been assigned to employees — none with verified WCAG-compliant captions. When an accommodation request triggers a compliance review, the organisation discovers that its entire security awareness training programme is outside the scope of its caption compliance programme. The fix requires a retrospective audit of all assigned security awareness content, an accelerated caption quality assessment, and contractual remediation with KnowBe4. The prevention is including all mandatory training content in the annual caption audit scope, regardless of which platform delivers it or which team manages the platform. The budget planning guide and compliance reporting framework both assume a complete inventory — security awareness training platforms must be in scope to produce an accurate compliance picture.

FAQ

Is the MITRE ATT&CK JSON file directly usable for glossary seeding, or does it require processing?

The MITRE ATT&CK STIX 2.1 JSON bundle requires processing to extract the glossary-relevant fields — it is a full knowledge representation file with relationship objects, external reference links, and metadata that is not needed for glossary purposes. A simple Python parser that filters for objects of type "attack-pattern" (technique and sub-technique entries), "x-mitre-tactic" (tactic entries), "intrusion-set" (threat actor groups), and "malware" (tool names as classified by MITRE) and extracts the "name" and "external_references" fields (where the external_references array contains the ATT&CK identifier for each entry) produces a clean vocabulary list suitable for glossary ingestion. The extracted technique names become glossary entries; the technique IDs are included as contextual annotation but the primary glossary entry is the canonical technique name, which is the natural-language form the ASR model handles correctly. The MITRE ATT&CK GitHub repository (github.com/mitre-attack/attack-stix-data) maintains versioned STIX files for all ATT&CK releases, which allows the glossary update process to be fully automated against the version history.

How do we handle content that references both older MITRE ATT&CK technique IDs and the renamed versions in newer framework releases?

MITRE occasionally retires technique IDs when techniques are reorganised — for example, T1086 (PowerShell) was superseded by T1059.001 in ATT&CK v7. Older training content may still reference the deprecated ID, while newer content uses the current ID. The glossary should include both the deprecated ID and the current ID as entries, both mapping to the correct technique name, to ensure consistency across content produced at different times. The QA reviewer should flag instances where deprecated IDs appear in content produced after the technique was retired — this may indicate outdated training content that needs a content review, not just a caption correction. The glossary's ATT&CK section can include a "deprecated" flag for retired identifiers to make this distinction visible in the review process. If an LMS migration is in the plan, the migration caption checklist includes a step for identifying content vintage — which is useful for identifying modules that may reference deprecated ATT&CK identifiers.

Our security certification prep content is produced by an external training vendor. Who is responsible for caption quality?

The compliance obligation is with the employer who assigns the training — but the practical responsibility depends on how the assignment is structured. If the employer purchases seats on the vendor's platform and employees access the training through the vendor's interface (as with SANS OnDemand or Offensive Security's training portal), the employer's remediation capability is limited to requesting corrected content from the vendor. If the employer purchases SCORM-deployable course packages and deploys them within its own LMS, the employer has the correction responsibility and must negotiate with the vendor to obtain updated packages with corrected captions. The contract should establish which party is responsible for maintaining WCAG-compliant captions — before signing, not after deployment. The vendor SLA review checklist includes the specific contract language to request. For certification prep content specifically, confirm that the vendor's WCAG compliance claim covers the technical vocabulary in the content — a vendor who claims WCAG compliance based on auto-caption presence without identifier accuracy verification is not providing the warranty the employer needs.

Our NERC CIP training is produced internally and referenced in compliance audits. What caption quality standard applies?

For NERC CIP compliance purposes, the training documentation (which includes the caption track in the training record) must accurately reflect the training content delivered. There is no NERC CIP-specific caption accuracy standard — the applicable standard is WCAG 2.1 AA (99% accuracy, properly synchronised), which applies via ADA and Section 508 requirements rather than through NERC CIP directly. However, the specific requirement to document mandatory training content means that caption errors in NERC CIP training have a documentation integrity dimension beyond the accessibility dimension. A caption track that renders CIP standard identifiers incorrectly is not a reliable training record of the content delivered. For NERC audit purposes, training records should include a QA-verified caption file that demonstrates identifier accuracy for all CIP standard references. Include the caption QA sign-off in the training record documentation — this provides audit evidence that caption quality was verified, not just that a caption file was present.

How do we prioritise which security training content to re-caption first if we discover widespread identifier errors in our existing library?

Apply the same risk-based prioritisation framework used for large-scale caption backlog remediation: prioritise active-enrollment content, mandatory compliance training, and content used in employee accommodation workflows. For cybersecurity training specifically, the highest-priority re-captioning targets are: (1) mandatory regulatory training with active assigned learners (NERC CIP, CMMC, FINRA, HIPAA Security Rule content); (2) security awareness content assigned to the full employee population (phishing awareness, social engineering — highest learner volume); (3) content used in security incident response training that references specific CVE identifiers (where the identifier is operationally important, not just contextual); (4) security operations and certification prep content for employees with documented accommodation needs. Content that references only tactic names and general security concepts (without specific identifier-class vocabulary) is lower priority for re-captioning because the natural-language content is correctly transcribed even without the cybersecurity glossary. A targeted scan of the library for identifier-pattern strings (CVE-\d{4}-\d+, T\d{4}) identifies the modules with the highest identifier density and therefore the highest re-captioning priority within each tier.

We are producing a security awareness training module in-house for the first time. What should we do differently from our standard L&D captioning workflow?

Four workflow modifications are specific to cybersecurity training content. First, build the glossary before captioning, not after: identify all CVE identifiers, ATT&CK technique IDs, NIST control codes, vendor product names, and tool names that appear in the script, and verify each is in the captioning glossary before the first submission. Second, use human review rather than AI-only, even for short modules: the identifier vocabulary density in security content makes AI-only outputs below threshold even with a domain glossary loaded, because the probability injection for identifier-format outputs is still weaker than the probability for natural-language alternatives. Third, conduct an identifier-specific QA review as described in the QA methodology section — do not rely on the standard DCMP word error rate metric alone. Fourth, build the glossary update trigger into your content production process: if a new CVE or ATT&CK technique appears in the script that is not in the glossary, the glossary update is a prerequisite for captioning submission, not a follow-up task. These four modifications add an estimated 30–45 minutes to the pre-production workflow for a typical 20-minute security module, but they prevent the re-captioning cost (typically 2–4× the original captioning cost) that results from discovering identifier errors after LMS deployment.

How do we handle security training content that uses internal terminology (proprietary threat actor names, internal system codenames) that is not in any public glossary source?

Internal vocabulary — proprietary threat group names used in threat intelligence training (like "Threat Actor X" or internal group naming conventions), internal system codenames referenced in security runbook training, internal tool names for custom security tools built by the engineering team — must be sourced manually rather than from public feeds. The process is the same as for any internal-vocabulary L&D content: the content producer or subject matter expert reviews the script and identifies all internally-named terms, provides the canonical spelling and capitalisation for each, and submits these as the manual component of the glossary alongside the programmatically-sourced ATT&CK and CVE entries. Internal threat actor naming conventions in particular should be reviewed by the threat intelligence team before being submitted to any external captioning vendor, to ensure that sharing the names with the vendor does not violate internal information classification policies. The caption compliance programme build guide covers the vendor data handling policies and how to evaluate whether an external captioning vendor is appropriate for classified or sensitive training content.