Enough is enough: How to do "enough" security to satisfy FDA

How to do enough security to survive and thrive through cybersecurity regulatory review and postmarket surveillance

I attended the AdvaMed Cybersecurity Summit last week (courtesy of a client - thank you!). The first talk was from the FDA, the panel had an FDA speaker, the next talk was by a leader who has collaborated with the FDA on cybersecurity standards and training for years, and the next was by a former FDA reviewer with specific expertise in software risk. In short, it was an event heavily laden with expertise in the FDA's expectations for cybersecurity.

AdvaMed Cybersecurity Summit; Panel led by Chris Reed, VP of Product Security for Medtronic

This summit represents a turning point. The prior AdvaMed summits and all the other medtech cyber-related events came before 524B, FDA's expanded, concrete authority. There was a palpable acceptance and focus not on whether there is cybersecurity work to do, but how much.

Audience members raised their hands and asked questions that belied an overall concern: "If I do X, is it enough?" or "My device does not connect to the internet, does that mean it is excluded from the new guidance?" There was even a session with a mock cybersecurity review where a would-be sponsor interacted with the FDA lead for cybersecurity reviews (Matt Hazelett). Most of the back and forth amounted to the sponsor saying "is x enough" and Matt responding "Read the guidance, do what it says."

I have spoken with countless medical device manufacturers (MDM) about what is "enough" for the FDA. This includes both R&D leaders from the top ten MDMs to CEOs of early-stage companies. Once people are past the denial stage, they ask "What do I have to do?"

The FDA has spelled it out for MDMs in its guidance, and the FDA is working hard to harmonize what you have to do for the FDA into international standards so they don't have to work extra hard on compliance for compliance's sake. "Enough" is doing, and having done, what the guidance says. It is really that simple. Read the directions, and do what they say.

The harder part, and something I can't spell out in a blog post, is the "how." How to do what the guidance says depends on the risk level of the device, the software stack, the use environment, and many other factors. Some complain that the guidance isn't prescriptive enough. I disagree wholeheartedly: It is a good thing that the FDA and other regulators don't specify the "how" - if they did, it would stifle innovation.

But, I promised "how" in my title. So here's how:

1. Read the guidance with which you're aiming to comply (30 mins).

2. Make a list of to-dos derived directly from the guidance (copy and paste, 30 mins).

3. Make a three-column table: the first column is the list of to-dos; the second column is a list of "hows;" and the third column is the human responsible for the "how." Drop the list from step 2 into this table (30 mins).

4. Take a break for at least a day.

5. Start filling in columns 2 and 3 (>1 hour).

Once you do this, if there are blank spots on the how column, reach out for help and/or start googling. There are a lot of free tools.

I am not being facetious. If you are responsible for bringing a software-enabled or "cyber device" to market and your responsibility includes engineering, this is a valuable exercise. Get to know the requirements personally. The requirements are much more valuable if you know the whole guidance yourself. You'll be able to empower your teams, you'll be able to work with vendors more adeptly (e.g., pentesters), and you'll feel more relaxed about how to do "enough" security for your device.

If you are concerned about meeting the requirements, for yourself or your customers, do this now. Later is always more expensive and requires more painful tradeoffs later in the development lifecycle.

~Shannon, the Optimistic Optimizer

Ps. I'm almost embarrassed to post this. It may appear sophomoric and naive. And yet, I speak and have worked with many people who are very concerned with submission, it's a critical responsibility of their job, and they've not read the guidance. I know not everyone can read all the guidances FDA puts out, but it seems like there would be a lot less stress at these conferences if more people would read it.