Product Security & Engineering
Have a plan. Follow it. Test it.
Have a plan that fits your devices
A documented plan names owners, decision points, and escalation paths for detecting, containing, and recovering from a security event. For a device manufacturer it also covers the installed base: which products and versions are in the field, and how customers will be reached.
Follow it as one team
Incidents cross R&D, QA, customer support, postmarket surveillance, product security, legal, and communications. The plan works when each team knows its role and handoffs before an incident starts, not during one.
Test it before it counts
A tabletop exercise walks your teams through a realistic scenario built from your products and threat profile. It shows where the plan is unclear and where handoffs stall while there is still time to fix them.
Incident Response Readiness Review
Review the plan, close the gaps, then test it.
Assess the plan
We review your incident response plan against Section 524B, FDA's premarket and postmarket cybersecurity guidance, and NIST SP 800-61r3, and find the gaps that could slow your response.
Engage your teams
R&D, QA, support, postmarket, product security, legal, and communications show us the practical gaps documentation misses: unclear ownership, logs no one reviews, escalation paths that skip a team.
Close the gaps
We help you strengthen the playbook and the policies and procedures behind it, using standards where they fit your quality management system.
Run the tabletop
Once remediations are in place, we facilitate a tabletop exercise built for your devices. The findings become recommendations, including the investments they justify.
Notification · not disclosure
Some incidents call for notifying customers or regulators, and your plan should say who approves and sends those notices. That is a communication about an event. Disclosing a vulnerability is a separate, coordinated process with its own policy and partners.