I regularly do a ASVS as part of my freelance activities, and I am excited to share some experiences with you. So firstly, what version do I use? Typically, I use the latest stable version. Occasionally, a costumer requests a specific version. But for now, just grab the latest stable PDF. My deliveries to costumers usually consist of a written report and checklist as an Excel file. You can go ahead and use this checklist to start: https://github.com/shenril/owasp-asvs-checklist Over the time, I developed my own Excel checklist file that can import the raw CSV the OWASP community provides and creates a very similar checklist and score calculation. It just makes it a bit easier to react to new versions and fits more my needs. But again, just grab the checklist from above and you have a good start. So how do we start? First, you need to understand that the ASVS stretches about various parts of a software project, and you won't be able to answer all these questions yourself. This is an assessment, and an assessment requires you to go around and ask people about the product. So first, you need to identify the stakeholder you can ask questions regarding this product. This typically includes the PO, Lead-Developer and so on. Specially, the PO should be your first and best bet, since he should know his product. A good PO can delegate you to the correct person. After I identified all stakeholders, I usually invite them to a kick-off meeting, where I explain to the people why we are doing this and importantly, answer one question: What Application Security Verification Levels this project falls under. Read the chapter in the standard to get an idea of the different levels, and then it's your job to determine the correct level by asking the people. After the kick-off meeting, I grab my checklist and go to work. I work through every category and every requirement that has the level we agreed on in the kick-off meeting and check the requirements whether they are fulfilled or not. For example, let's say we said that our product should target Level 2, as it handles customer data. I would create a copy of my checklist, fill out some information on the first sheet (customer information, product number, dates, yada yada) and go through every other category. Let's start with Architecture, Requirement 1.1.1: Verify the use of a secure software development lifecycle that addresses security in all stages of development. (C1) My job now is to verify this. So I go to the PO and tell him to hand me the project documentation of their SDLC. If they don't have a documentation, that requirement is already failed. If not, I will check it and make sure that all stages have been addressed. If not, the requirement doesn't pass, and I mark it as non-valid in the checklist. If yes, I will mark it as valid. If it's not a requirement that fits the level or is not-applicable (needs to have a good reason why) I mark the requirement as non-applicable. And I do that for all requirements in all categories. This process takes time. It usually requires a month to do such an assessment for a project. Afterward, I have an overview on how the project is doing. The checklist calculates a score, which should just serve as an indication. High score = good, low score = bad. Again, I usually also write a report about this. Meaning, I take each requirement, copy it to a Word document, and recommend what they could do better or how they could achieve the requirement. The entire report is mostly a copy and paste of my checklist anyway and (at least for me) mostly automatically generated from my checklist with some sprinkles on top. Management, for some reason, prefer a written document than an Excel file. And that's about it. The next steps depend on what the costumer wants. I either help him fix his stuff or they will try to do it themselves. And after a year or so, I come back and do the same assessments again and compare it to the old one, so you can see how stuff improved (or not). Answer from c-pid on reddit.com