The traditional approach is to go bottom up - start talking about the signals of CAN (briefly) then move up to CAN messages then build upon that to show what sort of things might be in messages, etc. But, to some extent car hackers probably care as much about how CAN looks on the wire as computer hackers care about how ethernet looks at a deep level. Which is to say, most of them don’t. The signals are unimportant, presumably the designer of the hardware knew what they were doing. Most people usually still mention signal level a bit to give some background but don’t spend a lot of time on it.
The really important aspect is the message format itself (std/etc, rtr, 0-8 data bytes, etc) then build on the abstractions above - J1939, CANOpen, UDS, etc. One needs to understand how UDS is formatted before getting into the nastier, more complicated aspects like challenge/response for security access.
So, I’d cover signals briefly, cover raw CAN for a little bit (it’s actually pretty simple and shouldn’t require much time I don’t think) then move to more and more complication and abstraction away from the raw format.