Fifteen penetration testing and vulnerability assessment interview questions covering assessment types, rules of engagement, scope and authorisation, testing methodology, reconnaissance and enumeration concepts, CVSS and its limits, risk rating, exploitability, proof of concept boundaries, reporting, handling critical and out-of-scope findings, remediation and retesting, and programme maturity.

Cybersecurity Interview Questions — Part 15: Penetration Testing & Vulnerability Assessment

Fifteen penetration testing and vulnerability assessment interview questions covering assessment types, rules of engagement, scope and authorisation, testing methodology, reconnaissance and enumeration concepts, CVSS and its limits, risk rating, exploitability, proof of concept boundaries, reporting, handling critical and out-of-scope findings, remediation and retesting, and programme maturity.

Part 14 was about detecting an adversary. Part 15 is about the profession that simulates one — under contract, under scope, and under authorisation.

That last point is not a disclaimer bolted onto this part; it is the subject of it. The technical distance between a penetration tester and a criminal is close to zero. The entire difference is authorisation, scope, documentation, and professional conduct — and that is precisely what interviewers in this field probe hardest. A candidate who can describe a technique but cannot describe what they would do if they found themselves outside scope is not employable, whatever their technical ability.

So this part contains no exploitation procedures, no tooling walkthroughs, and nothing that transfers to a system you do not have written permission to test. What it contains is the professional practice: how engagements are defined, how findings are rated and communicated, where the boundaries are, and how testing connects to actually fixing things — which is the only reason any of it exists.

I'm Karanam Shrivasta. This series is written as public study notes.

— -

Cybersecurity Interview Questions — Part 15

Question 1: What is the difference between vulnerability scanning, vulnerability assessment, penetration testing, and red teaming?

Answer:

Scanning is automated identification of known issues. Assessment adds human analysis — validation, context, prioritisation, and false positive removal. Penetration testing attempts to demonstrate real exploitability and impact within an agreed scope. Red teaming is objective-based adversary emulation testing the organisation's detection and response, usually without the defenders' prior knowledge. They answer progressively different questions and cost progressively more.

Explanation:

Distinctions that matter in practice:

Breadth versus depth. Scanning covers everything shallowly; penetration testing covers a defined scope deeply. Neither substitutes for the other, and an organisation that only does annual testing has no idea what changed in the intervening eleven months.
Who is being tested. Penetration testing tests the systems. Red teaming tests the people and the processes as much as the technology, which is why the defenders are usually not told in advance and why a small number of people must be aware for safety.
Objective-based versus coverage-based. A red team engagement has a goal — reach a specific system or dataset — and stops when it succeeds, so it does not enumerate everything wrong along the way.
Purple teaming is the highest-value option for most organisations that are not yet mature, because collaboration produces detection improvements immediately rather than producing a report.

The maturity sequence worth stating: an organisation should be doing continuous scanning and remediating reliably before it commissions penetration testing, and should have functioning detection before it commissions red teaming. Buying a red team engagement for an environment with no logging produces an expensive report saying the environment has no logging.

Example / Scenario:

An organisation commissions a red team engagement and the team reaches its objective in two days without triggering a single alert. The report is short and the finding is singular: there is no detection capability to test. The engagement would have delivered far more value as a purple team exercise building detections collaboratively, and the sequencing mistake cost most of the budget.

Interview Tip:

Add the maturity sequencing point — scan and remediate reliably before you commission testing, and build detection before you commission red teaming. It answers the question and demonstrates that you think about value for money, which is exactly the judgement a consultancy or an internal security lead is hiring for.

— -

Question 2: What goes into rules of engagement, and why does each element matter?

Answer:

Scope with explicit inclusions and exclusions, testing window and permitted hours, permitted and prohibited techniques, named points of contact on both sides with out-of-hours details, escalation and stop conditions, handling of discovered sensitive data, evidence and data retention terms, communication and reporting arrangements, and formal written authorisation from someone empowered to grant it. Each element exists because an engagement without it has caused a real problem for someone.

Explanation:

Three that deserve extra emphasis:

Contactability. A test can destabilise a system unintentionally. The single most important operational element is that the tester can reach a responsible person immediately and vice versa. Engagements have caused outages that lasted hours purely because nobody could be reached.
Sensitive data handling. Testers frequently encounter real personal, financial, or health data. The rules must state that access is demonstrated rather than extracted, that only the minimum is recorded as evidence, and how that evidence is protected and destroyed.
Third-party authorisation. Cloud providers and hosted platforms have their own testing policies. The client's authorisation does not extend to infrastructure the client does not own, and testing a shared platform without the provider's permission can breach terms of service and law simultaneously.

The professional standard: if it is not written down, it is not authorised. Verbal permission from an enthusiastic engineer is not authorisation, and an experienced tester will not proceed on it.

Example / Scenario:

An engagement's rules specify a testing window outside a month-end financial close, exclude denial-of-service techniques entirely, name two contacts on each side with mobile numbers, define immediate escalation for any finding permitting access to customer data, and state that evidence of such access will be a redacted screenshot rather than an extracted dataset. Every one of those provisions is there because it prevents a specific, foreseeable problem.

Interview Tip:

Say "if it is not written down, it is not authorised" and name the out-of-hours contact requirement as the most practically important element. The first shows professional discipline; the second shows you have thought about what happens when a test goes wrong at an inconvenient time, which is the scenario the rules of engagement really exist for.

— -

Question 3: How is scope defined, and what are the risks of getting it wrong?

Answer:

Scope is defined by explicit enumeration of what may be tested — addresses, hostnames, applications, accounts, physical locations, and personnel — plus explicit exclusions, the depth permitted, and the perspective from which testing occurs. Getting it wrong risks testing systems the client does not own, causing outages in production, missing the areas that actually matter, and producing a report that gives false assurance about an environment that was never examined.

Explanation:

Dimensions of scope:

Assets. Enumerated addresses, hostnames, applications, and interfaces. Wildcards are dangerous — an entire domain may include systems hosted by third parties.
Perspective. External unauthenticated, external authenticated, internal, assumed-breach, or a specific user role. Assumed-breach testing, which starts from a foothold, usually produces far more value than spending most of the engagement trying to get in.
Knowledge level. Black box, grey box, or white box. White box testing with source code and architecture access consistently finds more in the same time; black box testing better simulates a specific scenario. The trade-off should be a deliberate choice, not a default.
Depth. Whether exploitation is permitted, whether post-exploitation and lateral movement are permitted, and how far.
Exclusions. Fragile legacy systems, third-party hosted components, production databases, and anything safety-related.
Timing. Business-critical periods excluded.

Risks of poor scoping:

Testing something the client does not own. The most serious risk, and it happens through wildcards, shared hosting, inherited address ranges, and stale DNS records pointing at infrastructure someone else now controls. Verification of ownership before testing is the tester's responsibility as well as the client's.
Operational impact. Fragile systems, industrial equipment, and medical devices can fail under ordinary scanning, which is why identification of such systems belongs in scoping rather than in discovery.
Scope too narrow to be meaningful. Testing one application while excluding its authentication provider, its API, and its infrastructure produces a report about a fraction of the actual risk.
False assurance. A clean report on a narrow scope is routinely quoted as though it covered everything. The report must state its scope prominently for exactly this reason.
Missed value. Spending three weeks on external perimeter testing for an organisation whose realistic threat is a phished credential answers the wrong question.

Example / Scenario:

During scoping, a supplied address range is checked against ownership records and two addresses are found to belong to a different organisation entirely — inherited from an old allocation and never removed from the client's documentation. Testing them would have been unauthorised access to a third party. The verification takes twenty minutes and prevents a serious incident.

Interview Tip:

Say that verifying ownership of in-scope assets is the tester's responsibility, not only the client's, and give the stale-record example. It shows that you understand professional duty rather than treating a signed document as complete protection. Then recommend assumed-breach scoping as the option that usually produces the most value per day — a practical opinion that shows engagement experience.

— -

Question 4: What constitutes valid authorisation, and what would make you refuse to begin an engagement?

Answer:

Valid authorisation is written, specific, current, and granted by someone with the actual authority to permit testing of those systems — normally an executed contract or engagement letter naming the scope, the window, and the parties. I would refuse to begin without it, or where the person authorising clearly does not own the systems, where a third-party provider's permission is required and absent, where the scope cannot be verified as owned by the client, or where I am asked to test something that would endanger safety.

Explanation:

What valid authorisation looks like:

Written and signed by a person with authority — typically an executive, a system owner, or an authorised signatory, not an enthusiastic engineer.
Specific. Named systems, named window, named permitted activities. A general statement that "security testing is approved" is not authorisation for a particular engagement.
Current. Authorisation for last year's test does not cover this year's, and an extended engagement needs an extended authorisation.
From the right party. The organisation that owns or operates the systems. A client cannot authorise testing of a supplier's platform, and a parent company may not be able to authorise testing of a subsidiary in another jurisdiction.
Third-party permissions obtained where hosting providers, SaaS vendors, or shared platforms require them.

Circumstances that would stop me starting:

No signed authorisation, or authorisation that does not cover the requested activity.
The requester cannot demonstrate authority over the systems, or asks me to test something belonging to a competitor, a former employer, or an individual.
Scope includes assets whose ownership cannot be verified.
The stated purpose suggests the results will be used improperly, or the client asks for exploitation without any intention to remediate.
Safety-critical or medical systems are in scope without appropriate specialist arrangements.
A request to conduct testing without the knowledge of a party who has a right to know, in circumstances where that would be unlawful — including monitoring of individuals.
The client requests destructive testing on production without informed sign-off from someone who understands the consequences.

The professional posture: refusal is a normal part of the job, and the reason is not caution for its own sake. Unauthorised testing is a criminal offence in most jurisdictions regardless of intent, benefit, or the absence of harm — and no employer's instruction changes that.

Example / Scenario:

A request arrives to assess a partner-facing portal. The requesting organisation uses the portal but does not operate it; it is hosted and run by the partner. Testing proceeds only after the partner provides its own written authorisation, and the scope is amended to reflect the correct owner. The delay is two weeks and it is not negotiable.

Interview Tip:

Be direct that refusal is part of the job, and give a concrete example of a situation you would decline. Interviewers ask this question specifically to check professional judgement, and the answer they want is someone who treats authorisation as the foundation of the role rather than as paperwork. Adding that unauthorised testing is an offence regardless of intent makes the point without sounding preachy.

— -

Question 5: What are the phases of a penetration testing methodology?

Answer:

Pre-engagement and scoping, information gathering, threat modelling and planning, vulnerability identification and analysis, controlled exploitation, post-exploitation within agreed limits, analysis and risk rating, reporting, and remediation support with retesting. Recognised methodologies vary in naming but share this shape, and the phases before and after the technical work are where most of the professional value lies.

Explanation:

Pre-engagement. Scoping, rules of engagement, authorisation, contacts, and success criteria. Covered in the previous questions and consistently the phase that determines whether the engagement succeeds.
Information gathering. Understanding the target — its technology, its exposure, its architecture. Conducted within scope and, in the passive phase, without touching the target.
Threat modelling and planning. What would an adversary want here, which paths are plausible, and where should limited engagement time be spent. This is what distinguishes a professional test from running a tool.
Vulnerability identification. Combining automated discovery with manual analysis, then validating to remove false positives before anything else happens.
Exploitation. Controlled demonstration that an issue is genuinely exploitable, conducted within the agreed limits, with care taken not to affect availability or integrity.
Post-exploitation. Establishing what access actually means — what data is reachable, what further access is possible — strictly within the agreed depth. This is where business impact is established, and it is the part that makes a report persuasive.
Analysis and rating. Turning findings into risk statements with context, covered later in this part.
Reporting. The deliverable, and the actual product of the engagement.
Remediation support and retesting. Answering questions, validating fixes, and confirming closure.

Two points that mark an experienced answer:

Time allocation. Inexperienced testers spend most of the engagement on identification and rush the report. The report is what the client receives, and a brilliant finding communicated badly does not get fixed.
Continuous communication. Serious findings are escalated during the engagement, not saved for the report. A critical issue held for two weeks so it can be a highlight is a professional failure.

Recognised public methodologies exist for web application testing, for general penetration testing execution, and for technical security evaluation, and being able to name that structured methodologies exist — and that you would follow one — matters more than reciting a particular one's section headings.

Example / Scenario:

An engagement allocates its two weeks deliberately: two days of gathering and planning, five days of identification and controlled exploitation, one day of post-exploitation to establish business impact, and two days of analysis and writing. A critical finding discovered on day three is escalated within the hour, and the client has remediated it before the report is delivered.

Interview Tip:

Say that serious findings are escalated immediately rather than saved for the report, and that you would allocate real time to writing. Both are professional-conduct points rather than technical ones, and both are what separate a tester a client will hire again from one they will not.

— -

Question 6: What is the difference between passive and active reconnaissance, and where are the boundaries?

Answer:

Passive reconnaissance gathers information without interacting with the target's systems — public records, search engines, certificate transparency logs, public code repositories, job advertisements, and public documents. Active reconnaissance interacts directly with the target and is therefore both detectable and, without authorisation, potentially unlawful. The boundary matters because passive activity is generally lawful and active activity requires authorisation.

Explanation:

Passive sources and what they reveal:

Domain registration and DNS records, revealing infrastructure and hosting relationships.
Certificate transparency logs, which enumerate hostnames an organisation has requested certificates for — including internal-sounding names never intended to be public.
Search engine results and cached content.
Public code repositories, which sometimes contain configuration and credentials committed accidentally.
Document metadata from published files, revealing usernames, software versions, and internal paths.
Job advertisements, which describe the technology stack in detail.
Breach data and credential exposure notifications relevant to the organisation's domains.
Public cloud and storage indexes.

Active reconnaissance interacts: resolving and connecting to hosts, port and service identification, application crawling, and technology fingerprinting. All of it is logged by the target, all of it is detectable, and all of it requires authorisation.

Boundaries a professional observes:

Passive does not mean unlimited. Collecting personal information about employees engages data protection obligations, and social engineering reconnaissance must be within scope and lawful.
Anything that touches the target is active, including a single connection to check whether a service responds.
Third-party systems are out of bounds even when they appear in your target's records — shared hosting, content delivery networks, and SaaS platforms belong to someone else.
Credential material found in public sources must not be used. Discovering an exposed credential is a finding to report; using it is unauthorised access unless the account is explicitly in scope.
Report what you find about exposure, because passive findings are frequently the most valuable part of a report — an organisation usually does not know what its public footprint reveals.

The defensive counterpart, which is worth offering: organisations reduce this exposure by monitoring their own certificate transparency records, scanning their own public repositories for secrets, stripping document metadata before publication, reviewing what job advertisements disclose, and maintaining an accurate external asset inventory.

Example / Scenario:

Passive gathering for an authorised engagement identifies, from certificate transparency logs alone, several hostnames following an internal naming convention that the client's own external inventory did not include. None are touched until they are confirmed in scope and confirmed as belonging to the client — and the inventory gap itself becomes one of the report's more valuable findings.

Interview Tip:

Give the defensive counterpart unprompted. Explaining how an organisation reduces its passive exposure turns an offensive question into a demonstration that you understand both sides, which is exactly what most hiring managers want. Also state clearly that discovering an exposed credential is a finding to report, not a credential to use — that boundary is one interviewers listen for specifically.

— -

Question 7: What is enumeration in a testing context, and what does it look like from the defender's side?

Answer:

Enumeration is the systematic identification of what exists and what is accessible — services, versions, endpoints, accounts, shares, permissions, and configuration — to build an accurate picture before deciding where to focus. From the defender's side it appears as volume and breadth anomalies: many requests for resources that do not exist, systematic identifier progression, high failure ratios, and connection patterns that do not resemble legitimate use.

Explanation:

What enumeration establishes for an authorised tester: which services are reachable and what they are, which application endpoints exist including undocumented ones, which accounts and groups exist, which shares and resources are accessible with what permissions, and which configurations deviate from expected.

What it looks like defensively — the useful half of this answer:

The common thread is that enumeration produces a high ratio of failures to successes, and that ratio is the most reliable detection signal — as noted for APIs in Part 6. Volume alone is ambiguous; volume plus failure ratio plus breadth is not.

Defensive controls that reduce what enumeration yields: uniform responses that do not reveal whether a resource or account exists, rate limiting per identity and per source, restricting directory queries to what each account needs, removing unnecessary exposed services, and unpredictable identifiers so that guessing is impractical — noting, as in Part 5, that unpredictable identifiers are a privacy measure and not a substitute for authorisation.

For the tester, the professional consideration is pacing: aggressive enumeration can destabilise fragile services, and the rules of engagement usually constrain rate for that reason rather than to avoid detection.

Example / Scenario:

During an authorised test, the client's monitoring team is asked afterwards what they observed. They saw a spike in not-found responses on one application and nothing else — which reveals that service discovery and directory enumeration produced no detection at all. That gap becomes a detection engineering item, and the engagement delivers value beyond the vulnerability list.

Interview Tip:

Answer the defensive half thoroughly and mention comparing notes with the monitoring team afterwards. Turning a penetration test into a detection assessment costs nothing and delivers a second category of finding, and proposing it shows you understand testing as a way to improve the organisation rather than as a way to produce a list.

— -

Question 8: How does CVSS work, and what are its limitations as a prioritisation tool?

Answer:

It scores a vulnerability's characteristics on defined metrics — how it is accessed, how complex exploitation is, what privileges and interaction are required, and the impact on confidentiality, integrity, and availability — producing a base score, with optional groups that adjust for exploit maturity and for the specific environment. Its limitation is that the base score describes the vulnerability in the abstract, and almost everyone uses only the base score, so it says nothing about whether the affected asset matters or whether the issue is exploitable in your environment.

Explanation:

The metric groups:

Base. Intrinsic characteristics that do not change: attack vector, complexity, privileges required, user interaction, scope change, and the three impact metrics. This is what a vulnerability database publishes.
Threat or temporal. Adjusts for real-world exploit availability and maturity, which changes over time.
Environmental. Adjusts for the specific deployment — the importance of confidentiality, integrity, and availability for that asset, and any mitigations in place.

The limitations that matter:

Almost nobody applies the environmental group, which is precisely the part that makes the score relevant to a given organisation. A base score treats a laboratory machine and a payment system identically.
Score inflation. A large proportion of published vulnerabilities score high, so the ranking discriminates poorly. A queue of thousands of high-severity items provides no prioritisation at all.
Exploitability in practice is not captured well. A vulnerability with no public exploit and no realistic path in your environment can outscore one that is being actively exploited in the wild.
Reachability is invisible. Whether the vulnerable component is actually loaded, reachable, or in a code path that executes is not part of the model, and it is frequently the deciding factor.
Chained findings score badly. Three medium issues that combine into full compromise each score medium.
Business context is entirely absent — data sensitivity, regulatory exposure, and revenue impact are not inputs.

How to use it properly: treat the base score as one input, apply environmental adjustment for the assets that matter, and combine it with active exploitation intelligence, exposure, asset criticality, and existing compensating controls — which is the risk-based approach described in Part 3. Supplementary systems exist specifically to indicate exploitation status and to guide decision-making beyond a single number, and knowing that such systems exist is worth mentioning.

Example / Scenario:

A queue of vulnerabilities is re-ranked by combining the base score with three environmental factors: whether the asset is internet-facing, whether it holds regulated data, and whether the issue is known to be actively exploited. The top ten changes almost completely, and two items previously rated medium move to the top because they are exploited in the wild on externally reachable systems.

Interview Tip:

Make the point that the environmental metrics are the part that makes the score useful and the part nobody applies. Then give the chained-findings limitation — three mediums combining into a critical — because it is a concrete failure of the model that testers encounter constantly and that most candidates never mention.

— -

Question 9: How would you rate the risk of a finding in a report when the standard score does not reflect the business reality?

Answer:

Rate it on realistic likelihood and business impact, state the score you calculated alongside it, and explain the reasoning explicitly. A rating is a communication device: its purpose is to help the client decide what to fix first, so it must reflect their environment, their data, and their exposure — with the divergence from the standard score justified in writing so the client can disagree on an informed basis.

Explanation:

Factors that should shape a rating:

Realistic likelihood. Is exploitation practical here — is the component reachable, is the precondition satisfiable, does an exploit exist, and how much skill and access does it require?
Business impact. What does successful exploitation actually mean: which data, which service, which regulatory exposure, which financial consequence.
Asset criticality, from the client's own classification where one exists.
Existing compensating controls that reduce practical risk even though the vulnerability remains.
Chaining. If several findings combine, rate the chain as its own finding at the severity the combination warrants, and cross-reference the components.
Detection likelihood. An issue that would be exploited invisibly is worse than an equivalent one that would raise an alert.

How to present a divergence honestly:

State both: the calculated score and the assigned rating, with the reason for the difference in one or two sentences.
Describe the impact in the client's terms — customer records, payment processing, service availability — not only in technical terms.
Be willing to rate something lower than its score, not only higher. A tester who inflates every finding loses credibility, and clients notice.
Give each finding a clear, actionable remediation with an indication of effort, so the rating and the cost can be weighed together.
Separate the finding from the recommendation, so that a client who disagrees with the recommendation still has the finding.

The framing worth stating: a rating is not a measurement, it is an argument. Its job is to be persuasive and honest at the same time, and it should be written so that a reasonable person could disagree with the conclusion while still accepting the facts.

Example / Scenario:

A report contains an issue scoring high in the standard model, on an isolated internal system with no sensitive data and strong compensating controls. It is rated medium, with the calculated score shown and one sentence explaining why. A separate chain of three individually low findings — an information disclosure, a weak authorisation check, and a permissive upload — is rated critical as a combination, with each component cross-referenced.

Interview Tip:

Say that you would be willing to rate a finding lower than its calculated score, and explain why that builds credibility. Every client has received a report where everything was critical, and none of them acted on it. Demonstrating that you rate to help the client prioritise, rather than to make the engagement look impressive, is a strong professional signal.

— -

Question 10: What is the difference between a vulnerability being present and being exploitable?

Answer:

Presence means a vulnerable component or configuration exists. Exploitability means an attacker can actually reach it, satisfy its preconditions, and achieve an effect in that specific environment. The difference is decided by reachability, configuration, compensating controls, required privileges and access, and whether the vulnerable code path is used at all — and it is the single largest source of wasted remediation effort when ignored.

Explanation:

Factors that separate the two:

Reachability. Is the vulnerable component network-reachable from anywhere an attacker could be? Is the vulnerable function even called by the application?
Preconditions. Many issues require authentication, a specific privilege, a specific configuration option, or user interaction. If the precondition cannot be satisfied, practical risk is much lower.
Configuration. The vulnerable feature may be disabled, or the default that makes it exploitable may have been changed.
Compensating controls. A filtering layer, network isolation, or runtime protection may block the practical path.
Platform differences. Memory protections, sandboxing, and mandatory access control can turn a theoretically exploitable issue into one that is not practical.
Exploit existence and maturity. A theoretical issue with no working exploit is a different proposition from one with reliable public tooling and confirmed exploitation in the wild.

Why this matters:

Scanners report presence, usually by version detection, and version detection is frequently wrong — backported security fixes in particular mean a version string is not a reliable indicator of vulnerability.
Dependency scanning reports every vulnerable library, including code paths the application never calls, which is why reachability analysis has become a significant topic in application security.
Remediation capacity is finite. Treating presence as equivalent to exploitability guarantees that effort goes to the wrong items.
Conversely, presence should not be dismissed. An issue that is not exploitable today becomes exploitable when a configuration changes, a control is removed, or a new access path appears — so it should be recorded and tracked rather than closed as a false positive.

The correct posture: validate before escalating, prioritise by exploitability, and still remediate presence on a longer timeline because environments change.

Example / Scenario:

A scan reports a critical vulnerability on a fleet of servers based on a version string. Validation shows the distribution had backported the fix, so the systems are not vulnerable. A separate finding — a medium-scored issue in a library the application does actively call, on an internet-facing service — is genuinely exploitable and receives the remediation effort that would otherwise have gone to the first.

Interview Tip:

Name backported patches as the classic false positive, and reachability analysis as the modern answer for dependency findings. Both are specific and current. Then add the balancing point: not exploitable today is not the same as safe, so it gets tracked rather than closed. That balance is what an interviewer wants to hear from someone who would be running a remediation queue.

— -

Question 11: What makes a good proof of concept, and what limits would you set on demonstrating a finding?

Answer:

A good proof of concept demonstrates that the issue is real and shows its impact clearly, using the minimum action necessary, with evidence that is reproducible and safe to include in a report. The limits are firm: no destruction, no modification of data, no denial of service, no extraction of real personal data beyond what is needed to prove access, and nothing beyond the agreed scope or depth.

Explanation:

What makes it good:

Sufficient to convince. A screenshot showing that an unauthorised record can be retrieved is persuasive; a description alone frequently is not, and findings without evidence get disputed and deprioritised.
Minimal. Prove access, then stop. Retrieving one record demonstrates the same flaw as retrieving a hundred thousand and carries a fraction of the risk and the legal exposure.
Reproducible. Clear enough that the client's own team can verify it and confirm the fix. This is what makes the finding actionable rather than a claim.
Safe to publish internally. Reports circulate. Evidence should be redacted so the report itself does not become a disclosure of real data or a ready-made attack tool.
Non-destructive by construction. Demonstrate write access by creating a clearly marked benign object, not by altering anything real.

The limits, and the reasoning:

No destruction or modification of real data. Ever, regardless of what the client says is acceptable, unless a specifically designed test environment exists for it.
No availability impact unless denial-of-service testing is explicitly in scope with a defined window and sign-off.
Minimal data handling. Where personal data is encountered, record redacted evidence, note what categories were accessible, and do not retain the data.
Stop at the boundary. If a path leads out of scope, stop and escalate rather than continuing to see where it goes.
No persistence left behind. Any test artefact, account, or file created is documented and removed, and the report lists everything created and whether it was cleaned up.
No weaponised tooling in the report. Describe the issue and the reproduction steps for the client's own environment; a report is not the place for a general-purpose exploit.

The underlying professional principle: the objective is to inform the client of risk, not to maximise demonstrated impact. Impressive demonstrations that cause harm damage the client, the engagement, and the profession.

Example / Scenario:

An authorised test finds that one account can retrieve another's records. The evidence is a single redacted screenshot showing one record belonging to a second test account created for the purpose, alongside the request that produced it. No real customer data is accessed, the test accounts are documented, and their removal is confirmed in the report's cleanup section.

Interview Tip:

Mention creating test accounts and test data specifically to avoid touching real records, and mention the cleanup section listing every artefact created. Both are small operational details that demonstrate you have run engagements responsibly, and the cleanup list in particular is something clients value and inexperienced testers forget entirely.

— -

Question 12: What does a good penetration test report contain, and how do you write for its different readers?

Answer:

An executive summary in business language, the scope and its limitations stated prominently, the methodology, a prioritised findings list with clear ratings, each finding written with description, impact, evidence, and specific remediation, an assessment of overall posture including what worked well, and appendices with detail. Write it layered so an executive, an engineer, and a risk owner each find what they need without reading the others' sections.

Explanation:

Structure and audience:

Writing principles:

State scope limitations prominently. Reports are quoted out of context for years. A clean result on a narrow scope must not be readable as a clean result overall.
Impact in business terms. "An unauthenticated user can retrieve any customer's order history, including name and address" lands; a technical classification does not.
Remediation that is specific and actionable. Not "implement input validation" but which endpoint, which parameter, which control, and what effort is involved.
Group by root cause. Twenty instances of one underlying problem is one finding with twenty locations, not twenty findings — and that framing produces a structural fix instead of twenty tickets.
Include what worked. It is honest, it builds trust, and it prevents the defensive reaction that makes clients dismiss the whole report.
Avoid inflation and avoid theatre. No unnecessary drama, no scores presented as more precise than they are.

Example / Scenario:

A report groups eleven individual instances of missing authorisation checks into one finding titled as a systemic authorisation weakness, lists all eleven locations, and recommends a shared authorisation layer with automated cross-account tests — the structural fix described in Part 5. The client's remediation becomes one design change rather than eleven separate patches, and the retest verifies the pattern rather than each instance.

Interview Tip:

Emphasise grouping by root cause and including positive observations. The first changes what the client actually does with the report; the second is almost universally omitted and is the fastest way to build the relationship that gets your recommendations implemented. Both show that you measure your work by whether things got fixed, not by how many findings you produced.

— -

Question 13: You discover something critical mid-engagement, or realise you have gone outside scope. What do you do?

Answer:

For a critical finding: stop expanding on it, preserve the evidence, and notify the agreed contact immediately through the agreed channel, then follow their direction on whether to continue. For going out of scope: stop immediately, do not investigate further, document exactly what happened and what was touched, notify the client contact and your own management at once, and follow the incident process. In both cases, immediate disclosure is the only acceptable course.

Explanation:

A critical finding during testing:

Escalate immediately rather than saving it for the report. The rules of engagement should define what qualifies and who is notified.
Stop expanding the finding beyond what is needed to establish that it is real and what its impact is. Confirming that customer data is reachable does not require enumerating it.
Preserve evidence carefully and minimally.
If there are signs the issue has already been exploited by someone else — unexpected artefacts, accounts, or persistence — stop testing entirely and tell the client immediately, because this is now their incident and continued testing will contaminate it. This is the scenario interviewers most want to hear addressed.
Follow the client's decision on whether testing continues, and record it.

Going out of scope:

Stop the moment you realise. Do not continue to determine how far it goes.
Record precisely what was done, when, and what was touched — times, actions, and systems.
Notify the client contact and your own management immediately. Concealment turns a mistake into misconduct.
If a third party's systems were affected, the client and your management determine notification; you do not contact them unilaterally.
Cooperate fully with whatever follows, including preserving your own logs.
Afterwards, address the cause — usually a scoping or verification gap such as an inherited address range or a shared hosting environment.

The professional framing to state plainly: mistakes happen, and the profession's tolerance for them depends entirely on immediate, complete disclosure. Concealing an out-of-scope action is career-ending and potentially criminal, while reporting one promptly is a recoverable professional error.

Example / Scenario:

During an authorised test a system responds in a way indicating a prior compromise — an unexpected account and an unfamiliar scheduled task. Testing halts immediately, the finding is reported to the client contact within minutes by telephone rather than by email, and the tester provides a precise log of every action taken on that host so the client's responders can distinguish testing activity from adversary activity — the point made in Part 13.

Interview Tip:

Cover the prior-compromise scenario explicitly, including handing over your own action log so responders can separate your activity from the adversary's. It is the specific, practical thing that makes the difference during the client's subsequent investigation, and very few candidates think of it. Then be unambiguous that concealment is never an option.

— -

Question 14: How should remediation and retesting work after an assessment?

Answer:

Findings are tracked as owned items with agreed timelines based on risk, remediation is verified by retesting rather than accepted on assertion, retesting checks the underlying cause rather than the specific reproduction path, findings that will not be fixed are formally accepted as risk with an owner and a review date, and systemic issues are addressed structurally so the same class does not reappear in the next assessment.

Explanation:

A working process:

Track findings as items with owners and dates, in the same system the organisation uses for other work, not in a spreadsheet attached to a report. A finding without an owner is a finding that will still be open next year.
Set timelines by risk tier, defined in advance as a policy so that each remediation is not negotiated individually.
Provide remediation support. The tester answering questions during fixing produces better fixes than a report alone.
Retest properly. Verify the underlying issue is resolved, not merely that the exact reproduction step now fails. A filter blocking the specific input used in the proof of concept is not a fix, and testing only the original path will pass it.
Check for regression and for the same pattern elsewhere. If one endpoint had the flaw, retesting should sample others.
Formal risk acceptance where something will not be fixed: documented, with a named accepting owner at an appropriate level, a stated compensating control, and a review date. Silent non-remediation is the alternative, and it is far worse.
Close the loop with the retest report, so there is a record of what was verified and when.
Feed themes back. If the same class of finding appears in successive assessments, the problem is a process or design one, and the response should be a structural change — secure defaults, a shared component, a pipeline gate — rather than another round of individual fixes.

Two organisational points: remediation timelines that are never met should be recalibrated rather than repeatedly missed, because a policy nobody complies with provides no assurance; and metrics should track time to remediate by risk tier and compliance with the agreed timelines, per the discussion in Part 3.

Example / Scenario:

A retest verifies the systemic authorisation finding by testing four endpoints, including two that were not in the original report. Three pass. The fourth fails, because the shared authorisation layer was applied to the endpoints named in the report rather than to the pattern. The retest therefore catches an incomplete fix that a narrow verification would have missed.

Interview Tip:

Say that retesting must verify the underlying cause and sample beyond the specific instances reported, and give the reason: a fix applied only to the named locations is extremely common and looks identical to a real fix if you only test what you originally found. That single practice is what makes retesting worth doing.

— -

Question 15: How would you build or mature an organisation's vulnerability management and testing programme?

Answer:

Start with asset inventory and continuous discovery, add reliable scanning with validated results, establish risk-based prioritisation and remediation timelines with real ownership, then layer targeted penetration testing where depth is needed, then detection-focused exercises once response capability exists. Measure remediation performance rather than finding counts, and address recurring classes structurally rather than repeatedly.

Explanation:

A maturity progression, in the order that actually works:

Asset inventory and discovery. You cannot manage vulnerabilities on assets you do not know about, and unknown internet-facing assets are a leading cause of incidents. Continuous external discovery matters as much as internal.
Continuous scanning with credentialed access where possible, since unauthenticated scanning produces a much weaker and more error-prone picture.
Validation and false positive management, so that the queue is credible. A queue people do not trust is a queue people ignore.
Risk-based prioritisation combining severity, exploitation status, exposure, asset criticality, and compensating controls, as in Part 3.
Ownership and timelines by risk tier, tracked in the organisation's normal work management system with executive visibility on breaches of timeline.
Remediation capability. Frequently the real bottleneck is not identification but patching capacity, change windows, and application compatibility — and improving that is often the highest-value investment in the whole programme.
Targeted penetration testing for depth on the systems that matter, informed by threat modelling rather than scheduled uniformly.
Purple teaming, then red teaming, once detection exists to be tested.
Structural response to recurring classes — secure defaults, shared components, pipeline gates, and design review, per the approach in Parts 5, 6 and 9.

Metrics that drive the right behaviour: mean time to remediate by risk tier, percentage of remediations completed within their timeline, age of the oldest unremediated critical item, scanning and asset coverage, and recurrence rate of previously remediated classes. Total open finding count is a poor metric because it rewards not looking.

The honest framing for leadership: the objective is not zero vulnerabilities, which is unachievable. It is a reliable, measurable process that closes the ones that matter quickly and can demonstrate that it does.

Example / Scenario:

A programme review finds that the organisation scans well and remediates slowly, with the bottleneck in change approval rather than in engineering. The improvement effort goes into a pre-approved standard change path for security patching rather than into better scanning — and the mean time to remediate falls substantially without a single new tool.

Interview Tip:

Identify remediation capacity as the usual bottleneck rather than identification. Most organisations have far more findings than they can fix, so buying better detection of findings makes the problem worse. Saying "I would measure where the time actually goes before adding another scanner" demonstrates the kind of judgement that distinguishes someone who would run a programme from someone who would run a tool.

— -

Conclusion

Part 15 covered a discipline where the technical skills are the smaller half of the job. Authorisation, scope, conduct, and communication are what make offensive security a profession rather than an activity, and they are what interviewers in this field weigh most heavily.

The patterns worth carrying forward:

If it is not written down, it is not authorised — and verifying that in-scope assets belong to the client is the tester's responsibility too.
Escalate serious findings immediately. A critical issue held back for the report is a professional failure.
Presence is not exploitability, and exploitability is what should drive remediation order.
Group findings by root cause. Twenty instances of one problem is one design fix, not twenty tickets.
The measure of an engagement is what got fixed, not how many findings were produced.

To prepare with this part: build a lab of deliberately vulnerable applications on hardware you own, and then write a report about what you find — properly, with an executive summary, ratings you can justify, and remediation advice. Almost everyone practises the testing and almost nobody practises the writing, and the writing is what you will be paid for.

Everything in this part assumes explicit written authorisation. Practise only on systems you own, on deliberately vulnerable applications you have installed yourself in an isolated environment, on CTF platforms within their rules, or under a documented engagement. Unauthorised testing is a criminal offence in most jurisdictions regardless of intent, and no curiosity, employment, or good outcome changes that.

Part 16 moves the same concerns into the delivery pipeline — DevSecOps and application security, covering secure development lifecycle, static and dynamic analysis, dependency and container scanning, secret detection, infrastructure-as-code security, CI/CD pipeline protection, software bills of materials, security gates, and supply-chain security.

⚠️ Ethical & Legal Disclaimer

This article is published strictly for educational purposes and for cybersecurity interview preparation. It is study material. It is not an operational guide, a testing authorisation, or a substitute for professional, legal, or compliance advice.

Cybersecurity knowledge carries responsibility. Everything described here must be applied ethically and lawfully. Security testing of any kind — scanning, enumeration, exploitation, credential testing, configuration review, or traffic capture — must be performed only against systems, networks, applications, accounts, devices, or environments that you personally own, or for which you hold explicit, documented, and current authorisation from the owner. Purpose-built laboratories, CTF platforms, sandboxes, and training ranges are acceptable environments when you are permitted to use them and you stay inside their stated scope.

Nothing in this article may be used for any of the following, and none of it is endorsed by the author:

Unauthorised access to any system, account, network, or device.
Unauthorised scanning, enumeration, reconnaissance, or traffic interception.
Credential theft, credential harvesting, or the use of credentials you were not issued.
Development, distribution, or deployment of malware or ransomware.
Unauthorised exploitation, privilege escalation, or lateral movement.
Data theft, data exfiltration, or unauthorised disclosure of information.
Surveillance or monitoring of individuals without a lawful basis and appropriate consent.
Service disruption of any kind, including denial-of-service and distributed denial-of-service activity.
Bypassing security controls, authentication, or security products for unauthorised purposes. All offensive concepts referenced in this series are presented from a defensive, detection, and mitigation perspective. Explanations deliberately stop short of operational attack procedures, weaponised code, and step-by-step exploitation instructions. Every example is fictional, defensive, educational, or set in an authorised laboratory scenario, and every identifier used is a documentation-reserved placeholder rather than a real address, host, domain, organisation, account, or person.

Readers are solely responsible for complying with all applicable laws, regulations, organisational policies, employment agreements, client contracts, and terms of service in their own jurisdiction and in the jurisdiction of any system they interact with. This article does not grant permission to test, access, or interact with any system, and it confers no legal protection, defence, or authorisation of any kind. If you do not have written permission, you do not have permission.

The author does not endorse, encourage, or accept responsibility for any malicious, unethical, or unlawful use of the information presented here.

About the Author

Karanam Shrivasta is a cybersecurity learner who enjoys studying cybersecurity concepts and sharing educational interview-preparation content.

This series is written as public study notes. Corrections and additional perspectives are genuinely welcome in the responses.

Author: Karanam Shrivasta

LinkedIn: https://www.linkedin.com/in/karanam-shrivasta/

GitHub: https://github.com/mrshrivasta

Publishing Metadata

SEO Title:

Cybersecurity Interview Questions — Part 15: Penetration Testing & Vulnerability Assessment (15 Questions and Answers)

SEO Description:

15 penetration testing and vulnerability assessment interview questions and answers covering scanning versus assessment versus penetration testing versus red teaming, rules of engagement, scope and authorisation, testing methodology, reconnaissance and enumeration, CVSS limitations, risk rating, exploitability versus presence, proof of concept boundaries, reporting, handling critical and out-of-scope findings, retesting, and programme maturity.

Primary Keyword:

penetration testing interview questions

Secondary Keywords:

vulnerability assessment interview questions
penetration testing interview questions and answers
rules of engagement penetration test
CVSS interview questions
pentest report interview questions
red team interview questions
vulnerability management interview questions
cybersecurity interview questions and answers
ethical hacking interview questions
security testing scope and authorisation

Suggested Medium Topics (5):

Cybersecurity
Penetration Testing
Ethical Hacking
Information Security
Interview Questions

Suggested Canonical Keywords:

cybersecurity interview questions part 15
penetration testing and vulnerability assessment interview questions
rules of engagement checklist
penetration test scope definition
cvss limitations prioritisation
vulnerability presence vs exploitability
penetration test report structure
out of scope handling penetration test
remediation and retesting process
vulnerability management programme maturity

LinkedIn Promotional Post

The technical distance between a penetration tester and a criminal is close to zero. The entire difference is authorisation, scope, documentation, and conduct — which is exactly what interviewers in this field probe hardest. ⚖️

Cybersecurity Interview Questions — Part 15 is live: Penetration Testing & Vulnerability Assessment.

No exploitation procedures, no tooling walkthroughs. The professional practice instead:

→ What actually constitutes valid authorisation, and what would make you refuse to start?

→ Why is verifying that in-scope assets belong to the client the tester's responsibility too?

→ Why do the environmental CVSS metrics matter most — and why does nobody apply them?

→ What is the difference between a vulnerability being present and being exploitable?

→ You realise mid-test that you have gone out of scope, or that the system was already compromised. What now?

Plus scanning vs assessment vs pentest vs red team and the right maturity order, rules of engagement element by element, methodology phases, passive vs active reconnaissance boundaries, what enumeration looks like to the defenders, rating findings the client can act on, proof of concept limits, report writing for three different audiences, and how remediation and retesting should actually work.

15 questions. Each with a direct answer, an explanation, an authorised-engagement scenario, and one interview tip.

Written as study notes, shared in case they help someone else preparing.

What is the professional-conduct lesson you would give a new tester? Comments are open.

#CyberSecurity #PenetrationTesting #EthicalHacking #InfoSec #CyberSecurityInterview #RedTeam #VulnerabilityManagement #OffSec #InterviewPreparation #CyberSecurityCareer

Contents

Cybersecurity Interview Questions — Part 15: Penetration Testing & Vulnerability Assessment

Cybersecurity Interview Questions — Part 15

Question 1: What is the difference between vulnerability scanning, vulnerability assessment, penetration testing, and red teaming?

Question 2: What goes into rules of engagement, and why does each element matter?

Question 3: How is scope defined, and what are the risks of getting it wrong?

Question 4: What constitutes valid authorisation, and what would make you refuse to begin an engagement?

Question 5: What are the phases of a penetration testing methodology?

Question 6: What is the difference between passive and active reconnaissance, and where are the boundaries?

Question 7: What is enumeration in a testing context, and what does it look like from the defender's side?

Question 8: How does CVSS work, and what are its limitations as a prioritisation tool?

Question 9: How would you rate the risk of a finding in a report when the standard score does not reflect the business reality?

Question 10: What is the difference between a vulnerability being present and being exploitable?

Question 11: What makes a good proof of concept, and what limits would you set on demonstrating a finding?

Question 12: What does a good penetration test report contain, and how do you write for its different readers?

Question 13: You discover something critical mid-engagement, or realise you have gone outside scope. What do you do?

Question 14: How should remediation and retesting work after an assessment?

Question 15: How would you build or mature an organisation's vulnerability management and testing programme?

Conclusion

⚠️ Ethical & Legal Disclaimer

About the Author

Publishing Metadata

LinkedIn Promotional Post