JSP Concept Phase - Laying the Foundation

Picture this:
A new product idea is on the table. Marketing is buzzing about features. Engineering is sketching early designs. Executives are running the numbers.

Then someone asks: “How will we deliver security updates if there’s a vulnerability in the field?”

Silence.

That silence is exactly why the Concept Phase (Sections A.1 - A.3) of the Joint Security Plan (JSP) matters so much. This is where you pour the foundation of your cybersecurity “house.” If the foundation is strong, everything built on top stands firm. If it’s weak - or skipped - you’ll see cracks later, often when they're the most expensive fix.

‍

Blueprint the Foundation: Release and Change Project Planning (JSP2 Section A.1)

Every build starts with a blueprint and a budget. In product development, that means defining the scope of your project: are you building something brand new, making a major addition, or just replacing a few shingles (maintenance)?

At this stage, teams gather inputs - project charter, early user needs, even the JSP itself - to decide what security activities are needed. The outputs matter just as much: a Development Plan, a Change Impact Assessment, and updates to your Security Management Plan. 

And here’s the piece often overlooked: resources. Just like you would start pouring a slab of concrete without security materials and a construction crew, you shouldn’t launch development without committing the financial and professional resources for security activities. . If you don’t budget now, you’ll be underfunded and understaffed later, when it hurts the most.

‍

‍

Designing for the People Who Live in the House: Voice of the Customer (JSP2 Section A.2)

A good house works for the people who live in it. The same is true for medical devices. Stakeholders - patients, clinicians, hospital IT, services staff, regulators - all bring different security needs.

• Patients may expect updates that don’t require technical steps.
• Clinicians want controls that don’t disrupt workflow. 
• Hospital IT staff need patch schedules, access roles, and SBOMs.
• Field services teams want clear processes for secure remote access. 
• Regulators expect proof of compliance with the standards in their jurisdiction. 

These voices become inputs to your user needs. If you don’t capture them now, you mAy end up building security that looks good on paper but fails in the real world - like a house with doors that stick and windows no one can open. 

‍

Writing the Homeowner’s Manual: Security Management Planning (JSP2 Section A.3)

Finally, every good build comes with a plan for upkeep. In the Concept Phase, this takes the form of a Security Risk Management Plan - a living document that guides the rest of the project. 

This plan sets direction for: 

• How you’ll assess and document security risks alongside safety risks (think of it as making sure fire alarms work alongside door locks).
• What “acceptable” security risk looks like for this product, and what will require mitigation. 
• How vulnerabilities in third-party components will be monitored, assessed, and patched. 
• How you’ll handle updates and coordinated disclosure in the field.
• Supplier and contractor expectations for secure components.
• Roles and responsibilities across the team, so there’s no confusion later. 
• You’re not putting up walls yet, but you are deciding how strong the structure will be. That means answering questions like:

It is not the final playbook yet, but it’s enough to make sure the house can be maintained once people move in. And like any homeowner’s manual, it evolves when the scope changes - new additions, new markets, or new risks.

‍

Who’s in the Room

Pouring the foundation takes a team. Product managers, engineers, and RA/QA  lead planning. Executives commit resources. Sales and marketing push for clarity to answer customer questions. Service and manufacturing teams weigh in on feasibility. Clinicians (or end users) validate that  decision won’t compromise usability.

This is like the site meeting before the concrete truck arrives: Everyone needs to show up so there are no surprises once the pour begins.

Why It Matters

The FDA - and other regulators - play the role of the final inspector. They expect to see your foundation documented: security objectives, planning artifacts, stakeholder needs, and your Security Management Plan. Hospitals and buyers are are not inspectors too, asking: “What do I need to do to operate this device securely? Can this device be updated? Do you have security documentation such as MDS2 and SBOM?” Sales teams need those answers before they’re even in the field.

If you don’t prepare, you’ll be tearing up walls later to fix a crack in the foundation. That’s expensive, disruptive, and entirely avoidable.

‍

What You Walk Away With

At the end of the Concept Phase, you foundation should include: 

• A Development Plan or Change Impact Assessment
• A draft Security Management Plan, including preliminary risk acceptability criteria 
• Documented stakeholder security needs folded into user needs
• Defined update and rollback strategies
• An SBOM approach
• Risk register entries tying it all together

These artifacts may sound procedural, but they’re the rebar and concrete of your foundation - the proof that regulators and buyers will look for later. 

The Bottom Line

The Concept Phase isn’t about coding or cryptography. It’s about alignment, planning, and committing resources. Builders, Explainers, and Owners all have a role in making sure the foundation is strong. Do it well, and when the inspector shows up, your house will stand firm for years to come.