This is one of those cases where it depends on the context or situation.
Many risk controls are state of the art and well established. In such a case it's common to fudge over the details, with good reason.
For example, in an electrical device, I could write a medium sized book about the safety issues associated with just the appliance inlet (fire, thermal, cord retention, corrosion, electrical insulation, electrical conductivity, mechanical rigidity, fixing means; detailing the true risk controls from raw materials, physical characteristics, design tests, production controls, installation and more).
But instead we mumble something about "fire" and "electric shock" and refer to "IEC 60601-1 test" as a risk control.
There are times when this oversimplification is a problem. For example, a manufacturer recognises that water ingress is a potential issue. Instead of designing in features that provide water protection, they actually use testing as a risk control. They do the test, and some water gets in. Then they decide the location is OK, nothing bad happened, and judge the risk is acceptable.
Why is this wrong? In practice, a test is far from comprehensive. It's difficult to cover all the possible permutations, settings, conditions, options, variations in production, ageing and so on. Instead, most tests are more like spot checks. This approach works well when combined with good design and reasonable design margins (i.e. a little overkill). So, a good designer will add waterproof gaskets and position the remaining ventilation holes to places where the water won't be able to get near critical parts. The designer is then confident of a pass result before the test is performed.
That said, an experienced manufacturer might do all that stuff (gaskets, sensible vent holes) without spelling it out in the risk management file. So it could still end up like the first case, where the risk control is referred to as "IPX2 test".
Purists might argue that it's better to spell everything out just in case, to avoid the former try-and-see situation. It means, the literal risk control (gaskets and vent hole positions) should be referred to as the risk control, and IPX2 test is just verification.
But I think that is naive, because it does not take into account the true real volume of risk controls in a typical medical device. I suspect there are >>10,000 risk controls in a medium risk medical device (remember the number of issues handled by a simple appliance inlet, let alone thinking about functional and performance issues). And even referring to a "gasket" is major oversimplification; a gasket designer would be happy to talk for hours about the detail of what goes into reliable gasket design.
The true problem that ISO 14971 does not have a filter function to allow manufacturers to switch between different levels of documentation, ranging from no documentation (if it's already well covered by normal practice, standards and state of the art), through to detailed documentation for example in the case of new solutions, where R&D is required to establish the type and parameters of the risk control, or special cases where conflicting design or other issues force a level of risk to remain.
Instead we end up with a file full of fluff which naive auditors can easily find some meaningless semantics to argue about.
And, the final point (sorry!) is that if designers are so bad that they use a test-first approach instead of good design, semantics isn't going to fix things. This is a real concern with the rise of copy cat manufacturers that see a medical product and say "hey, I could make that at 1/3 the price" only to find they are way out of their depth. We need auditors with the guts to write a non-conformity report citing a lack of qualification and experience, not about the semantics in a risk management file.