# VAPT interview answers that lock scope first Source: https://ai.techclick.in/blog_vapt_interview Markdown: https://ai.techclick.in/blog_vapt_interview.md Publisher: Techclick Infosec Pvt Ltd VAPT interview questions and answers (2026): eight production scenarios on scope, NIST 800-115 Rules of Engagement, OWASP Top 10 vs WSTG, recon vs exploit, report structure, and CVSS-plus-business risk rating — plus a scored quiz. Say this out loud Nothing is in scope unless it is written. The RoE is the legal and safety boundary — authorized IPs, the exclude list, windows, banned techniques, emergency contacts, data handling, and who signs. Discovery finds possible weaknesses. Attack confirms them. A scanner line is not a finding. OWASP Top 10 names the risk class; WSTG and ASVS tell me what to test. I rate with a CVSS vector, then I add the client’s business impact. I do not dump production PII to prove I can. ## 1. Ticket hook — Slack said “also scan payroll” The SOW is three hostnames: www.example.com , api.example.com , admin.example.com . The RoE exclude list names the payroll VPN and a third-party payment processor. Day two, a manager DMs “we own 203.0.113.0/24, add it.” The junior’s scan already returned a Critical on 203.0.113.40 — an IP WHOIS shows is a hosting neighbor, not the client. That is the interview. NIST SP 800-115 §5.2.2 is explicit: if you are given authorized IPs, verify that public addresses are under the organization’s purview before testing begins. Appendix B of the same guide requires an exclude list and a signed RoE. A Slack message is not a signature. Hero · who talks to whom Notice: the RoE sits between the tester and the targets. In-scope hosts are authorized. The faded box is the exclude list. You do not route around the document. Hard words, once Scope — the written in-list (hosts, apps, CIDRs, accounts) plus the exclude list. Rules of Engagement (RoE) — the signed assessment plan: what is authorized, what is banned, when, who to call, how data is handled. Discovery — information gathering, scanning, and vulnerability analysis (possible issues). Attack / exploit — attempting to confirm a possible issue; a successful exploit is a verified finding. PoC — the smallest reproducible evidence that the issue is real. CVSS Base — intrinsic technical severity, 0.0–10.0, published with a vector string. Environmental score — that same issue, re-weighted for this client’s CIA requirements. ## 2. Mental model: four stations of an engagement Interviewers mix legal, method, exploit, and reporting on purpose. Keep them on different stations. A WSTG test case is not a Top 10 label. A Nessus plugin is not a finding. A CVSS 9.8 on a lab box is not automatically the first slide in the CISO pack. #### What the standard owns NIST SP 800-115 owns the four-stage pentest loop and the RoE template. OWASP owns the risk list (Top 10) and the test cases (WSTG). FIRST owns the CVSS equations. You do not invent a fifth stage called “the junior already scanned it.” #### What the tester owns Which station you are on, the written boundary, the decision to stop at discovery or proceed to attack, the evidence you will attach, and the sentence that turns a score into a business risk. Path · four stations Notice: NIST Figure 5-1 is Planning → Discovery → Attack → Reporting, with a feedback loop from Attack back to Discovery. Reporting runs in parallel — logs and status notes start on day one, not the night before delivery. ### VA is breadth. PT is confirmation. NIST groups techniques in three buckets: review (docs, logs, rulesets), target identification and analysis (discovery, port/service ID, vulnerability scanning), and target vulnerability validation (password cracking, penetration testing, social engineering). A vulnerability assessment lives mostly in the middle bucket. A penetration test adds the third — it exploits to confirm. VAPT, as clients use the word, is usually a scan-plus-manual-validation engagement. Do not let the interviewer treat the acronym as a standard. Treat it as a delivery mix, then name which NIST bucket you are in. ## 3. Decision flow: in-scope before exploit Flowchart first. You do not fire Metasploit because a plugin is red. You name the asset, check the in-list and the exclude list, check the banned-technique line, then decide: stay in discovery, or enter attack with a stop condition. Flow 1 · in-scope before exploit VAPT interview decision: classify the asset, check RoE, then discover or attack - New target host / CIDR / app On the in-list? and not excluded Technique allowed? window · DoS · creds Proceed log timestamp + tool Planning RoE · SOW · signatures NIST Appendix B Discovery recon + vuln analysis possible, not proven Attack smallest confirming PoC then loop to discovery Reporting risk rating + fix path runs in parallel Written + owned? WHOIS / RoE / exclude YES Test inside the window log tool · IP · command NO / UNCLEAR Stop. Amend RoE. do not scan the extra /24 A scanner flags suspects. An exploit convicts them. NIST §5.2.1: scanners check possible existence. The attack phase exploits to confirm. If exploit is banned, report as unverified with the plugin ID and the reason you stopped. Critical access during attack → notify the RoE contact immediately. Do not wait for the final PDF. Read left → right, then down. Diamond = written ownership. A Slack “we own it” is not WHOIS and is not a signature. Decision · two paths Path A is stay in discovery — log the possible issue, do not exploit. Path B is enter attack — smallest confirming PoC, then loop back to discovery. Caption in this lesson; do not invent labels from the picture. ## 4. How to choose the method Use the official words in the room. OWASP itself says the Top 10 is primarily an awareness document, and that using it as a pentest standard is the bare minimum . For a verifiable standard they point you at ASVS . For how to test a web app, the working document is the Web Security Testing Guide . Question First method Why this, not that Proof you name Is this host ours to touch? RoE in-list + exclude list + WHOIS / inventory A Slack ping is not authorization. NIST §5.2.2: verify public addresses before testing. Signed RoE page + owner record What may we do to it? RoE “testing execution” + banned list DoS, cred stuffing, production data dumps, and off-hours windows live here — not in the sales deck. Allowable / unallowable paragraph Client wants “OWASP coverage” WSTG test cases, mapped to Top 10 labels Top 10 is a risk list. A04 Insecure Design is mostly not a scanner check. OWASP says so. WSTG-* IDs in the method appendix Scanner said Critical Stay in discovery until you attempt (or formally skip) exploit Version-match plugins are suspects. A confirming request/response is a finding. PoC request + impact note, or “unverified” How bad is it for this client? CVSS Base vector + Environmental / business overlay Base is intrinsic. FIRST tells consumers to add environment. A 4.3 on the payment API can outrank a 9.8 on a lab VM. Vector string + CIA requirement VA or PT? Ask what question the buyer needs answered VA = possible weaknesses, broad, repeatable. PT = confirmed impact, narrower, human-driven. Which NIST bucket you will execute Common miss Reciting the 2021 Top 10 in order and calling that a methodology. OWASP’s own “How to use the Top 10 as a standard” page: it is the bare minimum for penetration testing, and they discourage claims of full Top 10 coverage because several risks (notably A04) are not comprehensively testable. Say the list, then name the WSTG cases and the ASVS level you actually ran. ## 5. Do: lock RoE → prove → report Side A is legal and logistics. Side B is execution inside the written box. Side C is the close-out a hiring manager wants to hear. Primary source for this block: NIST SP 800-115 Appendix B (RoE template), §5.2.1 (four-stage methodology), and §7.3–7.4 (analysis and data handling). ### Side A — Lock the boundary #### Write the in-list and the exclude list Hostnames, CIDRs, URLs, test accounts, and third-party systems. NIST Appendix B §4: identify systems not authorized for testing — the exclude list. Verify public IPs are actually the client’s before a packet leaves your box. - #### Write stop conditions and contacts Appendix B §3.2: criteria for halting, course of action if a procedure harms the network, and the incident-response call tree. Name the person who gets the 2 a.m. call if you land Domain Admin. NIST §7.3: a critical exploit is notified immediately, not buried in Friday’s PDF. - #### Get the signatures Appendix B §7: at minimum the test team leader and the organization’s senior security management (CSO / CISO / CIO). A project manager emoji-reacting in Slack is not that page. ### Side B — Execute inside the box (training mock) Primary source: NIST §5.2.1 discovery (info gathering + vulnerability analysis) then attack (confirm). Every action is timestamped. §7.2: record test type, tool, commands, and the IP of the testing equipment. roe://engagement/example-corp-2026-q3 · finding F-014 · training mock Training mock · not live RoE v1.2 signed · window 22:00–06:00 IST · DoS banned · no prod PII export ### F-014 · Broken access control (IDOR) Asset api.example.com · IN-LIST WSTG WSTG-ATHZ-04 · map A01:2021 PoC GET /v1/invoices/8841 as user-b → 200, peer invoice Data two invoice IDs only · no bulk export CVSS 3.1 AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N · Base 7.1 High Env overlay CR:H (invoices = customer financials) → treat as first-week fix Training mock · not live. Notice the fields: in-list, WSTG ID, smallest PoC, data-handling limit, CVSS vector, then the environmental overlay. That is the finding card, not a scanner CSV. Side B evidence you quote — not a payload cookbook RoE: in-list / exclude / window / banned / contacts / signatures Ownership: WHOIS or asset inventory for every public IP Discovery log: timestamp, tool, tester IP, command Finding card: asset, WSTG-ID, request/response (redacted), CVSS vector If critical: notify RoE contact now; do not wait for the report ### Side C — Close without becoming the incident - #### Handle data as the RoE wrote it NIST Appendix B §5.3 and §7.4: gathering, storing, transmitting, and destroying test data is written in advance. Vulnerability data is sensitive. Screenshots get redacted. Production dumps do not leave the engagement folder. - #### Write the report the CISO can act on NIST §5.2.1: the closing report describes identified vulnerabilities, presents a risk rating, and gives mitigation guidance. Structure: executive summary, scope and method, findings (one card each), risk table, remediation, appendix of evidence. Daily status notes already exist because reporting ran in parallel. - #### Rate, then overlay FIRST CVSS 3.1: publish the Base score and the vector. Qualitative bands: None 0.0, Low 0.1–3.9, Medium 4.0–6.9, High 7.0–8.9, Critical 9.0–10.0. Then say what the Environmental / business overlay does for this asset. Do not relabel a 4.3 as Critical without saying you left the Base equation. ## 6. Runtime path: NIST four stages After kickoff the engagement is a loop, not a waterfall. Discovery has two parts: information gathering / scanning, then vulnerability analysis (scanner databases plus the tester’s own knowledge). Attack confirms. A successful exploit often reveals a new host or privilege — that is the feedback arrow back into discovery. Reporting is not a fifth weekend activity; NIST draws it alongside all three other stages. Flow 2 · NIST SP 800-115 Figure 5-1 NIST four-stage penetration testing methodology with attack-to-discovery feedback and parallel reporting - Planning RoE / SOW / roles Discovery recon + vuln analysis Attack confirm / escalate new host / priv → back Reporting (parallel) ROE in planning · written logs in discovery/attack · closing report = vulns + risk rating + mitigation PTES (practitioner playbook) 7 phases: pre-engage → intel → threat model → vuln analysis → exploit → post → report OWASP (web test cases) Top 10 labels the risk · WSTG IDs the test ASVS is the verifiable standard Read the top row as NIST. The red arrow is the official feedback loop. The bottom row is what you cite when the interviewer asks “PTES or OWASP?” — both, for different jobs. Proof · cockpit Notice: proof is a finding card a reviewer can replay — asset, method ID, redacted request, vector, overlay — not a green dashboard. Illegible screen text is mood; you still quote the real fields in the runbook. ## 7. Eight interview scenarios ### Q1 · Scenario — Slack said add the payroll /24 SOW lists three hostnames. Mid-engagement the app owner DMs “also scan 203.0.113.0/24, we own it.” A junior’s scanner is already running. First move? Direct answer Stop the extra scan. Confirm ownership (WHOIS / inventory) and get a written RoE amendment with signatures before another packet. NIST §5.2.2: verify public addresses are under the organization’s purview before testing. Appendix B requires an exclude list and a signature page. A DM is neither. Why production cares That /24 is how testers accidentally hit a hosting neighbor, a payment processor, or the payroll VPN the original exclude list was written to protect. That is a legal event, not extra credit. Weak answer / trap “The client asked, so it’s in scope” or “we’ll add it to the report later.” Authorization is written and signed, then you test. #### Strong framing (say this) I halt, I prove ownership, I amend the RoE, I restart only the authorized range. I do not launder an out-of-scope scan through a Friday email. #### Evidence to name Signed RoE in-list and exclude list; WHOIS / asset owner; NIST SP 800-115 §5.2.2 and Appendix B §§4 and 7. ### Q2 · Evidence — what must be in the RoE The interviewer slides a one-page “authorization letter” that only says “Company X permits Techclick to test our website.” What is missing if you are answering from NIST Appendix B? Direct answer Almost everything Appendix B lists: introduction and purpose, scope, test equipment and authorized tools, communication cadence, incident handling and halt criteria, the target list and exclude list, allowable / unallowable technical activities, data-handling rules, reporting cadence and contents, and a signature page for the test lead and senior security management. Why production cares When the site goes 500 during a scan, the RoE is the document that says who you call, whether you stop, and that your tester IP was authorized. Without it you are an unattributed attacker in the SOC queue. Weak answer / trap “The SOW is enough” or listing only “IP ranges and dates.” Dates without halt criteria and data handling are how PII ends up in a personal Drive folder. #### Strong framing (say this) I treat Appendix B as the checklist. If a section is blank, we do not start discovery. #### Evidence to name NIST SP 800-115 Appendix B §§1–7 — especially §3.2 incident handling, §4 exclude list, §5.2 technical components, §5.3 data handling, §7 signatures. ### Q3 · Compare — OWASP Top 10 versus WSTG A hiring manager says “we need a full OWASP Top 10 pentest.” How do you answer without sounding like you refused the work? Direct answer The Top 10 is an awareness / risk taxonomy. OWASP’s own page: if you use it as a testing standard it is the bare minimum and just a starting point , and they discourage claims of full Top 10 coverage because several risks (A04 Insecure Design; effective logging and monitoring) are not comprehensively testable by a pentest. The working method is WSTG test cases (IDs such as WSTG-ATHZ-04 , WSTG-INPV-05 ) mapped back to Top 10 labels. For a verifiable standard, point at ASVS. Why production cares A “Top 10 certified clean” stamp is a false close. Design flaws and detection gaps survive a scanner-shaped test plan. Weak answer / trap Reciting A01–A10 from memory as if that were the runbook, or claiming your scanner “covers the Top 10.” #### Strong framing (say this) Top 10 names the conversation. WSTG drives the cases. ASVS is what I put in the method appendix when they need a standard, not a poster. #### Evidence to name OWASP Top 10:2021 list; “How to use the OWASP Top 10 as a standard”; WSTG scenario IDs; ASVS. ### Q4 · Troubleshoot — scanner Critical, exploit fails Nessus reports CVE-shaped Critical on api.example.com from a version banner. Your confirming request does not land. The PM wants it in the Critical slide anyway. What do you do first? Direct answer Stay honest about the station you are on. NIST §5.2.1: scanners check possible existence; the attack phase exploits to confirm. §7.3: a primary analysis goal is to identify false positives — manually, or with a second tool (knowing two tools can share the same false positive). Report it as unverified / informational with the plugin ID, the banner, and the failed confirm — or drop it. Do not promote it to Critical to match the scanner PDF. Why production cares Back-ported patches keep old version strings. A Critical that is not exploitable burns the patching week and trains the client to ignore the next report. Weak answer / trap “The scanner is industry standard so the finding stands” or deleting it silently so the count looks clean. #### Strong framing (say this) Possible versus confirmed. I will not launder a banner match into a Critical. I will show the failed confirm so they can still patch if they want defense in depth. #### Evidence to name NIST SP 800-115 §5.2.1 (scanner vs attack) and §7.3 (false positives, NVD/CVSS as a reference — not as automatic severity). ### Q5 · Architecture — draw the engagement Whiteboard. “Draw your methodology.” They have heard of PTES and of OWASP. What do you draw first, and what do you say about the red arrow? Direct answer Draw NIST Figure 5-1: Planning → Discovery → Attack → Reporting. Discovery splits into info gathering / scanning and vulnerability analysis. Attack confirms and may escalate. The red arrow is the official feedback loop from Attack back to Discovery when a new host or privilege appears. Reporting is drawn under all three — RoE in planning, written logs during test, closing report at the end. Then overlay: PTES is the seven-phase practitioner playbook; OWASP WSTG is the web test-case catalog. Why production cares Without the loop, testers “finish exploitation” and miss the jump host they just unlocked. Without parallel reporting, the only evidence is memory. Weak answer / trap A five-box “recon, scan, exploit, persist, report” with no authorization box and no feedback. Or claiming PTES replaced NIST. #### Strong framing (say this) NIST is the assessment spine I can defend in a regulated shop. PTES is how I talk phases with other testers. OWASP is how I test the web app on that spine. #### Evidence to name NIST SP 800-115 Figure 5-1 and §5.2.1; PTES seven phases as listed in the WSTG methodologies chapter; WSTG IDs in the method appendix. ### Q6 · Compare — client asks for “just a scan” Procurement wants a cheap VAPT. They say “run the scanner, we’ll call it a pentest for the auditor.” How do you separate VA from PT without losing the deal or lying to the auditor? Direct answer Name the NIST buckets. A vulnerability assessment is target identification and analysis — discovery, port/service ID, vulnerability scanning. A penetration test adds target vulnerability validation — you exploit to confirm impact. If they only buy a scan, the deliverable is a validated-or-explicitly-unverified vuln list, not an attack narrative. Do not title a scanner export “Penetration Test Report.” Why production cares Auditors and insurers now ask whether exploitation was in scope. A mislabeled scan is a findings-quality problem and a contracting problem. Weak answer / trap “VAPT always includes both, so any scan is a pentest” or refusing to explain the difference. #### Strong framing (say this) VA answers “what might be wrong.” PT answers “what I could actually do.” I will sell them the mix they need, and I will name it correctly on the cover. #### Evidence to name NIST SP 800-115 §2.2 technique groups; §5.2.1 scanner-versus-attack sentence; the report title matching the SOW. ### Q7 · Evidence — the report a CISO will fund You have 40 scanner rows and three confirmed issues, including an IDOR on invoices. What does the closing report contain, and how do you rate the IDOR? Direct answer NIST §5.2.1: identified vulnerabilities, a risk rating, and mitigation guidance. Lead with the executive summary and the three confirmed cards. Each card: asset, WSTG/CWE, redacted PoC, CVSS 3.1 vector and qualitative band, environmental / business overlay, fix. FIRST requires the score and the vector. The 40 unverified rows go in an appendix labeled unverified, or they do not ship. For the IDOR: Base might be High (e.g. 7.1, AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N ). If invoices are a high confidentiality requirement, say the overlay and the fix window — do not silently rewrite the Base number to 9.8. Why production cares CISOs fund the first-week fix list. They ignore a 40-row CSV. A vector lets another analyst replay your math. Weak answer / trap Pasting the scanner PDF, or calling everything Critical “so they patch.” #### Strong framing (say this) Confirmed first, unverified last. Score plus vector, then the business overlay in a separate sentence. #### Evidence to name NIST §5.2.1 reporting sentence; FIRST CVSS 3.1 §5 qualitative table and §6 vector string; finding card fields from Side B. ### Q8 · Unsafe shortcut — dump prod to “prove impact” A junior lands a SQLi. The RoE bans denial of service and bulk export of personal data. They want sqlmap --dump on the customers table “for the screenshot,” and a UDP flood “to show availability impact.” What do you stop, and what is the safer path? Direct answer Stop both. The RoE’s allowable / unallowable list and data-handling section are the boundary (NIST Appendix B §§5.2–5.3). Safer PoC: one or two non-sensitive rows, or a COUNT(*) / tautology that proves read access, redacted. Availability impact is described and, if needed, tested only if the RoE explicitly allows a controlled test on a named environment. NIST §7.2: if you cause or find an incident, follow the RoE and the org’s escalation — testers stop on the involved systems while response runs. Why production cares A dump of customer PII makes the tester the incident. A flood makes the tester the outage. Neither is “good impact.” Weak answer / trap “Impact has to be dramatic or they will not patch” or copying the dump to a personal laptop because the jump box will be wiped. #### Strong framing (say this) Smallest confirming evidence. I will not become the breach. If they want a destructive test, it is a new signed line in the RoE, on a named system, with a rollback. #### Evidence to name RoE banned-technique and data-handling clauses; NIST Appendix B §5.2–5.3, §3.2 halt criteria; §7.2 operational impact and incident handling; §7.4 data handling. ## 8. Traps and proof checklist Trap What you see Safer next step Slack scope change Extra /24 in the scan queue Halt. WHOIS / inventory. Written RoE amendment + signatures Authorization letter only One sentence, no exclude list, no halt criteria Fill NIST Appendix B before discovery Top 10 as the test plan “We covered OWASP” with ten scanner plugins WSTG IDs in the method; ASVS if they need a standard Scanner Critical = finding Banner match, exploit does not land Label unverified; do not promote the score No feedback loop New host after exploit, never re-scanned Attack → Discovery arrow; test the new privilege Scan titled “pentest” Auditor asks where the exploit evidence is Name the NIST bucket on the cover; do not relabel CVSS number without a vector Nobody can replay the 7.1 FIRST: score + vector; overlay in a separate sentence --dump / DoS for the screenshot PII in the evidence zip; or an outage Smallest confirming PoC; banned techniques stay banned Proof checklist (pilot / interview close) In-list and exclude list spoken; a Slack change is not treated as authorization. - RoE sections named: halt criteria, contacts, data handling, signatures (lead + CISO/CSO/CIO). - Ownership of every public IP checked before a packet (NIST §5.2.2). - OWASP Top 10 used as labels; at least one WSTG ID named; ASVS mentioned if they asked for a standard. - Discovery versus attack named; a scanner row is not called confirmed. - Finding card: asset, method ID, redacted PoC, CVSS vector + band, business overlay, fix. ## Knowledge check Six judgment items. Each maps to a promise bullet. Check answers, then reset and re-read the traps table if you miss any. Q1 The signed RoE lists three hostnames. The client DMs “add 203.0.113.0/24, we own it.” What is the first correct move? Start the scanner on the /24 so you do not lose a day Halt any extra scan; prove ownership; amend the signed RoE before another packet Scan it but omit it from the report if WHOIS looks messy Ask sales to forward the DM to legal after the report ships Correct: b . NIST §5.2.2: verify public addresses before testing. A DM is not Appendix B. Re-read Q1 + Flow 1. Q2 A vulnerability scanner reports Critical SQL injection from a version banner. Your confirming request fails. What is true? The scanner is the finding — put it on the Critical slide Delete the row so the report stays clean It remains a possible issue until exploit (or a documented skip); do not promote an unconfirmed banner match Run a second identical scanner and average the two scores Correct: c . NIST §5.2.1: scanners check possible existence; attack confirms. §7.3: hunt false positives. Re-read Q4 + Side B. Q3 A client asks for “full OWASP Top 10 coverage” as the test plan. What is the accurate answer? Top 10 is awareness / risk taxonomy — the bare minimum for a pentest; drive cases with WSTG and use ASVS if they need a verifiable standard Top 10 replaced WSTG in 2021 and is the complete test catalog A scanner that maps plugins to A01–A10 is full coverage, including A04 Insecure Design Refuse the engagement because OWASP cannot be used in reports Correct: a . OWASP: Top 10 is primarily awareness; pentest use is bare minimum; they discourage full-coverage claims. Re-read Q3 + the choose table. Q4 Confirmed IDOR on the production invoice API scores CVSS 3.1 Base 7.1 High. The CISO’s confidentiality requirement for invoices is High. What do you do with the rating? Silently change the Base score to 9.8 so it sorts as Critical Drop the finding because 7.1 is only High Publish the number without a vector — the band is enough Publish Base 7.1 with the vector, then a separate environmental / business overlay that justifies the fix window Correct: d . FIRST: score + vector; Environmental metrics are how consumers adjust for their CIA requirements. Do not rewrite Base. Re-read Q7 + Side C. Q5 You exploit a host and suddenly have a new internal jump point. What does NIST Figure 5-1 require next? Stop the test — exploitation is the last phase Follow the Attack → Discovery feedback loop and treat the new access as a new discovery target (still inside RoE) Skip reporting until every host in the company is owned Move straight to the closing PDF; the loop is a PTES-only idea Correct: b . NIST §5.2.1 / Figure 5-1: successful attack often returns you to discovery. Stay inside the RoE. Re-read Flow 2 + Q5. Q6 The RoE bans bulk export of personal data and denial of service. A junior wants sqlmap --dump on customers and a UDP flood for the screenshot. What is correct? Dump the table — impact must be dramatic or they will not patch Flood first, dump second, then file the incident as the client’s problem Refuse both; take the smallest confirming PoC (one/two redacted rows or a count) and describe availability unless a destructive test is newly signed Copy the dump to a personal laptop so the jump box wipe does not lose evidence Correct: c . Appendix B data handling and banned techniques win. You do not become the incident. Re-read Q8 + traps. Check answers Reset ## Sources - NIST SP 800-115 — Technical Guide to Information Security Testing and Assessment (CSRC landing page) - NIST SP 800-115 PDF — Figure 5-1 four-stage methodology; §5.2.1 discovery vs attack vs reporting; §5.2.2 verify authorized public IPs; §7.2–7.4 incidents, analysis, data handling; Appendix B RoE template - OWASP Top 10:2021 — official risk list A01–A10 (awareness document) - How to use the OWASP Top 10 as a standard — pentest use is bare minimum; ASVS is the verifiable standard; no full-coverage claims - A01:2021 Broken Access Control — IDOR / force browsing examples used in the finding card - OWASP Web Security Testing Guide — test-case catalog and WSTG-* identifiers - WSTG — Penetration Testing Methodologies — PTES seven phases as cited by OWASP - OWASP ASVS — verifiable application security standard OWASP recommends instead of Top 10-as-test-plan - FIRST CVSS v3.1 specification — Base / Temporal / Environmental; qualitative bands; score must ship with the vector Related: Burp Suite pentest interview · SOC analyst interview · Linux interview · Wireshark interview · Interview hub --- Cite this Techclick lesson with the source URL. Do not invent fees, batch dates, or job guarantees. Browse all lessons: https://ai.techclick.in/blogs AI index: https://ai.techclick.in/llms.txt