This post is part of our ongoing MTSA cybersecurity series, where we work through the regulation’s requirements using a crawl, walk, run approach.
Catch up on the rest of the series and find related infographics in Related resources at the end of this post.
Every other requirement in this series assumes competent humans are executing it. Segmentation, access control, encryption, none of it holds if the people touching the systems don’t know what they’re looking at. That’s what 33 CFR 101.650(d) is for, and it splits into two tiers rather than one blanket requirement.Key personnel, those with access to IT or remotely accessible OT systems, get two more topics on top of that baseline:
● understanding their role and responsibilities during a cyber incident and response procedure,
● and staying current on changing threats and countermeasures.
The regulation’s own language does real work here that’s easy to skim past: baseline training applies to “personnel with access to the IT or OT systems, including contractors, whether part-time, full-time, temporary, or permanent.” That clause follows the access, not the org chart, and it catches populations most training programs never touch:
- Vendors and third-party maintenance techs who connect to OT gear during a service visit
- OEM personnel who show up for warranty work, commissioning, or troubleshooting and get handed local access on the spot
- Assessment teams, Dragos included, who get scoped access to run a penetration test, vulnerability assessment, or tabletop exercise
None of these people are employees, and all of them are in scope the moment they touch a keyboard connected to IT or OT. If a vendor tech shows up for a two-hour service call and hasn’t completed training, the honest options are accompanied access under 101.650(d)(3), or they don’t get on the system unescorted. “They’re only here for an hour” is not an exception the regulation carved out.
One practical option worth considering, and this is a suggestion, not something 101.650(d) requires: have the vessel, facility, or OCS facility provide the training itself rather than pushing the burden onto every vendor, OEM, and third party to build their own program. A lot of the companies sending techs onto your site, especially smaller ones, may not have the budget or bandwidth to stand up compliant cybersecurity training on their own. Providing it yourself solves two problems at once: it removes that cost barrier for smaller vendors, and it guarantees everyone touching your systems, employee or not, is trained against the same content instead of whatever patchwork each outside company happened to put together on their own.
Baseline population: Build the actual list of everyone with IT or OT access, including contractors, part-time staff, and anyone temporary. “Everyone with a badge” and “everyone with system access” are usually two different lists, and the regulation cares about the second one.
Key personnel: Work out, with the CySO, who actually has access to IT or remotely accessible OT: that’s your key personnel population, and it’s usually smaller and more specific than “management” or “senior staff.”
Current state: Find out what training already exists, however informal, and map it against the five baseline topics and two key-personnel topics. Most organizations already have some general security awareness training; almost none of it covers OT-specific recognition or the reporting path to a named CySO.
At this stage, the deliverable is a training population roster split into baseline and key personnel, and a gap analysis against the seven required topics.
Baseline training: Stand up training that hits all five required topics, and don’t let “cybersecurity training” quietly become generic phishing-awareness content. The OT-specific topic in particular gets skipped constantly because it’s easier to hand everyone the same IT-focused module. If someone’s duties include using OT, they need OT-specific content, full stop.
Key personnel training: Layer the two additional topics on top for anyone in that population: incident response roles and responsibilities, and a mechanism for staying current on threats. This is usually a shorter, more targeted add-on rather than a second full course.
Accompanied access: For anyone who has to access IT or OT before their training is complete, 101.650(d)(3) requires they be accompanied or monitored by someone who has already completed it. This needs to be a documented, enforced process, not a verbal “just stick with Dave for now.”
Timelines: This is where a lot of programs quietly fall behind. Recognition and detection, circumvention techniques, reporting procedures, and OT-specific training (topics (ii) through (v)) were due by January 12, 2026, and annually thereafter. That deadline has already passed. The Cybersecurity Plan awareness topic, (d)(1)(i), is due within 60 days of the Plan’s approval instead, since you can’t train on a plan that doesn’t exist yet. New hires get 5 days from system access, no later than 30 days from hire date. Personnel getting access to new IT or OT systems get 5 days from that access. Everything repeats annually after the first cycle.
At this stage, the deliverables mature into a documented curriculum mapped to each required topic, a completion tracker split by baseline and key personnel, a written accompanied-access procedure, and a training calendar built around the actual regulatory deadlines rather than a generic annual refresh date.
Baseline and key personnel: Training completion gets tracked in something that flags lapses automatically, not a spreadsheet someone remembers to check. New hires and role changes trigger their training clock the moment access is granted, not at the next scheduled session. Content gets reviewed and updated on a cycle tied to the current threat landscape, not just reused year over year because it technically still covers the five topics.
Accompanied access: The accompanied-access list gets audited against actual training completion, so “temporarily escorted” doesn’t quietly become the permanent status for someone who never finishes the course.
During a tabletop exercise, we had actual operators in the room, which is when this requirement stops being theoretical. We handed a senior operator a scenario: a ransomware message on her HMI. Her answer was reasonable on its own terms: try a few things, then just move to the next HMI to keep production going, and mention it to the maintenance supervisor at shift turnover. Production doesn’t wait, and nobody had told her it should.
The maintenance supervisor, also in the room, said he’d reboot it, unplug and replug a few things, and eventually loop in IT. The IT person, sitting in the back, said his plan was to just reload the machine.
Three people, three completely reasonable-sounding responses, and not one of them involved recognizing that what they were looking at was ransomware. Every response also happened to be the fastest way to destroy the forensic evidence and let the encryption keep spreading to the next HMI in line. That’s the baseline training topic on recognition and detection, and the OT-specific topic, doing exactly the job they’re supposed to do, and in this exercise, neither one had actually reached the people standing closest to the incident when it started.
- Blog #1: All Hands-on Deck: The USCG Just Made Cybersecurity Non-Negotiable
- Blog #2: You Can’t Protect What You Can’t See: MTSA’s Asset Inventory Mandate
- Blog #3: Who’s Allowed on the Bridge: MTSA’s Network Segmentation Requirement
- Blog #4: Designing for Disruption: MTSA’s Resilience Requirement
- Blog #5: The Work that Never Makes the Highlight Reel: MTSA’s Routine Maintenance Requirement
- Blog #6: No Devices Adrift: MTSA’s Device Security Requirement
- Blog #7: One Password, One Pipeline: MTSA’s Account Security Requirement
- Blog #8: Locking the Log Book: MTSA’s Data Security Requirement
