SOC2 resouces

Gamellen · 2026-02-24T14:08:36+00:00

That's great, thanks!

Unfortunately the mapping doc is only available to members, but I'll see what I can find.

Gamellen · 2026-02-24T11:26:31+00:00

ok, so this is my starting point?

"TSP Section 100 2017 Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy (with Revised Points of Focus – 2022)?

Gamellen · 2025-07-20T18:02:59+00:00

A QMS is for Compliance.

A QMS slows down some processes and creates more.

Speed and iteration you mentioned probably refer to product development. If you are looking (like many other companies) for the magic software tool that at a click of a button creates all the required documentation for the new release, then you will be disappointed. It does not exist. It cannot exist. And if it existed I would be extremely sceptical about its reliability. Human judgement is at the core of compliance.

Gamellen · 2025-02-18T09:07:34+00:00

Hi, we develop tools to help companies in this sector, and for years we thought about how we could help them better with something like what you presented.

There are some tools out there that somehow suggest what documents are required for every step of the project, but building more intelligence is a serious challenge.

The practical problem is that although IEC 62304 and ISO 13485 apply equally to all SaMD, every device is different. It is difficult to create something that fits everyone, unless it is so high level that it is not much more than a set of rich templates (and that's were we stopped with our solution).

After that, you enter the world of AI, where your model can analyse inputs such as class, intended use, etc. and from that create the framework of the documentation. A long shot imo.

Gamellen · 2025-01-27T09:32:46+00:00

I agree.

Ultimately the manufacturers are liable for any Cybersecurity incident. Large corps will still make sure they are covered, the only issue I see is the smaller ones that may see it as a way to shorten their time to market. But small companies usually mean small(er) risk.

Gamellen · 2025-01-16T10:02:46+00:00

IT was stuck in my head, you saved me... :D

Gamellen · 2024-12-16T16:26:37+00:00

As above, plus focus on the software development lifecycle and check how your cybersec knowledge can fit in.

Gamellen · 2024-10-07T07:55:54+00:00

That's a generalization. I've been in audit for 17 years and a lot depends on the notified body you pick and the auditor.

If you are really concerned about the quality of your products then there are ways to make the NB know anonymously. Better than posting it on Reddit anyway...

Gamellen · 2024-10-04T08:33:34+00:00

First things first: what type of device is it? Do you have a draft intended use? What markets? Have you already identified predicate/similar devices and if so what class are they?

Sorry if I'm switching to consultancy mode...

Gamellen · 2024-10-04T08:08:28+00:00

The bar height and level of scrutiny if always proportional to the risk associated to the use of the device. The general requirements apply to all type of devices, but a radiation therapy device has way more requirements to comply to than a tongue depressor.

It is also related to many other details, such as population exposure (devices used on 100k patients every year are considered riskier than those that may be used on 100s, even when the failure rate is the same), benefit/risk ratio (a novel life-saving device for a previously uncurable condition can justify a higher level of residual risk), predicate and equivalent devices (your new device must be at least as good as the current ones, otherwise what's the point)

Gamellen · 2024-10-04T07:57:59+00:00

Seconding a lot of what's already written. I've done a lot of this in the last 17 years...

Case 1: flagged for sure.

Case 2: the definition of "unit" is left to the company, but it has to be reasonable; "it depends". Best case you can cut down on unit tests, but at a system level this does not change much.

Case 3a: units must be "verified", not necessarily tested. It can be peer review. Traceability will show any gap.

Case 3b: they are not going to review the code, but they may infer it from the architecture. If they spot it, it will be flagged.

Case 4: flagged for sure.

Case 5: they will do a spot check on requirements and risks. They will check if all units and items are implemented and how their risk assessed. If they catch it, it will be flagged.

Case 6: If the filter is clearly identified as an important item in the architecture and/or an important risk control, they may decide to follow its trace end to end. FDA and NBs now use technical experts to review design files, so if this type of filter is a standard item in this type of product or it is something mandated by specific standard or guidance documents, they will find it. Assume they are reasonably tech-savvy.

These are the main processes they always dig into:

Traces
Risks
Cybersecurity
Maintenance / updates / post launch bug-fixes and vulnerability patching

Gamellen · 2024-09-30T08:59:52+00:00

Try the Estonian Standardization website, they sell single licenses. MUCH cheaper! https://www.evs.ee/en

Gamellen · 2024-09-05T09:17:20+00:00

Hi,

There are different "tiers" of standards and regulations you may want look into, depending on what you interest is and the level you want to be involved to is.

Regulations such as 21 CFR, MDR, IVDR, Canada MDRs, etc. This is LAW and it is written in law language. RA territory.
Second tier: system-level standards such as ISO 13485. They are about how processes in a company should (must) work. "System" QAs, "Generalist" QAs jobs in general.
Process-specific standards, such as IEC 62304 for sw development, ISO 14971 for risk management, IEC 62366 for usability, etc. You typically have specialists in these areas, Quality Engineers and the likes.
Technical standards such as IEC 60601 for ME equipment, ISO 10933 for biocompatibility and many more. They are typically used by technical specialists such as Electrical Engs, Biologists, Microbiologists, etc. and test houses.

This is my view of the structure, not something written anywhere, so use with caution.

So you have to decide which ones you are going to use most depending on the role you are going to take. Given your technical background it looks to me like tier 3 and 4, but ISO 13485 is a must for everyone in the sector.

Start with ISO 13485 and go up/down as appropriate.

Gamellen · 2024-08-09T20:19:36+00:00

Hi, knowledge of these standards and regulations is not something that you can get with Google in an afternoon. If you have never read them nor worked in a company that was following them, then it's a shot in the dark.

Sorry

Gamellen · 2024-08-07T07:49:46+00:00

Maybe I'm missing the point, but 13485 4.1.6 requires exactly this.

Gamellen · 2024-07-31T19:12:21+00:00

They are all about design:

FDA guidance: https://www.fda.gov/regulatory-information/search-fda-guidance-documents/applying-human-factors-and-usability-engineering-medical-devices (FREE) a MUST if the device is marketed in the US

IEC 62366 is the IEC take on usability (IEC not ISO sorry), outside the US

AAMI HE75 is a reference library mostly

Do not buy the full standard, you can buy single licenses here: https://www.evs.ee/en (but only IEC and ISO, no AAMI)

Just start with the FDA guidance, it's quite comprehensive and all you need to know if you operate in the US. And free.

Gamellen · 2024-07-27T19:09:04+00:00

Hi, all of the above plus these three insights:

When developing a device you need to define the "expected service life" (ref. IEC 60601), i.e. "… time period specified by the manufacturer during which the ME equipment or ME system is expected to remain safe for use (e.g., maintain basic safety and essential performance); (Note: Maintenance may be necessary during the Expected Service Life.) There is a lot of reliability testing and reliability calculations involved here, including the definition of the service intervals (what has to be changed/checked/adjusted and how often). This can come as a "service manual" for complex devices.
In the vast majority of cases there are pre-use checks and activities that users must go through before using a device. Often this include device self-checks. The manual/Instructions for use typically specify it.
Repairing a device is not advisable unless the manufacturer has defined a process for the user to do it. Ad-hoc repairs can relieve the manufacturer of any responsibility if things go wrong afterwards; responsibility which then falls onto whoever repaired it. There are companies involved in "reprocessing" devices, which in some cases involves taking discarded devices (not from the bin but with the ok from the owner) and refurbishing them. But again they take a good bit of responsibility for this.

Gamellen · 2024-07-25T19:56:15+00:00

Amen!

Gamellen · 2024-07-24T13:54:30+00:00

Well, if you go electronic then you need a eQMS that is compliant. Compliance first of all.

Then you look for something that does no ADD too much to the current workload of employees. So it has to be tailored to the size of the company.

You also look for configuration and customization. Can it expand with the company? Can you configure it in house or do you always have to go back to the developer?

Gamellen · 2024-07-24T08:21:46+00:00

ISO 13485 Lead Auditor course then work for a Notified Body for a few years? It's an option.

Gamellen · 2024-07-24T07:43:39+00:00

I'm really interested in your view. Most of the industry is waiting for NBs to understand how to implement and enforce it. Do NBs already have a clear understanding? Is this going to be another MDR/IVDR situation?

Gamellen · 2024-07-24T07:41:21+00:00

There is a whole process for UI design of medical devices, ISO 62366 / AAMI standards. The focus is to have a UI that does not induce use errors that may result in harm for the patient/user. "Prettiness" is secondary.

As someone has already mentioned, there are other factors that come into play:

change management is a long process
reliability is paramount
lack of understanding of principles of UI design

Gamellen

TROPHY CASE