Thank you for your comment! I want to add to it as a former pentester: it's absolutely painful to read about these nitpicky "the world is going to burn if you

Thank you for your comment! I want to add to it as a former pentester: it's absolutely painful to read about these nitpicky "the world is going to burn if you don't modify trivial security setting X that will destroy user experience". Not because these shouldn't be included in the report, but because the focus is wrong. As strayptr, I would also include the trivial issues as "informationals" in the report as you do want your clients to know about these for a number of reasons. However, most of my time would go to hunting for severe issues, where I defined severe on some mental ranking based on "difficulty to exploit", potential impact,... In addition, these issues were also where most of my attention went to afterwards, because you need to explain and educate development, testing and business on the issues, why you think they are important and how to best/quickest fix them. In my opinion, building up relationships and having empathy for your client is very important. I would always try to have a chat with development/test/business to get a feel of where their heads were at. That would help me both while testing (what is important to them? how did they develop it? what is their maturity?) and while reporting issues (they would actually believe me, I could help them rank the issues and they would allow me to brainstorm how to best mitigate the issues for their environment).