If only a small part of your code has been changed since your last release, you can just go ahead and check which software requirements and tests are affected by it. Only re-run those. But write down your reasoning somewhere, e.g. in your test plan, where you describe which tests don’t have to be re-done and why.
This is assuming that those tests were on a small (e.g. unit) level. Regarding your integration tests, I’d re-run those to ensure that you haven’t inadvertently broken something. This should be an easy win because your integration tests are usually automated (they are, right?).
The main point of this is to minimize unnecessary human (manual) testing if it’s not necessary.
But this is yet another topic which heavily depends on your auditor. When in doubt, I’d suggest that you make a proposal (write a test plan as described above), send it to them and ask them if that approach would be okay. They aren’t allowed to provide consulting to you but they should be able to give you an indication on whether you can move ahead with your approach or whether it needs more work.
See also my article on software system testing and the software system test plan template.
