Service — Build the capability
Your quality system needs a cybersecurity spine. We install one.
Not a template pack you adapt alone over six months. Working procedures, a live risk assessment workbook, and a pilot on a real project — adapted to your document control, approved through your workflow, and handed over to your team.
There is a gap in the middle of this market.
At one end you can buy a downloadable cybersecurity template pack. It is cheap, it is generic, and it leaves you to work out what FDA meant, which parts apply to your device, how the pieces connect, and how any of it survives an audit. Teams routinely spend more internal hours adapting a template pack than the pack saved them.
At the other end you can hire a consultancy to produce one submission’s worth of documentation. That gets you through this filing. It does not leave you with a process, so the next device starts over — and QMSR now means an auditor can ask to see the process, not just the output.
This service is the middle. A cybersecurity quality system that exists after we leave, that your engineers can run without us, and that produces submission-grade evidence as a by-product of ordinary development.
21 CFR Part 820 now incorporates ISO 13485:2016. Cybersecurity activities are design controls. That means the question is no longer only “did you produce the artifacts for this submission” but “do you have a documented process, and can you show the records it produced.”
FDA’s February 2026 guidance reinforces this: it expects a secure product development framework integrated with your quality system, with objective evidence at every design phase. A cybersecurity file assembled outside the QMS answers the wrong question.
What gets installed.
A procedure layer that says how the work is done, a template layer that captures the output, and a tooling layer that does the scoring and the analysis. All three, adapted to you.
How the work gets done
- Cybersecurity risk assessment procedure
- Cybersecurity management procedure, covering the management plan, the management report, and the postmarket commitments under §524B(b)(1)
- Cybersecurity testing and verification procedure
- Work instruction for threat generation in the Microsoft Threat Modeling Tool
- Work instruction for operating the risk assessment workbook
- Interfaces defined to your existing software lifecycle, design control, risk management, complaint handling, and CAPA procedures
What the work produces
- Cybersecurity management plan
- Cybersecurity management report
- Cybersecurity test plan
- Cybersecurity test summary report
- Security architecture views — all four, structured to the guidance’s Appendix 2 level of detail
- Consolidated security risk management report
- Traceability matrix: requirement → threat → control → verification → residual risk → ISO 14971 harm
- SBOM and vulnerability assessment, including support status and end-of-support
- Security labeling and customer security documentation
- Unresolved anomalies assessment
The risk assessment workbook
- CVSS v4.0 scoring, including environmental, modified, and supplemental metrics such as Safety and Automatable
- Initial and residual risk per threat — before and after controls
- STRIDE threat import from the Microsoft Threat Modeling Tool
- Acceptability decisions with benefit-risk flag and explicit safety linkage
- SBOM vulnerability analysis tab with CVE, CVSS, and CISA KEV flagging
- Controls catalog typed to FDA’s security control categories
- Metrics and summary tabs that roll up for the management report
Adapted, not dropped on you. Procedures get your document numbers, your approval roles, and your revision history. Templates match your header, footer, and formatting conventions. References point at your surrounding procedures. The workbook is tuned to how your team actually scores risk. If it looks like it came from somewhere else, it will not get used.
The front door
Start with a gap assessment.
Two to three weeks, fixed scope. It tells you what you have, what the February 2026 guidance expects, and what it will take to close the distance — whether or not you do the rest of the work with us.
What we review
- Existing cybersecurity procedures, work instructions, and templates — or the absence of them
- Your software lifecycle, design control, and risk management procedures, for the seams where security has to connect
- A completed exemplar project if one exists: a filled risk assessment, a management plan, a test report
- Your SBOM tooling and a sample output
- Any FDA correspondence, audit findings, or notified body observations touching security
What you get
- A finding-by-finding gap list against the February 2026 guidance and §524B, each one traced to the guidance section that drives it
- Priority ranking — what blocks a submission, what an auditor will find, what can wait
- Currency check: templates and procedures still citing superseded guidance, and the references that need to change
- A remediation plan with sequence, effort, and owner for each item
- A written read on whether your current threat model and architecture views would survive review
The gap assessment is deliberately useful on its own. If you want to take the findings and close them internally, that is a perfectly good outcome and the report is written to let you do it. If you would rather not, we already know exactly what needs building.
How the install runs.
Assess
The gap assessment above. Nothing gets written until we know what you already have and where the real exposure is.
Adapt
Procedures, templates, and the workbook rewritten into your document control, with references pointed at your surrounding QMS. Reviewed and approved through your normal workflow.
Pilot
Run the system once, on a real project, with your engineers doing the work and ours alongside. A threat model, a scored risk assessment, a test plan. This is where the process gets tested rather than admired.
Hand over
Training for engineering, quality, and regulatory in their own language. Then you own it: the documents, the workbook, and a team that has already used them once.
The pilot is not optional and it is the point. A procedure that has never been executed is a document. A procedure that has produced a real threat model, a scored risk file, and a test report is a process — and only one of those two survives an audit.
Who this is for.
Teams that will file more than once and would rather build the muscle than rent it every time.
- A first connected product, with more in the roadmap
- A QMS with no security risk management procedure
- Templates that still cite superseded FDA guidance
- An audit or notified body finding on cybersecurity
- A platform strategy where several devices share software
- A team that has outgrown a downloaded template pack
- Security risk and safety risk kept in two files that disagree
- Engineers doing this ad hoc, differently each time
Questions about the framework.
Do we own the procedures and templates afterward?
Yes. They become your controlled documents, under your numbering and revision control, for use across your product line. That is the whole idea — you should not need us to run your quality system.
How is this different from buying a template pack?
Three things. The procedures are written to interface with your existing lifecycle and risk procedures rather than to a generic QMS that does not exist. The risk workbook is working tooling — CVSS v4.0 scoring, STRIDE import, KEV screening, controls catalog — not a blank table. And we run it once with your team on a real project, so the handover is to people who have used it rather than people who have read it.
Can you do this while we are mid-submission?
Often, yes, but be honest with yourself about sequencing. If a filing date is close, the right move is usually to build the submission content first and install the framework immediately behind it, reusing what the submission produced. We would rather tell you that than sell you both at once and miss the date.
Will this satisfy an ISO 13485 or QMSR audit?
The framework is built to be auditable: defined procedures, defined records, traceability into design controls, and objective evidence at each phase. What we cannot do is promise an outcome from an audit we do not conduct. What we can do is make sure the process exists, the records are where an auditor expects to find them, and the answers to the obvious questions are already written down.
We use an eQMS. Does that change anything?
No, it usually helps. The procedures and templates go into your eQMS the same way any controlled document does. The risk assessment workbook lives alongside as a controlled record. If your eQMS has native security risk capability, we will use it rather than duplicating it — the goal is one place where the risk file lives.
Start with a conversation about your device.
Thirty minutes with a senior medical device software expert who understands both the regulatory requirements and the business realities of bringing software to market. Bring your architecture, your submission type, and your timeline. You will leave knowing which artifacts you are missing and what it takes to close them.
- Submission type and target date — 510(k), De Novo, PMA, IDE, or a postmarket change
- A block diagram or architecture sketch, however rough
- Your interface list: network, LIS, USB, wireless, cloud, service ports
- Whatever cybersecurity documentation exists today, including nothing at all
- Any FDA correspondence you have already received